MITRE ATT&CK Evaluations (2020年実施分)の個人的な結果検証 その８

ベンダー別検知状況集計結果一覧

ベンダーごとに、検知した項目数を集計した結果一覧です。

検知率は、全項目数のうち、〇になった数の比率です。

また、設定変更数は「Configration Change」が1つ以上付与されていた項目数です。

表示は検知率順にしています。

ベンダー	〇	△	×	検知率	設定変更数
SentinelOne	159	15	0	91.37931	0
Check Point	157	6	11	90.229885	49
Bitdefender	151	7	16	86.781609	39
Palo Alto	149	20	5	85.632184	0
Cybereason	148	12	14	85.057471	5
Trend Micro	139	28	7	79.885057	53
Microsoft	134	17	23	77.011494	32
CyCraft	125	5	44	71.83908	0
Symantec	124	35	15	71.264368	7
FireEye	124	12	38	71.264368	15
Fidelis	121	28	25	69.54023	53
Cynet	107	46	21	61.494253	31
ReaQta	101	34	39	58.045977	0
ESET	93	54	15	57.407407	22
BlackBerry Cylance	99	42	33	56.896552	28
McAfee	93	58	23	53.448276	12
Malwarebytes	85	31	46	52.469136	33
VMware Carbon Black	90	64	20	51.724138	0
Micro Focus	83	38	53	47.701149	15
F-Secure	80	72	22	45.977011	14
Open Text	67	58	37	41.358025	56
Fortinet	67	50	45	41.358025	10
Elastic	63	77	34	36.206897	22
CrowdStrike	63	89	22	36.206897	24
GoSecure	58	42	62	35.802469	8
Uptycs	62	65	47	35.632184	9
Cisco	42	80	52	24.137931	3
Sophos	39	79	44	24.074074	6
AhnLab	36	54	72	22.222222	4

ざっくりな所感（小並感）

小並感書く前に、Mitre Engenuity Att&ck Evaluations の Result からデータを Excel に転記して集計する作業の段階で力尽きてますが。

実際のAPTグループの手法を模擬したテストと、多数のベンダーが参加したということで、性能や傾向分析のためにやってみましたが、色々と読み取れるものはあると思います。

その4～その7で、各検知項目別で〇×を付けてみましたが。

それぞれの項目ごとに、検知したベンダー、検知できなかったベンダーの数を集計してみても、割と面白いことが分かります。

例えば、×になっている項目の集計結果の大きいものをみていくと、多くのベンダーが不得手にしている攻撃が見えてきます。

×になっている集計結果を大きいものから並べなおしてみると、通信系が多いことが目立ちます。

MitreのIDとしては、T1071（アプリケーション層プロトコル）、T1573（暗号化されたチャネル）といったものが対象です。

多くのエンドポイントセキュリティソリューションが通信系からの検知を苦手としていることが分かります。

ただし、これが大きな弱点になるか、というと、必ずしもそうでもありません。

ネットワークの監視は、社内の環境であればネットワーク機器やネットワークセキュリティサービスが監視していることもあり、こちらでカバーできるのであれば、組み合わせで守る、ということも十分考慮できます。

他に×になっている集計結果で大きいものは、T1083（ファイルとディレクトリの探索）、T1113（スクリーンキャプチャ）、T1057（プロセスの探索）、T1016（システムネットワーク構成の検出）といった情報収集系のものが目立ちます。

これらについては、ユーザや管理者による操作との見分けが難しいため、検知も難しいということも考えられます。

また、データ収集をやろうと思えばできるものの、実環境でユーザが操作している場合では、データが多くなりすぎたり、誤検知が多くなる可能性もあり、あえて対象外にしているベンダーもあるのではないかと思われます。

こういった傾向分析をふまえて、そこから妥当なセキュリティ環境構築をできればよいのではないかと思います。

「Configration Change」については、個人的には引っかかるポイントです。

今回検知率が高かったベンダーであっても、設定変更によりヒットした項目が多くみられるものもあります。

先の記事でも述べましたが、「これ、運用時にそんなに都合よく設定変更できるものなの？」という疑問が付きまといます。

「Configration Change」が付いている場合、「特定の設定で一度も設定変更せずシナリオを実施した場合の検知状況」もあれば、ベストな検知設定のケースとはいえ、運用時に近い結果になるんじゃないかと思ったりします。

（それでも、「そんなにいい設定なら、なんで最初からそれにしておかないの？」っていう別の疑問もあるっちゃありますが。）

今回、私はやっていませんが、「運用時に都合よく設定変更なんてできないんだから、「Configration Change」のついた項目は×扱い」というシビアな基準で評価をしてみると、検知率の集計結果も結構変わるかもしれません。

この表で検知率が上位でも、Configration Changeが40近く～50台と、割と目立つ回数、設定変更行っているベンダーがあり、これらは設定変更が無い場合は大きく性能を下げる可能性があります。

なお、今回の集計では、「Configration Change」がついている項目は機械的に全てカウントしてしまっています。

例えば、同じ項目に「Technique」と「Technique(Configration Change)」があっても、「1」とカウントしてしまっています。

このケースでは、Configration Changeせずに検知しているものもあるので、設定変更は×という基準だったとしても評価は「〇」でいいと思います。

このため、私のこのブログの表の 検知数（〇の項目） - 設定変更数 としても、設定変更無しの正しい検知数にはならないため、注意してください。

各ベンダーごとの小並感は・・・私がエラソーなこと言えるわけではないのですが。

時間があって気が向いたら、知ってるベンダーあたりは書くかも？しれません。

Mitre Engenuity Att&ck Evaluations の結果は、かなりしっかりした手順で評価していると思います。

今回の記事の方法に限らず、Result を色々な観点で評価し、ソリューション選定に役立ててみては、と思います。