なぜ自社で脆弱性診断を行うべきなのか

なぜ自社で脆弱性診断を行うべきなのか株式会社トライコーダ上野宣2017年2月6日

https://tricorder.jp/

(c) 2017 Tricorder Co. Ltd. 1

Profile: 上野宣 (Sen UENO)株式会社トライコーダ代表取締役奈良先端科学技術大学院大学で情報セキュリティを専攻、eコマース開発ベンチャーで東証マザーズ上場などを経て、2006年に株式会社トライコーダを設立企業や官公庁などにサイバーセキュリティ教育や演習、脆弱性診断、ペネトレーションテストなどを提供

情報セキュリティ専門誌『ScanNetSecurity』編集長、OWASP Japan Chapter リーダー、Hardening プロジェクト実行委員、JNSA ISOG-J WG1リーダー、SECCON 実行委員、セキュリティキャンプ講師主査、独立行政法人情報処理推進機構セキュリティセンター研究員などを務める

主な著書Webセキュリティ担当者のための脆弱性診断スタートガイド - 上野宣が教える情報漏えいを防ぐ技術、HTTPの教科書（日本語、簡体字、ハングル）、今夜わかるシリーズ（TCP/IP, HTTP, メール）、めんどうくさいWebセキュリティ、他多数


Webセキュリティ担当者のための脆弱性診断スタートガイド上野宣が教える情報漏えいを防ぐ技術

目次1. 脆弱性診断とは2. 診断に必要なHTTPの基本3. Webアプリケーションの

脆弱性4. 脆弱性診断の流れ5. 実習環境とその準備6. 自動診断ツールによる脆弱

性診断の実施7. 手動診断補助ツールによる

脆弱性診断の実施8. 診断報告書の作成9. 関係法令とガイドライン


今日の話はだいたいこの本に書いてます。が、本にもこの資料にも書けない話があるんですよね。

必要な脆弱性診断サービスの選び方


脆弱性診断は主にどうしてる？① 脆弱性診断サービスを提供する業者に外注② 自動診断ツールのみを使って脆弱性診断を実施③ 自動診断ツール・手動診断補助ツールを使って

脆弱性診断を実施している④ 実施していない


脆弱性診断は主にどうしてる？① 脆弱性診断サービスを提供する業者に外注– コストは決して安くない– その業者の診断は信用できる？

② 自動診断ツールのみを使って脆弱性診断を実施– 自動診断ツールには得意分野と不得意分野があり、自動

ツールだけでは完結しない– コストも決して安くない

③ 自動診断ツール・手動診断補助ツールを使って脆弱性診断を実施している– スキルは十分か？

④ 実施していない– ……。


脆弱性診断とペネトレーションテスト• 脆弱性診断– 網羅的により多くの脆弱性を探す– 脆弱性やセキュリティの問題を見つけることが目的– テストケースに則ったセキュリティテスト

• ペネトレーションテスト– いかにシステムに深く侵入するか– 管理者権限の奪取や情報の入手が目的– 複数の脆弱性やセキュリティの問題を組み合わせて

利用することもある– 診断士個人のスキルに依存することが多い


脆弱性とセキュリティ機能の不足• 脆弱性– プログラムのバグ– バグの中で悪用可能なものが脆弱性

• セキュリティ機能の不足– 実装すればセキュリティレベルが向上する対策を実

施していない– 安全でないプロトコルや弱いパスワードの利用など

も

• 脆弱性とセキュリティ機能の不足を見つけるのが脆弱性診断


脆弱性診断の対象• プラットフォーム脆弱性診断

– OSやミドルウェア、TCP/IPの各種サービスなどのプロダクトが対象

• Webアプリケーション脆弱性診断– Webアプリケーションが対象

• その他– ソースコード診断– データベース診断– スマートフォンアプリケーション診断– 無線LAN診断– 組み込み機器診断– etc...


Webアプリの脆弱性診断はゼロデイ探しプラットフォームで対策すべき事項• 既知の脆弱性

– バージョンが古く脆弱性が存在する– すでにプロダクトのサポートが終了しているため脆弱性が

