規模や業種を問わず、機密データを持つあらゆる組織がサイバー攻撃の標的になる可能性がある。より多くの企業がクラウドに移行する中、脅威の状況は加速度的に進化しており、敵対者は最終目標に到達するために高度な戦術を展開しています。
レスポンス インシデントは、データを保護し、攻撃が組織に大打撃を与えるのを防ぐ上で、重要な役割を果たします。
成功するクラウドインシデント対応プログラムの基盤は、準備、運用、およびインシデント発生後の活動に重点を置いています。 NISTとSANS ：どちらも信頼できる組織で、これらのフェーズに密接に沿ったインシデントレスポンスのステップを持つ IR フレームワークを開発しました。Vectra AWSインシデントレスポンスのためのAI CDRは、NISTインシデントレスポンスライフサイクルと整合させる必要性から、これらのフェーズに基づいて開発され、AI主導の検知、封じ込めを伴う分析、根絶、回復を包含する運用と組み合わされている。AWSセキュリティインシデントレスポンスガイドは、インシデントレスポンス技術を自動化するための多くの方法を概説しています。
AWSセキュリティインシデントレスポンスガイドは、インシデントに備えることが不可欠であると概説している。インシデントレスポンスの検知フェーズでイベントを検知し、分析フェーズでそれを分析した後 - サポートされている4つのAWSサービスの封じ込めのために自動化されたソリューションを使用することができます。インシデントの封じ込めは、リアルタイムで脅威に対処するために非常に重要です。自動化された封じ込めインスタンスとはどのようなものでしょうか？
Vectra 「AWSエンティティ・ロックダウン」の理由
セキュリティはVectraの最優先事項です。AWSは責任共有モデルを採用している：AWSはクラウド のセキュリティを管理し、顧客はクラウドのセキュリティに責任を持ちます。このようなモデルでは、顧客はセキュリティ実装を完全にコントロールできますが、セキュリティインシデントレスポンス は複雑になる可能性があります。Vectra CDR for AWS のエンティティのロックダウン自動化機能を採用することで、SecOps チームのレスポンス スピードが向上し、インシデントレスポンス 業務が簡素化されるため、イベントが発生した場合の備えが強化され、組織に大惨事が発生する前に脅威を最小限に抑えることができます。
私たちのやり方はこうだ：
SecOpsは、設定ミスや外部要因の変化など、ベースラインからの逸脱が発生した場合に対応し、調査する必要があります。Vectra CDR for AWS Entity Lockdown ソリューションは、以下を提供することで、セキュリティイベントに対するチームの備えを強化します：
- AWSの最小特権の原則：SNSの公開権限のみを公開すればよい。強力なアクセス制御。
- 自動化されたワークフロー：このソリューションは、既存のワークフローにきれいに統合することができ、自動的に起動して帯域外の制御を確保し、攻撃が影響に拡大するのを阻止します。
- 自動化された監査証跡：このソリューションは、コンプライアンス監査とロギングを可能にします。
- クロスリージョン、クロスアカウント：AWS環境全体で1つの場所から作業できるため、利用が簡素化されます。
- 特定/標的型：漏洩した認証情報が包括的にロックアウトされるため、攻撃者は別の攻撃経路を利用することができません。これにより、侵害された認証情報のみがロックアウトされ、通常業務への影響を回避します。
AWS封じ込めのアーキテクチャと設計
Vectra CDR for AWS は、AWS SNS トピックメッセージを使用して Lambda 関数をトリガーします。まず、AWS SNSメッセージは手動またはサードパーティツール（Amazon Security HubやSOARなど）を通して公開されます。その後、Lambdaコードがメッセージの内容に基づいてさらなるアクションをトリガーする。SNSメッセージは2つのメッセージ属性を必要とする。隔離するエンティティのARNとExtranalIdだ。ユーザーはCloud Formationテンプレートのデプロイ時にExtranalIdを設定する。このフィールドは静的で、Incidentレスポンス Lambda関数によるSNSメッセージの検証に使用される。
これにより、図1に示すように、以下のタスクが達成される：
- AWS SNS メッセージは、AWS エンティティの ARN と ExternalId で発行される。
- SNS メッセージによって AWS Lambda 関数が呼び出されます。Lambda 関数は、エンティティタイプに基づいてインシデントレスポンス のビジネスロジックを実行します。
- AWS SNS の監査メールは、プロセス全体を通してユーザーに送信されます。プロセスの開始時に1通、成功または失敗時に1通、そしてメッセージがデッドレターキューに落ちた場合に1通のメールが送信されます。
ラムダ関数が呼び出されると、以下のビジネス・ロジックが実行される：インシデントレスポンス のビジネスロジックを図2に示す。
AWSエンティティタイプを決定します。サポートされているエンティティ：Lambda、IAM User、IAM Role、EC2。
Lambda関数は、エンティティタイプがIAM RoleまたはUserの場合、DenyAll AWSマネージドポリシーをアタッチします。
エンティティタイプがAWS Lambda関数の場合、以下のロジックが適用されます：
- Lambdaの実行ロールにAWSマネージドポリシーのDenyAllをアタッチします。
- ラムダ関数のプロパティfunction_currency を 0 に設定する。
エンティティタイプがAWS EC2インスタンスの場合、以下のロジックが適用されます。
セキュリティグループのルールは、すべてのトラフィックを暗黙のうちに拒否することから始まる。 ルールが存在しない場合は、特定のトラフィックを許可するルールを作成する。インバウンドのトラフィックはアウトバウンドのルールに関係なく許可され、その逆も同様である。ルールはいつでも追加または削除でき、変更はセキュリティグループに関連付けられたインスタンスに即座に適用される。しかし、いくつかのルール変更の効果は、トラフィックがどのように追跡されるかに依存する可能性がある。追跡される接続がどのように機能するかを理解することは、効果的なセキュリティグループの封じ込めを実装するために不可欠です。接続が追跡されると、ルールのないセキュリティ・グループをアタッチしているにもかかわらず、インターネット接続を維持することができます。セキュリティグループは接続追跡を使用して、インスタンスへのトラフィックとインスタンスからのトラフィックに関する情報を追跡します。すべてのトラフィックフローが追跡されるわけではありませんが、これがステートフル接続を実装する方法です。1つだけ例外がある。ICMPトラフィックは常に追跡される。
追跡なし接続は、いずれかの方向のすべてのポートに対して、クワッドゼロ ルールを持つあらゆるトラフィックタイプに適用されます。追跡される接続と追跡されない接続の例を見ることができます。
- すべてのトラフィック(0.0.0.0/0 Tracked。 :/0）に対して TCP または UDP フローがあり、もう一方の方向に、すべてのポート(0-65535）に対してすべてのレスポンス トラフィック(0.0.0.0/0 または :/0）を許可する対応するルールがある場合、そのトラフィックフローは追跡されない -Not tracked。
- インバウンドルールが 203.0.113.1/32 からのトラフィックのみを許可し、すべての IP アドレス(0.0.0.0/0）を許可しないため、ポート 22(SSH） のインバウンドおよびアウトバウンドの TCP トラフィックが追跡される。
- ポート80(HTTP）のインバウンドおよびアウトバウンドのTCPトラフィックは追跡されません。なぜなら、インバウンドおよびアウトバウンドのルールは、すべてのIPアドレスからのトラフィックを許可しているからです。
- ICMPトラフィックは常に追跡さ れる。
IPv4トラフィックのアウトバウンドルールを削除すると、ポート80(HTTP）のトラフィックを含む、すべてのインバウンドおよびアウトバウンドIPv4トラフィックが追跡されます。IPv6トラフィック用の送信ルールを削除した場合は、IPv6トラフィックについても同じことが適用されます。- 追跡されます。
セキュリティ・グループは非常に効果的で、単一のEc2インスタンスの封じ込めを目標とする。追跡された接続と追跡されていない接続を終了させるには、アクティブな接続を終了させ、将来の接続を防止するための複数段階のプロセスが必要です。Vectra エンティティ・ロックダウン・ソリューションを適用すると、追跡されていない接続はすべて直ちに終了します。しかし、アクティブな追跡された接続のみが終了します。私たちのソリューションでは、アクティブな接続とは、ネットワーク・トラフィックが継続的に、または1分以上の間隔で流れている接続を指します。
以下のソリューションは、継続的にアクティブな接続に対して機能する。 例えば、侵害されたEC2インスタンスが暗号マイニングに使用されている場合や、ランサムウェア攻撃の一部である場合などである。
インシデントレスポンス Lambda関数が呼び出され、分離するエンティティタイプがAWS EC2インスタンスである場合、以下のアクションが実行される。
- 侵害されたEC2インスタンスのインスタンスプロファイルに、すべてのアクションを拒否する条件付きポリシーをアタッチする。多くのソリューションは、インスタンスからInstance Profile Roleを切り離すことを提案している。しかし、このようなアクションはインスタンスが新しいセッションを開始するのを防ぐが、既存のセッションを取り消すことはできない。例えば、攻撃者が設定ミスのアプリケーションを悪用してインスタンスのメタデータからセキュリティ認証情報を取得した場合、これらの認証情報は最大12時間有効なままとなる。
- EC2インスタンスが存在するVPCに、追跡されない接続のセキュリティグループが存在するかチェックする。存在しない場合は作成し、インスタンスにセキュリティグループを適用する。このセキュリティグループには、0.0.0.0/0というイングレスとイグレスのルールが1つずつあり、追跡される接続を追跡されない接続に変換する。
- VPCに分離セキュリティ・グループが存在するか確認します。存在しない場合は作成し、インスタンスにセキュリティグループを適用します。このセキュリティグループにはイングレスとイグレスのルールはない。このセキュリティグループを割り当てると、EC2インスタンスが完全に隔離される。
Vectra CDR for AWSの導入
Vectra CDR for AWSをデプロイするには、まずCloudFormationテンプレートにアクセスする必要がある。1つのAWSアカウントを使用している場合は、デプロイメントインシデントレスポンスリソーステンプレートのみが必要です。しかし、複数アカウントのセットアップがあり、クロスアカウントのインシデントレスポンスソリューションが必要な場合は、2つのテンプレートをデプロイする必要があります。最初のテンプレートをAWSセキュリティアカウントにデプロイすると、インシデントレスポンスリソースがホストされます。2つ目のテンプレートは、ソリューションをカバーしたい他のアカウントにクロスアカウントIAM Roleを作成します。ソリューションのREADMEは、AWS CloudFormationテンプレートとスタックの詳細を完全に文書化しています。GitHub リポジトリにその他のリソースがあります。
Vectra CDR for AWS Automation
自動化を開始するには、まずVectra CDR for AWS Cloud Formation スタックをデプロイする必要がある。その後、AWSコンソールを使用している場合は、サービスリソース画面からSNSメッセージを発行することができます。AWS CLIまたはAWS SDKを使用する場合は、Incidentレスポンス SNS ARNはAWS Cloud Formationスタックのoutputタブで見つけることができます。各アプローチの詳細なチュートリアルは GitHub リポジトリの README にあります。
AWSインシデントの封じ込め
前述したように、CloudFormationに従うことで、SOCアナリストはAWSインシデントに対応するためにSNSのパブリッシュ権限のみを必要とします。Amazon Security HubやSOARのようなセキュリティサービスも、SecOpsチームのワークフローの一部としてメッセージをパブリッシュできる。したがって、SOCアナリストは、疑わしいAWSサービスに対する管理権限を必要としません。概説したステップに従うことで、SecOpsチームはAWSネイティブツールを利用してインシデントレスポンス を作成できるようになる。この方法論は、クロスアカウントおよびクロスリージョンの封じ込めもサポートしている。各アカウントのスタックを削除する場合、EC2分離のために作成されたこれらのセキュリティグループを削除するには、手動でのクリーンアップが必要になる。
インシデントレスポンス は、すべての企業にとってサイバーセキュリティ戦略の不可欠な部分です。AWSインシデントの封じ込めを通じて、SecOpsチームはEC2インスタンス、IAMユーザーとRole、およびAWS環境内の疑わしいエンティティに対応するLambda関数の分離を自動化する方法を知っているという保証を得ることができます。
次のステップ
無料トライアルで Vectra CDR for AWS のパワーを直接体験してください。