セキュリティはセキュリティチームだけの責任ではなく、全員の責任です。
多くの場合、他の部門がセキュリティタスクに協力します。例えば、バックアップは IT 部門が行うことが多く、開発者はしばしばインフラストラクチャをコードとして作成します。
他の部門との協力関係をすべて RACI (Responsible: 実行責任者 / Accountable: 説明責任者 / Consulted: 協議先 / Informed: 報告先) チャート(責任分担表) に文書化してください。
例えば、IT がバックアップの実行責任者であり、セキュリティチームはバックアップが適切に行われていることを管理する説明責任者です。バックアップの頻度とストレージ階層の定義は、おそらく別のタスクで、セキュリティが実行責任者ですが、ビジネス部門は要件について協議先となります。
サイバー攻撃はブロックされ、通常のトラフィックは許可されますが、セキュリティチームがブロックすべきかどうか明確でない異常なケースもあります。このような状況では、セキュリティチームが決定を下すのは適切ではありません。多くの場合、セキュリティチームにはリスクの低い異常をすべて調査するリソースがありません。このような状況では、ビジネスオーナーに潜在的な損失と疑わしい理由を示し、承認または拒否のフィードバックを求めるための体制を整備することが望ましいでしょう。
例を見てみましょう。
重大なアプリケーションの脆弱性に対する攻撃が検出された場合、ビジネス関係者に許可するかどうかを問い合わせることはせず、単純にブロックします。
しかし、AWS WAF のレートベースルールで検出された大量の注文など、IP アドレスのプールに関連する異常な動作が検出された場合、アプリケーションに大きな負荷がかかるだけで、アプリケーションの安定性を損なうことなく対処できます。それらの IP アドレスに関連する認証済みユーザーの名前を追加して情報を充実させ、ビジネス関係者にメールを送信して検出結果の詳細や状況を説明し、彼らの基準に基づいてトラフィックの継続を許可するか、ブロックするかの決定を任せることができます (例えば、それらのユーザーの作成日、過去の成功した取引の数、評判の低い連絡先データの使用など、不正の指標を考慮することができます)。
このようにして、どのセキュリティチームにとっても最も希少なリソースである資格のあるセキュリティスペシャリストを大切にし、彼らが運用面のタスクではなく、戦略的なアクションを取れるようにすることができます。