リストで考える防御者、グラフで考える攻撃者たち (2015)
(github.com/JohnLaTwC)- ネットワーク防御は資産を列挙し優先順位を付けるところから始まるが、実際の攻撃対象領域は資産間のセキュリティ依存グラフとして形成される
- 攻撃者は最も強固な資産を正面から攻撃するのではなく、防御の弱いワークステーションや管理経路をたどって高価値資産への迂回経路を探す
- Windows ネットワークでは、ログオン方式、資格情報、Kerberos TGT、NTLM ハッシュ、共通のローカル管理者パスワード、ログオン スクリプトといった要素がすべてグラフの辺になり得る
- 防御者は資産一覧をグラフに変換し、インフラ分割・資格情報サイロ・最小権限化・二要素認証・資格情報ローテーションによって接続性を下げる必要がある
- 攻撃者は古い図ではなく実際のインフラを断片的に学習するため、防御者は現在のネットワークの接続関係をより正確に把握してこそ優位に立てる
リスト型の防御が見落とすもの
- 多くのネットワーク防御は、攻撃者と接触する前から戦場を誤って理解しているためにずれてしまう
- 防御者は資産を保護し、優先順位を付け、ワークロードや業務機能ごとに整理することに集中する
- システム管理サービス、資産インベントリ データベース、BCDR スプレッドシートには資産リストがあふれている
- しかし防御者が実際に扱うべきなのは個々の資産リストではなく、資産同士がセキュリティ関係で結ばれたグラフである
- 攻撃者はスピアフィッシング(spearphishing)のような手法でグラフ上のどこかに着地し、脆弱なシステムを探してネットワーク内を移動する
- このグラフは外部から与えられるものではなく、ネットワークを設計し運用する防御者自身が作り出している
ネットワーク内のグラフが意味するもの
- ネットワークのグラフは、資産間に同値クラスを作るセキュリティ依存関係の集合である
- グラフに影響する要素は大きく4つある
- ネットワーク設計
- ネットワークの管理方法
- ネットワークで使われるソフトウェアとサービス
- ユーザーの行動
- ドメイン コントローラーの事例では、弱い管理経路が1つあるだけで高価値資産全体のセキュリティ水準が下がる
- Bob がワークステーションからドメイン コントローラーを管理している
- そのワークステーションがドメイン コントローラーと同程度に保護されていなければ、ドメイン コントローラーも侵害され得る
- Bob のワークステーションに管理者権限を持つ別のアカウントも、Bob とドメイン コントローラーを侵害できる
- その管理者たちは業務上、1台以上の別のマシンにログオンする
- 攻撃者がそのうち1台を侵害すれば、ドメイン コントローラーへ至る経路が生まれる
Six Degrees of Mallory: グラフに沿ったラテラル ムーブメント
- 攻撃者は侵害したマシンで待機し、mimikatz のような認証情報ダンパーで高価値アカウントのログオンを待つことができる
- 例示されたグラフの左側のクラスターは、数百人のユーザーが使う単一の Terminal Server である
- 攻撃者がこのマシンを侵害すると、時間の経過とともに多数のユーザーの資格情報をダンプできる
- グラフ探索によって High Value Asset に向かう複数の経路が明らかになる
- Terminal Server の侵害により User46 と User128 も侵害可能になる
- User46 は Machine2821 の管理者であり、User128 は Machine115 の管理者である
- これらのワークステーションを侵害すると User1 と User34 を侵害できる
- User1 と User34 はどちらも High Value Asset の管理者である
- High Value Asset を保護するには、それに依存するすべての要素を High Value Asset と同じ厳しさで保護する必要があり、それらが1つの同値クラスを成す
セキュリティ依存関係を生む関係性
- Windows ネットワークでユーザーが Interactive、Terminal Server など特定のログオンを行うと、基盤ホストが侵害された場合にそのユーザーの資格情報が盗難にさらされる
- 露出対象には資格情報だけでなく、Kerberos TGT や NTLM ハッシュのようなシングル サインオン等価物も含まれる
- セキュリティ依存関係は日常的な管理関係からも生まれる
- 共通パスワードを使うローカル管理者アカウント: あるシステムでローカル管理者パスワードをダンプした後、同じパスワードを使う別ホストに利用できる
- 多数のユーザーに対して実行されるログオン スクリプトを置いたファイル サーバーやソフトウェア更新サーバー
- 利用時にクライアント マシンへプリント ドライバーを配布するプリント サーバー
- スマートカード ログオンに有効な証明書を発行する認証局
- 特権ユーザーとして実行されるデータベース サーバーのコンテキストでコードを実行できるデータベース管理者
- 間接的な関係もグラフの一部になる
- 脆弱性のあるマシンが侵害されると、攻撃者はグラフに新しい辺を作れる
- ユーザーが信頼関係のない2つのドメインに同じパスワードのアカウントを持っていると、ドメイン間に隠れた辺が生まれる
グラフを縮小する防御方法
- 防御者の第一歩は、資産リストをグラフに変換してネットワークを可視化することである
- その後、大きな接続性の爆発を生む不要な辺を見つけ、グラフを剪定しなければならない
- インフラ分割と資格情報サイロを実装する
- 管理者数を減らし、Just-In-Time / Just Enough の手法で権限を最小化する
- 特定の辺の移動を緩和するために二要素認証を使う
- ユーザー アカウント侵害に備えて堅牢な資格情報ローテーション方式を適用する
- forest trust 関係を見直す
攻撃者より優れた現実モデルを作る
- 防御者は戦場を可視化する際、攻撃者に優位を渡してはならない
- 防御者は自分のネットワークについて全体情報を持てるが、攻撃者はネットワークを断片的に学習するしかない
- 攻撃者が研究するのは、不正確なメンタルモデルや不完全な資産インベントリ システム、古いネットワーク図ではなく、現に存在するインフラである
- 防御者も現実を基準にネットワークを管理してこそ、準備された防御者の思考様式に近づける
さらに読む
- Heat-ray: Combating Identity Snowball Attacks Using Machine Learning, Combinatorial Optimization and Attack Graph: J. Dunagan, D. Simon, A. Zheng
- Two Formal Analyses of Attack Graphs: S. Jha, O. Sheyner, J. Wing
- Using Model Checking to Analyze Network Vulnerabilities: P. Ammann, R. Ritchey
- A Graph-Based System for Network-Vulnerability Analysis: C. Phillips, L. Swiler
- Automated Generation and Analysis of Attack Graphs: J. Haines, S. Jha, R. Lippman, O. Sheyner, J. Wing
- Modern Intrusion Practices: Gerardo Richarte
- Attack Planning in the Real World: Jorge Lucangeli Obes, Gerardo Richarte, Carlos Sarraute
1件のコメント
Hacker Newsの意見
攻撃者は通常、重要データの流出、対象の不安定化、ランサムウェアといった一つの任務を持っており、その任務を達成するまで必要なだけ深く探索できる。
一方で防御側は同時に多くのシグナルと脅威ベクトルを追跡しなければならないため、どうしてもリストで考えることになるし、規制のために対処しなければならない項目にまで優先順位を付けなければならない。
グラフのあちこちに防御側がランダムに配置されていて興味深い活動を探す、というのでない限り、防御側がどうやってグラフで考えるのかはよく分からない。筆者が提案したものも結局は、防御側が照合すべきリスト内のシグナルになるだけだ
防御側がその方法を導入すると、レッドチームが実行に移す前に潜在的な攻撃を特定できるようになった。賢いチームなら、たとえば AWS をグラフとしてクロールし、低価値アカウントから高価値アカウントへ至る経路を探すレッドチームの技術をすぐに取り入れるはずだ。
ゼロサムや大転換の話ではないが、防御側も攻撃者のようにもっと考え、攻撃者のツールを防御にもっと頻繁に活用できる
ならばその目標へ至る経路を守るべきであり、その経路がどのようなものか、あるいはソフトウェアに限定されるかどうかは関係ない。
攻撃者が CVE を悪用してインフォテインメントシステムをサービス拒否状態にできるかもしれないが、実際にそれがどれほど重要なのかは疑問だ
実際の攻撃の大半は、「何が見つかるか見て回って、それをどう使うかは後で考えよう」に近い。情報収集、影響工作、プロパガンダのような多くの攻撃活動も同様だ
防御側がリストを使うのは、何百、何千もの資産を同時に管理しなければならないからだ。多くのものを管理するときには、リストを作り、そのリストを見直し、チェックリストを適用することになる。
もちろん防御側も依存関係グラフを作るべきだが、まずリストを作り、それが最新か、限定的信頼を前提にしているか、リソースが分離されているかを確認し、その上で依存関係グラフを作らなければならない。
防御側はリストとグラフの両方を考えながら膨大な数の項目を管理しなければならないが、攻撃者は少数だけ見ればよい
リストをグラフへ変換する洞察がなければ、結局は中核資産のリストだけを手にして、自分が考慮していない無数のアクセス経路をモグラたたき式に塞ぐことになる
この記事は深く入り込みすぎている気がする。あるいは理由は合っていても原因は間違っているのかもしれない。防御側の仕事は防御そのものではない。
サイバーセキュリティは、明確で対等な目標がありポジションを交代で担うスポーツ競技ではなく、防御側が本業として行おうとしている別のビジネスの横にある付随イベントであり、気を散らすものに近い。
逆に攻撃者の仕事は全体がシステムを攻撃することだ。攻撃を弱めるような別の目的や副次的オーナー、考慮事項はない。
攻撃者が勝つ理由は、Microsoft が Cisco より OS のリリースをうまくやる理由と同じだ。Cisco にとって OS は手段だが、Microsoft にとっては目的なのだ
企業がデータ流出によって市場からほとんど罰せられない理由の説明にもなる
サイバー攻撃にはデータ窃取やサービス妨害など明確な目的がある。ただ壊して混乱を起こしたいだけの未熟なアクターには当てはまるかもしれないが、国家アクターや金銭目的の犯罪者を考えると、完全に的外れな見方だ
この記事はむしろ十分に深く入り込んでいない気がする :-)
「リスト」は構成要素の略記であり、「グラフ」は相互運用の略記だ。構成要素の観点は分析であり、相互作用の観点にはまだ適切な言葉がないが、記事で言うようにしばしば攻撃面になる。
複雑適応系には構成要素とメッセージバスがあり、このバスが構成要素同士の相互運用の方法を提供する点が重要だ。アリを一匹ずつ潰すことはできても、本当に防ぐにはフェロモンの痕跡を残す能力を失わせなければならない。
相互運用の仕組みを理解するためにも、「分析」のような言葉があるとよいのだが。Gestaltysis みたいなもの?
以前、少しの間サイバーセキュリティ企業で働いていたことがあるが、なぜその製品が嫌いで、その会社や業界のかなりの部分のアプローチが結局は偽物っぽく感じられたのか、うまく言葉にできなかった。
今ならわかる。私たちはサイバーセキュリティにおける最も役に立たない実践、つまり組織レベルのチェックリストを支えるツールを作っていた。
あらゆる活動の中心にはリストと反復スケジュールがある。定期的に現れて、やるべきことをやらなければならない。
もちろん、その「やるべきこと」の段階では、より深く、より良いアプローチが必要だという点には同意する。
「私たちはすべてのチェックリストに従ったし、セキュリティソフトウェアが見逃したのだから、私たちの責任ではない」と言うためだ。
会社が本当にセキュリティを気にしているなら、S/N比が1%未満の役に立たないスキャナに金を払う代わりに、レッドチームを雇うはずだ。
航空業界を見れば、パイロットはチェックリストに頼って生きている。飛行中に絶対に問題が起きない保証はないが、チェックリストに従わなかったり軽視したりするのは災害を招く。そうしたチェックリストは、何年にもわたる高価な経験の上に作られている。
ただし、単に「チェックリストがある」と言うためだけに存在するものや、実際の条件に合わせて定期的に見直し・更新されないチェックリストは無意味だ。
多くの企業はこれを誤解している。チェックリストそのものがセキュリティだと考えるが、実際にはチェックリストは、以前に正しくやったことを継続して維持するよう思い出させるための道具にすぎない。チェックリストを目標そのものとして扱った瞬間に道を外れる。
ペネトレーションテスターの立場から言うと、攻撃者も必ずしもグラフで考えるわけではない。
BloodHoundを除けば、グラフを使うツールはあまり思い浮かばない。
Webセキュリティでも、「グラフ思考」が当てはまるものは思いつかない。代わりに、テストすべき攻撃の一覧は非常に大きい: https://portswigger.net/web-security/all-topics
そしてペネトレーションテスト報告書に最終的に入るのは、グラフではなく、結局はやることリストだ。たとえばSMB署名、すべてのマシン管理にドメイン管理者アカウントを使わないこと、その他いろいろ。
この言い回しが人気なのは主に、ハッカーコミュニティの自尊心をくすぐるからだ。「自分たちは賢い側で、防御側はExcelシートばかりいじっている」という感じだ。
とはいえ、真実の一片はある。防御側は、それほど重要ではないことにかなりの時間を使ってしまうことがある。すべてのサーバーにCISベンチマークを手作業で適用しているあいだに、強いセキュリティ態勢を作る低い位置の果実を見逃すようなものだ。
多くの企業では、防御側は何に集中すべきかわからないシステム管理者にすぎない。
すぐに思い浮かぶ例がバグチェーンだ。CVSS 4〜7レベルの脆弱性をいくつか組み合わせると、完全なリモートコード実行のような9.8級の結果に変わりうる。こうしたバグの連結は、本質的には侵害要素をたどるグラフ走査だ。
BloodHoundは素晴らしく、攻撃グラフを概念化するのに適した視覚ツールだが、攻撃者の観点で対象ドメインを理解する過程の一部にすぎない。
WebペネトレーションテストにBloodHoundのような整ったツールがない理由は、侵害チェーンを単純にツールの形へ還元しにくいからだ。ADではセキュリティ境界がある程度理解され、コード化されているが、Webアプリのチェーンは基盤フレームワークよりも、そのアプリケーション固有であることが多い。
ペネトレーションテスト報告書にSMB署名や「DAアカウントですべてを管理しないこと」のような項目が入るのは、それらが侵害チェーンのごく初期で強く光るノードだからだ。現実には、しばしばそういう形でやられる。
ペネトレーションテスターがグラフ思考を理解していないというより、グラフの最初のノードが事実上完全侵害を意味するので、それ以上たどる理由がない場合が多い。
これは、防御側があらゆる侵入口を守らなければならない一方で、攻撃側は弱点ひとつ見つければいい、という話を格好よく言い換えたものに近い。
たとえばハニーポットを使って、ゼロデイエクスプロイトを攻撃者の機材へ送り返すようなことはできないだろうか。GoogleやMicrosoftなどの製品に意図的に設計されている可能性もある。
ある種のもっともらしい否認可能性を残しつつ、完全にブラックハットのように振る舞い、ランサムウェア攻撃者にランサムウェアを食らわせるようなものだ。
書いていて、SFに出てくる邪悪な全能企業のように思えてきたが、そういう企業はたいてい敵の暗殺までやる。
インシデント対応もやったことがあり、ペネトレーションテストとレッドチームの経験もある。要約した表現ではあるが、ある程度は正しいし、記事が言うほど否定的に捉える必要はないと思う。
防御はいくつもの要素から成る。たとえば、セキュリティインシデントのリスクと影響を減らす効果的な統制の開発、攻撃と侵害の識別、インシデント対応などだ。標準や対応のリストはうまく機能する。
防御には、こうした統制を設計するためにネットワークグラフを考えなければならないアーキテクチャ上の意思決定も含まれる。防御分野も、アーキテクチャ/エンジニアリング、リスク管理、インシデント対応、アプリケーションセキュリティ、教育、脅威インテリジェンスなど多様だ。
書き手が、防御をリストで考えることが問題だと示唆したあとで、防御改善のために検討すべき項目のリストを提示している点も興味深い。
攻撃者が勝つのは、弱点を見つけたあと、一度だけ成功すればよいからだ。防御側はすべてを同時に守らなければならない。
どのネットワークにも、侵入者を捕まえるためのハニーポットが少なくとも1つは必要に思える。偽の暗号資産認証情報や、偽のパスワード保管庫のようなものだ。