В заметке мы затронули тему открытого тестирования решений по ИБ, наподобие ATT&CK Evaluations, попробуем ее раскрыть чуть более подробно
Если коротко, то не надо здесь изобретать велосипеды, за основу разумно просто брать ATT&CK Evaluations. Их подход уже прошел несколько итераций и вполне достиг зрелости.
Важно не проводить сравнение предложений друг с другом, а каждое решение оценивать независимо по заранее утвержденной методике. Кому надо, тот, впоследствии, может сам оцифровать результаты, учитывая что для него важно, и сравнить решения между собой. Но в рамках тестирования нужно просто подтверждать соответствие функционала предопределенным критериям!
Далее по разделам коснемся обязательных составляющих, которые следует детально проработать и утвердить перед началом тестирования.
Методика оценки
Это - самый первый и, наверно, самый важный пункт. Это как раз те критерии, на соответствие которым будет проверяться та или иная фича тестируемого решения, например, полнота детекта. Методика оценки должна быть публично доступна заблаговременно. Ее можно и нужно выработать коллегиально, а начать следует все с той же MITRE.
Формат отчетности
Выше мы писали, что в рамках тестирования решения не должны сравниваться между собой. Однако, это не означает, что результаты должны быть несравнимы. Более того, мы все понимаем, что такое сравнение будет выполняться в частном порядке конечными потребителями, и в этом мы должны помочь.
Чтобы результаты были сравнимыми, необходимо зафиксировать формат отчетности, как по карточкам алертов и инцидентов, так и по общему финальному представлению результатов участника тестирования. Здесь речь, конечно же, не идет о внешнем виде, а о некотором чек-листе. Например, карточка алерта должна содержать: название алерта, источник атаки, жертва, тактика, техника, описание, рекомендации по реагированию, возможные ложные срабатывания и т.п. Возможность ответить на все вопросы чек-листа тесно связана с методикой оценки, и, упомянутой ранее, "полнотой детекта". По факту, требования к отчетности - это раздел, типа "Формат предоставления данных на валидацию" в рамках общей Методики оценки.
План тестирования
Подробный план тестирования, включая инструменты и командные строки Красных, должен быть известен заранее. Это может показаться, на первый взгляд, плохим условием, типа, участники смогут создать кастомные конфигурации, непосредственно для теста, а тестировать надо в конфигурации по умолчанию. Однако "заточку под тест" можно немного нивелировать требованием и подтверждением использования конфигурации по умолчанию, а, если немного поразмыслить, может, подобная подстройка под условия тестирования и не такая уж большая проблема. Любая система и детектирующая логика должны адаптироваться, - стоит ли это блокировать? Если практические результаты первых тестов покажут что "заточка под тест" имеет значимое влияние, то в последующие тесты можно включать и сценарии на проверку отсутствия ложных срабатываний (False positives), - но пусть это будет следующим этапом, а пока будем проверять только True positives и отсутствие False negatives (пропусков).
Публичность и прозрачность сценариев тестирования снимет возможные кривотолки о "доступности подробного плана для избранных друзей друзей" и т.д. и т.п. Поэтому лучше все сразу опубликовать для всех участников, чтобы не было возможности получить преимущество из секретности подробного плана тестирования.
План тестирования нужно создавать коллегиально. В качестве идеи можно взять все тот же тест MITRE - например, мы будем тестировать на базе техник и процедур APTXXX, - все участники могут присылать свои отчеты о деятельности АРТХХХ, а финальный тест-план будет компиляцией полученных данных.
Контроль результата
Чтобы поставщики решений охотнее шли в тестирование, нужно дать им возможность полного контроля результата тестирования. Т.е. если результат не устраивает - его не публикуют.
Мы ранее писали, что участие вендора в тестировании должно быть платным - это и будет мотивацией идти до конца, т.е. до публикации результатов. Однако, все равно надо оставить за вендором право отказа от публикации, если его что-то не устраивает. Оплата участия в тестировании при этом, конечно же, не возвращается, так как фактически тестирование проведено и результаты получены, это должно быть учтено в шаблонах юридических документов (как и все остальные возможные конфликтные ситуации).
Продумать юридически
Ни одна нормальная компания не сможет просто так заплатить денег другой нормальной компании. Для решения этой, очевидной, проблемы необходимо продумать юридический порядок участия в тестировании. Все необходимые шаблоны договоров должны быть заранее публично доступны, порядок юридического оформления участия в тестировании должен быть полностью прозрачен для всех участников сего мероприятия.
С чего начать
Чтобы не получить сразу много проблем, способных полностью загубить все начинание, начинать надо медленно, потихоньку. Поэтому, предлагаем начать с тестирования только EPP-EDR, только продуктов. Тестирование связки с сервисом, EPP-EDR-MDR, а может и EPP-XDR-MXDR, ... - это следующие этапы.
