パープルチーム
検知カバー率は通常、フレームワークに対する百分率で語られます。その数字はルール名を読んで出てきたものです。ルールが本当に発報するかを知る唯一の方法は、それが捉えるはずの行為を実際に行い、誰かがコンソールを見ている状態で、何が現れたかを書き留めることです。
含まれるもの
- MITRE ATT&CK と、私たちが実際に目にしているものから選んだ、事前合意の技術リスト
- 貴社の検知チームと並走しながら、リアルタイムで実行
- 技術ごとの結果: アラートが上がった、アラートなしでログだけ残った、あるいはテレメトリが一切ない
- あと一歩で発報したルールへのチューニング提案
- 時間が許せば、同じ案件の中でチューニング後に失敗した技術を再実行
得られるもの
- 双方のタイムスタンプを添えた、技術ごとの結果一覧表
- カバー率が低かったという事実だけでなく、具体的に欠けていたログソース
- 貴社が実際に使っているクエリ言語で書いた検知ロジックの提案
- まず何を直すべきかの短いリスト。技術の一般的な広まり具合で並べます
- 検知チームとの振り返り
- ご要望に応じた、監査人・顧客向けの証明書簡
- 再テスト後の修正証明書（独立した文書として）
案件の形
- 個別に範囲設定テスト開始前に書面で確定します。現地またはオンラインで 2〜5 日一般的な実施期間。期限がある場合はそれに合わせて組み立てます。料金の考え方
たいてい見えてくること
よくある結果は、検知が「無い」ことではありません。テレメトリはある、ルールもある、しかし両者が噛み合っていない - ルールが参照するテーブルに当のログソースが書き込んでいない、技術が使わないプロセス名で絞り込んでいる、あるいは午前 2 時に誰も見ていないチャネルへ通知している。いずれも、起きていることを誰かが示しさえすれば、安く直せます。
二番目によくある結果は、まったく問題のないログを出しているのに、それを誰も照会していない技術です。このリストの中で最も安上がりな指摘事項であり、文書レビューだけでは最も見落としやすいものでもあります。
セッションの進め方
まず技術リストを合意します。誰も不意を突かれず、貴社チームがクエリを準備できるようにするためです。当日は各技術を順に実行し、実行しながらその都度宣言します。貴社チームは、何がいつ見えたかを報告します。双方がタイムスタンプを記録します。ある技術が何も生まなければ、そこで止まり、原因がログソースなのか、ルールなのか、転送経路なのかを切り分けてから次へ進みます。
これに当たらないもの
これは協働の演習であり、秘匿のものではありません。捕まらないように動く相手を貴社チームが捉えられるかを知りたいのであれば、それはレッドチーム評価であり、測るものが異なります。また、私たちは貴社の検知体制を運用も監視も人員提供もしません。テストし、調整を手伝い、その所有者にお返しします。
ご質問
ログが集まる場所と、それを照会できる人が必要です。成熟している必要はありません。最も有益だったセッションのいくつかは、SIEM 導入から 3 か月のチームが、自分たちの前提のどれが正しかったのかを確かめたいという場面でした。
MITRE ATT&CK から事前に合意し、実際に使われているのを目にするもの - 認証情報へのアクセス、水平移動、証明書の悪用、永続化 - に重みを置きます。特定の脅威モデルや、業界で最近起きた事案で取り上げたいものがあれば、お持ちください。
ロジックをご提案し、貴社が使っている言語でクエリの草案をお渡しします。多くは Microsoft Sentinel 向けの KQL です。所有し、検証し、展開するのは貴社チームです。社内の誰も理解していないルールは、次の抜けになるからです。
はい。案件の実施期間が許せば、同じセッション内で失敗した技術を再実行します。これが最も速いフィードバックの回し方です。
個別に。技術リストの規模と実施期間の長さによります。通話の後に書面で確定します。
購入前に、対象範囲をきちんと定めてください。
通話は 30 分、24 時間以内に書面の固定価格、そしてこれが必要な案件でない場合には率直にそう申し上げます。