はじめに

クラウドネイティブ環境が当たり前になった今、攻撃者もまたクラウドやコンテナを標的とした手法を急速に進化させています。「うちの環境はどの攻撃手法に対して弱いのか？」「検知の抜け漏れはどこにあるのか？」――こうした問いに体系的に答えてくれるのが MITRE ATT&CK（マイター・アタック） フレームワークです。

本記事では、MITRE ATT&CK の基礎から、クラウド・コンテナ向けマトリクスの詳細、そして Sysdig がこのフレームワークをどのように活用してランタイムセキュリティを実現しているかまで、実務で役立つレベルで徹底解説します。

対象読者: クラウドネイティブセキュリティに関わるエンジニア、SOC アナリスト、セキュリティアーキテクト

1. MITRE ATT&CK の概要

ATT&CK とは

MITRE ATT&CK は、Adversarial Tactics, Techniques, and Common Knowledge（敵対的な戦術・技術・共通知識）の略称です。米国の非営利研究機関である MITRE Corporation が 2013 年に開発を開始し、現在では世界中のセキュリティチームが採用する事実上の業界標準フレームワークとなっています。

ATT&CK の核心は、実際に観測された攻撃者の行動パターン をもとにしている点です。理論上の脅威ではなく、APT グループや犯罪組織が実際に使った手法を、認定された脅威インテリジェンスに基づいて体系化しています。

なぜ ATT&CK が重要なのか

従来のセキュリティ対策では、「ファイアウォールを入れた」「アンチウイルスを導入した」といった ツールベース の考え方が中心でした。しかし、これでは「どの攻撃手法に対して有効なのか」「どこに穴があるのか」が不明確です。

ATT&CK は 攻撃者の視点 からセキュリティを評価する共通言語を提供します。

これにより、セキュリティの「定量的な評価」と「優先順位付け」が可能になります。

公式リソース

公式サイト: https://attack.mitre.org/
ATT&CK Navigator（可視化ツール）: https://mitre-attack.github.io/attack-navigator/
すべての情報は無料で公開されています。

2. フレームワークの構造を理解する

ATT&CK は階層構造を持っており、以下の 5 つのレイヤーで構成されます。

フレームワーク階層図

2.1 マトリクス（Matrices）

ATT&CK は対象環境ごとに複数のマトリクスを提供します。

本記事では特に Enterprise マトリクスの Cloud および Containers に焦点を当てます。

2.2 戦術（Tactics）

戦術は「攻撃者がなぜその行動を取るのか」を表す目的のカテゴリです。Enterprise マトリクスには 14 の戦術 が定義されています。これは攻撃のライフサイクル（キルチェーン）に沿って並んでいます。

2.3 技術（Techniques）とサブテクニック（Sub-techniques）

技術は「攻撃者が どのように 目的を達成するのか」を表す具体的な手法です。2023 年時点で 193 の技術 と 401 のサブテクニック が定義されています。

例えば「権限昇格」という戦術の下に「コンテナからホストへのエスケープ（T1611）」という技術がある、という関係です。

2.4 手順（Procedures）

手順は、特定の攻撃グループやマルウェアが実際に使用した技術の 具体的な実装方法 です。例えば、APT28 が T1078（正規アカウントの使用）をどのように実行したか、といった詳細が記述されています。

2.5 緩和策（Mitigations）と検知方法（Detections）

各技術に対して、どのような防御策が有効か（緩和策）、どのようにして攻撃を検出できるか（検知方法）が紐づけられています。

3. 14 の戦術（Tactics）を深掘りする

Enterprise ATT&CK マトリクスの 14 戦術を、攻撃ライフサイクル順に解説します。

攻撃ライフサイクル全体像

下記の SVG イラストは攻撃ライフサイクルの全体像と Sysdig の検知カバレッジを示しています。

TA0043: 偵察（Reconnaissance）

攻撃の最初のフェーズです。攻撃者はターゲット組織の情報を収集します。

DNS 情報の収集
従業員のメールアドレスや SNS 情報の調査
公開されている技術スタックの特定
IP アドレスレンジのスキャン

