1．増加／高度化するサイバー攻撃
サイバー攻撃の状況についてまとめた「NICTER観測レポート2021（※1）」によると、ダークネット観測における1IPアドレスあたりの年間総観測パケット数は、2012年が53,206件、2021年は1,747,685件と、10年間で30倍以上になっています。
サイバー攻撃自体も高度化かつ組織化しています。ウクライナではサイバー攻撃により、2015年12月と2016年12月の2年連続での停電、2017年6月のマルウェアNotPetyaによる重要インフラへの甚大な被害、ロシアによるウクライナ侵攻前後にも政府機関や重要インフラへのサイバー被害などを被っています。
高度な攻撃技術と潤沢なリソースを有する組織に狙われた場合は、狙われた側は高度で執拗な大規模攻撃に長期に渡って対処し続ける必要があります。
2．大量のアラート対応に追われて疲弊していませんか？
高度なサイバー攻撃を頻繁に受けると定型的に処理することのできないアラートが大量に発生し、一つ一つのアラートに対し有識者による分析と対処が必要になります。また、分析に用いる各種ログの分量もゼロトラストモデルの導入により増大しています。
過検知や誤検知、あるいは重要度や緊急度の低い大量のアラートにも対応しなければならないセキュリティ担当者の負担は、昨今非常に大きいものになっています。担当者が疲弊すると、アラートへの対応が遅れるだけでなく判断ミスが生じたり、真に重要なインシデントを見逃してしまったりする恐れが生じます。これは情報システムを運用する多くの組織で共通の課題となっています。
図：アラート対応により疲弊する理由
高度な調査や分析が可能な有識者は世界的に不足している状態であり、インソースで人材を確保することは困難な状況です。そのため、24時間365日の監視や、真に重要なインシデントの見極めといった業務をSOC（Security Operation Center）ベンダーやMSS（Managed Security Service）ベンダーにアウトソースする企業や組織も多くなっています。
3．失敗事例？ユーザーの期待とSOCベンダーの想定の乖離
SOCやMSSをアウトソースする場合、表1の形態が大きく考えられます。
表1：SOC/MSSアウトソースの形態
SOCやMSSベンダーのサービス内容や分析ノウハウ、スタンスなどは様々です。ユーザー側で期待する要件とSOCベンダー側の想定に意識ずれが発生すると、失敗事例となる確率が上がります。ここでは意識ずれが発生してしまった具体的事例をご紹介します。
【事例】プライベートSOCの構築
ユーザーはプライベートSOCの構築や運用経験がなかったことから、SOCベンダーへの期待を要件として明確にすることができませんでした。そのため、ユーザー側の真の期待とSOCベンダー側の想定に乖離が発生してしまいました。
ユーザーがSOCベンダーへ示した要件
- ユーザーが定義したインシデント判断基準に照らし、深刻な影響を与えるインシデントを識別する
- SOCベンダーが深刻な影響を与えないと判断した場合は、ユーザーに対しその根拠を示す
SOCベンダーの解釈
- 深刻な影響を与えるインシデントか否かを識別する基準と根拠はユーザー側が提示する
- 深刻なインシデントであるか識別できない場合、ユーザーに個々のアラートを全てエスカレーションして指示を仰ぐ
SOCの運用を開始すると、SOCベンダーはユーザーが事前に示した判断基準では識別できないと判断した個々のアラートをユーザーにエスカレーションし、ユーザー側の指示を仰ぐようになりました。定型的に処理することのできない大量のアラートに対する高度な分析と対処は、ユーザー側のセキュリティ担当者が実施することになり、却って担当者の負荷が増大する状況となってしまいました。
運用開始後に明確になったユーザー側の真の期待値は以下の通りでした。
- インシデントの評価をすべてユーザーに任せるのではなく、SOCベンダーの高度な知見を駆使して一連の攻撃の流れが深刻な影響を与えるインシデントか否かを識別し、ユーザー側での高度な分析と対処は不要にして欲しい
- SOCで深刻な影響を与えないと判断した場合の判断根拠を示して欲しい
4．実際の事例を踏まえた注意点
このように、SOC/MSSアウトソース成功の鍵を握るのは、ユーザーが期待する要件の具体化と、ユーザーが期待する要件とアウトソース先の提供内容が合致するか否かの確認です。特にプライベートSOCの場合は委託可能なベンダーが少なく乗り換えが困難であるため、契約前に入念な確認が必要となります。
「対応内容と範囲」の観点については、「セキュリティ対応組織（SOC/CSIRT）の教科書（※2）」などを用いて調整を行うと網羅的な確認が可能です。また、実例を通じて得た具体的な確認内容や注意点は、INSIGHTに関連記事「これで満点！？セキュリティ組織「SOC」立ち上げの注意点（※3）」がございますのでご参照下さい。
「分析内容／レベル」の観点については、SOC/MSSPベンダーのノウハウであり具体的な開示が難しい内容であることから確認できる内容は限られてしまいます。このような制約の中でも、比較的ベンダーの多くが開示可能である以下の内容を確認することで、期待値の乖離幅を縮めることが可能になります。
表2：確認ポイントの例
また、プライベートSOCの場合にはもう一歩踏み込んで、実際の機器のアラートを含むログを提示したり、「マネージドセキュリティサービス（MSS）選定ガイドライン（※4）」のケーススタディやINSIGHTの関連記事「プロキシ（Proxy）ログ調査に重要な3つの項目（※5）」などの具体例を用いたりして、以下のような内容を確認することもご検討ください。
- 一連の攻撃活動について、ベンダー側でどのような情報提供や対応が実施可能か
- 攻撃の成功や失敗が確認できていない、定型的に処理することのできないアラートの場合は、誰がどのように影響がないことを確認するのか
- 一連の攻撃のインシデントタイムラインはどのタイミングで誰が作成するのか
5．さいごに
サイバー攻撃の増加と高度化でますます業務量が増え、セキュリティ担当者が疲弊すると、セキュリティ対応を持続することが困難な状況に陥ってしまいます。今回ご紹介した実際の事例を踏まえた注意点を踏まえてSOC/MSSを活用することで、INSIGHTの関連記事「MISPでサイバー攻撃対応力アップ！（※6）」などサイバー攻撃に対応する範囲の拡大と対応スピードアップにつなげていくことも可能になります。
今回の記事が、サイバー攻撃を防御する必要に迫られているセキュリティ担当者の皆さまの、SOC/MSSアウトソース検討の一助となれば幸いです。
