SecOpsの民主化が必要、SOCの縮小ではなく

An increasing complexity of technologies, as well as an increasing number of failures and attacks followed by an increasing dependency on business goals, is changing the way we run Security Operations Centers.

技術の複雑さが増し、失敗や攻撃の数が増加し、ビジネス目標への依存度が高まる中で、セキュリティオペレーションセンターの運営方法が変わりつつあります。

I previously discussed the concept of a Fusion Centre as an imperative to respond to the second trend. While bringing business experts into a SOC function might help security professionals get a better alignment with the business and strategize the SOC, it will not address all the scalability and agility problems inherent in a SOC.

以前、第二のトレンドに対応するための必須事項として、フュージョンセンターの概念について議論しました。ビジネスの専門家をSOC機能に取り込むことは、セキュリティ専門家がビジネスとの整合性を高め、SOCの戦略を立てるのに役立つかもしれませんが、SOCに内在するすべてのスケーラビリティとアジリティの問題を解決するわけではありません。

SecOpsにおけるSOARを活用したサイバーセキュリティ自動化の実装方法

自動化は明らかな解決策です。だからこそ、ほとんどのSOCがセキュリティオーケストレーション自動化と対応（SOAR）プロジェクトを優先しているのです。これは、SOCプレイブックを自動化するための素晴らしい基盤です。

一部のCISOは、SOARをDevSecOpsの基盤と見なしています。私にとってもこれは理にかなっています。というのも、ほとんどの従来のSOCアナリストはソフトウェアエンジニアリングや開発者のバックグラウンドを持っていないからです。この場合、ローコードまたはノーコードのSOARプラットフォームは、SOCプレイブックを自動化し、DevOpsや増大するビジネスの監視とIRの需要に対応するための完璧な戦術的解決策です。

「SOCに自動化を導入することで、セキュリティ運用モデルが一変します。」

自動化の旅の最初の質問は通常、どこに焦点を当てるかです。 残念ながら、既存のプレイブックをそのまま自動化プラットフォームに組み込むSOCをよく見かけます。おそらく、既存のプレイブックは、規制要件や他のコミットメントのために、あまり変更せずに自動化するのに十分かもしれません。

一方で、このアプローチには根本的な欠陥があります。過去の他の変革の旅でも見られたように、例えば、パブリッククラウドへの急速な移行と緊急の配信が、多くのCIOに「リフトアンドシフト」戦略を採用させ、アプリケーションをリファクタリングしてパブリッククラウドのすべての利点を享受することを怠らせました。結果として、迅速な配信は実現しましたが、可能な利益の表面をかすめただけでした。

SOCに自動化を導入することで、セキュリティ運用モデルが一変します。 ほとんどのタスクを自動化できるSOCは、すべてをより迅速に完了することで効率を高めるだけでなく、セキュリティオペレーションの方法を革命的に変える可能性があります。 自動化により、プレイブックを光の速さで実行し、すべての従業員と顧客に合わせた体験を提供するための無限のスケーラビリティを維持できます。

「時間が経つにつれて、SOCの『O』と『C』は徐々に消えていくでしょう。」

SecOpsの現状

SecOpsの進化は、特に大規模な組織において、サイバーセキュリティの効果を向上させる必要性によって推進されてきました。SecOpsは、セキュリティに対する反応的なアプローチから、より自動化とオーケストレーションに焦点を当てた積極的なアプローチへと進化しました。

SecOpsの課題には、環境の複雑さと既存のプロセスやシステムとの統合の必要性が含まれます。組織は、資産とデータを安全に管理しながら、コンプライアンスと規制要件を満たす必要があります。さらに、SecOpsチームは、セキュリティイベントを迅速に検出し、対応する能力を持たなければなりません。

過去には、組織はセキュリティイベントが発生した後にのみ対応し、手動プロセスを使用することが多かったです。今日では、SecOpsチームは自動化を使用して手動作業を減らし、セキュリティイベントをより迅速に特定、対応、軽減することを可能にしています。