クラウド環境では、公開された S3 バケットや誤設定された API エンドポイントの探索もここに含まれます。

TA0042: リソース開発（Resource Development）

攻撃者が攻撃に使うインフラやツールを準備するフェーズです。

C2（コマンド&コントロール）サーバの設置
フィッシングドメインの取得
マルウェアの開発・購入
盗んだ認証情報の入手

TA0001: 初期アクセス（Initial Access）

ネットワークやシステムへの最初の侵入ポイントです。

フィッシングメール
公開アプリケーションの脆弱性悪用（T1190）
有効なアカウントの使用（T1078）
サプライチェーン攻撃

コンテナ環境では、公開された Kubernetes API サーバ や 脆弱なコンテナイメージ が初期アクセスの経路になります。

TA0002: 実行（Execution）

侵入後、攻撃者がコードやコマンドを実行するフェーズです。

コンテナ管理コマンドの実行（T1609）
悪意あるコンテナのデプロイ（T1610）
スケジュールタスク/ジョブ（T1053）

Sysdig の知見: 初期アクセスと実行は最も頻繁にトリガーされる検知カテゴリです。

TA0003: 永続化（Persistence）

アクセスを維持するための手法です。再起動やパスワード変更があっても戻れるようにします。

内部イメージへのインプラント（T1525）
コンテナサービスの作成・変更（T1543.005）
追加のクラスターロールの作成（T1098.006）
バックドアの設置

TA0004: 権限昇格（Privilege Escalation）

より高い権限を取得するフェーズです。

コンテナからホストへのエスケープ（T1611） ― コンテナ環境における最重要テクニックの一つ
脆弱性を悪用した権限昇格（T1068）
ホスト上でのイメージビルド（T1612）

TA0005: 防御回避（Defense Evasion）

セキュリティツールや監視の検知を逃れる手法です。

セキュリティツールの無効化（T1562）
ログの削除・改ざん（T1070）
マスカレード（正規プロセスへのなりすまし）（T1036）
正規アカウントの悪用（T1078）

Sysdig の知見: Falco ルール分析では、権限昇格と防御回避にラベル付けされたルールが最も頻繁にトリガーされると報告されています。

TA0006: 認証情報アクセス（Credential Access）

パスワードやトークンを窃取するフェーズです。

ブルートフォース攻撃（T1110）
アプリケーションアクセストークンの窃取（T1528）
セキュアでない認証情報の取得（T1552）

Kubernetes 環境では、ServiceAccount トークン や Secrets が主要なターゲットです。

TA0007: 探索（Discovery）

侵入先の環境を理解するための情報収集です。

コンテナとリソースの探索（T1613）
ネットワークサービスの探索（T1046）
権限グループの探索（T1069）

TA0008: ラテラルムーブメント（Lateral Movement）

他のシステムやコンテナへの横展開です。

代替認証情報の使用（T1550）
Pod 間の移動
ノード間の移動

TA0009〜TA0011: 収集・C2・持ち出し

攻撃者がデータを集め、外部の C2 サーバと通信し、窃取したデータを送出するフェーズです。

TA0040: 影響（Impact）

最終目的を達成するフェーズです。

データ破壊（T1485）
サービス拒否攻撃（T1498/T1499）
リソースハイジャック（T1496） ― クラウド環境では暗号通貨マイニングが代表的
システムリカバリの阻害（T1490）

4. ATT&CK for Containers ― コンテナ特化マトリクス

背景

ATT&CK for Containers は、Center for Threat-Informed Defense の研究プロジェクトとして、Citigroup、JPMorgan Chase、Microsoft のスポンサーシップのもとで開発されました。ATT&CK バージョン 9.0 で正式に統合され、Docker や Kubernetes といったコンテナ技術に特化した攻撃手法が体系化されています。

コンテナマトリクスの全体像

コンテナマトリクスでは以下の 9 つの戦術 と 39 の技術/サブテクニック が定義されています。

