MITRE ATT&CK Evaluations (APT29)の個人的な結果検証　その３

前回の記事でも書きましたが、MITRE ATT&CK Evaluations は、テストの結果として検知状況の客観的な評価のみが行われています。

この結果を見て、どのソリューションが有用か判断するのは、見る人の価値観次第ということになります。

「Telemetry以上があれば良い」という人もいれば、「Techniqueが分かることに意義がある」という人もおり、そういった見る人の基準によって優劣の判断が異なるわけです。

今回、このブログの記事では、MSSP、General、Tactic、Techniqueに重点を置いて評価します。

理由としては、「サイバー攻撃の対策として、まずは検知ができることが重要」という考え方に基づいています。

このため、MSSP、General、Tactic、Techniqueは検知として「〇」、Telemetryは検知にいたらなかったもののデータがあり、事後検証には有用なので「△」、Noneは未検知として「×」とします。

次に、スコアリングのルールです。

テストは大きな2つのシナリオで大きく10ステップありますが、その1ステップの中でも実施項目（Procedures）が複数あります。

例えば、「ステップ１：初期侵害」でも、1.A.1～4、1.B.1～2と6つの実施項目があります。

今回は、この実施項目を1単位として、その単位ごとに評価します。

例えば、「1.A.1 〇、1.A.2 〇、1.A.3 △、 1.A.4 ×、1.B.1 〇、1.B.2 △」といったように、実施項目ごとに検知の有無でスコアリングしていきます。

なお、今回のEvaluationsでは、実施項目に複数の評価がついていることがあります。

（以下は、MITRE ATT&CK EvaluationsのResultから抜粋）

以上の例では、1.A.1 では「ユーザ"Pam"でrcs.3aka3.docを実行」という実施項目に対し、TechniqueとMSSPが評価として出されています。

これは、この実施項目で、検知のエビデンスが複数得られたためのようです。

また、ややこしいもになると、１項目で「MSSP」と「Telemetry」がある場合もあります。

今回は、実施項目１つあたりで複数検知があっても、一つの検知としてスコアリングします。

例えば、1.A.1 「ユーザ"Pam"でrcs.3aka3.docを実行」という実施項目についてみる場合、これを検知できたかできなかったかで判断し、これの検知にいくつのエビデンスが得られたかは問わない、という判断です。

こういった判定にした理由は、評価対象のソリューションで評価数の分母を揃えたかった事と、実施項目による検知にばらつきがあっても、１つの実施項目で複数の検知があることで、検知数が多く見えてしまうのはナニカチガウと思ったためです。

実施項目毎のスコアにすることで、各手法に対しまんべんなく検知できているのか、得手不得手があるのかというのが見えるのではという考えです。

とまあ、相変わらずダラダラと考え方を書きましたが、まとめると今回は以下の「さきえる的オススメソリューション」基準で評価します。

検知したかどうかを重視するため、MSSP、General、Tactic、Techniqueを〇とする。
検知はできなかったものの、後で検証するときに使えるエビデンスがあるということで、Telemetryは△とする。
検知も情報収集もできていなかったNoneは×とする。
評価は実施項目単位で、複数評価があった場合は一番いいものを評価対象とする。（例：一つの実施項目に「MSSP」と「Telemetry」があった場合、「MSSP」による検知があったと判断し、その実施項目は「〇」とする。）
検出の修飾子は、今回の評価対象では特にスコアには影響しない。

「検知が重要」とはしているものの、アナリスト寄りな観点ではありますねｗ。これは立場によって良しあしが変わってくるので、ご了承ください。

むしろ、「自分はこれを重視したい」、「こうスコアリングしたい」というのがあれば、それを決めて自分で資料を作成したほうが、より良い資料が得られます。

この評価基準に納得できなくても、それで自分の納得いく評価基準を作っての評価をするという尻を叩ければ、今回の記事の目的は達成できているのですから。

では、以上のルールで判定した結果の表を、次のページ以降で掲載します。

本当はこのページにまとめて掲載しようと編集していたのですが、ブログの文字数制限を超えてしまったので・・・（表にしているため、タグ文字で相当膨れた）。

同じ原因で、２シナリオ分でも文字数オーバーしてしまい、シナリオ毎の掲載になってしまいました。すいません。

表も、このままだとやはり見難いので、追加の記事で集計結果も出します。

（少々お待ちください。）

表は、ブログでのHTMLでの表という都合上、ソリューション名を略名にしています。

また、各ステップの詳細な実行内容やその時のテクニックも、表の幅の関係上、厳しかったので含めていません。

それでも、表にそれなりに幅があるので、スマホでは見切れてしまうかもしれません（汗）。

実際に自身で表を作る場合、実行内容やそれぞれのテクニックも転記しておいたほうが良いでしょう。

そうすれば、〇×と比較して、どのような攻撃に対して検知ができる、できないが浮き彫りになります。

例えば、あるソリューションではPowerShellを使った検知が厳しかったり、またあるソリューションでは通信関係の検知が厳しかったり、ということが分かります。

もちろんその逆で、強みが分かることもあります。

多少の手間にはなりますが、そういったこともした方が、よりよい評価資料になるでしょう。

reverse-eg-mal-memoのブログ