чтобы проводить какую-либо оценку нужно иметь достоверные данные и четкие определения.

о каких-либо четких определениях в разрезе всех техник пока говорить сложно, но:

- о некоторых техниках все же можно (зависит от компетенций. например вырубаешь везде NTLM и прощай PtH, но тут сложности с легаси, как вы уже описали)
- о подходе со стороны известных правил детекшена тоже можно. иными словами, вы можете взять все известне техники, взять имеющиеся у вас правила детекшена, определить какие источники данных необходимо собирать, какие политики логирования реализовать, включить все это дело в тестовом режиме на части своих систем, посчитать сколько данных (EPS) к вам на мониторинг прилетает, и на основе этих данных перевести все в деньги (посчитав необходимые ресурсы). мы эту аналитику предоставляем в нашем проекте (https://github.com/krakow2600/atomic-threat-coverage). но не как MITRE,абстрактно, типо процесс экзекушн лог, а конкретно — такой-то лог, такая-то политика логирования и тд

У нас есть оценка почти всех митровых техник (через наши правила обнаружения) с точек зрения - критичности, достоверности обнаружения (false negative) и "постороннего шума" (false positive), что в совокупности дает условный коэффициент полезности правила. Но это очень условная оценка, которая в контектсе конкретной инфраструктуры может значительно исказиться.

Поэтому поддержу как этот проект, так и сам подход)
Если хотите построить адекватную оценку ресурсозатрат для выявеления всех техник, актуальных для модели угроз вашей инфраструктуры, то наилучший вариант это выделение тестового сегмента инфраструктуры, в рамках которого будут выполнены все настройки аудита, сбора и обработки нужной инфы. Далее проверяете, что все актуальные для вас техники ловятся или блокируются и оцениваете ресурсо и трудозатраты.

Относительно маппинга источников и типов событий на техники, есть и решения попроще, чем вышеупомянутый ATC, например:
https://medium.com/@olafhartong/assess-your-data-potential-with-att-ck-datamap-f44884cfed11

у Олафа есть один косяк — он использует данные указанные в MITRE ATT&CK. то есть оно там и остается, на неком уровне абстракции, без конкретики

от того что он сделал аналитику по этим абстрактным данным, и привел свою волшебную (иначе не назвать) шкалу рассчета покрытия (pretty good, good, not good, shitty, etc) никому ни горячо не холодно. как это применять на практике не понятно

я спросил у него что стоит за этими его категориями, он ответил какую-то нелепицу навроде неких весовых коэффициентов, но оно все равно все настолько условно что совсем условно, ибо чтобы что-то считать — нужно знать где этому всему делу начало, и где конец.

(он выступал сразу после нас на AMSTERDAM FIRST TC пару недель назад)

Там есть некоторые ограничения, но в целом это лучше, чем у митра - там вполне конкретные типы источников и типы событий.

Категории мне тоже не особо понятны)
Я рассматривал это как альтернативный инструмент структурирования базы знаний, по факту небольшое расширение аттак.

не, я ничего не имею против, это очень крутой дядька, который сделал шаг в сторону решения этой проблемы и это очень достойный труд. он пушил идеи и функции для sysmon, некоторые вещи там появились только благодаря его риквестам.
я это к тому что подход по прежнему спорный, и не является решением проблем хоть с какой-либо позиции. как доп. аналитика по  MITRE ATT&CK — это ок.

этим летом мы сконтачимся с ним и другими пацанами и попробуем этот вопрос вместе решить.
MITRE не особо отзывчива в этом плане, ребята отвественные за CAR сейчас какую-то другую фигню пилят, не понятно вообще, все обсуждения остановились. видимо комьюнити само предложит какие-то решения, но лучше бы, конечно, какое-то одно. через пару недель будет EU MITRE ATT&CK Workshop в Брюсселе. Это будет реальный шанс обсудить эти проблемы, предложить решение получить фидбек от ребят из MITRE. Они тоже там будут

9 мая - не, у меня выходной =)

Вообще очень крутая работа!

а где вы трудитесь? в свое время (2017) эти парни мне сказали что россия им не интересна как рынок

логично спрева обозреть локальные фиды, благо их есть до 5

предыдущие парни из темы TI которым не была интересна россия померли (неожиданное банкротство) через год после того как сказали об отстутствии интереса - это были Norse

Кто имел опыт с помощью какого-нибудь nxlog собирать логи из таблицы ms sql?

Тема сложная, почитай, как вариант, про по Apache NiFi.
Может коллеги что другое посоветуют.