修正されない• 設定の不備

– 最新バージョンであってもセキュリティに関わる設定の不備による脆弱性が存在する

• Webアプリケーションはゼロデイを探し– 攻撃者以外は誰も脆弱性を発見してくれない

（プロダクトやパッケージを除く）


Webアプリケーション脆弱性診断の診断手法


脆弱性診断の実施手順


テストケース作成脆弱性診断の実施診断結果の検証レポート作成

• 診断対象の記録• シナリオ作成

• 自動診断ツールを使った診断

• 手動診断補助ツールを使った診断

• 診断ツールによるレポート出力

• 手作業によるレポート作成

• 手作業による診断結果の検証

自動と手動の診断手法2つの診断手法• 自動的に脆弱性を発見する診断

– 自動診断ツールによる診断• 手作業で脆弱性を発見する診断– 手動診断補助ツールを使う手作業による診断

• 自動診断ツールでは発見が難しい脆弱性や、自動的に探すことが困難な機能や箇所があるため、確実に脆弱性診断を行うためには手作業による診断を合わせて行うことが必要– 自動診断ツールにしか発見できない脆弱性はない


脆弱性診断に使用するツール• Proxyツール– WebブラウザとWebサーバーの間にProxyとして入

り、リクエスト・レスポンスに介在する


Webブラウザ WebサーバーProxyツール

HTTPメッセージの確認リクエストの書き換えHTTPメッセージの記録

自動診断ツールによる脆弱性診断


自動診断ツールを使った脆弱性診断の実施手順

1.テストケース作成 2.脆弱性診断の実施 3.診断結果の検証 4.レポート作成

• 自動クロール機能を使って診断対象を記録

• プロキシ機能を使って手動クロールによる診断対象の記録

• シナリオ作成

• 動的スキャンを使った診断

• 静的スキャンを使った診断

• レポート出力• 手作業による

レポート作成


正常系を記録させる必要がある

誤検知と見逃しがないようにしたい


自動診断ツール• URLを入れると自動的に脆弱性診断を実施…

• 適切に実施するためには設定が必要– 診断すべきページをすべて診断するように– 関係のないページを診断しないように– 障害を発生させないように– サーバーをダウンさせないように

• 苦手分野もある


自動診断ツールの特長と得意分野• 最も大きな特長はスピード• パラメーターに値を挿入して発見するタイプの脆弱性

– SQLインジェクションやクロスサイトスクリプティングなど• HTMLやCookieなどのセキュリティ機能の不足

– レスポンス内容を見れば判断ができるセキュリティ機能の不足の発見

– オートコンプリート機能、CookieのHttpOnly属性、X-Frame-Optionsなど

• ディレクトリやファイルの発見– リンクされているURL、robots.txtなどからファイルを探索– crossdomain.xmlなどの特定のアプリケーションのためのファ

イルの探索– 辞書機能で、どこからもリンクされていないファイルやディレ

クトリを探すこともある(c) 2017 Tricorder Co. Ltd. 18

自動診断ツールでは発見が難しい脆弱性や機能発見が難しい脆弱性• 認可制御の不備・欠落• ビジネスロジック上の問題• メールヘッダーインジェクション• クロスサイトリクエストフォージェリ（CSRF）

発見が難しい機能• 人間の判断や操作が必要になるもの• メール受信、CAPTCHA、二要素認証、複数要素認証• ゲームのような操作を伴うもの• 脆弱性の発動に複数のパラメーターを利用するもの• 一度しか実行できない機能• 入力値の影響が次画面ではなく他の画面にでるもの


ツールによって異なる

自動診断ツールの誤検知と見逃しを減らす• 異なる自動診断ツールを使った診断• 自動診断レポートの確認

– 必要な場合には手作業で確かめる


効率的かつ確実な診断には自動診断ツールと手作業による診断を

組み合わせて行うことが必要

誤検知と見逃し誤検知（false positive）• 正常なものを誤って脆弱性だと判断してしまう

