意外と見落とされがち! Webセキュリティ診断の報告書とは? 〜セキュリティ診断について理解を深めるその6〜
Webセキュリティ診断というと、ツールによる診断なのか、手作業による診断なのか、その手法や内容がフィーチャーされがち。いやでも、診断したからには、診断の結果が書いてある「報告書」をどう見るか。そこが大事なんじゃなかろうか。
世の中あまりにも関心がなさすぎじゃない?と感じた、ブログ担当のワタクシもちゃじ。
そこで、この記事では「報告書」に着目していきます。何が書かれているのか、もちゃじ独断の推しポイントなどについて紹介します。
診断結果の伝え方は、報告書、メール、ポータルで確認、報告会など、サービスによって異なるのでしょうが、ここでは便宜上、診断結果を報告するものを「報告書」とします。
セキュリティ診断の理解を深めるシリーズもこの記事で6回目。その他の記事についてはこちらからご覧いただけます。
- その1 ブラックボックス診断とは?
- その2 セキュリティ診断の診断項目、その多さの理由に迫る
- その3 ローカルプロキシツールとは?
- その4 ツールによる診断とは?
- その5 手作業による診断とは?
- その6 報告書とは?←本記事
- その7 セキュリティ診断員ってこんな仕事
報告書の枚数ってめっちゃ多い! 何が書かれている?
皆さん、Webセキュリティ診断の報告書ってご覧になったことありますか? 初めて見たとき、もちゃじはひっくり返りそうになりました。
……多くないか?
なんだか暗号みたいなものが書かれていて(今思えばコード)、一見すると難解に思えてしまうんですよね。その時は、中学時代の初めての挫折本『カラマーゾフの兄弟』を思い出しました。
診断の種類やサービスによっても報告書のボリュームには差があるとのこと。
例えば、ツール診断の場合は、そんなに大量にならないとか、いやボリュームすごいやつがあるとかなんとか。人が書かずにコンピューターさんが診断結果まで書いてくれるとかなんとか。そのあたりはサービスによって違うそうです。
なので、この記事では当社のWebセキュリティ診断「ABURIDA」の報告書を例にご紹介します。
報告書に書かれていること
ツールと手作業によるハイブリッドWebセキュリティ診断「ABURIDA」。その報告書の枚数は多めです。なんでそんなに枚数が多くなるのかというと、以下の事柄が書かれているからなんです。
- 脆弱性の概要
- 再現方法
- 対策方法
ふむふむ。
ツールに加えて手作業で診断しているからこそ、検出された脆弱性やセキュリティ上のリスクを詳細に記載し、その再現や対策の方法までしっかり書くことができる。
診断は複雑なプロセスを踏む上に、多くの情報を伝える必要があるから、そりゃ枚数も多くなるはずです。
診断項目も多いですしね。診断項目についてはこちらの記事をご覧ください。
報告書の枚数は検出した脆弱性の数による
報告書のボリュームは、診断で検出された脆弱性の数や複雑さによって異なります。
例えば、脆弱性が10個検出されたとします。
単純な脆弱性の場合、それほどページ数も多くなりません。反対に、複雑な手順をふむ脆弱性やパラメーターの数が多い、パターンが多いなどの場合はそれぞれに記載する必要があるので枚数も増えるというわけなんです。
例えば、ECサイトでの支払い方法がクレジットカード、電子マネー、QRコードと3つある場合、それぞれの支払い方法に対して検証し、検出したパターンを個別に記載することになります。同じQRコード決済でも、ユーザーで操作が違う場合、それぞれの操作パターンを記載する必要があります。
それぞれのパターン。それぞれのパターン!!
また、プログラムがエラーを出力している場合は、エラーメッセージごとに検証するんです。それぞれのパターンで!
うん、そりゃ報告書の枚数も増えていきますよね。
いちいち細かく全部検証していることが分かりますね、セキュリティ診断。
ちなみに、ABURIDAの場合、総合評価Aの報告書であっても、総評や確認した観点などの記載があり、そのページ数は13ページほどになります。総合評価がAだとしても!
危険度の判定基準
総合評価Aとはどういう状態のことかというと、脆弱性が検出されなかった時につく評価です。総合評価はA〜Eまでの5段階で表され、Webサイトやアプリケーションの危険度を示しています。
以下が総合評価の基準です。
評価 | 基準 |
A | 脆弱性が検出されなかった |
B | 危険度Lowの脆弱性のみ検出 |
C | 危険度Mediumの脆弱性を検出 |
D | 危険度Highの脆弱性を検出 |
E | 危険度Highの脆弱性を複数検出 |
危険度の判定は、攻撃の実現可能性と想定される被害の規模を軸として「High」「Medium」「Low」の3段階に分けて判定されます。検出された脆弱性の数だけではなく、その脆弱性の影響度を考慮して判定をしているんですね。
「ABURIDA」報告書の3つの推しポイント
もちゃじ的に推せる「ABURIDA」の報告書。実際に「ABURIDA」の報告書が見やすい、分かりやすいというお客さまからのお声もいただいていて、報告書って大事だよね、と診断員も改めて気付くきっかけにもなりました。
推しポイント1:デザイン
報告書はその情報量の多さから、読むのに「うへぇ」となってしまう人もいると思うのですが(もちゃじです)、報告書の作成者側としては、できれば余す所なく読んでいただきたいと思っている。はず。
では、どうしたら読み進めてもらえるのか。デザインの力を借りるのです。
もちゃじが思うABURIDA報告書のデザインのポイント
- クリアで整然としたレイアウト
- 視覚的な要素の活用
- 読み手の視点を考慮した記述
「分かりやすい」を目指しているABURIDAの報告書は、すっきりとしたシンプルなレイアウト。専門用語や技術的な事柄などは分かりやすいように、図解や画像を入れて視覚的にも理解しやすい工夫がされています。
セキュリティに詳しくない人(もちゃじとか)でも読み進められるのがうれしいポイント。
中学時代は挫折したけど、大学生になったらあの長い『カラマーゾフの兄弟』も読めたように、いちげんさんはひるむかもしれませんが、大丈夫です。カラマーゾフよりは読みやすいと思う。カラマーゾフより短いし(もちゃじの感想です)。
推しポイント2:想定される被害の記載
「ABURIDA」報告書には、検出された脆弱性から想定される具体的な被害がリアルな例として記載されています。これにより、抽象的なリスクではなく、実際の被害イメージがつかみやすく、セキュリティリスクの重要性を理解しやすくなっています。
例えば、不正アクセス、なりすまし行為などによる個人情報の漏えい、機密データの改ざん、サービスの停止などの具体的な被害例は、報告書を受け取った人が脅威を正確に把握して、適切な対策をするための指針になります。
もちろん、それに対する対策法も具体的に、分かりやすく記載されています。
推しポイント3:再現方法
診断で脆弱性を発見するために使用した手順やテストケースを詳細に記載しています。これにより、システム管理者や開発者が再現できるので、問題の特定と修正に役立てることができます。
報告書の裏話
日々Webセキュリティ診断をしているABURIDAの診断員に話を聞いたところ、なかなか興味深い話があったので、その中から二つご紹介します。
割と検出しがちな脆弱性
Webセキュリティ診断をしている中でも、割と頻繁に検出される脆弱性があるとのこと。その一つが、クロスサイトスクリプティング(XSS)なんです。この脆弱性は、本ブログでも頻繁に登場する三大脆弱性の一つですね。
三大脆弱性について詳しくはこちらの記事をご覧ください。
最低3人の診断員の目を通して作成される
ABURIDAの報告書は、高い品質と信頼性を保証するために、丁寧な作成プロセスを経て完成します。基本的な流れは以下のとおりです。
- 担当診断員が検出された脆弱性やセキュリティ上のリスクを総合的にまとめ、報告書を作成
- 他の診断員がチェックリストなどを元に、抜け漏れがないか確認
- セキュリティ部門責任者による脆弱性の妥当性をチェックし、報告書の内容を最終確認
このように、最低3人の診断員の目を通して作成されます。なかなか緻密で丁寧に作成されているのが分かり、報告書が信頼できると改めて感じます。
まとめ
Webセキュリティ診断の報告書は、ABURIDAの場合、脆弱性の概要や再現方法、対策方法などの詳細な情報が記載されており、セキュリティリスクを明確に伝える役割を果たしていることが分かりました。
「こういう脆弱性がありましたよ、想定される被害はこうです。こういうプロセスでこんなことをしてみたら、この脆弱性が発見されたんです。だから、ここにこういった対策をしてくださいね」
指示語が多くてアレですが、検出された脆弱性ごとに、この流れが詳細に記載されているんですね。だからページ数が増えていく。納得でした。
もちゃじは報告書を読んでみて、めちゃくちゃ勉強になりました。やはり報告書の重要性は広く知れ渡ってほしいものです。セキュリティリスクを発見する上でも、脆弱性を理解する上でも、報告書はやっぱりめちゃくちゃ重要だった。
Webセキュリティ診断、ぜひやってみてほしい。分かりやすい報告書がセットになっているサービスでぜひ。その意味で「ABURIDA」は優秀だなと改めて思ったもちゃじなのでした。
ふう書き終えた
『カラマーゾフの兄弟』、当時読破したぞっていう達成感はものすごいものがありました。中学時代の挫折ポイントは、名前と愛称が覚えられなかったというのもあるかもしれない。当時からカタカナに弱かったもちゃじ。
ライター/もちゃじ
IT業界に縁なく秘書畑をさすらい、前職はインドで社長秘書。ほぼ日本語とパッションのみで乗り切ったずうずうしさはスキルの一つか。完全なインドア派ながらたまにふらりと旅に出る。行き場のない母性を持て余し、友人の犬を溺愛するもほえられる。体が硬く、インドでヨガティーチャーに笑われたことに深く傷つく一面も。
ITド素人の私がWebセキュリティについて学び、レベルアップしていく(予定です)様子をお届けします。学びを発信することで、少しでもWebセキュリティに関する「難しそう」というイメージが下がり、苦手意識のある方たちに届いたらうれしいです。