20180601 OWASP Nagoya Chapter ミーティング 第５回 OWASP Top 10 2017の読み方

1. OWASP Top 10 2017の読み方
1
2018.06.01 (Fri)
Isanori Sakanashi

2. 自己紹介
• 坂梨 功典（さかなし いさのり）
• facebook： https://www.facebook.com/isanori.sakanashi
• twitter ： @PandaTw2
• メール ： isanori.sakanashi@owasp.org
– SIベンダー系SE（インフラエンジニア）
– 登録セキスペ(登録番号: 第002084号)
– OWASP Nagoya Chapter Leader
2

3. 私から皆さんに質問です。
● OWASPって知っていますか？
● OWASP Projectって知っていますか？
● OWASP Top 10って知っていますか？
● OWASP ZAPって知っていますか？
● WEBアプリケーションのセキュリティって知っていますか？
● WEBアプリケーションのセキュア開発に興味ありますか？
3
是非OWASPの各種ドキュメントを一緒に勉強しましょう

4. 1.前書き
2.OWASP Top 10-2017へようこそ
3.リリースノート
4.次のステップ
4
Agenda

5. 1. 前書き
5
OWASP Top 10 2017

6. OWASP Top 10 2017
6
● セキュアでないソフトウェア
○ 財務、医療、防衛、エネルギーおよびその他の重要インフラを損な
います
● モダンなソフトウェア開発プロセスの急速な進歩により共通するリスク
を迅速かつ正確に発見し開発することは不可欠です
● 様々なコミュニティが、このOWASP Top 10に対して情熱があります
● いまやTop 10はアプリケーションセキュリティのデファクト・スタンダ
ードとなっています
● アプリケーションセキュリティの問題や改善提案は簡潔かつ確認できる
方法を提供します
○ 本リリースで適用
前書き

7. OWASP Top 10 2017
7
● OWASP Top 10を見る人に対して次のステップへの提案
○ 「開発者のための次のステップ」
○ 「セキュリティテスト担当者のための次のステップ」
○ CIOやCISOに適した「組織のための次のステップ」
○ アプリケーションマネージャやアプリケーションのライフサイクル
の責任を持つ人に適した「アプリケーションマネージャのための次
のステップ」
● 長期的
○ 組織が今持っている強みを活かしながら、SAMM(ソフトウェア品質
成熟度モデル)を用いてアプリケーションセキュリティプログラムを
計測し改善します
前書き

8. 2. OWASP Top 10–2017へようこそ
8
OWASP Top 10 2017

9. OWASP Top 10 2017
9
ようこそ

10. OWASP Top 10 2017
10
● メジャーアップデート
○ A8：2017-安全でないデシリアライゼーション
○ A10：2017-不十分なロギングとモニタリング
ようこそ

11. OWASP Top 10 2017
11
● 集計に使用されたデータ
■ 数多くのコミュニティのフィードバック、組織から充てめられた
数多くの広範囲なデータをもとにして作成されています。主に、
アプリケーションのセキュリティを専門とする企業から寄せられ
た40以上のデータをもとに集計しています
■ 500人以上の個々の人々による業界調査を実施しています
■ データは数百の組織の10万以上の実在するアプリケーションおよ
びAPIから集められた脆弱性にまたがるもので集計しています
ようこそ

12. OWASP Top 10 2017
12
● 主要な目的
○ 開発者、デザイナー、アーキテクト、マネージャ、組織に最も一般
的かつ最も重要なWebアプリケーションセキュリティの弱点の影響
について教育します
○ これらのリスクの高い問題のある領域を守るための基本的なテクニ
ックを提供し、現時点からどこへ進めるべきなかについてのガイダ
ンスを提供しています
ようこそ

13. OWASP Top 10 2017
13
● 将来への道筋
○ 10まででやめない
■ Webアプリケーションの全体的なセキュリティに影響を与える可能性のあ
る問題は数多く存在します
● OWASP Developer's GuideやOWASP Cheat Sheet Series参照
○ WebアプリケーションやAPIを開発するどんな人にとっても不可欠な情報
■ WebアプリケーションおよびAPIの脆弱性を効果的に見つける方法に関する
ガイダンスを提供します
● OWASP Testing Guide参照
○ 定期的に変更
■ OWASP Top 10はこれからも変化し続けます
■ アプリケーションコードの1行も変更していなくても脆弱になる可能性があ
ります
ようこそ