こと見逃し（false negative）• 脆弱性を発見できずに見逃してしまうこと

• 誤検知が起きるときはWebアプリケーションに何らかの問題があることも多いので、一概に誤検知が悪いこととはいえないこともある


診断結果の検証• 発見した脆弱性は本当に問題になるのか？脅威

になるのか？を検証• 自動診断ツールによる診断の場合は、手作業に

よる診断結果の検証が必要な場合もある• 手動診断補助ツールを使った診断の場合は脆弱

性診断の実施時に合わせて行うこともある


手動診断補助ツールによる脆弱性診断


手動診断補助ツールによる脆弱性診断


Webブラウザ WebサーバーProxyツール

リクエストの書き換えHTTPメッセージの確認

WebサーバーProxyツール

取得したリクエストを再利用して書き換えたリクエストを送信

手動診断補助ツールを使った脆弱性診断の実施手順

1.テストケース作成 2.脆弱性診断の実施 3.診断結果の検証 4.レポート作成

• プロキシ機能を使って手動クロールによる診断対象の記録

• シナリオ作成

• 手動診断補助ツールを使った手作業による診断

• （Passive Scanを使った診断）

• 手作業によるレポート作成



テストケース(診断リスト)の作成• どこを診断するのか？– URL– Webページ内の特定の機能– クエリーやPOSTデータ、ヘッダーフィールドなどの

パラメーター• どの順序で診断するのか？– どのページから先に行うかの優先順位– 特定の機能を利用するための画面遷移の順序


診断リスト

NNoo.. 名名称称 UURRLL TTYYPPEE パパララメメーータターー SSQQLLii ココママンンドドii

CCRRLLFFii XXSSSS パパスストトララババーーササルル

オオーーププンンリリダダイイレレククトト

RRFFII ククリリッッククジジャャッッキキンンググ

認認証証認認可可制制御御のの不不備備・・欠欠落落

セセッッシショョンンフフィィククセセイイシショョンン

CCSSRRFF HHttttppOOnnllyy属属性性未未設設定定

推推測測可可能能ななセセッッシショョンンIIDD

情情報報漏漏ええいい

1 トップページ http://www.badstore.net/ 1Cookie SSOidCookie CartID

2 Home http://www.badstore.net/cgi-bin/badstore.cgi

Cookie SSOid - - - - -Cookie CartID - - - - -URL action - - - - -

3 Sign our Guestbook

http://www.badstore.net/cgi-bin/badstore.cgi?action=guestbook

URL action - - - - -Cookie SSOid - - - - -Cookie CartID - - - - -

4Sign our Guestbook > Add Entry

http://www.badstore.net/cgi-bin/badstore.cgi?action=doguestbook 1 2

URL action - - -Cookie SSOid - - -Cookie CartID - - -Body name - - 4Body email - - 5Body comments - - 6


診断リスト


診断をしない項目は塗りつぶす

診断リスト


診断リスト


パラメーターに起因しない脆弱性

パラメーターに起因しない脆弱性

パラメーターに起因する脆弱性

診断リスト


診断の結果脆弱性がなければ「-」診断の結果

脆弱性があれば「番号」を付ける番号は詳細レポートと紐付く

診断完了後はすべての項目が埋まる

Webアプリケーション脆弱性診断手法• OWASP＆JNSA ISOG-Jの共同WG「脆弱性診

断士スキルマッププロジェクト」で作成• https://archives.tricorder.jp/webpen/Web_

Application_Penetration_Testing_Techniques.pdf– 短縮URL：https://goo.gl/CgCqtL

• リリース版は2017年3～4月ごろの予定


例：SQLインジェクション診断番号診断対象の脆弱性診断を実施すべき箇所1 SQLインジェクションすべて検出パターン診断を行う箇所診断方法「'」(シングルクォート1つ) パラメーターパラメーターの値に検出パターン

を挿入し、リクエストを送信

脆弱性がある場合の結果脆弱性がない場合の結果備考DB関連のエラーが表示されるか、正常動作と挙動が異なる

