ブログ一覧へ戻る

Oktaのような
IdPへのサプライチェーン侵害が
あった場合にどうすべきか

著者
Luke Richards
|
2022-03-25

著者:Luke Richards、Dmitriy Beryoza、Kat Traxler

最近発生したOkta社への侵害は、サプライチェーン攻撃に対して新たな問題を提議するものとなりました。攻撃は完全には成功しなかったようで、被害を受けた企業の数は限られています。しかし、IDプロバイダー(IdP)に対するサプライチェーン攻撃が成功した場合にどうなるのかという観点から見て、興味深い議論を生み出した事例となっています。IdPの侵害、または同様の広く普及しているテクノロジーへの侵害は、結果として攻撃者に数百万人のユーザー、数千の企業へのアクセスを与えてしまう可能性があります。

サプライチェーンへの侵害という戦術自体は、Kaseya社SolarWinds社に対する攻撃が記憶に新しい通り、目新しいものではありません。しかし、アカウント管理に焦点を当てたサプライチェーン攻撃がいかに恐ろしいものであるか、セキュリティ部門が攻撃を受けた後に何をするべきかという演習を行うと、それがわかります。

最近発生した侵害に関する85%は、アカウントへの不正アクセスによるものです。アカウントへの不正アクセスにより、攻撃者は、ペイロードや監視対象となっているエンドポイントとの接触を必要とせずに、パブリッククラウドのSaaSアプリケーションにあるクラウド管理リソースからネットワーク資産まで、組織内のほぼすべてのものにアクセスできてしまいます。

IdPやその他のIDに関連するソフトウェアがサプライチェーンの侵害に関わってしまった場合に、セキュリティ部門が、どんな問題が起こったのかを踏まえた上で取るべき推奨事項を、以下にまとめています。これらの推奨事項は、サプライチェーン攻撃以外の手口によるアカウントの侵害にも適用されるものです。攻撃者から見れば、サプライチェーンの侵害は、数多くの攻撃方法の 1つに過ぎません。攻撃者がアカウントを悪用してターゲットの環境内で目的を果たす方法と、防御者が侵害を検知して、それに対するレスポンスを行う方法は、侵害の方法に本質的に同じです。  

現状を評価する

侵害に関する情報を可能な限り入手する

自分の組織以外が関わる侵害の場合、影響を受けた組織による制限された情報と攻撃者からの情報では、実際の全体像がつかめないことがあります。独立したセキュリティ研究者のコメントなど、複数の情報源を分析し、侵害の範囲を推定してください。

侵害の大まかな時間枠を確定する

セキュリティイベントのニュースは、攻撃の数週間後、あるいは数ヶ月後まで伝えられないことがあります。できるだけ多くのIoC(侵害の痕跡)を見つけるために、情報網を広く張り、悪意ある活動が発生した可能性のある現実的な時間枠を定義します。

IdPが関連するすべてのインベントリを取得する

現代の企業は、何百もの異なるサービスやアプリケーションを使用しており、ときにはSOCでさえもインベントリの正確な把握に苦労することがあります。当たり前のことですが、知らないものを適切に防御することはできません。侵害による被害のすべてに対処するためには、プロバイダーがサービスを提供しているすべてのエンティティを、完全に網羅する情報を得ることが極めて重要です。

ログに記録された最近のアクティビティと、トリガーされたアラートを確認する

信頼できるプロバイダーは、環境内のすべての重要な活動に関する、正確なログを持っているはずです。時系列の推定値をもとに、システム構成に関連するすべての変更を確認し、新しい管理者ユーザー、昇格した権限、重複したアクセス認証情報、新しくインストールしたアプリケーション、登録したデバイスなど、攻撃者が組織へ侵入する足がかりとなる可能性のあるものを洗い出します。また、ログに記録されたセキュリティアラートも検証する必要があります。

冗長なアクセスを提供する変更点を調査する

利用可能なログが有効でない、または適切でない場合もあります。現在のセキュリティ設定を検証し、通常とは異なる変更が行われていないかどうかを確認してください。

 

悪意を持って行われた変更を制御する

悪意のある設定変更をロールバックする

このステップは説明しなくても明らかですが、検知された悪意のある変更はすべてロールバックすべきです。侵害の全体像をまとめ、さらなるフォレンジック活動をサポートするために、詳細を完全に記録する必要があります。

ユーザーパスワードのリセット

個々のユーザーアカウントが侵害されている可能性がある場合、ユーザー認証の強制的なロールオーバーが必要な場合があります。この措置は、ユーザーには歓迎されないかもしれませんが、実行は簡単であり、アカウント侵害の可能性に対処するための現実的な工程となります。

キーと証明書のローテーション

アプリケーションやサービスの認証情報のリセットは、通常、より複雑で手間のかかる作業です。関連する機密が流出した場合はやむを得ないかもしれませんが、着手する前にその必要性を確認しましょう。

過剰なサードパーティ権限をすべて取り消す

Okta社を含むIdPの中には、テナント設定へのアクセスや変更、システムデバッグの実行に関してユーザーからの許可を得て、権限を持っているものがあります。プロバイダーが危険にさらされた場合、すでに許可しているアクセス権は取り消すことが賢明です。

 

防御を強化する

現在のセキュリティ設定を見直す

これも説明するまでもないかもしれませんが、セキュリティインシデントは、現状の設定を見直し、強化する機会とも言えます。Azure ADやMicrosoft 365の設定をスキャンしてその死角を特定するSiriuxのようなセキュリティポスチャ管理製品は、その大きな助けになります。