14. OWASP Top 10 2017
14
● 将来への道筋
○ 積極的に思考
■ 脆弱性を追いかけるのをやめ、アプリケーションセキュリティコントロール
を強力なものに確立する準備ができたら
● OWASP Proactive Controlsプロジェクトを活用します
○ 開発者がセキュリティをアプリケーションに組み込むための出発点
を提供します
● OWASP Application Security Verification Standard (ASVS)を活用します
○ 組織にとって、またアプリケーションレビュワーにとって何を検証
したら良いかを示すガイドとして提供します
ようこそ

15. OWASP Top 10 2017
15
● 将来への道筋
○ 賢くツールを活用
■ セキュリティ脆弱性は、非常に複雑で深刻なコードに埋もれていることがあ
ります
■ そのような弱点を発見して排除するための最も費用対効果の高いアプローチ
は、高度なツールを手元に備えている専門家となります
■ ツールのみに依存することは、セキュリティに関する誤った感覚をもたらし
てしまうので、お勧めしません
○ 左へ右へ、どこへでも進める
■ セキュリティをソフトウェア開発の組織全体のカルチャーにかかわる不可欠
なものとすることに集中してください
■ OWASP Software Assurance Maturity Model (SAMM)を参考にしてください
ようこそ

16. OWASP Top 10 2017
16
参考
ようこそ
要件定義 OWASP Top 10 Project
設計・開発 OWASP Proactive Controls
OWASP Application Security Verification Standard(ASVS)
OWASP Cheat Sheet Series
テスト OWASP Testing Project(OWASP Testing Guide etc…)
OWASP Offensive Web Testing Framework(OWTF)
運用・保守 OWASP ModSecurity Core Rule Set Project
OWASP AppSensor
OWASP CSRFGuard Project
OWASP Dependency Check
※OWASP World Training Tour Tokyo 2017の資料より引用

17. 3. リリースノート
17
OWASP Top 10 2017

18. OWASP Top 10 2017
18
● OWASP Top 10はここ数年の急激な変化によって大きく改版
○ リファクタリング
○ 手法を改良
○ 新しいデータ募集のプロセスを活用
○ コミュニティと協働
○ リスクを評価し直す
○ それぞれのリスクを一から書き直す
○ 一般に利用されているフレームワークや言語への参照
リリースノート

19. OWASP Top 10 2017
19
● アプリケーションの基本的な技術とアーキテクチャが大きく変化
○ 従来のモノリシックアプリケーションからnode.jsやSpring Bootで書かれたマイクロサ
ービスに置き換わっています
■ マイクロサービスには独自のセキュリティ上の課題が存在します
■ シングルページアプリケーション（SPA）やモバイルアプリケーションによって
使いまくられているAPI やRESTful Webサービスの背後に居座っています
■ コードによるアーキテクチャの前提、たとえば信頼できる発信者のような前提は
もはや有効ではありません
○ モジュール化された機能豊富なフロントエンドの開発ができるようになりました
(AngularやReactなどのJavaScriptフレームワーク)
○ サーバー側で提供されてきた機能がクライアント側の機能に移るため、それはそれで
独自のセキュリティ上の課題が発生しています
リリースノート

20. OWASP Top 10 2017
20
● データに裏付けられた新しい問題
○ A4:2017-XML 外部エンティティ参照(XXE)
■ 新しいカテゴリとして追加
■ 主にソースコード分析を行うセキュリティテストツール(SAST)から寄せられたデ
ータが根拠
■ コミュニティにより裏付けられた新しい問題
○ A8:2017-安全でないデシリアライゼーション
■ 問題のある環境ではリモートからのコード実行や機微なオブジェクト操作が可能
○ A10:2017-不十分なロギングとモニタリング
■ 機能の欠落は、不正な活動やセキュリティ違反の検知、インシデント対応、デジ
タルフォレンジックを妨げるか、あるいは大幅に遅延させる可能性
リリースノート

21. OWASP Top 10 2017
21
● 統合、引退(ただし、忘れて良いという意味ではありません)
○ A4-安全でないオブジェクト直接参照とA7-機能レベルアクセス制御の欠落
■ 「A5:2017-アクセス制御の不備」へ統合
○ A8-クロスサイトリクエストフォージェリ(CSRF)
○ A10-未検証のリダイレクトとフォワード
リリースノート