DB関連のエラーは表示されない DB関連のエラー（SQL Syntax, SQLException, pg_exec, ORA-5桁数字, ODBC Driver Managerなど）は画面に表示されることもあれば、HTMLソースに表示されることもあるSQLiがあるが、エラーが画面にでない場合には正常時と挙動が異なることもあるただし、この診断手法の脆弱性の有無については確定ではなく、あくまで可能性を示唆するものである


例：クロスサイトスクリプティング診断番号診断対象の脆弱性診断を実施すべき箇所16 クロスサイトスクリプ

ティング（XSS）すべて

検出パターン診断を行う箇所診断方法<script>alert(1)</script> パラメーターパラメーターの値に検出

パターンを挿入し、リクエストを送信

脆弱性がある場合の結果脆弱性がない場合の結果備考スクリプトが実行されるスクリプトが実行されな

い


例：セッションフィクセイション診断番号診断対象の脆弱性診断を実施すべき箇所54 セッションフィクセイ

ションログイン機能

検出パターン診断を行う箇所診断方法Set-Cookieヘッダーフィールド

ログイン成功後に新しい認証に使うセッションIDが発行されるかを確認

脆弱性がある場合の結果脆弱性がない場合の結果備考ログイン成功前と同じセッションIDが継続して使用される場合

ログイン成功後に新しいセッションIDが発行され、古いセッションIDは破棄される


報告書の作成


診断報告書の作成


1.材料を集める 2.報告書の作成 3.内部レビュー 4.納品／報告会

• 診断実施概要• 脆弱性診断結果• 各種契約

• 集めた材料に基づき報告書を作成

• 顧客への納品• 報告会の実施

• 診断会社内でのレビュー

• 承認

診断実施後少なくとも1～2週間以内の提出が望ましい

診断報告書のポイント• 読み手に修正すべき問題点を認識してもらう– 対策につなげてもらうため

• 再現性があることが重要– ペイロード、リクエストメッセージ、ツール、実施

日時、ネットワーク環境など– 再現方法がわからないと、脆弱性の確認、修正後の

状態確認ができない


すべてのドキュメントは読み手に読後に何をさせたいかという

目的を明確にするべき

診断報告書の記載事項• 表紙

– タイトル、日付、報告者（会社名、部署名、担当者名など）• 目次• イントロダクション

– 診断報告書について（報告書の概要や目的について）– 脆弱性診断サービスの診断対象について– 業務運営上のリスク（診断対象の事業やサービスなどのリスクについて）– 診断を行う際に同意した契約上の規則（免責事項、守秘義務など）– 診断を行う際の制限事項（主に脆弱性を発見にあたっての阻害要因）

• 診断実施概要– 診断の実施日程– 診断対象（URL、ドメイン、IPアドレス、機器名、サービス名など）– ネットワーク環境（診断対象と診断実施側のネットワーク的な関係）– 診断実施者（診断を担当した脆弱性診断士）– 診断環境（診断に使用したOS環境や診断ツール、バージョンなど）

• 診断結果– 診断結果の総合評価– 個別の脆弱性の報告


脆弱性診断の流れ


診断業務の流れ


診断実施前の準備

診断実施

診断実施後のアフターサポート

診断対象の確認、見積もり、ヒアリング、作業環境の準備など

自動診断ツールを用いた診断、手作業による手動診断、レポート作成など

報告会の実施、診断実施後の問い合わせ対応、再診断など

診断実施前の準備

• 診断対象となるWebアプリケーションの選定や優先順位付けを行う

診断対象の確認

• 診断の内容やサービス提供の流れ、診断時の注意事項など診断前に事前に説明すべき事項の説明を行う

実施内容の説明

• 診断の実施形態や診断対象の環境など診断に必要な情報を事前に確認する

ヒアリング

• 診断に必要なアカウント情報や各種権限などの準備を行う

環境・データ準備

• オンサイト環境での診断の場合に診断対象のネットワークへの接続方法や作業場所などの準備を行う

オンサイト作業環境の準備


報告書や脆弱性診断の各種データの扱い• 脆弱性診断の情報は機密情報– 報告書、報告書作成のための資料、診断ツールのロ

