SECのサイバーセキュリティに関する新しい規則の概要と企業に求められる対応

米国証券取引委員会(SEC：The United States Securities and Exchange Commission’s)は7月26日、サイバーセキュリティ「インシデント」の情報開示に関する新しい規則を採択しました。この規則は、すべての上場企業に適用されるため、これらの企業にとっては、規則の内容と企業が負う責任を理解しておくことが極めて重要です。SECがこの規則案を初めて公表したのは2022年3月ですが、サイバーインシデントの情報開示については10年以上前から協議されてきました。では、その内容を見ていきましょう。

新しい規則は2023年後半に施行される予定で、上場企業(登録企業)に対して、セキュリティインシデントが発生したときに、そのインシデントが「重大」だと判断された場合は、4営業日以内に情報を開示することを求めています。報告期限には例外があり、当該インシデントの情報開示によって国家や公共の安全が脅かされる可能性がある場合は猶予が与えられます。ただし、例外の適用には米国司法長官の承認が必要です。

この規則で特に興味深いのは、重大なサイバーセキュリティインシデントについて開示義務があるのはその影響についてであり、技術的な詳細(悪用された脆弱性や侵害の兆候など)の開示は必須ではない点です。登録企業に求められるのは、インシデントの性質、影響範囲、発生時期と、登録企業が受けた重大な影響または今後受ける可能性の高い重大な影響(財務状況や経営成績など)に関する報告です。

新しい規則では、サイバーインシデントの情報開示に加えて、サイバーセキュリティに関するリスク管理、戦略、ガバナンス、リスク要因などの情報を定期的に報告することも義務付けられています。 

つまり、この規則で企業に求められるのは、インシデントの技術的な詳細を説明する能力ではなく、対応と報告を適時に行うための次の2つの能力を備えることです。

• 1つ目はスピードです。サイバーセキュリティインシデントが「重大」だと考えられる場合は4日以内に情報を開示する必要があるため、企業はさまざまなツールとソースからテレメトリをすばやく収集、分析して、イベントの重大度を特定し、SECへの報告が必要かどうかを判断できる体制を整える必要があります。そのためには、極めて協調的で洗練された部門横断チームを構築することが必要です。
• 2つ目はレジリエンスです。  レジリエンス戦略を推進すれば、障害に強い組織になれます。問題が発生しても、それをすばやく検出してデータをバックアップから回復できれば、投資家に影響が及ぶような重大な問題に発展するのを回避して、報告が不要になる可能性もあります。  MTTD (Mean Time To Detect：平均検出時間)に関連する新しい指標として、MTTD-ROR (Mean Time To Detect, Respond to Obviate Reporting：平均検出時間の短縮によって報告を回避できた対応率)なんてものも生まれるかもしれません。

レジリエンスを早期に実現するためのロードマップ

サービス障害の原因は同じように見えることが多々ありますが、問題をすばやく解決するには、状況を包括的に把握できる必要があります。障害発生時には、ビジネスリーダーから、セキュリティ運用チーム、IT運用チーム、監査担当者、エンジニア、開発者、アーキテクトまで、幅広い関係者がそれぞれの役割を果たします。では、予期しないサイバーインシデントに備え、すばやく復旧できるようにするには、何をすればよいでしょうか？

まずは、サイバーレジリエンスを実現するために必要な人材、プロセス、テクノロジーに十分に投資することです。これにより、セキュリティ運用チーム、IT運用チーム、エンジニアリングチームは、適切なツールを介して協力し合い、重大な問題を防止し、迅速に修復できるようになり、さらにはトランスフォーメーションの加速にもつながります。 

Splunkを含む上場企業はSECの新しい規則への対応を通じて、以下のようなテクノロジーを活用してIT/OT運用の可視性を向上させることにより、レジリエンスファーストのアプローチを実現できるでしょう。

• オンプレミス、クラウド、ハイブリッドのいずれの環境でも全体をリアルタイムで可視化し、セキュリティイベントとオブザーバビリティイベントの両方を自動的に分析する。
• セキュリティ分析、脅威インテリジェンス、強力な調査機能、SOARとシームレスに統合して、単一の最新UIで監視し、意図的な攻撃と運用上の問題(ソフトウェアの不具合や設定ミスなど)を切り分ける。

サイバーレジリエンスを強化してSECの情報開示要件を満たすためのSplunkの活用方法について詳しくは、こちらをご覧ください。

このブログはこちらの英語ブログの翻訳、前園 曙宏によるレビューです。