業界をリードするセキュリティオペレーションセンターがこの自動化の旅にどのように取り組んでいるか、いくつかの例を見てみましょう。

• Amazon AWSは、しばらくの間、集中型SOCを持たないと主張しています。すべてのアラートは直接スタッフにエスカレーションされ、監視システムを監視するエンジニアは一人だけです。これは多くの組織にとっては幻想のように聞こえますが、ほとんどの組織はグリーンフィールドアプローチとエンジニアの軍隊を持つ特権を持っていません。
• Palo Alto Networksでは、30/30/30モデルと呼ばれる方法を適用するセキュリティオペレーションエンジニアの小グループがあります。アナリストは、30%の時間を高精度のシグナルのトリアージに、30%を検出分析の構築と調整に、30%を脅威ハンティングとレトロスペクティブ分析に費やします。ほとんどのアラートは、最初に影響を受けた従業員にトリアージのために送られ、特定のフィードバックやアラートのしきい値に達しない限り、SOCアナリストは関与しません。この方法には明確なコストメリットがあります。必ずしも高価な24/7のローテーションモデルが必要ではありません。ほとんどのアラートは自動化でカバーされ、業務時間外にアラートがしきい値に達した場合には、担当のアナリストが対応します。
• 最後に、Googleは、強力で多様なセキュリティ専門家のグループで知られており、最近このトピックに関するホワイトペーパーを発表しました。彼らは、内部でのセキュリティ運用と従来のSOCを自律的なセキュリティオペレーションに変革する際の教訓を共有しました。このホワイトペーパーでは、Anton Chuvakin氏とその同僚が、クラウドの採用がセキュリティオペレーション戦略の変革の主要な推進力であると主張しています。時間が経つにつれて、「SOC」の「O」（オペレーション）と「C」（センター）は消えていくでしょう。結果は上記の概念と非常に似たものになるでしょう：SOCレス組織。

SecOps自動化の課題

セキュリティコミュニティは、この自動化のトピックについてしばらく議論してきました。それでは、なぜSOCにとって自動化が依然として大きな問題なのでしょうか？一部の慎重なCISOに尋ねると、彼らの躊躇は技術的なものであると答えるでしょう。例えば、「まだコントロールをインストゥルメント化しようとしている」や「プレイブックによれば、自動化が安定性の問題を引き起こす可能性がある」といった具合です。しかし、フィードバックは主にSOC自体の要件に集中しており、ビジネスチームや労働力の要件ではありません。

これが自動化の問題の核心かもしれません。私たちはしばしば、内部顧客によって確立された問題と要件を再確認することを忘れがちです。SecOpsのヒーローとして、私たちは（誤って）ほとんどの従業員が問題を理解していないと信じ、傲慢にも私たちだけが正しくできると仮定します。私たちは魔法使いであり、すべての従業員はマグルです。しかし、従来のSOCの問題の多くは、ビジネスコンテキストの欠如したアラートに関連していることを忘れてはなりません。

「私たちはしばしば、内部顧客によって確立された問題と要件を再確認することを忘れがちです。」

では、自動化の旅において、より顧客中心の視点をどのように考慮できるでしょうか？私のCISOの同僚の一人は次のように要約しました。「今日、従業員やビジネス機能は、セキュリティチームから受け取るアラートの可視性と数に関して選択の自由を持ちたいと考えています。彼らが責任を持ち、リスクを理解している限り、私たちはこの快適さを提供しますが、スポットチェックを行って確認します。」

実際には、このような民主化されたSOCモデルは、組織ごとに非常に異なるものになる可能性がありますが、この戦略の良い例がいくつかあります：