戦術	主要な技術	技術数
初期アクセス	公開アプリケーションの悪用、有効なアカウント	3
実行	コンテナ管理コマンド、コンテナのデプロイ、悪意あるイメージ	4
永続化	内部イメージへのインプラント、コンテナサービスの作成	7
権限昇格	コンテナエスケープ、ホスト上でのイメージビルド	6
防御回避	セキュリティ機能の無効化、ログの削除	7
認証情報アクセス	ブルートフォース、トークン窃取	3
探索	コンテナ/リソース探索、ネットワーク探索	3
ラテラルムーブメント	代替認証情報の使用	1
影響	リソースハイジャック、データ破壊、DoS	5

コンテナ環境特有の重要テクニック

T1611: コンテナからホストへのエスケープ（Escape to Host）

コンテナ環境で最も危険なテクニックの一つです。攻撃者がコンテナの分離を破り、ホストの OS にアクセスします。

下記の SVG イラストはコンテナエスケープと Sysdig の検知の仕組みを示しています。

T1610: コンテナのデプロイ（Deploy Container）

攻撃者が悪意あるコンテナを正規の環境にデプロイする手法です。

攻撃例:
1. 窃取した kubeconfig を使用
2. 暗号通貨マイナーを含むコンテナをデプロイ
3. hostNetwork: true で設定してホストネットワークにアクセス

T1525: 内部イメージへのインプラント（Implant Internal Image）

プライベートレジストリに保管されたコンテナイメージにバックドアを仕込む手法です。CI/CD パイプラインの侵害と組み合わされることが多く、サプライチェーン攻撃の一形態です。

T1609: コンテナ管理コマンド（Container Administration Command）

kubectl exec、docker exec などのコンテナ管理コマンドを悪用して、コンテナ内でコードを実行します。

5. ATT&CK for Cloud ― クラウド環境のマトリクス

クラウドマトリクスの対象プラットフォーム

ATT&CK のクラウドマトリクスは以下のプラットフォームをカバーします。

クラウド固有の主要テクニック

クラウド IAM の悪用

T1078.004: Cloud Accounts
 → 漏洩した AWS アクセスキーの悪用
 → Azure サービスプリンシパルの乗っ取り
 → GCP サービスアカウントキーの窃取

クラウドインフラの操作

T1578: Modify Cloud Compute Infrastructure
 → スナップショットからの機密データ抽出
 → セキュリティグループの変更
 → コンピュートインスタンスの作成（マイニング用）

クラウドストレージの操作

T1530: Data from Cloud Storage
 → S3 バケットからのデータ窃取
 → Azure Blob Storage への不正アクセス
 → GCS バケットの公開設定変更

クラウド攻撃シナリオの全体像

6. MITRE D3FEND ― 防御側のフレームワーク

ATT&CK と D3FEND の関係

ATT&CK が 攻撃者の視点 からの知識ベースであるのに対し、D3FEND は 防御者の視点 からのフレームワークです。

D3FEND の 5 つの防御カテゴリ

カテゴリ	説明	Sysdig での実装例
Harden（強化）	攻撃面の縮小	CIEM による IAM 最適化
Detect（検知）	攻撃の識別	Falco ランタイム検知
Isolate（隔離）	被害の封じ込め	コンテナ Kill/Pause、NetworkPolicy
Deceive（欺瞞）	ハニーポット、デコイ	-
Evict（排除）	攻撃者の排除	自動レスポンスアクション

7. Sysdig と MITRE ATT&CK：ランタイムセキュリティの実践

ここからが本記事の核心です。Sysdig が MITRE ATT&CK フレームワークをどのように活用し、クラウドネイティブ環境のセキュリティを実現しているかを詳しく見ていきます。

7.1 Sysdig の基本アーキテクチャと ATT&CK

Sysdig は Cloud Detection and Response（CDR） プラットフォームとして、以下の 3 つの層でセキュリティを提供します。

7.2 Falco ― ATT&CK マッピングの心臓部

