Written by Y.N.
エンタープライズエンジニアとして、脆弱性診断における品質向上のためのツール開発など、バックエンドの強化に従事。
脆弱性診断を受けたものの、「診断後に何をすればよいか分からない」「診断結果や指摘事項をどのように活用すればよいか迷っている」といった悩みを抱える企業・組織は少なくありません。
そこで本記事では、脆弱性診断で発見された指摘事項の読み方や、具体的な修正対応の進め方について、専門家の視点でわかりやすく解説します。
「脆弱性診断の実施を検討している」「診断を検討しているものの、社内に専門人材が不足している」といった企業・組織の方は、ぜひご一読ください。
なお、本記事は後編となります。前編では、「脆弱性診断報告書の読み方」や「脆弱性に対する優先度の付け方」について解説しています。
本記事とあわせてぜひご確認ください。
はじめに
脆弱性診断を受けたものの、「具体的な修正対応の進め方に迷っている」「指摘事項のどこを重要視すればよいのか分からない」といった悩みを抱える企業は少なくないのではないでしょうか。
本記事では、脆弱性診断によって実際に発見された指摘事項の読み解き方と、その活かし方についてわかりやすく解説します。
脆弱性診断は一度実施して終わるものではありません。発見された脆弱性を正しく理解し、適切に修正していくことが重要です。
「具体的にどのように修正を進めればよいのか」「報告書をどのように活かせばいいのか」といった点に悩んでいる企業・組織の方は、ぜひ本記事を参考にしてください。
なお、指摘事項の優先度の付け方については、前編の「脆弱性診断報告書における優先度の設定方法」で解説しています。
本記事とあわせてご確認いただくことで、より理解が深まります。ぜひ前編もご確認ください。
修正内容の確認と対応実施
修正対応を進めるにあたってまず確認したいのが、脆弱性診断の実施後に提供される報告書に記載された「指摘事項」です。
前編の「脆弱性診断報告書の読み方」では、発見された脆弱性に対する優先度の付け方として、「ビジネスへの影響度」「脆弱性の悪用可否」「サービスの公開範囲・状況」という3つの要素を解説しました。
本記事では、こうした優先度を踏まえたうえで、発見された脆弱性に対して具体的にどのような修正対応を進めていくべきか、また、その際にどのような点を考慮するべきなのかを解説します。
具体的な修正対応を進めるためには、「発見された脆弱性が再現されるのか」、そして「どこに問題があるのか」を正しく把握することが重要です。
これらを把握するための重要な手掛かりとなるのが、脆弱性診断の報告書に記載されている「脆弱性の詳細」という項目です。
この項目は、診断ベンダー各社で最も特色が出やすい箇所であり、脆弱性の再現手順や該当箇所、対策例などが記載されています。
記載事項について詳しく確認する前に、まずは脆弱性診断が主にどのように実施されているのか、その前提から確認していきましょう。
脆弱性診断の進め方
脆弱性診断では、ブラックボックステストと呼ばれる手法が主に用いられます。
ブラックボックスとは、「箱の中身が見えない状態」を指し、Webアプリケーションにおいては、サーバー側のソースコードが見えない状態のことを指します。
ブラックボックステストでは、入力に対する反応を確認することで、脆弱性の有無を判断します。
例えば、クロスサイトスクリプティングの有無を確認する場合、以下のような検査文字列を入力します。
"><script>alert(1)</script>この入力に対して、アプリケーションが適切な処理を行なっていない場合、以下のようにスクリプトが動作してしまいます。
<input type="text" value=""><script>alert(1)</script>">この結果、画面上にポップアップが表示され、クロスサイトスクリプティングの脆弱性が存在することが分かります。
脆弱性診断報告書の各項目の読み方
ここからは脆弱性診断報告書に記載される「脆弱性の詳細」における各項目の読み方を解説します。
- 脆弱性の再現手順
- 脆弱性の該当箇所
- 修正計画の立案と実施
前述の通り、具体的な修正対応を進めるためには、「発見された脆弱性が再現されるのか」「どこに問題があるのか」を正しく把握することが重要です。
各項目を正しく活用するためにも、確認していきましょう。
脆弱性の再現手順
「脆弱性の再現手順」の項目は、ベンダーや診断プランによって、記載内容が最も大きく異なる箇所です。
本項目では、診断によって発見された脆弱性が、どのような手順で再現できるのかが示されます。
これは、「どのようにして攻撃されるか」また、「万が一攻撃を受けた場合に、どのような被害が発生するか」を把握するために、非常に重要な情報です。
実際の報告書では、ベンダーやプランによって、以下のように記載内容が異なる場合があります。
- すべての該当箇所に対して、再現手順を網羅して記載している
- 脆弱性の発見パターンのみを網羅して記載してい
- 画面キャプチャがなく、テキストのみで記載している
- 再現手順自体が記載されていない
いずれの記載方法にもメリット・デメリットがあるため、自社の目的や体制にあった内容を選定することが重要です。
なお、エムオーテックスの脆弱性診断では、上記すべてではありませんが、診断プランに応じて記載内容が選べるようになっています。
脆弱性の該当箇所
「脆弱性の該当箇所」は、脆弱性が発見された箇所の情報が記載される項目であり、「再現手順」と同様に重要性の高い項目です。
Webアプリケーション診断の場合、該当箇所としてURLやパラメータなどの情報が記載されます。
本項目については、記載される情報の粒度に多少の差はあるものの、ベンダーによって大きな違いが出にくい項目です。
ただし、ベンダー側と実際に診断を受けるお客様との間に、「該当箇所」に対する認識の乖離が生じる可能性があるため注意が必要です。
例えば、以下はエムオーテックスのEssentialプランにおけるクロスサイトスクリプティング脆弱性（以下、XSS）の該当箇所の例です。
No.1の「アンケート回答」の画面では、入力確認ボタンをクリックした際に送信されるURLとパラメータが、該当箇所として記載されています。
ここで注意すべきなのは、この該当箇所は「入力箇所」を示している点です。
XSSの場合、実際に対策を行うべき箇所は、主に「出力時の箇所」となります。
なぜ「報告書の該当箇所」と「実際の対策箇所」が異なってしまうかというと、これはブラックボックステストの特性によるものです。（なお、ホワイトボックスを推奨しているわけではありません）
脆弱性診断を実施するベンダーでは、入力値を改ざんし、その結果として出力先でXSSが起きた場合、改ざんを行なった入力箇所（入力値）を該当箇所として報告します。（XSSのタイプによって扱いは異なります）
これは、ブラックボックステストの内部ロジックが確認できないという特性から、出力位置が診断員やツールが検知した箇所のみとなるためです。
その結果、入力箇所が「脆弱性の該当箇所」として報告されます。
なお、本記事では「反射型」と呼ばれるXSSを想定して記載しています。ほかの種類のXSSや別の脆弱性については、該当箇所の考え方が異なる場合があります。
脆弱性への対策例
「脆弱性への対策例」の項目には、発見された脆弱性に対する対策内容の一例が記載されます。
この項目については、ベンダーによって大きな差が出にくく、多くのベンダーでは、発見された脆弱性に対する基本的な対策方針が記載されます。
開発側の立場としては、「どの箇所を、具体的にどのように修正すればよいか」を記載してほしいと感じることもあるでしょう。
しかし、使用されているプログラミング言語は多種多様であり、セッションの取り扱いやアクセス権限の管理方法も各サイトによって異なるため、「脆弱性への対策例」には、一般的な対策方法が記載されるケースが多くなります。
このような背景を踏まえ、本項目はあくまでも「対策例」として参考にしつつ、自社サイトやサービスにあった適切な対策を検討することが重要です。
修正計画の立案と実施
脆弱性診断の報告書には、「修正計画の立案と実施」についても記載されます。
修正計画の内容や実施方法は、各企業の方針や体制によって異なるものですが、一般的に想定される修正計画としては、下記のようなパターンが挙げられます。
- 発見された脆弱性をすべて修正する
- 危険度の高い脆弱性のみを修正する
- WAFなどのセキュリティソリューションを利用して対策する
本項目については、明確な正解はありませんが、あえて理想をあげるとすれば、発見されたすべての脆弱性を修正することです。
とはいえ、コストやリリーススケジュールなどの兼ね合いから、一部のリスクを許容することや後日の修正計画とするケースももちろんあると思います。
重要なのは、重大な脅威を放置したことにより、取り返しのつかない事態を招かないことです。
このような事態を防ぐには、脆弱性を正しく把握し、適切な優先度を付けた上で対応を進めていくことが重要です。
また、脆弱性診断の結果は、一度修正して終わりにするものではありません。
脆弱性の対策（改修）状況の管理や、テスト・修正確認などを含めた一連の対応を定期的かつ継続的に行なっていく必要があります。
対応が疎かなまま進んでしまうと、修正漏れなどの発生につながる可能性もあるため、可能な限り余裕をもったスケジュールで管理することを推奨します。
そして、対策を施した後には、正しく改修ができているかを確認することが欠かせません。
多くのベンダーでは再診断サービスが提供されているので、初回診断で発見された脆弱性に対する修正確認として、再診断を活用することも有効な手段です。
なお、自社で確認することも重要ですが、修正が甘かったり、新たな脆弱性を作りこんでしまったりと、問題が生じる可能性もあります。
そのため再診断は、アウトソーシングされることを推奨します。
セキュリティ教育とトレーニングの重要性
近年では、サイバー脅威の高度化・巧妙化が進んでおり、セキュリティを開発要件に含むことや、脆弱性診断を受けて改修を行うだけでは、脅威を十分に防ぐことが難しくなっています。
被害を防ぐためには、セキュリティソリューションの導入や、脆弱性診断に基づいた適切な対応を行うことも重要ですが、それと同時に、従業員一人ひとりのセキュリティ意識を高め、基本的なセキュリティ対策を日頃から行うことも非常に重要です。
近年、被害件数の増加や被害規模の拡大に伴い、サイバー攻撃がニュースに取り上げられる機会も増え、脆弱性に対する社会全体の理解は高まりつつあります。
しかし、万が一サイバー攻撃を受け、機密情報や個人情報が漏洩した場合、攻撃を受けた被害者側であったとしても、「情報漏洩が発生した企業」として世間に認識され、社会的信頼が失われるリスクがあります。
また、過去の判例にはなりますが、脆弱性を突いた攻撃によって情報漏洩が発生した際、開発要件にセキュリティ要件を含んでいなかったことを事由に、企業側が裁判で敗訴したケースもあります。
その判例の中では、セキュリティ対策を講じた状態で実装することは、単なる推奨ではなく、対策を取るべき責務であると示されています。
本件ウェブアプリケーション等がウェブ受注システムとして必要十分なセキュリティレベルとなるように，本件ウェブアプリケーション提供後も管理及び運用すべき債務を負っていた。
出典：SOFTIC 判例ゼミ 2014-5 2014.11.13
このように、セキュリティ対策を適切に行うことは、いまや企業の社会的責任の一つとなっています。
この責任を果たすためには、最低限でも脆弱性に対する知識を持つことが欠かせません。
脆弱性を正しく理解することで、開発を進める上で、どこに気をつけなければいけないかが分かるようになります。
そして、万が一脆弱性を作りこんでしまったとしても、どこに問題があるかを正しく把握し、迅速かつ適切な対応が行えるようになるでしょう。
脆弱性診断は定期的な実施がおすすめ
前述の通り脆弱性診断は、一度診断しただけでは不十分となる可能性があります。
機能改修や新機能追加を実装したタイミングで実施を検討される企業・組織の方も多いかと思いますが、攻撃手法の進化や診断精度の向上、診断対象のデータの状態、そのほか複合的な要素によって、同じ対象でも、新たな脆弱性が発見される場合があります。
このような脆弱性を見逃し・見落としを防ぐためには、脆弱性診断を定期的かつ継続的に実施することが推奨されます。
頻度やタイミングについて、詳しく知りたい方は、下記の記事を合わせてご確認ください。
まとめ
前編では「脆弱性診断報告書の読み方」について、後編では「診断後の活かし方」について解説しました。
脆弱性診断は、診断を受けるだけで満足するのではなく、報告書を受け取ってからの行動が非常に重要です。
脆弱性を放置すれば、インシデントになる可能性が高まります。また、十分な理解がないまま対応を進めてしまうと、逆に脆弱性を作りこんでしまい、さらなる攻撃リスクに晒される可能性もあります。
本記事の内容が、脆弱性と向き合い、診断後の対応を着実に進めていくための一助となり、自社にとって最適な診断ベンダーを見つける際の参考となれば幸いです。
おすすめ記事
