社内セキュリティレポートの始め方 - ウェルスナビ開発者ブログ

みなさん、はじめまして。セキュリティチームの岡地です。もともとはSierでインフラを担当し、セキュリティ製品ベンダーでの技術職を経て、企業内のセキュリティ担当として働いています。ウェルスナビには昨年12月にへジョインし、セキュリティアラート監視、脆弱性管理、インシデント対応等を担当しています。

本記事では、当社で今年から始めたセキュリティレポートの取り組みをテーマにお送りします。地味なテーマで恐縮ですが、同じ立場でお仕事をされている方の参考になれば嬉しいです。

ここでいうセキュリティレポートとは？

セキュリティレポートと聞いてどういったものを連想されるでしょうか？

公的機関から発行される、最近のセキュリティ脅威動向や注意喚起に関するレポート
セキュリティベンダーから発行される、最新の攻撃手口を解説したレポート
民間企業がステークホルダー向けに、自社の情報セキュリティの取り組みを情報開示する報告書
民間企業内で、経営層や従業員に自社のセキュリティ状況を報告、共有するためのレポート

私の方で、すぐ思いつくものを上に挙げてみました。特に1，2については日々の情報収集のうえ、セキュリティ対策の強化に活用させて頂いております。しかし、本記事で扱うセキュリティレポートは上記のうち、4に分類されるものです。

企業内でセキュリティレポートが必要な理由

なぜ、セキュリティを生業としない会社において、セキュリティレポートを作成し、共有する必要があるのでしょうか？まず、建前論的な回答としては、経済産業省とIPAが策定するサイバーセキュリティ経営ガイドラインで求められているためです。同ガイドラインでは、サイバー攻撃から企業を守るために、経営者が認識すべき「3原則」と、サイバーセキュリティ経営の「重要10項目」がまとめられています。これを実現するうえで、組織内のセキュリティリスクを把握できる形で可視化したレポートを定期的に作成し、しかるべきレイヤーに報告をあげることは、企業内セキュリティ担当の仕事だと考えています。

一方で、担当者目線で考える、もう少し切実なモチベーションとしては以下のようなことがあげられます。 - 様々なセキュリティ対策を導入しているが、実際のところどの程度防げているのか、どの辺りが危ういのか、すぐ分からなくて不安 - 日々、新しい攻撃情報のニュースが流れてくるが、当社の状況を体系的に整理できていないと、影響有無の判断が困難 - 新しいセキュリティ対策を検討するにも、自社のリスクを根拠を持って説明できないと、納得感のある社内提案ができない

リスクの定義を、リスク＝脅威 × 脆弱性 × 資産とすると、外部の脅威状況とともに、自社のことを正確に理解していることが重要です。 これを継続的に実現する仕掛けとして、セキュリティレポートが有効と考えています。

セキュリティレポートの始め方

では、ここからタイトルの通り、当社におけるレポートの始め方を説明してみたいと思います。

❶フォーマットを決める

セキュリティ対策の難しいのは、大部分の領域でしっかりと対策が出来ていても、一部の対策漏れやセキュリティホールがあるとそれをつかれて大きな被害をもたらすケースがあるという点だと思います。このため、セキュリティレポートを作る上でも、自社におけるセキュリティに関する事象を余すことなく取り上げられていることが"理想"です。これを念頭に、まず報告フォーマットや項目を検討します。

- 大項目：扱っている領域や属性
  - 中項目：対象の種類
    - 小項目：詳細な数値

特に大分類をどう置くかでレポートの見え方が大きく変わるので重要です。当社ではJNSAさんが提案するCISOダッシュボードに書かれたCISOダッシュボード主要項目を採用しました。CISOダッシュボードは、「経営会議において情報セキュリティに関する状況を適切に報告し、必要な施策に関する経営会議での了解を得る」ための内容を取りまとめたものとされています。

これを採用した理由は大きく下記の2点です - 組織がセキュリティとしてケアすべき領域がシンプルに分かりやすく定義されていて、網羅性も保ちやすい - 異なる領域で発生した事象を一つのレポートの中で関連付けて説明することが可能