グ、貸与したアカウントなどの情報、診断対象についての情報

• 保管しなければならない情報は安全に暗号化• 不要なデータや紙媒体の情報は復元できない形

にする


脆弱性診断士に求められる倫理観• 「脆弱性診断士は、高い倫理を持ち、適切な手法で

ITシステムの脆弱性診断を行える者であり、脆弱性診断士スキルマップ＆シラバスで求める技術や知識を保有している者に対して与えられる呼称である。」（脆弱性診断士スキルマップの解説）

• 脆弱性診断の技術を悪用することで他者に不利益を与えたり、犯罪を起こしてしまうこともある

• 自分に権利があるもの以外を勝手に脆弱性診断をしないこと– 余計な正義感は不要– バグバウンティ・プログラムなどもある


脆弱性診断をなぜ自社でやるべきか


脆弱性診断をなぜ自社でやるべきか• コストの削減– 診断を外部委託すると、開発が終わった後の診断実

施となる– その後修正して、また再診断を行う必要がある

• 脆弱性診断＝セキュリティテスト– 機能テストや性能テストと同様に開発者や品質管理

部門がやるとよい


セキュリティホールを修正するコスト（フェーズ別）


参考：Kevin Soo Hoo, “Tangible ROI through Secure Software Engineering.”Security Business Quarterly, Vol.1, No.2, Fourth Quarter, 2001.

1 6.5 15

60

要求仕様・設計時実装時テスト時運用開始後

コス

ト

脆弱性診断をなぜ自社でやるべきか• 診断業者はそのシステムに精通しているのか？– 正しい動作、こうあるべき動作を知っているか？– 医療系システムは？– 制御系システムは？– IoT機器は？

• システムのことは自分たち／自社が一番よく知っている– 正しいアクセス制御の状態– ビジネスロジックの動き


自社では十分でない場合もある• 脆弱性診断には監査的な側面もある– PCI DSSなどの認証を取得する条件


セキュリティ予算の目安


診断の予算（アンケートベース）• 1回当たりの予算は20万円未満が3割、50万円

未満で5割


参考：WEBアプリケーション脆弱性診断実施回数は年2～4回、予算は一回20万円が最多（NHNテコラス、イード） | ScanNetSecurityhttp://scan.netsecurity.ne.jp/article/2017/01/25/39379.html

何パーセントぐらいをセキュリティに投資すべきか？• ソフトウェア予算の9%をセキュリティに投資– 予算全体の6%– ただし、59％のITプロフェッショナルがセキュリ

ティに適切に投資していないと回答– 2016年 Spiceworksの調査


参考：IT budgets 2016: Surveys, software and services | ZDNethttp://www.zdnet.com/article/it-budgets-2016-surveys-software-and-services/

PR: 脆弱性診断講座


PR: 自社で取り組むWebアプリケーション脆弱性診断講座• Webアプリケーションの脅威とその攻撃手法

– Webサイトへの攻撃とその特徴– HTTPの基礎– Webアプリケーションへの攻撃手法– 各種攻撃手法、脆弱性、セキュリティ機能の不足

• 脆弱性診断の実施– Webアプリケーション脆弱性診断の実施手順– 自動と手動の診断手法– 自動診断ツールの得意分野と不得意分野– 注意すべき診断ツールの設定– 診断結果の検証– 診断リスト（テストケース）の作成– 脆弱性診断の診断方法と脆弱性の有無の判定方法について– 脆弱性診断の診断対象の選び方– 報告書の作成– 診断会社の業務における脆弱性診断

• 脆弱性診断演習– 診断ツールのセットアップ– 自動診断ツールの使い方– 手動診断補助ツールの使い方– 各脆弱性に対応した診断方法– 実際の診断業務を想定した演習


2日間のハンズオン講座

お問い合わせは株式会社トライコーダなどへhttps://tricorder.jp/

なぜ自社で脆弱性診断を行うべきなのか

Technology

Transcript of なぜ自社で脆弱性診断を行うべきなのか