Luke Richards、Dmitriy Beryoza、Kat Traxlerによるレポート。
最近Oktaで発生したセキュリティインシデントは、サプライチェーンの侵害の別の見方を示している。この攻撃は完全には実現されなかったようで、その結果、被害を受けた企業の数は明らかに限られているが、IDPに対するサプライチェーン攻撃が完全に実現された場合にどのようになるかという点で、考えるべき興味深い一連の問題を提起している。IDPが侵害された場合、あるいは同様の普及型技術が侵害された場合、数百万人のユーザーと数千の企業にアクセスできる攻撃グループが出現する可能性がある。
KaseyaやSolarWindsのような最近の有名な侵害事件が思い浮かぶ。 しかし、アカウント管理に焦点を当てたサプライチェーン攻撃のようなものは、セキュリティチームが何をする必要があるのか、紙の演習を通して考えると恐ろしい。
アカウントへのアクセスは、最近の侵害の 85%に関与しています。 アカウントは、ペイロードや監視対象エンドポイントとの接触を必要とせずに、クラウドパブリッククラウド SaaSアプリケーションで管理されたリソースからネットワーク資産に至るまで、攻撃者に組織内のほぼすべてのものへのアクセスを提供します。
何が起こった可能性があるのかという疑問が提起されたことを踏まえ、IDP またはその他の ID に特化したソフトウェアがサプライチェーン侵害に関与した場合に、セキュリ ティチームが取るべき推奨事項を以下に概説する。これらの推奨事項は、サプライチェーン攻撃以外の手口によるアカウントの侵害にも適用される。攻撃者から見れば、サプライチェーンはアカウントを侵害する多くの方法の 1 つに過ぎない。攻撃者がどのように侵害されたアカウントを活用して標的環境内で目標を達成するか、また、防御者がどのように検知 、それらの行為に対応するかは、侵害の最初の方法に関係なく本質的に同じです。
現状を評価する
情報漏えいに関する可能な限りの情報を入手する。
第三者を巻き込んだ侵害が発生した場合、影響を受けた組織が公表する統制された情報と攻撃者の発言から、何が発生しているのかの全体像をまとめるのは難しいかもしれません。インシデントの程度を推定するために、独立したセキュリティリサーチャーのコメントなど、複数の情報源を分析に加味する。
侵害の大まかな時間枠を決める
セキュリティイベントのニュースは、攻撃の数週間後、あるいは数カ月後に報道されることもある。可能な限り多くの IoC を発見するために、網を広く張り、悪意ある活動が発生した可能性のある現実的な時間枠を定義する。
アイデンティティ・プロバイダーが触れるすべてのものの棚卸しを行う
現代の企業は何百もの異なるサービスやアプリケーションを使用しており、SOCでさえインベントリの正確な把握が困難な場合があります。知らないものを適切に保護することはできないため、侵害のあらゆる結果をカバーするためには、プロバイダーがサービスを提供するすべてのエンティティに関する完全な知識を取得することが極めて重要である。
ログの最近のアクティビティとトリガーされたアラートを確認する。
確立されたプロバイダーは、環境内のすべての重要な活動の適切なログを持っているはずです。新しい管理者ユーザ、昇格した権限、冗長化されたアクセス認証情報、新しくインストールされたアプリケー ション、登録されたデバイスなど、攻撃者が企業内に侵入する足がかりとなる可能性のあるものを発見するために、時系列 推定をもとに、システム構成におけるすべての関連する変更をレビューする。ログに記録されたセキュリティ・アラートも評価する必要があります。
冗長アクセスを提供する可能性のあるその他の変更を調査する。
利用可能なロギングが有効になっていなかったり、適切でなかったりすることがあります。現在のセキュリティ設定を見直して、通常とは異なる変更が行われていないかどうかを確認することは、時間をかける価値があります。
悪意のある変更を阻止する
悪意のある設定変更のロールバック
検知された悪意のある変更はロールバックされるべきである。侵害の全体像をまとめ、さらなるフォレンジック活動を支援するために、その全詳細を記録すべきである。
ユーザーパスワードのリセット
個々のユーザ・アカウントが侵害された可能性があると思われる場合、ユーザ・クレデンシャ ルのロールオーバーを強制することは必要なステップかもしれません。このステップはユーザベースには不評であろうが、実行は簡単であり、アカウント侵害の可能性に対処するための実際的なステップである。
鍵と証明書のローテーション
アプリケーションやサービスの認証情報をリセットするのは、通常、もっと複雑で手間のかかる作業である。関連する機密が流出した場合はやむを得ないかもしれないが、それに着手する前に必要であることを確認すること。
すべての過剰なサードパーティの許可を取り消す
一部の ID プロバイダ(Okta を含む）は、テナント設定へのアクセスおよび変更、またはシス テムのデバッグを実行する許可を顧客に要求できる。プロバイダの危殆化に直面した場合、すでに付与されたそのようなアクセス権を取り消すことが賢明である。
守備の強化
現在のセキュリティ設定を確認する
これも当然の措置である。セキュリティインシデントは、現在のセキュリティ設定を見直し、強化する絶好の機会です。Azure ADとM365コントロールの設定のギャップをスキャンして特定できるSiriuxのようなセキュリティ姿勢管理製品は、大きな助けになる。
監視ソリューションの導入
最もよく構成されたセキュリティソリューションであっても、侵害を免れることはできない。人的要因やサプライチェーン攻撃(IdPの侵害など）は、外部の防御をバイパスする可能性があります。 インシデントが発生した場合に対処するには、Vectra Platform のような、悪意のある活動を監視し、攻撃者の進行を阻止するための効果的な検知とレスポンスソリューションが必要です。
インシデントのレビューレスポンス プレイブック
理想的には、アイデンティティ・プロバイダーでのインシデントに対する計画がすでにあり、 今まさに実行していることである。準備態勢にギャップがあることに気づいた人は、この機会に、企業が依存している重要なイ ンフラ・プロバイダの侵害による影響に対処する計画を実施すべきである。
第三者監査を検討する
塵も積もれば山となる、であるが、セキュリティ体制が適切に設計され、明らかな穴がないことを検証するために、信頼できるセキュリティ・プロバイダーによる第三者監査を予定しておくとよい。
漏洩したアカウントの兆候とは？
つまたは複数のアカウントが侵害された場合、その影響はすぐに明らかになるとは限りません。アカウントが実行できるアクションは多様であり、資産がどのように管理されているかにもよるため、侵害されたアカウントのシグナルは、最も一般的には、貴重なサービス、機能、ホスト、またはデータへのアクセスに関連する異常なアクティビティとして特徴付けられる。 何が異常で、何が価値あるものかを定義することは、明らかに単純な作業ではない。
ネットワーク上のActive Directoryのログを調べたり、クラウドサービスによって記録されたアクションを確認することは可能だが、問題の規模と曖昧さは、何が異常で攻撃者の目的に沿っているかを理解するためにAIソリューションを使用するのが最適である。 これは、誰が危険にさらされているのかを正確に把握できないまま、認証情報、アクセストークン、そして潜在的には秘密鍵を再ロールすることになるシナリオに直面した場合に特に重要である。
Vectra は、ハイブリッド(クラウド)、SaaS、AWSにまたがるお客様のビジネスにおいて、侵害されたアカウントを持つ攻撃者の行動を監視し、対応するために、セキュリティ主導のAIを適用します。 アラートは、何が異常であるかだけでなく、攻撃者の行動に焦点を当てています。VectraのPrivilege Analyticsのような技術は、ハイブリッドクラウド と純粋なSaaS環境の両方におけるアカウントとアセットの価値を自動的に理解し、過去のアクティビティに基づいてアセットの価値を理解することで、異常事態を理解することができる。
漏洩したアカウントやリスクの高いアカウントを手動で調査
Vectraのようなプラットフォームの恩恵がない場合、脅威ハンターは、インシデントの詳細と、IDPがどのように自社の環境と相互作用しているかを評価し、侵害が疑われる潜在的なアカウントを特定する必要がある。Oktaのケースでは、IDPインフラストラクチャ内で攻撃者が制御している開示された期間中のアカウント変更を調べることが一例として挙げられます。
通常の運用 セキュリティオペレーションでは、アナリストはドメイン管理者やサービス・ アカウントのような知名度の高いアカウントの監視に特別な労力を費やすことがある。これらのアカウントは堅牢で安定したアカウントであることが多く、日々の運用方法にほとんど変化はありません。サプライチェーン・タイプの攻撃を考慮せざるを得なくなると、これらの高権限アカウントの範囲を超えて、ネットワーク上のほとんどすべてのアカウントに焦点が移ります。認証情報、アクセストークン、潜在的な秘密鍵の再ロールは、複雑で時間がかかるだけでなく、時には実行不可能な作業である。
アカウントが危険にさらされている疑いがある場合、または高リスクとしてタグ付けされている場合、検知以外で最もよく調べるべき場所はActive Directoryセキュリティログであり、特に以下のイベントIDである。
-4624 (An account successfully logged on)このアカウントは2種類のログオンを記録している。
- ログオンタイプ10
§リモート対話ログオン- これは、RDP、リモート支援、またはシャドー接続に関連する。このタイプのログオンは、リモートIPアドレスにもログオンする。
- ログオンタイプ3
§ ネットワークログオン - これは、認証されたユーザーがリモートホスト上のサービスに接続していることを示す。
-4768 Kerberos認証(TGT)チケットが生成された。このイベントは、ネットワーク上で認証されるユーザーアカウントを示す。TGTは有効なパスワードを持つ有効なアカウントに与えられる。繰り返しますが、これは潜在的な異常動作を追跡するためにIPアドレスを生成します。
これらのログを追跡することで、潜在的に侵害されたアカウントの活動を明らかにすることができる。アプリケーションとサービス・アカウントは非常に安定している傾向があるため、Vectra 、これらのアカウントの通常の行動を学習し、それらが確立されたパターンから外れた行動を開始したときに特権異常検知を提供することができる。同じことが、より刹那的なアカウントや、オペレータアカウントや一般ユーザアカウントのような広い範囲を持つアカウントにも当てはまります。これらのアカウントは、安定したビジネスクリティカルなサービスと相互作用する可能性が低いため、Vectra「アイデンティティを監視して異常な動作を検知する」というアプローチにより、検知を生成し、それに応じてチームの焦点を導くことができます。