セキュリティレポートを始めてから継続していくと、セキュリティ施策が積み上がり報告すべき事項は増えていきます。この時、大きく構造を変えずに吸収できるような項目でレポートが作られていることが望ましく、CISOダッシュボードであればそれが可能と感じました。また、各領域の事象を一つのレポートの中で関連付けて報告できる点は非常に有用だと感じています。例えば、特定のインシデント（Attack condition）に対する再発防止を、Protection conditionの中で進捗報告を継続する、といった使い方をするイメージです。

ベースが決まれば、あとは自社で該当する対策を紐づけて整理していく作業となります。当社では下記のような構成とし、冒頭にエグゼクティブサマリーページを配置するフォーマットとしました。

- Attack condition
  - トピック
  - 概況  
    - サービスへの攻撃
    - オフィス環境に対するネットワーク経由での攻撃
    - オフィス環境に対するメール経由での攻撃
- Protection condition
  - トピック
  - 概況  
    - システムの脆弱性保有状況
    - オフィス環境の脆弱性保有状況
    - 定期セキュリティパッチ適用状況
    - アカウント棚卸し状況
- Suspicious activity
  - トピック
  - 概況  
    - サービス上の不審な挙動検知
    - サービス上の不審なログイン検知
    - 業務用アカウントの不審な挙動検知
    - 情報漏えいの疑いがある挙動や通報の検知
- Indirect activity
  - トピック
  - 概況  
    - 社給デバイスの紛失
    - フィッシングサイトの検知

❷リスク評価指標（KRI）の設定

フォーマットが決まったら、次に決めておいた方がよい重要事項が、報告書内で利用するリスク評価指標の定義です。

こういったレポートの罠として、集めた数値に翻弄されて本質を見失う可能性があります。例えばWAFを例に挙げると、前提として外部から公開サーバに対する攻撃を検査する製品なので、定常的に処理するトラフィック量が多く、増減の幅も大きくなりがちです。この場合、ブロック件数が増える度に分析してレポートする本質的ではない議論を喚起してしまい、結果的に報告者も報告を受ける側も疲弊してしまいます。

こういった事態を避けるために、自社にとって意味のあるポイントで数値を抽出し、被害の発生可能性および発生時インパクトの２つの観点でしきい値を設定することが重要です。当社ではリスク評価の原則的な考え方をイメージ化した上で、各監視対象ごとにKRIを仮設定し、レポートでの実績を踏まえながら調整を検討していこうと考えています。ただし、KRI（Key Risk Indicator）自体もあまり柔軟に変え過ぎるのも避けたいので、なかなか調整が難しいと感じています。

❸定期的な報告の場を確保する

最後に、セキュリティレポートの内容を読んでもらいたいレイヤーに報告するための場を確保します。新しく始める場合は特に、導入として目的と全体像を丁寧に説明する必要がありますので、口頭での説明が望ましいです。また、定例化して継続することで、例えば以下のように連続性を持った報告が可能になります。 - Attack condition - 異常な概況に気づき、これを改善する対策の実施状況について継続的に報告する - Protection condition - ある時に見つかった課題に対する改善策の進行状況について継続的に報告し、具体的な改善状況をレポートの指標として示す

まとめ

セキュリティレポートの始め方、いかがでしたでしょうか？タイトル的に一応、断定口調で書いてみましたが、当社でもまだ手探りではじめた施策ですので、もし良い事例をお持ちの会社様がいらっしゃいましたら意見交換させて頂けるとうれしいです！

最後にセキュリティレポートをはじめて良かった点と今後の展望を書いて締めたいと思います。

良かったこと

担当者としても自社の定常的なリスク状況が把握や気づきが得やすくなった
- さらにこれを定期的に報告することで上位層にも常に共有できている状況が作られた
レポートとして整理することで、改めて不足している箇所（課題）が鮮明になった
- レポート上もあえて空白で作成し、改善活動をすることで改善も見える形になった
セキュリティに関する話題を有識者と定期的にする機会を創出できた