Sysdig のランタイム脅威検知の中核は、オープンソースの Falco エンジンです。Falco は CNCF（Cloud Native Computing Foundation）の卒業プロジェクトであり、Linux カーネルのシステムコールをリアルタイムに監視します。

Sysdig Secure では、Falco のルールが MITRE ATT&CK の戦術・技術 ID でタグ付け されています。これにより、検知イベントが ATT&CK マトリクス上のどこに位置するかが即座に分かります。

Falco ルールの構造と ATT&CK タグ

- rule: Launch Disallowed Container
  desc: >
    Detect the initial process started by a container that is not
    in a list of allowed containers.
  condition: >
    container_started and container and
    not container.image.repository in (allowed_containers)
  output: >
    Container started and not in allowed list
    (user=%user.name container_id=%container.id
     container_name=%container.name
     image=%container.image.repository:%container.image.tag)
  priority: WARNING
  tags:
    - MITRE_TA0002    # Execution（実行）
    - MITRE_T1610     # Deploy Container
    - MITRE_TA0005    # Defense Evasion（防御回避）
    - container
    - MITRE

このルールは、許可リストにないコンテナが起動された場合にアラートを発生させます。ATT&CK の「実行」と「防御回避」の両方の戦術にマッピングされており、不正なコンテナのデプロイ（T1610）として分類されています。

7.3 Falco ルールから ATT&CK マッピングへの流れ

7.4 TA（戦術）と TI（脅威インテリジェンス）の区別

Sysdig の Falco ルールでは、2 種類のタグを使い分けています。

TA タグ ― 攻撃者が使う特定の手法（戦術・技術）を示す。例: MITRE_TA0002（実行戦術）
TI タグ ― 脅威に関する情報で、防御戦略の立案に使用される

この区分により、「この検知は攻撃のどのフェーズか」と「このインテリジェンスはどう防御に活かせるか」を明確に分離できます。

7.5 コンテナワークロードとクラウドインフラの二面カバレッジ

Sysdig は ATT&CK マッピングを 2 つのレイヤー で行います。

コンテナワークロード層

Linux システムコールの監視による ランタイム検知
ATT&CK の「初期アクセス」から「コマンド&コントロール」までをカバー
偵察やリソース開発はホストレベルの話であり、コンテナスコープでは除外

Sysdig Secure の UI では Tag: 'MITRE' > Type: 'Workload' でフィルタリングすることで、コンテナワークロード向けのルールを一覧できます。

クラウドインフラ層

AWS CloudTrail、GCP Audit Logs、Azure Platform Logs などの クラウド監査ログ を分析
偵察（TA0043）やリソース開発（TA0042）を含む 全 14 戦術 をカバー
クラウド固有のテクニック（IAM 操作、ストレージ設定変更など）に対応

7.6 555 ベンチマーク ― Sysdig のランタイム検知哲学

Sysdig は独自の 「555 ベンチマーク」 を提唱しています。

下記の SVG イラストは 555 ベンチマークのコンセプトを示しています。

5 秒 で脅威を検知
5 分 でトリアージ（調査・判断）
5 分 で対応

クラウド環境では攻撃の展開が非常に速く、従来の「日単位」のインシデントレスポンスでは間に合いません。Sysdig はシステムコールレベルのリアルタイム監視と ATT&CK マッピングを組み合わせることで、この高速な検知-対応サイクルを実現しています。

8. Sysdig の具体的な検知事例とマッピング

事例 1: 不正コンテナのデプロイ検知

ATT&CK マッピング: T1610（Deploy Container）+ TA0002（Execution）

シナリオ:
攻撃者が窃取した kubeconfig を使って、暗号通貨マイナーの
コンテナをクラスタにデプロイする。

Sysdig の検知:
1. Falco ルール「Launch Disallowed Container」がトリガー
2. 許可リストにないイメージからのコンテナ起動を検出
3. ATT&CK の TA0002（実行）と TA0005（防御回避）にマッピング
4. プロセスメタデータ、コンテナ情報を含むアラート生成

対応:
Sysdig Policy により自動的にコンテナを Kill/Stop/Pause

事例 2: Azure Blob Storage の匿名アクセス有効化

