本文の内容は、2024年3月13日に CRYSTAL MORIN が投稿したブログ（https://sysdig.com/blog/ciso-takeaways-sysdig-2024-cloud-native-security-and-usage-report)を元に日本語に翻訳・再構成した内容となっております。
世界中でサイバー攻撃がニュースの見出しを飾った 1 年後、MGM リゾーツ、Clorox、T-Mobileなどの多くの組織が、ソーラーウィンズと同様の風評被害を受けました。Sysdig 2024年版クラウドネイティブセキュリティおよび利用状況レポート では、CISOがセキュリティ体制を改善するために必要な情報を提供しています。CISOとして、このようなリストに自分の組織が載ることは避けたいものです。
第7回目となる本レポートは、実際のデータに基づいています。意見に偏ることなく、クラウド・セキュリティの現状に関する事実に基づいた情報を提供しています。 そのため、このブログでは、レポートから得られた重要なポイントをいくつか取り上げ、組織ですぐに実施できるセキュリティ・リスク削減策を提案します。重要なことは、私たちは敵のスピードに追いついていないということです。今後数カ月間、サイバーセキュリティの態勢をレベルアップする際には、このマントラに従ってください。
攻撃、対応、開示のスピードを考慮する
アプリケーションを動かすワークロードが、どれくらいの速さで寿命を迎えるかご存知ですか？70%のコンテナの寿命は5分以下です。バラ色のレンズを通すと、攻撃者が脆弱なコンテナから侵入した場合、そのコンテナが停止してブートされるまでに横方向に動き回れる時間は5分しかないということになります。しかし残念なことに、攻撃者は1回目に失敗しても次のチャンスがあることを知っています。もし攻撃者が5分以内にそのコンテナを通過することに成功すれば、セキュリティチームは迅速な封じ込めだけでなく、インシデント対応アクションのためのフォレンジックデータの収集も逃してしまうかもしれません。
では、存続期間の短いワークロードはクラウド攻撃の速度には太刀打ちできないという概念にどうやって対抗できるのでしょうか? まず、実行時に使用される脆弱性の軽減を優先します。既知の脆弱性を放置しておいて攻撃者が利用できるようにしないでください。レポートによると、昨年、ランタイムの優先順位付けにより、使用されている重大かつ高レベルの脆弱性が 50% 近く減少しました。この優先順位付けにより、開かれた扉が閉まり、そもそも攻撃者が持つ機会が減ります。他の人が最も重要だと考えるものではなく、組織の環境で最も重要なものを修正してください。
- 環境内で実行されている脆弱性、特に積極的に悪用されている脆弱性を優先します。これらの脆弱性は CISA のWeb サイトで見つけることができます。運用環境に存在しない脆弱性に対処すると、組織を実際に危険にさらす脆弱性に費やすことができる貴重な時間が無駄になります。また、積極的に悪用されていない脆弱性は、悪者によって悪用されている脆弱性よりもリスクが低くなります。
- 新たな重大かつ悪用可能な脆弱性が世に出て、それがニュースになり、CISA や FBI からの警告が出たとしても、パニックに陥る必要はありません。多くの場合、セキュリティ リーダーはニュースを読んだ後に過剰反応し、脆弱なツールであるイメージが、それが何であれ、環境のどこにも存在しないことが判明します。この時点では、自分の祝福を噛み締め、メディアの熱狂を無視してください。影響がある場合は、ガイダンスに従ってください。セキュリティチームと開発者は何をすべきかを知っているはずです。
次に、潜在的な攻撃者の振る舞いを確実にリアルタイムで検出する必要があります。攻撃者は 5 分以内に侵入して移動する可能性があります。これは、おそらく 1 日の始まりに最初のコーヒーを飲み終えるか、メールを読むのにかかる時間よりも短いです。これに対抗する唯一の方法は、攻撃者が最初の行動をとったらすぐにアラートに基づいて行動することです。
2023 年のグローバル クラウド脅威レポートとSysdig の 5/5/5 ベンチマークで、Sysdig 脅威リサーチチーム (TRT) は、平均 10 分でゼロからクリプトマイナー、データ窃盗、またはさらに悪いことに至るクラウド攻撃の複数の例を提供しました。部分的には自動化の使用です。このベンチマークは目標を設定し、検出、データ相関、および対応に関してセキュリティプログラムを運用するための規範的な推奨事項を提供します。ランサムウェアやSCARLETEEL攻撃など、一刻を争うクラウド攻撃を想定して、セキュリティチームは時間との勝負を挑みましょう。これにより、ツール、アプリケーション、プロセスを変更して検出と応答時間を改善するために使用できるベースラインが提供されます。
- 数時間かけて (それ以上かからないといいのですが)、セキュリティチームとリアルタイムで机上演習を実行します。全員が揃って準備を整え、レッドチームまたは第三者に攻撃を開始してもらいます。これは、セキュリティ プロセスを合理化するための出発点となります。この演習を使用して、高度に自動化された攻撃を検出して対応するための準備ができているかを確認します。
セキュリティインシデントが発生した際、迅速な検知と対応は取締役会レベルでも役立ちます。SECの重大なインシデントに関する4営業日の要件や、CIRCIAのCISAへの報告に72時間の要件、EU NIS2の24時間以内の検出と72時間以内の開示など、規制の開示要件に設定された短い期限があります。インシデントの理解が早いほど、より良いです。
チームと一緒にこれらのタイムスケールを確認して検証してください。検出および対応プロセスのどこに自動化を導入できると考えているかチームに尋ねてください。
- この時点でセキュリティ プロセスの自動化を検討してください。AI ではなく自動化について述べたことに注意してください (ただし、これも LLM の悪い使用例ではありません)。チームがすぐにデータ分析に取り組めるように、データ相関プロセスの一部を自動化することを検討してください。対応アクションを自動化します。対応がまだ自動化されていない場合は、チームと協力して自動化を実装できる場所を決定します。ドリフトコントロールは、実行時に変更されたワークロードをシャットダウンできる、自動化されたセキュリティ対応の好例です。詳細については、レポート全文をご覧ください。
権限をしっかりと把握する
ID 管理は、ほとんどの CISO とセキュリティチームにとって悩みの種です。攻撃は通常、悪用された脆弱性または ID の問題から始まります。攻撃者はアカウントのアクセスと特権を使用してデータを収集し、ネットワークを移動するため、悪用された脆弱性でも何らかの形で ID が関与します。レポートでは、アカウント権限の 98% が未使用のままになっていると指摘しています。それは不必要なリスクが大きすぎます。
今年の使用状況レポートでは、クラウドインフラストラクチャーエンタイトルメント管理 (CIEM) を毎週使用している顧客はわずか 20% であることも指摘しました。別の CIEM を使用している可能性もありますが、それでも過剰なアクセス許可の割合を説明することはできません。
- 権限レビューに関して組織がどのような立場にあるのかを把握します。あなたの組織では、週ごと、月ごと、四半期ごと、または年ごとにアクセス許可を確認していますか? あなたの組織には、これらのレビューの実施方法に関する基準はありますか? そうでない場合は、過度に寛容な人間とマシンの ID を最小限に抑えるための ID 管理レビュー プロセスの実装を検討してください。
率直に言って、特にマシン（人間ではない）のアイデンティティに関しては、このような注目の欠如には弁解の余地がないと言えるでしょう。ただし、技術的に複雑なため、人間のユーザーやマシンがその時点で必要とするすべての許可を、その位置、プロジェクト、通常の動作に基づいて理解することは非常に困難です。報告書によると、一部のマシン ユーザーは何千もの未使用または手付かずのアクセス許可を持っており、その ID にアクセスできる攻撃者は基本的に自由にアクセスできることになります。この数字が天文学的な数字であるという事実は、問題がいかに難しいかを物語っています。ただし、この複雑な課題に対処するのに役立つアプローチがあります。
- 組織内のID 管理のステータスについてスタッフと話し合ってください。許可レビューの頻度を決定し、現在の慣行がリスクを適切に軽減しているかどうかを判断します。
- 設定したリズムに従って、最初のプロビジョニング時とその後も継続的に人間以外の権限をレビューするというガイダンスを実行してください。
- このような会話が行われ、付与された権限が依然として横行している場合は、コミュニケーションが中断されている理由と場所、および透明性が欠如しているかどうかを判断してください。セキュリティ チームは過負荷になっているか、適切なアクセス制御をサポートする適切なツールやプロセスが不足している可能性があります。
- 権限パラメータを決定して実装します。これらには、特定の役職を持つユーザーや特定のプロジェクトに従事するユーザー、および 90 日間使用されなかった場合の権限の削除などのタイムライン制限が含まれる場合があります (高リスク ID には 60 日または 30 日のパラメーターを使用することを検討してください)。これらのパラメータは自動化できますが、定期的なレビューの一部として含める必要があります。
スピードはビジネスを助けるが、利便性はセキュリティを損なう
アプリケーション パッケージがどこから来たのか、またはどのように保存されているか知っていますか? レポートによると、大多数の組織 (66%) がイメージの公開ソースに依存しているとのことです。これらの情報源は、その出所から合理的に安全であると想定されるか、一度スキャンされ、その時点から精査されたとみなされるかのいずれかです。
確かに、パブリックイメージを使用すると、ベンダー管理のサービスに料金を支払ったり、プライベートレジストリのメンテナンスに従業員や時間を費やしたりする必要がないため、コストが安くなります。ただし、これらのパブリック レジストリではセキュリティ管理の実施が制限されているため (組織の管理下にないため)、ソフトウェアサプライチェーンのリスクに対して脆弱なままであることを認識しましょう。パブリックソースを使用している場合は、組織が管理可能と判断するペースで定期的かつ一貫してスキャンされていることを確認してください。スキャンと修復の管理をオープンソースエンティティに依存すべきではないことが肝要です。
- ソフトウェア構成分析 (SCA) と呼ばれる自動ツールの使用を検討して、オープンソースソフトウェアを特定して分析し、アプリケーションのソフトウェア部品表 (SBOM) を生成します。
- 前に提案したように、脆弱性とリスクに優先順位を付け、それに応じて修正して攻撃のリスクを軽減します。悪用されたことが知られている脆弱性と、実行時にワークロードに影響を与える脆弱性に焦点を当てます。
セキュリティよりも利便性が優先される可能性があるもう 1 つの領域は、リソースの制約です。残念ながら、多くの組織は上限を設定していないか、CPU やメモリの使用量に関するアラートを受け取っていません。これは、攻撃者が環境にクリプトマイナーを投下し、そのリソース消費に対して料金を支払わせるときに当てにしているものです。制限は開発と生産性の妨げになるため、リソースが無制限であればビジネスの運営が速くなり、利益が増えるという意見があります。ただし、あなたが支払っているリソースをクリプトマイナーが使用できるようになる場合、その利益は減少します。
- リソース制限を実装し、 80% (または適切と思われる値) でリソース消費がトリガーされるアラートをオンにし、必要に応じて制限を見直します。
- キャパシティプランを確立し、特定のワークロード、プロジェクトなどのリソース パラメーターを実装することで可用性を確保し、インシデント発生時における組み込まれた復元力を確保しましょう。たとえば、環境またはワークロードの制限を区分し、そのうちの 2 つの制限をそれぞれ 40% に設定すると、一方に障害が発生した場合、またはプルダウンする必要がある場合に、もう一方の側が余裕を持ってワークロードを引き受けることができます。
まとめ
Sysdig の最近のレポートから得られる CISO クラウドセキュリティの最大のポイントは、組織が日常的にガバナンスとセキュリティよりも運用と便宜を優先しているということです。これは予期せぬリスクを引き起こす可能性がありますが、率直に言って、回避することは可能です。
リスクを軽減するには、セキュリティをビジネスの速度で運用する必要があり、CISO にとって、ビジネスと歩調を合わせることは最優先事項です。一刻を争う開示要件 (最近の SEC 規則を思い浮かべてください) や注目度の高い違反は、現在、経営層および取締役会レベルの注目を集めています。CISO は、リスクをどの程度タイムリーに検出して対応できるかを継続的に評価する必要があります。ビジネスのスピードで業務を遂行するために、CISO とそのチームはテレメトリと自動化に重点を置く必要があります。
CISO として、たとえ他の人がどんなに反対しても、ビジネスにセキュリティを導入するのはあなたの責任です。セキュリティ活動がビジネスと一致していることを確認する必要があるため、ビジネスにおける同僚と時間をかけて優先順位と取り組みをよりよく理解し、セキュリティへの取り組みがそれに応じて一致していることを確認することが最も有益です。
リスクを早期に把握して軽減すると、企業価値を損なう可能性のある注意散漫のリスクが軽減されます。SolarWinds、T-Mobile、Equifax など、ニュースで大規模な侵害があったことを他の人に思い出してみましょう。あなたの CEO や CFO は、彼らのようになりたいと思っていますか？ 答えはおそらく「ノー」です。したがって、セキュリティをビジネスの最前線に据え始め、行動を起こすかどうかはチーム次第です。