22. 4. アプリケーションセキュリティリスクについて
22
OWASP Top 10 2017

23. OWASP Top 10 2017
23
● 組織におけるリスクを判断するためにまず次のようなことを考慮する必要
○ 「脅威エージェント」
○ 「攻撃手法」
○ 「セキュリティ上の弱点」などに関する可能性を評価
● 組織に対して
○ 「技術面への影響」
○ 「ビジネス面への影響」
アプリケーションリスク

24. OWASP Top 10 2017
24
● あなたにとってのリスク
○ 最も重大なウェブアプリケーションセキュリティリスクを特定すること
○ OWASP Risk Rating Methodologyに基づいた格付手法により、発生可能性と技術面へ
の影響について評価
○ 公共の利益団体において公開情報をCMSにより管理している場合や、医療システムに
おいてセンシティブな健康記録を管理するために同じようなCMSを利用している場合
に、同じソフトウェアであっても脅威を引き起こすアクターやビジネスへの影響は大
きく異なります
アプリケーションリスク

25. OWASP Top 10 2017
25
OWASP Top 10 2017の変更点
変更点

26. 4. 次のステップ
26
OWASP Top 10 2017

27. OWASP Top 10 2017
27
● 反復可能なセキュリティプロセスと標準セキュリティ制御の確立と使用
○ 組織におけるリスクを判断するためにまず次のようなことを考慮する必要があります
■ 「脅威エージェント」、「攻撃手法」、「セキュリティ上の弱点」などに関する
可能性を評価する必要性があります
● 組織に対して
○ 「技術面への影響」
○ 「ビジネス面への影響」
開発者
次ステップ
アプリケーション
セキュリティ要件
アプリケーション
セキュリティ
アーキテクチャ
標準的な
セキュリティ制御
セキュアな開発
ライフサイクル
アプリケーション
セキュリティ教育

28. OWASP Top 10 2017
28
● 継続的なアプリケーションセキュリティテストを確立します
○ アプリケーションポートフォリオの全体において、重要と考えられることにどのよう
に焦点をあて、費用対効果の高い手法をとるべきかを考慮することを強く推奨してい
ます
○ 開発スピードを損なうことのないようセキュリティの自動化を施し、既存の開発プロ
セスを強化を実施します
○ アプリケーションポートフォリオの規模に応じたテスト、トリアージ、修復、再テス
ト、再デプロイに係る年間コストを考慮します
セキュリティテスト担当者
次ステップ
脅威モデルの理解
SDLC（ソフトウ
ェア開発ライフサ
イクル）の理解
テスト戦略
範囲と正確さの
達成
明確な結果の伝達

29. OWASP Top 10 2017
29
● 今すぐ、アプリケーションセキュリティ計画を開始しましょう
○ アプリケーションセキュリティの実装は必須事項となります
○ 増加する攻撃と規制の圧力の間で、アプリケーションとAPIを保護するための効果的な
プロセスや能力を組織において確立する必要があります
○ アプリケーションとAPIにおけるセキュリティを改良するためにアプリケーションセキ
ュリティのプログラムを組織において確立することを推奨しています
（OWASPとして）
○ アプリケーションセキュリティを実現するには、セキュリティと監査、ソフトウェア
開発、ビジネス及びエグゼクティブマネジメントを含む、組織のさまざまな部門が効
率的に連携する必要があります
■ OWASP SAMM、OWASP Application Security Guide For CISO
組織
次ステップ
はじめに
リスクベース
ポートフォリオ
アプローチ
強力な基礎の
作り上げ
セキュリティを
既存プロセスに
統合
管理可視化の提供

30. OWASP Top 10 2017
30
● アプリケーションライフサイクル全体を管理します
○ アプリケーションは、人が定期的に作成し、維持する最も複雑なシステム
○ アプリケーションにおけるITマネジメントは、アプリケーションのITライフサイクル
全体の責任を有するITスペシャリストにより実施されるべき
○ アプリケーションマネージャは、ITの観点から、要件策定からシステムの廃棄に至る
までのアプリケーションライフサイクル全体を担当
アプリケーションマネージャ
次ステップ
リソース管理の
要件
提案依頼書(RFP)
と契約
計画と設計
デプロイ、テスト
及び公開
運用及び変更管理 システムの廃棄
追 加

31. Thank you!

32. OWASP Top 10 2017
32