目次
1. はじめに
2. 学んだこと
3. 最後に
4. 参考資料
1. はじめに
Web脆弱性診断士になってから2か月目の私が、報告会に参加した際に学んだことを備忘録として残します
報告会という特殊なケースに関係なく、ビジネスの場で当たり前である項目も多いと思いますが、そこはご容赦を...！(笑)
2. 学んだこと
2-1. 診断対象がどんなシステムかを把握する
報告会というか、診断時に把握しておくべきことと思いますが...
把握しておくとビジネスへの影響レベルがある程度想定でき、お客様の層を推し量ることが可能かと思います。
2-2. 相手のレベル感に合わせた説明を準備しておく
報告会時にお客様からの質問があって、その時に初めてお客様のレベル感を理解することが多いです。
事前にお客様の情報を知れるなら聞いておくに越したことはありませんが、難しい場合もあるので...。
相手のレベル感に合わせた説明が出来ると臨機応変に対応できます。
2-3. 脆弱性に紐づく攻撃手法、対処方法の具体例を提示すると分かりやすい
報告書に脆弱性の概要を記載しているかと思いますが、補足情報として最近ニュースになったセキュリティインシデントや具体的な対処方法をお伝えすると、より伝わります
2-4. 説明用の図を用意しておくと良い
脆弱性について言葉だけで説明するのは難しいです。
図を用意していると時間をかけずに理解してもらえます。
2-5. NWやPFに関する情報がある場合は一応確認しておく
例えば「ミドルウェアレベルで対策するので、アプリケーションでは対応しなくても良い？」と言った質問をされる場合があるので、事前に情報が見れる場合は確認しておくと良いです。
2-6. 初歩的なことも質問されることがある。日頃から技術理解をあやふやにせず学習し、説明できるようになる
脆弱性に関わらず、初歩的な質問をされることがります。
例えば「HTTPとHTTPSの違いって？」「APIって何ですか？」「JSONって何ですか？」などなど
私の場合は「概念は知っているけど、言葉で説明できるレベルまでは理解できていない」ということが多いので、なあなあにせず言葉で説明できるように復習しなければ...
2-7. 相手の理解の細かい部分がずれていても、細かい部分を訂正して行ったらキリがない。「こちらの説明は間違っていなかった」といえるレベルの妥協点を見極める
時間が限られていますし、細かい部分を正していったらキリがないので...。
とは言え、あまりにも誤った認識のままでは問題ですし、「こういった説明をしていました。こちらの説明は間違っていません」と自信をもって言えるレベルの妥協点を、自分自身の中で定め置くと良いです。
2-8. 説明に詰まってしまっても堂々としている。分からないことは良くないが、なよなよした態度をとってしまうとより不安を与えてしまう
例え経験が浅くても、お客様からしたら知ったこっちゃないし、プロフェッショナルとして見られています。
どうしても分からない、言葉に詰まってしまうことはあります。せめてそういった場面でも慌てず堂々とすることによって、お客様に不安を与えないことが大事です。
2-9. 相手の立場を考えた内容を伝える
例えば管理者で開発者でない立場の方は「どう開発者に伝えればよいか」という点に重きを置いている印象を受けます。
言葉尻や質問の内容から立場を察して、「開発者の方には〇〇と言えば伝わりやすいと思います」という言い回しが出来ると良いと思いました。
2-10. 「これは対処しなくても問題ないか？」という聞き方をされることがある。主観や経験則を交えず、あくまで客観的に返答する
断言しすぎると診断側の責任問題になってくるし、かといってあまりにも濁した返答をしてしまうと印象が悪いです。
主観や経験則に基づいた回答は避け、客観的・中立的な意見を述べると良いです。
2-11. 「他社はこの脆弱性の対処しているのか？」といった趣旨の質問にも対処できるようになると良い
意外とこれを気にされているお客様は多い印象です。
普段から情報収集を心掛ける、再診断の依頼があった場合は前回と比べてどう修正されたのか？という観点で確認しておくと良いです。
2-12. 対応の優先度
TODO
2-13. 診断対象のシステムのセキュリティインシデント発生状況について知る
特に直近でセキュリティインシデントが発生している場合は、通常より細かくお客様に質問されるようです。こちらの対応を変える訳ではありませんが、心の準備を...
3. 最後に
今後も報告会で学んだことがあれば追記していく予定です。
メモ書きレベルで文章が汚いので、こちらも追々修正しなければ...
4. 参考資料
なし