Автор
KL FC Bot
Есть такое когнитивное искажение «отклонение в сторону статус-кво». Оно про то, что нам всем не нравятся перемены, поскольку «ущерб от потери статус-кво воспринимается как больший, чем потенциальная выгода». А еще есть эффект владения, когда человек больше ценит вещи, которыми уже владеет, а не те, которыми может овладеть. И еще 13 разных искажений, которые заставляют нас предпочитать то, во что уже вложены время и усилия.
К чему это я и при чем тут XDR? А я это к тому, что мы не особо любим новое. И хотя вроде бы при принятии решений об использовании того или иного нового ИБ-продукта мы хорошенько все обдумываем и взвешиваем, причем не в одиночку, в конечном итоге все равно решение принимают люди.
Как правило, если рынок начинает активно обсуждать какую-то новую систему, то реальную ее полезность пользователи признают только через пару-тройку лет. И это в лучшем случае. Есть еще вариант, когда система вообще не проходит это испытание и либо плавно сливается с существующим классом решений, либо вовсе исчезает.
Сейчас новым кандидатом, проходящим тест на полезность, стал XDR. И в данном случае под XDR я буду подразумевать платформу, в состав которой входит как минимум EDR, NTA, TI, SIEM и SOAR/IRP. То есть защита сети и конечных точек, система мониторинга и автоматизации реагирования (плейбуки разной степени вложенности и вот это все).
И, возможно, наша нелюбовь к изменениям — это очень даже неплохо. Как будто бы это поможет нам подготовиться и выжать из XDR максимум пользы. Мы же помним, что в стратегиях MITRE есть одна из заповедей, которая говорит, что надо обязательно «максимизировать пользу от закупленных технологий». Да и вообще, вдруг нам не нужен XDR? Как понять, стоит ли отдать много денег вендору?
Как понять, не пора ли купить XDR?
На мой взгляд, существует достаточно четкий критерий: XDR должен автоматизировать уже существующие процессы и механизмы, а не становиться новым продуктом в SOC. Ну в крайнем случае — автоматизировать процессы и механизмы, о которых сотрудники SOC уже задумались и реализацию которых запланировали. Потому что если автоматизировать бардак — получится просто автоматизированный бардак. А хотелось бы получить процесс управления информационной безопасностью.
Получается, если мы хотим использовать XDR — нам надо сначала выстроить все процессы. От выявления до реагирования. Давайте посмотрим, что тут можно сделать своими руками, без волшебной «XDR-коробки» от вендора. А потом подумаем, в каком случае она все-таки может нам пригодиться.
Если посмотреть на классические определения SOC, то вы увидите, что это либо исключительно команда аналитиков, либо совокупность людей, процессов и только в последнюю очередь — технологий.
Поэтому первым делом нужно выстраивать процессы в общечеловеческом понимании: определить, что в целом происходит в инфраструктуре, кто за что отвечает и кто поможет решить какие проблемы в случае чего. И тут особо не помогут никакая автоматизация и никакие инструменты: придется что-то придумывать самостоятельно. Ну или списать готовое, это тоже хороший вариант — не зря же методологи пишут тонны всевозможных документов про лучшие практики.
Посмотреть статью полностью
Автор Erhogg
Автор KL FC Bot
Рекомендуемые сообщения
Пожалуйста, войдите, чтобы комментировать
Вы сможете оставить комментарий после входа в
Войти