ATT&CK マッピング: T1070（Indicator Removal）+ T1562.001（Disable or Modify Tools）

事例 3: コンテナエスケープの検知

ATT&CK マッピング: T1611（Escape to Host）

シナリオ:
攻撃者が特権コンテナからホストのファイルシステムにアクセスし、
ホスト上でプロセスを実行しようとする。

Sysdig の検知:
1. システムコール監視で異常なファイルアクセスパターンを検出
   （/proc/1/root、/host マウントなど）
2. コンテナ外のプロセス実行を検知
3. T1611（Escape to Host）にマッピング
4. 権限昇格戦術（TA0004）として高優先度アラート生成

対応:
該当コンテナの即時停止とインシデント調査の開始

事例 4: Kubernetes Secrets へのアクセス

ATT&CK マッピング: T1552（Unsecured Credentials）

事例 5: クリプトマイニングの検知

ATT&CK マッピング: T1496（Resource Hijacking）

9. Sysdig と MITRE D3FEND の連携

Sysdig は ATT&CK（攻撃側）だけでなく、D3FEND（防御側）のフレームワークにもマッピングしています。

D3FEND カバレッジマップ

9.1 Harden（強化）― IAM の最適化

D3FEND カテゴリ: Identity & Access Management

Sysdig は CIEM（Cloud Infrastructure Entitlement Management） 機能を通じて、以下の強化策を実現します。

ユーザーフォーカスのリスク管理

過剰権限の検出: 実際に使用していない権限を持つアカウントを特定し、権限の縮小を推奨
非アクティブユーザーの検出: 長期間ログインしていないアカウントをフラグし、削除を推奨

リソースフォーカスのリスク管理

ワイルドカード権限の排除: IAM ポリシー内の Resource: "*" を、過去の使用履歴に基づく具体的なリソース ARN に置き換える推奨を生成
最小権限の原則の適用: 各ユーザー/ロールが本当に必要な権限のみを持つよう最適化

9.2 Detect（検知）― ランタイム脅威検知

前述の Falco ベースの検知がここに該当します。D3FEND の検知カテゴリとの対応は以下の通りです。

D3FEND 検知手法	Sysdig の実装
D3-PSA（プロセスの自己実行分析）	Falco によるシステムコール監視
D3-NTA（ネットワークトラフィック分析）	ネットワーク接続の監視
D3-FCA（ファイルコンテンツ分析）	ファイル整合性監視（FIM）

9.3 Isolate（隔離）― 被害の封じ込め

D3-KBPI: カーネルベースのプロセス隔離

Sysdig Secure はプロセスレベルの制限を強制し、アプリケーションが不要なシステムリソースにアクセスすることを防止します。

疑わしいシステムコールが検出された場合のアクション定義
Docker / CRI-O デーモンへのコマンド発行によるコンテナの隔離
コンテナの Kill / Stop / Pause の自動実行

D3-OTF: アウトバウンドトラフィックフィルタリング

Sysdig はコンテナ間のネットワーク接続を動的にトポロジーマップとして可視化し、Kubernetes NetworkPolicy の自動生成を支援します。

# Sysdig が生成する NetworkPolicy の例
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: restrict-egress
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: web-frontend
  policyTypes:
    - Egress
  egress:
    - to:
        - podSelector:
            matchLabels:
              app: api-backend
      ports:
        - protocol: TCP
          port: 8080
    - to:
        - namespaceSelector:
            matchLabels:
              name: kube-system
      ports:
        - protocol: UDP
          port: 53   # DNS

これにより、正規の通信は維持しつつ、データの持ち出し（Exfiltration）経路を遮断します。

9.4 Evict（排除）― 攻撃者の排除

Sysdig の Policy エンジンは、検知と対応を一気通貫で実行できます。

10. 実践：ATT&CK を使ったセキュリティギャップ分析の進め方

MITRE ATT&CK と Sysdig を使って、自組織のセキュリティギャップを分析する実践的なステップを紹介します。

ギャップ分析フロー

