本文の内容は、2023年3月1日にNIGEL DOUGLASが投稿したブログ（https://sysdig.com/blog/mitre-attck-and-d3fend-for-cloud-and-containers）を元に日本語に翻訳・再構成した内容となっております。 MITRE ATT&CKとMITRE D3FENDは、どちらも非営利団体MITREが開発したフレームワークですが、その目的は異なっています。
- MITRE ATT&CK（Adversarial Tactics, Techniques, and Common Knowledge）は、サイバー攻撃時に使用可能な敵対者の戦術やテクニックに関する知識ベースです。攻撃者が使用する手法やツールを理解し、組織の防御のギャップを特定するために使用されます。
- MITRE D3FENDは、MITRE ATT&CKフレームワークに記載されている戦術やテクニックに対する防御のためのガイドラインのセットです。組織のセキュリティポスチャーを改善するためのベストプラクティスや推奨アクションを包括的に提供します。
MITRE ATT&CKマトリクス
MITRE ATT&CKは、攻めと守りの両方の文脈で使用できる強力なツールです。 防御的に使用する場合、組織がセキュリティ態勢のギャップを特定し、既知の脅威に対してセキュリティ手法を強化するための措置を講じるのに役立ちます。また、組織のセキュリティ体制を改善するためのベストプラクティスと推奨アクションを包括的に提供します。
Enterprise Linux 全体にわたる MITRE の戦術は、コンテナやクラウドよりもはるかに広範であり、これらは互いに異なっ て動作することに留意しましょう。
エンタープライズ ATT&CK マトリクス全体は、次のようなものです。セキュリティ環境の進化に伴い、戦術は時間の経過とともに変更される可能性があることに留意してください。
コンテナに関するMITRE ATT&CKマトリクス
コンテナ型ワークロードについては、Advanced Persistent Threat（APT）であろうと、Command & Control（C2）サーバーへのデータ漏洩であろうと、コンテナ型ワークロードへのアクセス、権限の昇格、そして最終的に侵害する一般的な手法すべてを明確に整合したマトリクスを用意しています。
Enterprise Linux 全体の見解とは異なり、私たちは「初期アクセス」で戦術を開始します。それは、敵対者がコンテナ化されたワークロードで「偵察」と「リソース開発」をどのように実行するかが不明確なためです。コンテナをホストするサーバー上でアクティブスキャンを実行することはできても、コンテナそのものをスキャンすることはできないからです。Sysdig SecureでFalcoのルールに割り当てられたMITREのテクニックを見つけるには、単純にTagをフィルターにかけます。’MITRE’ > Type: ‘Workload’とします。こうすることで、関連するMITREの戦術とテクニックを持つコンテナ関連のルールを見つけることができます。
デプロイコンテナ
Deploy Container が「Execution」と「Defense Evasion」の列にリストアップされていることがわかります。
これは、敵が実行を容易にするため、または防御を回避するために、環境にコンテナをデプロイすることを望んでいる可能性があるからです。私たちはこれをすぐに知ることはできないでしょう。
その結果、Falcoのルールでは、関連する両方の戦術についてタグが追加されます。
- rule: Launch Disallowed Container
desc: >
Detect initial process started by an unlisted container as allowed
condition: container_started and container and not allowed_containers
output: >-
Container started and not in allowed list (user.name=%user.name
user.loginuid=%user.loginuid proc.cmdline=%proc.cmdline %container.info
evt.type=%evt.type evt.res=%evt.res proc.pid=%proc.pid proc.cwd=%proc.cwd|
proc.ppid=%proc.ppid proc.pcmdline=%proc.pcmdline proc.sid=%proc.sid
proc.exepath=%proc.exepath user.uid=%user.uid user.loginname=%user.loginname
group.gid=%group.gid group.name=%group.name container.id=%container.id
container.name=%container.name
image=%container.image.repository:%container.image.tag)
priority: warning
Tags:
- container
- MITRE_TA0008_defense evasion
- MITRE_TA0002_execution
- MITRE_T1204_user_execution
- MITRE_T1204.003_malicious_image
source: syscall
append: false
Exceptions:
- name: image_repo
comps: in
fields: container.image.repository
TA vs. TI
MITREの公式文書かFalcoのルール出力で、TIとTAという頭字語が互換的に使われていることにお気づきでしょう。両者が MITRE の ID に追加されているのには、それなりの理由があります。 MITRE ATT&CK フレームワークでは、TA（Tactics, Techniques, and Procedures）は、攻撃者がシステムまたはネットワークへの不正アクセスを行うために使用する可能性のある特定の方法とテクニックを指します。 TI（Threat Intelligence）とは、組織に対する現在および潜在的な脅威に関する情報と知識を指し、特定の攻撃者やその戦術、テクニック、手順に関する情報も含まれます。 TI は組織が遭遇する可能性のある TA について情報を提供し、TA はシステムまたはネットワークを侵害しようとする特定の攻撃者またはグループを特定するために使用されるため、この 2 つは密接に関連しています。MITRE ATT&CK Matrix for Cloud
以下は、クラウドベースの技術をカバーするMITRE ATT&CK Matrix for Enterpriseを代表する戦術と技術です。このマトリクスには、以下のプラットフォームに関する情報が含まれています。Azure AD、Office 365、Google Workspace、SaaS、IaaS。この記事では、Azure AD、Office 365、Google Workspaceなどのサービスを特に掘り下げることはしませんが、MITREの戦術がさまざまなクラウドプロバイダーにどのように関連しているかを全体的に理解することは良いことです。
Sysdig Secure ルールライブラリのワークロードフィルターと同様に、クラウドロギングサービス（Azure Platform Logsなど）を検索すると、MITREフレームワークに合致するルールを教えてくれます。
Azure のアクセスレベルをパブリックに設定
この安全でない動作が、Defense Evasion MITRE tactic と正しく整合するように、TI のT1070 と T1562.001 が次の Falco のルールでどのように使用されているかに注目してください：
- rule: Azure Access Level for Blob Container Set to Public
desc: >
Anonymous, public read access to a container and its blobs can be enabled
condition: >-
jevt.value[/operationName]="MICROSOFT.STORAGE/STORAGEACCOUNTS/WRITE" and
jevt.value[/resultType]="Success" and
jevt.value[/resultSignature]="Succeeded.OK" and
jevt.value[/properties/responseBody] contains
"\"allowBlobPublicAccess\":true"
output: >-
Anonymous access to blob containers has been allowed on storage account
(requesting user=%jevt.value [/identity/claims/http:~1~1schemas.xmlsoap.org~1ws~12005~105~1identity~1claims~1name],
storage account=%jevt.value[/resourceId])
priority: warning
Tags:
- MITRE_TA0005_defense_evasion
- MITRE_T1070_indicator_removal_on_host
- MITRE_T1562.001_impair_defenses_disable_or_modify_tools
- Cloud
source: azure_platformlogs
クラウドの戦術をFalcoのルールに合わせる場合、クラウドプロバイダーごとに専用のプラグインを使用します。この場合、Falco ルールでは Azure Platform Logs を「ソース」として使用します。コンテナの場合、Falcoの専用プラグインは必要ありません。それらのコンテナがECS（Elastic Container Service）のようなクラウドサービスで動作しているか、スタンドアロンのLinux EC2インスタンスで動作しているかに関係なく、Linuxの既存のシステムコールアーキテクチャーを使って、Linuxホスト上で動作するコンテナで何が起こっているかを確認できるからです。
また、MITREの戦術T1562.001に混乱がある場合に備えて、この手法ではIDの後に(.)が付き、さらに別のIDが提供されます。これは、ツールの無効化または変更は、Impairing Defenseのサブテクニックであるためです。クラウド＆コンテナマトリクスの脅威の状況を完全に把握するためには、テクニックとサブテクニックのレイアウトに慣れることが重要です。
MITRE D3FEND
MITRE D3FENDは、対策知識ベースをコード化したフレームワークです。これは、MITRE ATT&CKフレームワークを防御のために使用することを示す、単なる略語または方法です。 つまり、MITRE D3FENDは、組織がフレームワークの防御的側面に焦点を当てたいときに、MITRE ATT&CKの代わりに使用されます。攻撃者が使用する戦術やテクニック、そしてそれらに対する防御方法をより良く理解するための参考ガイドとして使用することができます。
このサイバーセキュリティ対策のナレッジグラフは、「Harden」「Detect」「Isolate」「Deceive」「Evict」などのATT&CK戦術と関連する防御戦略を簡単に調べることができる優れた方法です。MITRE ATT&CKとは異なり、クラウドとコンテナに関するブレイクアウトマトリクスはありません。これらの指示はやや一般的なものであり、すべてのアドバイスはすべてのマトリクスにわたって考慮されるべきです。
D3FEND for Cloud
Sysdig Secureは、脅威を検知するだけでなく、防御するために使用することもできます。クラウドセキュリティの場合、まずクラウド環境を堅牢化することから始めたいと思います。 ‘Harden’ のカラム名をクリックします。執筆時点では、このカテゴリーには32のテクニックがありました。このテクニック（D3-UAP）は、ユーザーアカウント権限に関連するものです。ユーザーがオンプレミスシステムで稼働していても、クラウド内で稼働していても、一般的なアドバイスは、ユーザーアカウントのリソースへのアクセスを制限することです。Identity & Access Management (IAM)
クラウド環境では、IAMのようなサービスを使用してユーザーの権限を管理します。残念ながら、ユーザーには最終的に必要とする以上の権限が与えられていることが多いです。幸い、Sysdig Secureのユーザーインターフェースからは、2つの異なる角度からリスクを迅速に把握することができます：- ユーザーに焦点を当てたリスク：これは、ユーザーとロールに過剰な権限が割り当てられている場合です。この場合、Sysdig Secureは、これらの不要な権限を削除するための新しいIAMポリシーを提案することができます。また、ユーザーアカウントが長期間にわたって非アクティブになっている場合（従業員が退職したなど）、Sysdig Secureは非アクティブなユーザーの削除を推奨することもします。
- リソースに特化したリスク： これは、特定のリソースにアクセスできる管理者を特定し、過剰な権限を持つユーザーからの疑わしいクラウドリソースアクティビティにアラートを発します。最近の権限変更があれば、ユーザーの実際のアクティビティに基づいて、改善されたポリシーを提案することでリスクを是正し、リンク先のAWSコンソールですぐにAWSポリシーに貼り付けることができます。ご覧のように、ワイルドカード（*）文は、すべてのリソースを削除し、特定の過去に使用されたリソースのみを許可する右側のスクリーンショットと置き換えられることを表しています。
D3FEND for Containers
前述の通り、コンテナ専用のD3FENDテーブルはありませんが、コンテナ化されたワークロードにそのロジックを適用することは可能です。例えば、‘Isolate’ 戦術は、システム内に論理的または物理的な障壁を作り、敵対者がさらなるアクセスを行う機会を減らすものです。Isolateのカテゴリは、以下のように分類されます：- 実行の隔離
- ネットワーク隔離
実行の隔離
実行分離のテクニックは、アプリケーション・プロセスがメモリ、デバイス、ファイルなどの非本質的なシステム・リソースにアクセスするのを防止します。例えば、Sysdig Secureはカーネルベースプロセス隔離（D3-KBPI）を得意としています。
Sysdig Secureでは、オープンソースのFalcoのルールは ‘Policy’ と呼ばれる別の抽象化レイヤーにカプセル化されています。ポリシーによって、あるルールやルールの集合がトリガーされたときのアクションを定義することができます。ルールの条件を定義することで、最終的にはアラートの疲労を軽減し、追加のセキュリティコンテキストを提供し、さらに重要なことに、コンテナが疑わしいシステムコールをトリガーしたり、不要なプロセスアクティビティを作成した場合に修復アクションを取ることができます。
ポリシーのアクションは非同期で発生します。ポリシーにコンテナのアクションと一致するアクティビティがある場合、エージェントはDocker/Cri-oデーモンにストップ/キル/ポーズのアクションを実行するよう要求します。
ネットワークの分離
ネットワーク分離テクニックにより、ネットワークホストが本質的でないシステムネットワークリソースにアクセスするのを防ぎます。Sysdigは、Cloud Detection & Response（CDR）プラットフォームであるため、Network Policyのようなオープンソースでクラウドネイティブな構造を利用し、コンテナレベルでネットワーク分離を提供します。
すべてのコンテナ接続の動的ネットワークトポロジーグラフを作成することにより、Sysdig Secureは、上記のように、信頼されていないネットワークに向けられたプライベートホストまたはエンクレーブに由来するネットワークトラフィックを制限できます。 これにより、Generateポリシーを使用して、D3Fenseの戦術 ‘Outbound Traffic Filtering’ (D3-OTF)に対処できます。
AWSクラウドでネットワークを構成し、セキュリティを確保するために必要なベストプラクティスについては、AWSセキュリティグループガイドで詳しく解説しています。