監視ソリューションの導入

どんなに適切に設定されたセキュリティソリューションであっても、侵入を回避することはできません。人的要因やサプライチェーンの攻撃(IdPへの侵害など)は、外部に対する防御を迂回することができてしまうからです。インシデントが発生した場合に対処するには、悪意のある活動を監視し、攻撃者の進行を阻止するVectraプラットフォームのような、効果的な検知およびレスポンスのソリューションが有効です。

インシデント対応のプレイブックを見直す

理想は、IdPでインシデントが発生した場合の対策をすでに持っており、すぐにでも実行することです。対策を準備中であるなら、インフラプロバイダーの侵害に対処するための計画を作成する良い機会です。

第三者による監査

すべての対応が落ち着いたら、セキュリティポスチャが適切に整備され、明らかな抜け穴がないことを確認するために、信頼できるセキュリティプロバイダーによる第三者監査を受けると良いでしょう。

 

アカウント侵害の兆候とは?

アカウントが侵害された場合、その影響がすぐに明らかになるとは限りません。それは、アカウントが実行できるアクションは多様であり、資産の管理方法も異なるためです。侵害されたアカウントは、重要なサービス、機能、ホスト、またはデータへのアクセスに関連する異常な活動として一般的に特徴付けられます。しかし、何が異常で、何が価値あるのかを定義することは、簡単な作業ではありません。

ネットワーク上のActive Directoryのログを調べたり、クラウドサービスで記録されたアクションを確認したりすることはできますが、この問題が持つ規模と曖昧さに対しては、AIを活用して、どういった異常で、何が攻撃者の目的なのかを理解することが最善です。これは、誰が侵害されたかを正確に把握できない場合で、認証情報、アクセストークン、そして秘密鍵を再ロールすることになるというシナリオにおいて特に重要です。

Vectraは、セキュリティ主導のAIを適用し、ハイブリッドクラウド、SaaS、AWSにまたがるお客様のビジネスに対して、侵害されたアカウントに対する攻撃者の振る舞いを監視し、レスポンスを行います。アラートは、異常なものだけでなく、攻撃者の振る舞いにも焦点を当てたものです。ハイブリッドクラウドとSaaS環境の両方で、アカウントと資産の価値を自動的に理解するVectraのPrivilege Analyticsのような技術は、過去の活動に基づいて資産の価値を理解することによって、異常事態を把握します。

 

漏洩したアカウントやリスクの高いアカウントを、手動で調査

Vectraのようなプラットフォームを利用していない場合、脅威ハンターは、インシデントの詳細とIdPが自社の環境とどのように相互作用するかを評価し、侵害の疑いがあるアカウントを特定する必要があります。Okta社の件のような場合、攻撃者がIdPインフラストラクチャを制御している期間中の、アカウント変更を調べることが、1つの例として挙げられます。

通常の運用では、セキュリティオペレーション担当は、ドメイン管理者やサービスアカウントなど、注目度の高いアカウントの監視に特に力を入れています。これらのアカウントは、堅牢で安定したアカウントであることが多く、日々の運用方法にはほとんど変化がありません。しかし、サプライチェーン型の攻撃に対応する場合、高い特権アカウントの範囲を超えて、ネットワーク上のほぼすべてのアカウントに焦点を当てなければなりません。ただし、認証情報、アクセストークン、および秘密鍵を再ロールする作業は、複雑で時間がかかるだけでなく、実行不可能な場合もあります。

 

もし、あるアカウントが危険な状態にある、または高リスクであると判断された場合、Active Directoryのセキュリティログ、特に以下のイベントIDを確認するのが、最も良い方法となります。

- 4624 (An account successfully logged on) このアカウントは、2つのログオンタイプを生成。

- ログオンタイプ10

§ リモート対話型ログオン: RDP、リモートアシスタンス、またはシャドウ接続に関連するもの。このタイプのログオンは、リモートIPアドレスもログオンする。

- ログオンタイプ3

§ ネットワークログオン:認証されたユーザーがリモートホストのサービスに接続することを示す。

- 4768 Kerberos認証(TGT)チケットが生成されたこのイベントは、ネットワーク上で認証されたユーザーアカウントを示す。TGT は、有効なパスワードを持つ有効なアカウントに付与。この場合も、潜在的な異常行動を追跡するために、IPアドレスが生成される。

 

これらのログを追跡すると、侵害されたかもしれないアカウントでの活動を明らかにできる可能性があります。アプリケーションやサービスアカウントは非常に安定している傾向があるため、Vectraはこれらのアカウントの正常な動作を学習しておき、確立されたパターンから外れた動作を開始したときに異常検知を提供することができるのです。同じことが、一時的なアカウントや、オペレータアカウント、一般ユーザーアカウントなど、広い範囲をカバーするアカウントにも当てはまります。これらのアカウントは、安定しており、ビジネスクリティカルなサービスと相互作用する可能性が低いため、IDの異常な動作を監視するVectraのアプローチによって検知できます。その結果、本当に焦点を当てるべき業務に集中することができます。

Vectraについてのご質問や詳細については、お気軽にお問い合わせください。また、30日間無料のデモもございますので合わせてご検討ください。

本ブログは『What If there was a Supply Chain Compromise of an IDP like Okta?』の翻訳となります。

追記:Vectra Japanは、2022年5月16日(月)から5月20日(金)に開催される、株式会社マクニカ主催のセキュリティに特化したオンラインイベント Macnica Security Forum 2022に参加しセッションを行います。事前登録は4月4日より開始しておりますので、ぜひご参加ください。