ステップ 1: 脅威プロファイルの特定

自組織が対象になりやすい攻撃グループや攻撃手法を特定します。

ATT&CK の Groups ページで、自社の業界を標的にする APT グループを調査
そのグループが使用する Techniques のリストを取得
Sysdig の脅威インテリジェンスフィードと照合

ステップ 2: ATT&CK Navigator でカバレッジを可視化

ATT&CK Navigator を使って、現在の検知カバレッジをヒートマップで可視化します。

ステップ 3: ギャップの優先順位付け

すべてのギャップを埋める必要はありません。以下の基準で優先順位をつけます。

縦軸: 影響度 / 横軸: 頻度

最優先対応（右上）: Container Escape T1611、Valid Accounts T1078

計画的に対応（左上）: Implant Image T1525

段階的対応（右下）: Resource Hijacking T1496、Brute Force T1110

ステップ 4: Sysdig ルールのカスタマイズ

ギャップに対して Falco ルールをカスタマイズします。

# カスタムルールの例: 特定の名前空間での異常なイメージプル
- rule: Suspicious Image Pull in Production
  desc: >
    Detect when an image from an untrusted registry is pulled
    in the production namespace.
  condition: >
    kevt and k8s.ns.name = "production" and
    ka.verb = "create" and
    ka.target.resource = "pods" and
    not ka.req.container.image.repository in
    (trusted_registries)
  output: >
    Untrusted image pulled in production
    (user=%ka.user.name image=%ka.req.container.image.repository
     namespace=%k8s.ns.name)
  priority: CRITICAL
  tags:
    - MITRE_TA0001    # Initial Access
    - MITRE_T1525     # Implant Internal Image
    - MITRE
    - cloud
    - k8s

ステップ 5: 定期的な評価とアップデート

ATT&CK フレームワークは定期的に更新されるため、新しいテクニックへの対応を確認
Sysdig のマネージドルールのアップデートを適用
パープルチーム演習（攻撃チームと防御チームの合同演習）で検知能力を検証

11. まとめ

MITRE ATT&CK を採用する意義

MITRE ATT&CK は、サイバーセキュリティにおける「共通言語」です。セキュリティチーム内の会話から、経営層への報告、ベンダー間の比較まで、あらゆる場面で一貫した基準を提供します。

クラウド・コンテナ時代における重要性

Kubernetes やコンテナ技術の普及により、ATT&CK for Containers マトリクスの重要性は増す一方です。コンテナエスケープ、悪意あるイメージのデプロイ、クラウド IAM の悪用といった手法は、従来のオンプレミス中心の ATT&CK では十分にカバーされていませんでした。

Sysdig の強み ― ATT&CK 活用における 5 つのアドバンテージ

1. ランタイムファースト
シフトレフトだけでは不十分です。Sysdig は 実行時のシステムコール を監視することで、静的分析では見つけられない脅威をリアルタイムに検知します。これは ATT&CK が実際の攻撃行動をベースにしているのと同じ思想です。

2. オープンソース基盤（Falco）
検知エンジンが OSS の Falco であるため、ルールの透明性が高く、コミュニティの知見を活用できます。ATT&CK タグ付きのルールをそのまま ATT&CK Navigator に反映できます。

3. マルチレイヤーの ATT&CK カバレッジ
コンテナワークロード（システムコール）とクラウドインフラ（監査ログ）の両方で ATT&CK マッピングを行い、攻撃のライフサイクル全体をカバーします。

4. 検知から対応までの自動化
ATT&CK テクニックの検知だけでなく、D3FEND の隔離・排除カテゴリに対応する 自動レスポンス まで一気通貫で提供します。

5. 555 ベンチマーク
クラウド攻撃の速さに対応する「5 秒検知・5 分トリアージ・5 分対応」は、ATT&CK の実践的な活用を象徴する指標です。

最後に

セキュリティは終わりのない旅です。MITRE ATT&CK というマップを手に、Sysdig というコンパスを使って、クラウドネイティブ環境のセキュリティを継続的に改善していきましょう。

参考リンク