自社の検知はRansomwareを十分カバーできているか
MITRE ATT&CKのカバー率が高いだけでは、自社の実力を判断できません。検知ルールが実際に動くか確認するための4つの問いを整理します。
自社の検知はランサムウェアを十分カバーできているか
「今日ランサムウェアが入ってきたら、うちは検知できるのか」― 経営層からこう聞かれたとき、いちばんよく返ってくる答えが「大丈夫です、EDRもSIEMもファイアウォールも一通り揃っています」です。
これは答えになっていません。買ったものの一覧です。
ずっと答えにくいのは、どこまでカバーできていて、その根拠は何かという問いのほうです。稟議を通す人にとっての「一通り揃っている」と、深夜3時に画面を見続ける人にとっての「一通り揃っている」は、同じ言葉で別のものを指しています。
カバー率のパーセンテージが目を曇らせる理由
MITRE ATT&CKは、この問いに答える最も直接的な方法です。「守れているか」を、チェックの入る表に変換してくれるからです。（ATT&CK自体がまだ馴染みのない方は、まずMITRE ATT&CKとは何かをご覧ください。）
ただし、その表を1つのパーセンテージに圧縮した瞬間、その数字は少なくとも3通りのやり方で読み手を欺き始めます。
罠1 ― ルールがあることと、ルールが動いていることは別
最初にぶつかるのがこれです。多くのSIEMは初日から大量の検知ルールを標準搭載していて、レポート画面はその全件をカバレッジとして数えます。
問題は、ルールはログが供給されて初めて発火するという点にあります。エンドポイントのログを前提としたルールが、EDRをSIEMに接続していない環境に置かれていれば、それはよく書けたまま眠っているルールです。紙の上ではカバレッジに数えられますが、何も守っていません。
罠2 ― technique単位で数えると実力以上に見える
ATT&CKはtechnique単位で数えます。現実には、1つのtechniqueに複数のやり方があります。
暗号化の前に防御機能を止める動きを例に取ると、サービスを停止する手も、レジストリを書き換える手も、正規に署名された脆弱なドライバを持ち込んでEDRを落とす手もあります。ルールが最初の手しか捉えられなくても、表の上ではそのtechniqueはcoveredのままです。
パーセンテージが嘘をついているわけではありません。ただ、レポートを読む人が思っているよりずっと粗いのです。
罠3 ― マトリクス全体を埋めることと、ランサムウェアをカバーすることは違う
ATT&CKにはtechniqueが大量にあり、ランサムウェアはそのすべてを使うわけではありません。表を端から緑にしていく作業は、重み付けのない力の配分になります。
やるべきは、ランサムウェアが実際に歩く経路を選んで、そこだけを深く測ることです。どう侵入し、どう権限を上げ、どう横に移動し、どう防御を止め、最後に暗号化するのか。この経路のどこか一点でも穴が空いていれば、マトリクス全体の数字は何の役にも立ちません。
数字を1つにまとめず、状態別に数える
zcrSIEMのDetection Coverage画面は、まさに罠1を見抜くために作られています。検知ルールを総数ひとまとめで数えるのではなく、状態別に分けて数えるからです。区分は3つあります。対応するログソースがすでにログを送っていて、今日発火しうるもの（Live）。ルール自体はあるものの、それを動かすログをまだ繋いでいないため待機しているもの（Ready）。そして、今のところどのソースからもログが来る見込みのないもの（Uncovered）。
罠1は、これで数字として見分けられます。「持っている件数」と「今日動いている件数」が、別々に並ぶからです。この2つが離れているほど、レポート上の緑と実態の差は大きいということになります。
ATT&CKのtechnique単位でも、同じ切り分けが効きます。ルールが用意されているtechniqueの数と、そのうち実際にingestされているログの上で発火しているtechniqueの数が、別々に表示されるからです。前者だけを取り出して「すべてカバー済み」と経営層に報告すれば、その差の分だけ死角を自分の手で覆い隠したことになります。レポートに出る分母が何を数えた数字なのかも、同じように説明できるようにしておくべきです。
右側のMITRE ATT&CK coverage by tacticのグラフは、この差をtactic別に分解します。濃いバーが今日のログの上で発火している部分、淡いバーが残りです。どのtacticが薄いのかは、数字の一覧よりバーで見るほうがずっと早く分かります。
見るべきはバー1本の長さそのものより、tactic同士の関係です。Initial Accessが端まで濃いのにLateral Movementの濃い部分が途中で止まっているなら、そのグラフは居心地の悪いことを言っています ― 誰かが侵入した瞬間は捉えられても、その人が別の端末へ移っていく場面は捉えられない。ランサムウェアにとって、そこは見逃したときの代償が最も大きい段階です。
ログソースの側はどうか
Coverage by log sourceのパネルが、もう半分に答えます。ログソースを1つずつ並べ、そのソースが有効化するルールを、今日ログが届いているもの（Ingested）と、これから繋ぐ予定のものとに分けて示す作りです。FortiGate、Palo Alto、Cisco ASA、Sangfor NGAFといったネットワーク機器、Windows Active Directoryの認証ログ、CrowdStrike Falconのエンドポイントログ、メールゲートウェイ ― パネルに載るのはこうしたソースです。
この一覧が効いてくるのは、1行が消えたときです。もし今日CrowdStrike Falconがログを送らなくなったら ― エージェントの不具合、誰かが触ったポリシー、ライセンス切れ ― そのソースに紐づいていたルールが、同じ瞬間にまとめて沈黙します。しかも、けたたましいアラートと違って、沈黙は自分から名乗り出てくれません。「ログが来ていないこと」を見張る仕組みは別途設定が必要な話で、最初から有効になっていると思い込まないほうが安全です。
「このソースに紐づくルール数」が行ごとに見えることの価値は、思っているより大きい。「ログソースが落ちた」を、ありふれたIT障害から、技術に明るくない相手にも一息で説明できるリスクの数値に変えてくれます ― ルールを買い足す前にEDRのログをSIEMへ正しく取り込む作業を片付けておく価値があるのは、このためです。
どう測るか ― 4つの問いから
大がかりなプロジェクトは要りません。まずこの4つに答えてみてください。
1. 今この瞬間、実際に動いているルールは何件か。 その数と、システムに登録されている件数。この2つが大きく離れているなら、その差はまだ払っていない負債です。
2. ランサムウェアを段階ごとに切ったとき、各段階を支えているログはどれか。 検知の手引きではなく、棚卸しの表として使ってください。
| ランサムウェアの段階 | その段階が見えるために必要なログ | 今日ingestされているか |
|---|
| 初期侵入 | メールゲートウェイ、境界のファイアウォール/VPN、プロキシ | ☐ |
| 認証情報の窃取と権限昇格 | ADの認証ログ | ☐ |
| 探索と横方向の移動 | エンドポイント（EDR）＋認証 | ☐ |
| 防御停止とバックアップの削除 | エンドポイント（EDR） | ☐ |
| ファイルの暗号化 | エンドポイント（EDR） | ☐ |
どのログで見えるのかを即答できない段階、あるいは分かっていてもそのログをまだ繋いでいない段階 ― そこが本物の死角です。ATT&CKの表に残った空白マスより、はるかに重い。
各段階でルールが何を探すべきかはSIEMでランサムウェアを検知するにまとめてあります。散らばったイベントが1本の線につながっていく様子は、MITRE ATT&CKでattack flowを読むをご覧ください。
3. 最も重要なログソースが1つ消えたら、何件のルールを失うか。 30秒で答えられないなら、誰もこれを測っていません。
4. 最後に実際に撃ってテストしたのはいつか。 これがいちばん重要で、どのダッシュボードにも代わりに答えられない問いです。
カバレッジ画面が答えられないこと（答えられるふりをしてはいけないこと）
この種の画面は「ルールがあるか、そして動いているか」にはよく答えます。少なくとも4つ、答えられないことがあります。
ルールがチューニングされているかは分かりません。 1日に200回発火して、チームが通知を切ってしまったルール。それはルールが無いのと同じ価値です。それでもカバレッジ画面の上では、いちばん優秀なルールと並んでLiveと数えられます。
入ってきているログが「揃っている」かは分かりません。 Ingestedのタグは、そのソースからログが来ていることだけを示します。すべての種類が有効になっている保証はありません。トラフィックログだけを送りIPSログを送っていないファイアウォールも、同じようにIngestedと表示されます。これは機器の設定を自分で確認するしかなく、近道はありません。
実際に検知できることの証明にはなりません。 「捉えられるはずのルールがある」と「テストして実際に捉えた」の間には、テストでしか埋められない距離があります。ダッシュボードを読むだけでは埋まりません。
間に合うかどうかは分かりません。 カバレッジは「見える」ことの話です。止めるのが間に合うかは別の問題で、自動化と人の訓練の領分になります。
率直に言えば、Detection Coverage画面の価値は、感覚で議論する代わりにデータで議論できるようになることです。それだけでも十分に元は取れます。ただ、安全であることの証明書ではありませんし、その証明書を発行できるツールも存在しません。
この話が自分ごとかどうかのサイン
- 今実際に動いているルールが何件か、その場で答えられない
- 新しいログソースを繋いだばかりだが、それがどのルールを有効にしたか把握していない
- ログソースが何日も停止したまま、誰も気づかなかったことがある
- 経営層向けレポートにカバレッジのパーセンテージが載っているが、その分母を説明できる人がいない
- ランサムウェア側のルールが本当に発火するか、テストしたことがない
2つ以上当てはまるなら、いちばん費用対効果が高いのは、今持っているものを正確に測ることです。ルールやツールの買い足しは、そのあとで構いません。手元のうち何件が動いているのかすら、まだ分かっていないからです。
zcrSIEMのアプローチ
zcrSIEMは「持っているルール」と「実際に動いているルール」を1画面で切り分けます。Live / Ready / Uncoveredがルールの状態を示し、coverage by log sourceはどのソースを失うと何件のルールを失うかを示し、ATT&CK by tacticのグラフは穴がどのtacticにあるかを示します。既製のルールでは届かないケース向けに、Create custom ruleのボタンも用意されています。
代わりにやってくれないのは、どの穴を先に塞ぐべきかという判断です。そこはまだ、自社のビジネスを知っている人間の仕事です。
今の環境が実際にどこまでカバーできているか知りたい方は、プランと料金をご覧ください。ルールがまだ捉えられていないものをどう狩りにいくかに関心があれば、AI threat huntingへ続けてどうぞ。
お問い合わせ
今お使いのdetectionのどこに穴があるのか知りたい方は、お気軽にご相談ください。無料でご相談いただけます。
参考資料