• データ漏洩検出は、展開が最も難しく、これまで存在した中で最も騒がしいサイバーセキュリティコントロールです。DLPアラートの中央レビューは効果的でなく、コストがかかるだけでなく、データプライバシーにも大きな影響を与えます。統計によれば、ほとんどのデータ漏洩は意図的ではありません。したがって、これらのアラートを直接該当する従業員とそのマネージャーにエスカレーションし、問題を理解する手助けをすることで、最終的には会社にとって最高の投資利益率を生み出すでしょう。データセキュリティ文化を改善することは、ゲームチェンジャーとなる可能性があります。
• アプリケーションの欠陥や設定の問題。 SOCアナリストがアプリケーションセキュリティの問題とDevOpsチームの間のギャップを一貫して埋めることができると本当に信じていますか？すべてのDevOpsチームは、シンプルな原則を理解しています：あなたが作ったものは、あなたが運用する。CISOとして、この原則に「あなたがセキュリティを確保する」を追加する必要があります。
• CISOとそのチームは、SDLCまたはCI/CDパイプラインの一部として、適切な優先順位付けされたポリシーとガードレールを定義し、構成することで、SOCに価値を追加します。すべてのアラートは、レビューと処理のために直接該当するDevOpsチームに送られます。例：Google Cloudでの新しいプロジェクトが不適切な設定でライブになると、自動的にシャットダウンされ、修正のためにDevOpsチームにエスカレーションされます。例外はありません！
• フィッシング。 そうです、2021年であり、誰もがフィッシングについて知っており、それに対処する方法を知っているべきです。従業員に力を与え、ブロックされていないフィッシングメールのアラートを彼らにエスカレーションすることで、アナリストがより重要なタスクに集中できるだけでなく、従業員の意識も高まります。
• コンプライアンス監視。 一部の業界規制当局は、システム管理者の活動や重要なアプリケーションへのアクセス試行の監視を義務付けています。これらのアラートを直接該当するチームにエスカレーションすることには、インサイダー脅威のような明らかなリスクがありますが、中央集権的なSOCがこれらの活動をSMEの助けなしに解釈できると仮定するのは狂気だと思います。したがって、これらのアラートを直接部族リーダーや専任のセキュリティ専門家にエスカレーションしてはどうでしょうか？
• 最終的には、ネットワーク侵入やマルウェアイベントのような従来のSOCアラートが残りますが、これらはSOCの専門家によってのみ処理されることができます。一方で、ほとんどの現代のIPS/サンドボックス技術は、これらのアラートを直接予防的なシグネチャに変換することができます。したがって、すべてのアラートをレビューし、トリアージする必要はありません。SOCが保持する唯一の中央運用機能は、インシデント対応と、データやマルウェアを遡って調査し、ポリシーと分析を改善する専任の脅威ハンティング/フォレンジックチームです。

民主化されたSOCのユースケースのリストは続けることができますが、私が伝えたいポイントは、自動化されたSOCは常に顧客と共に解決しようとしている問題を再評価することから始めなければならないということです。プロセスを民主化するには、常に双方向のアプローチが必要です。労働力を教育し、範囲についての同意を得てから、彼らを拡張されたSecOpsアナリストとして活用し始めます。

理想的には、SOCに自動化を導入する前にこれを行います。何を異なる方法で行うか、またはまったく行わないかに驚かれることでしょう。その結果、一部の組織はSOCレス組織のビジョンを達成するかもしれませんが、現実には、ほとんどの組織はレガシーインフラストラクチャやプロセスを管理するための中央チームを依然として必要とするでしょう。

同時に、より多くの従来のSOCの責任が会社の労働力に移行し、彼らが自分自身のセキュリティオペレーションに責任を持つようになります。これが民主化されたSOCです。

SecOpsの未来

SecOpsは、より積極的なセキュリティ管理に向けて進化し続けます。これには、セキュリティプロセスのさらなる自動化、潜在的な脅威の検出、データ侵害の防止が含まれます。人工知能（AI）と機械学習（ML）は、潜在的な脅威を特定し、データを分析し、応答時間を支援するために使用されます。さらに、組織はクラウドベースのサービスを使用してセキュリティオペレーションを集中化し、手動プロセスを削減し、セキュリティチームの時間を解放します。セキュリティチームは、SecOpsで成功するために、技術的、分析的、コミュニケーションスキルを組み合わせたマルチスキルを持ち続ける必要があります。