誰も口にしたがらない傾向
「Locked Shields 2026 」は、4月24日にタリンで閉幕しました。。 41 カ国から4,000 名を超える参加者が16 の多国籍チームを結成し、防空、電子投票、5G、衛星管理、および完全に構築された発電システムといった重要インフラを対象とした、およそ 8,000 件のリアルタイムサイバー攻撃に対抗しました。 公式声明では、例年通り、参加者が「悪意のあるサイバー活動を検知し、対応する」能力を称賛しました。
その見方は正しいです。 また、毎年、誰もが話題にしたがる部分でもありますが、その陰で、あまり好ましくない傾向が静かに覆い隠されています。つまり、苦戦しているブルーチームが苦戦しているのは、SOCのプレイブックが不十分だったからではないのです。 彼らは、足元で何かが壊れてしまい、その予兆に全く気づかなかったために、苦境に立たされているのです。 彼らはレイヤー 7 を見上げていましたが、レッドチームはすでにレイヤー2にいました。
ブルーチームの一員として参加したことがある方なら、その会話の内容はお分かりでしょう。 あるサービスが利用できなくなりました。 最初の10分間は、ファイアウォールに向かって怒鳴り散らすことに費やされます。 次の10分間は、EDRコンソールで作業を行います。 誰かが ` ` を実行したり、`arp -a ` を実行したり、あるいは BGP テーブルを確認したりする頃には、そのラウンドはすでに半分終わっています。
この投稿は、OSIモデルについて解説したものです。7層モデルが絶対的なものだからというのではなく、反射的にIR思考に陥りがちなエンジニアにとって、これが最も明快なチェックリストとなるからです。 もし「サービスがダウンしている」という状況に対して、直感的に「WAFを確認しよう」と考えてしまうのであれば、レッドチームがすでに侵入している5つの攻撃対象領域を見落としていることになります。
目次
OSIモデルが今なおその地位を保っている理由
数年おきに、「OSIモデルは時代遅れだ、TCP/IPを使うべきだ」という主張を掲げる人が現れます。 このモデルが抽象化であるという点については、彼らの指摘は正しいです。特にレイヤー 5 と6 は、現代のスタックにおいては、その大部分が単なる管理処理に過ぎません。 「これでは役に立たない」というのは間違いです。 OSIはトリアージフレームです。 何かが故障したり、攻撃を受けたりした際、ツールがたまたま可視化できる箇所ではなく、下から上へと各層を順にたどっていくことが、障害の原因を特定する最も手っ取り早い方法です。
レッドチームはこれを承知しています。 彼らは、検出結果が最も薄い層を選びます。 「Locked Shields」環境においては、それがレイヤー 7であることはほとんどありません。
レイヤー1：物理層
この演習では物理層は抽象化されていますが、そこから得られる教訓は次の通りです：アウト・オブ・バンド管理、コンソールサーバー、KVM、ライトアウト管理インターフェース（iDRAC、iLO、IPMI）。 これらは通常、デフォルトの認証情報や共有管理VLANのままにされており、上流にあるあらゆる検知制御を迂回する経路を提供してしまいます。
ブルーチームの率直な失敗： が OOB ネットワークを「インフラであり、対象範囲外」として扱っていたこと。 対象範囲に含まれます。 もし「red」がiDRACに到達できてしまうなら、その上のファイアウォールは単なる飾りに過ぎません。
レイヤー 2：データリンク層
ここが、不釣り合いなほど多くのダメージが発生する場所であり、「スイッチが処理してくれる」という理由で、ベテランのディフェンダーたちの多くがもはや意識しなくなっている層なのです。 そのスイッチでは対応できません。 このスイッチは、設定された内容をすべて適用しますが、多くの場合、何も設定されていません。
「Layer 2 」の攻撃カタログは、決して新しいものではありません。 そこが肝心なのです。 これらはいずれも、目新しい研究というわけではありません：
- ARPスプーフィング／キャッシュポイズニング（ ）は、ダイナミックARPインスペクションが有効になっていないセグメントであれば、依然として機能します。 攻撃者に、L3+ツールからは検知されない中間者（Man-in-the-Middle）の立場を与えます
- CAMテーブルのフラッディング（ ）により、スイッチがハブとして機能し、攻撃者が傍受できるフレームをブロードキャストしてしまいます
- ダブルタグ付けやDTPの悪用によるVLANホッピング（ ）：設定ミスのあるトランクポートが1つあるだけで、あなたの「セグメント化された」ネットワークはフラットな状態になってしまいます
- DHCPスターベーションと不正DHCP 独自のゲートウェイを割り当て、すべてのトラフィックをそのゲートウェイ経由で転送する
- STP攻撃： がルートブリッジであると主張し、L2 のトポロジーを再構成し、トラフィックをタップ経由で強制的に流します
- LLDP/CDPのインジェクション は、状況把握に役立ち、一部のプラットフォームでは、近隣デバイスを欺くためにも利用できます
これらの防御策は古くからあり、よく文書化されていますが、慢性的に不完全な状態で導入されています。具体的には、ポートセキュリティ、DHCPスヌーピング、ダイナミックARPインスペクション、BPDUガード、ルートガード、DTPの無効化、管理VLANの分離などです。 そのどれもが、ベンダーのホワイトペーパーの表紙を飾っているわけではありません。 それらはすべて、ラウンドの勝敗を決定します。
ブルーチームの率直な失敗： 。ネットワークチームが2019 の段階でこれを行ったと信頼し、その後一度も確認しなかったことです。 チェックを実行してください。 所要時間は1時間です。
レイヤー 3：ネットワーク（そして、もちろんBGPも）
IP層は、防御側にとって安心できる領域ですが、ルーティングプロトコルの領域に足を踏み入れると、その安心感は根拠のないものになってしまいます。
内部ルーティング（OSPF、EIGRP、IS-IS）については、 L2 と同様のパターンが繰り返されます。 このプロトコルにおいて、認証はオプションですが、実際には必須であり、実験室や演習環境では「当面の間」日常的に無効化されているため、それがそのまま本番環境での習慣となってしまっています。 OSPF MD5/SHA 認証が設定されていないピアリングセグメント上の攻撃者は、経路を注入したり、トラフィックをブラックホールに送り込んだり、あるいは気付かれずにトラフィックをリダイレクトしたりすることが可能です。
それから、BGPがあります。 BGPは、その起源をRFC 1105 および1989にまで遡る信頼モデルに基づいてインターネットを運用しており、現実世界の攻撃者も同様にこのモデルを採用しているため、「ロックド・シールズ」シナリオにおいても、BGPがますます取り入れられるようになっています。 関連する攻撃対象領域：
- ルートハイジャック： 自身が所有していない、より具体的なプレフィックスをアナウンスし、トラフィックを自分の方へ誘導すること
- ルートリーク： 。ポリシーに違反して、あるピアから学習したルートを別のピアに通知してしまう現象で、多くの場合、誤って発生し、ハイジャックと同様の運用上の影響をもたらします。
- セッションのリセット： では、細工された TCP トラフィックを使用して BGP セッションを切断します。 これが、TCP-AO（RFC 5925）、あるいは歴史的にはTCP MD5が存在する理由です
- パス操作： ASパスの先頭への追加やコミュニティの悪用により、ルートが依然として「有効」であるため、監視システムでは検知できない形でトラフィックを迂回させる
これらの緩和策は運用上の措置であり、製品固有のものではありません。具体的には、RPKIによる発信元検証、プレフィックスの最大数制限、すべてのeBGPセッションにおけるプレフィックスフィルタリング、ピア認証、そして利用可能な場合はBGPsecなどが挙げられます。 「上流からのルートリークに対して脆弱か」という質問に対する答えが「ファイアウォールが防いでくれる」というものであれば、実際には防げません。 ファイアウォールは、到着するパケットを検知します。 それは、彼らが本来存在してはならない道を通って到着したことに気づいていません。
ブルーチームの率直な失敗： ルーティングを「ネットワークチームの問題」として扱い、セキュリティ部門から切り離して考えていたことです。 演習においても、現実においても、ルーティングこそがセキュリティそのものです。
レイヤー 4：トランスポート
ここではそれほど大げさな話ではありませんが、基本的な対策は依然として重要です。SYNフラッド対策、適切なTCPタイムアウトの設定、シーケンス番号が漏洩するとアイドル状態のTCPセッションが乗っ取られる可能性があるという認識、そして公開しているあらゆるサービス（DNS、NTP、memcached、CLDAP）におけるUDP増幅攻撃の脆弱性への対策です。 ほとんどのディフェンダーは、これをしっかりとこなしています。 L4 でのミスは、通常、検出の失敗ではありません。 の露出に関する記事はこちらです：。 本来アクセスできないはずのセグメントから、サービスにアクセスできてしまう状態です。
レイヤー 5 および6：セッションとプレゼンテーション
実際には、これは「TLSとその周辺のすべて」ということになります。 脆弱な暗号方式、有効期限が切れている、または適切に検証されていない証明書、セッション再開の設定ミス、サーバー側がクライアントの証明書チェーンを検証しないため、実際には「相互」ではない相互TLSなどです。 「Locked Shields」のシナリオでは、意図的な罠として、設定ミスのあるTLSが常套手段として仕込まれています。 単に「HTTPSが有効になっているか」を確認するだけの防御担当者は、この点を見落としています。
もう1つ、過小評価されがちな L5/6 の問題は、アプリケーションのセッション管理です。具体的には、予測可能なセッションID、更新されないトークン、署名なしのJWTなどが挙げられます。 これらはOWASPの定義における L7 の脆弱性ですが、これらはセッションとプレゼンテーションの境界に存在しており、足場を築いた攻撃者が、これらを利用して長期にわたるIDへのアクセス権を獲得する手段となります。
[サイバー犯罪者が「ラテラルムーブメント」を利用してネットワーク内を移動する仕組み、その検知が困難な理由、そしてこれを阻止するのに役立つ対策について学びましょう]
レイヤー 7：アプリケーション
実際に、防御用のツールのほとんどはここに配置されているため、多くの防御担当者は自然とここを真っ先に検討するのです。 Webの脆弱性、マルウェアの挙動、認証の悪用、APIのロジックの欠陥。 どれも重要ではないわけではありませんが、すでに広く知られたことであり、お使いのスタックではすでに考慮されています。 修正すべき偏りは、その逆です。つまり、インシデントの調査開始から30分が経過しても、症状が一致しないにもかかわらず、依然として「 L7 」の説明を探し続けている場合は、調査のプロセスを一歩戻って見直してください。
ファイアウォールは本題ではありません
長年にわたる「Locked Shields」の事後報告書や、その報告書の作成の糧となっている本業からの経験に基づき、次のような仮説が立てられます。経験豊富なブルーチームのエンジニアの中央値は、検知を過大評価し、設定を過小評価しているということです。 検知機能こそが、彼らのツールの売りなのです。 設定こそが、そのラウンドの勝敗を左右するものです。
A useful pre-engagement 5 step checklist for an experienced defender, in the order an attacker thinks about them:
- すべてのアクセススイッチにおいて、レイヤー 2 のセキュリティ対策（ポートセキュリティ、DHCPスヌーピング、DAI、BPDUガード、DTP無効化、管理VLANの分離）は適切に実施されていますか？
- ルーティングプロトコルのセッションは認証されており、すべてのeBGPピアでmax-prefixおよびprefixフィルターが設定されていますか？ RPKIの検証は、単に有効化されているだけでなく、実際に実施されているのでしょうか？
- 管理用インターフェース（OOB、iDRAC/iLO/IPMI、スイッチ管理、ハイパーバイザーコンソール）は、攻撃者が侵害されたユーザーエンドポイントから到達できないセグメントに配置されていますか？
- TLSの設定は、単に想定されているのではなく、実際に検証されていますか？mTLSが主張されている場合のクライアント証明書の検証も含まれますか？
- 次に、 L7 スタックです：WAFルール、EDRの適用範囲、SIEMによる検知、IRプレイブック。
順番が重要です。 最初の4つの項目は、 のIRフェーズ がまだ始まる前から、知らず知らずのうちにラウンドを失ってしまう原因となっています。 また、これらは正常に動作している間はアラートが発生しないため、四半期レビューのスライドに盛り込まれる可能性が最も低い項目でもあります。
（基礎が整った上で）Taniumがどのような場面で役立つか
範囲については正直に申し上げたいと思います。 Taniumでは、BGPピアの認証は行われません。 この設定では、アクセススイッチ上でダイナミックARPインスペクションは設定されません。 上記のチェックリストの最初の4項目はネットワークエンジニアリングであり、その業務に代わるエンドポイントプラットフォームは存在しません。
しかし、スタックを逆方向にたどっていくと、状況は一変します。 というのも、ネットワークプレーンが正しく設定された後、次に浮かぶ疑問は、「各エンドポイントで実際に何が実行されているのか、本当に把握しているでしょうか？」ということです。 パッチが適用され、セキュリティ強化され、ご自身が想定されている通りに設定されていますか？ 必要なサービスだけを正常に実行し、それ以上は何も行わないのでしょうか？
それが、「Locked Shields 2026」でTaniumを導入したレイヤーです。 ライブ配信期間中、当プラットフォームでは以下のコンテンツをお届けしました：
- 環境内のすべてのホストのリアルタイム在庫状況 WindowsおよびLinux向け。演習の途中で追加したセグメントも含まれます。
- ソフトウェアの部品表（SBOM）とライブラリレベルの可視性。 は、コンポーネントやバージョンに至るまで、すべてのエンドポイントを網羅しています。
- 修正措置に直接リンクされた脆弱性データ： 脆弱性のあるライブラリを特定し、同じコンソールから修正プログラムを適用します
- 新たに検出されたホストへのTaniumエージェント「 」の自動展開。手動によるオンボーディングキューは不要です。
- パートナー各社のアンチウイルス（AV）およびEDRエージェントの配布と更新 は、単一のコンソールからTaniumと連携して、全端末に一斉に展開されます
- OSおよび のサードパーティ製パッチ適用 を大規模に実施 Windowsの累積更新プログラム、.NET、SharePoint、Linuxカーネル、ライブラリのパッチなど
- のセキュリティ強化スクリプトを環境全体に展開・再適用したため、設定されていないホストは一つも残らなかった
- ローカル認証情報のローテーションにより、 を短い間隔で展開し、盗まれたパスワードの有効期間を制限しました
- による、プレッシャーの下で作成され、全端末に展開されたカスタムインシデント対応パッケージ。これには、ファイアウォールルールの展開、持続性関連のクリーンアップ、インプラントの削除が含まれています。
- 単一のコンソールから、エンドポイント環境全体にわたる脅威ハンティング を実施します
- 標準のネットワーク経路が機能低下した際のフォールバックとして、エージェントベースのコマンド配信 を利用します
そうしたことは、レイヤー 2 を正しく理解することに代わるものではありません。 どのエンドポイントがあるか把握していないと、すべてが機能しなくなってしまいます。 この2つの分野は互いに補完し合っています。 「Locked Shields」で好成績を収めているチームは、これら2つを並行して運用しています。すなわち、下層には堅牢化されたネットワークプレーンを、上層には完全に管理され、可視性が確保されたエンドポイント環境を構築しているのです。
まとめ
『Locked Shields』は素晴らしい作品であり、その中で紹介されている赤外線技術は本物です。 しかし、この演習では、年を追うごとに、経験豊富なディフェンダーが基盤となる層で勝利を収めていることが、繰り返し示されています。 アクセスセグメントでARPとDHCPを厳重に管理し、ルーティングセッションの認証を行い、管理プレーンをセグメント化したチームは、平均的に見て、より洗練されたSOARプレイブックを持つチームを上回る成果を上げるでしょう。
この記事（ ）から一つだけ覚えておいていただきたいことがあります。次に何か不具合が発生し、反射的にファイアウォールのコンソールを開こうとしたときは、まずshow mac address-table または show ip bgp summary を実行してください。 その答えは、あなたが認めたくないほど頻繁にそこにあるのです。 そして、ネットワーク層が安定したら、その上に実際のエンドポイントプラットフォームが構築されていることを確認してください。 まずは基本から。 2番目のプラットフォームです。 その順番で。
「Locked Shields 2026 」の数値および引用文は、、CCDCOE、 、SHAPE NATO より引用しており、演習シナリオの詳細は および SANS Institute を通じて確認されました。
掲載画像提供：Blue Team 10 @ Locked Shields
