Почти двадцать лет спустя я написал свою первую книжку по обнаружению атак, которая, до сих пор используется в учебном процессе ряда ВУЗов. При этом ее часто даже сейчас воспринимают как догму, забывая, что за двадцать лет технологии обнаружения атак сильно поменялись, а возможности решений по обнаружению атак не ограничены только классическими IDSами (хотя регуляторы, присвоив аббревиатуры СОВ и СОА вполне конкретным типам решений, сильно подпортили картину).
В одном из недавних проектов по аудиту SOC я столкнулся с этой проблемой. Заказчик в ТЗ на построение системы защиты указал, что необходимо, среди прочего, построить систему обнаружения атак, а проектировщик не долго думая, просто прописал в проекте кучу сенсоров сетевой системы обнаружения атак и все. В рамках аудита, мы выясняли, причину такого решения, и почему проектант даже имеющийся у заказчика Stealthwatch (решение класса Network Traffic Analytics, NTA) не включил в список технологий обнаружения. Разумеется, все остальные варианты обнаружения вредоносной активности также не были рассмотрены проектироващиком, который почему-то посчитал, что обнаружение атак - это только классические сетевые СОВы (СОА), которые появились в то время, когда основным источником при обнаружении атак был сетевой трафик и, иногда, системные логи.
С тех пор ситуация сильно поменялась и к источникам, по которым можно обнаруживать проявления вредоносной активности, добавилось куча всего другого - файлы, Web-трафик, Netflow (и вообще flow-протоколы), URL, домены, активность пользователя и активность приложений. И это еще не полный перечень.
Другая проблема в обнаружении атак в том, что эти решения обычно ставят на периметра корпоративной или ведомственной сети, в то время как они сегодня давно не ограничены одной площадкой или одним выходом в Интернет. У вас есть внутренняя сеть и куча способов проникновения в нее, минуя периметр. У вас есть Wi-Fi, у вас есть АСУ ТП, у вас есть облака, у вас есть 4G и еще куча точек и отрезков контроля. Обратите внимание, что я специально упомянул не только точки, которые можно контролировать на предмет вредоносной активности, но и отрезки, на которых это можно сделать.
В итоге, если попробовать уйти от устаревшего толкования термина "обнаружение атак" и наполнить его новым смыслом, лучше отражающем реалии современной ИБ, чем далекие от идеала и почти всегда запаздывающие нормативные документы, то у нас получается вот такая матрица, где крестик означает возможность мониторинга чего-то плохого и скрытого в файлах, DNS-запросах, URL, мета-данных Web-трафика, почтовых сообщениях и т.п.
И чтобы бороться с современными угрозами необходимо на место каждого крестика поставить соответствующее решение или технологию, коммерческое или бесплатное, сертифицированное или нет. Вот тогда можно говорить о том, что организация приблизилась к тому, чтобы действительно выстроить систему обнаружения атак.
Да ну, фигня это все, можете сказать вы. У меня есть МСЭ, СОВ и антивирус, да еще и сертифицированный VPN; зачем мне еще что-то? Они прекрасно справляются со своими задачами. Ну еще WAF куплю в 2020-м. Как вообще вышеприведенную матрицу транслировать в приоритезированный список технологий обнаружения атак, которые надо внедрять в организации? Я бы начал с матрицы MITRE ATT@CK, которая описывает самые распространенные тактики, техники и процедуры киберпреступников. Существует маппинг TTP из нее с источниками данных, позволяющих выявлять плохих парней. Обратите внимание, что на первом месте у нас мониторинг процессов, файлов, параметров командной строки, API, реестра и сетевого трафика. Сетевой трафик вообще на последнем месте в Топ7 источников.
Для упрощения можно посмотреть Топ10 источников данных для мониторинга от Red Canary и посмотреть, что из этого вы мониторите, после чего уже принимать взвешенное решение о том, какие источники данных у вас не охвачены и какие технологии нужны для их охвата.
В одном из недавних проектов по аудиту SOC я столкнулся с этой проблемой. Заказчик в ТЗ на построение системы защиты указал, что необходимо, среди прочего, построить систему обнаружения атак, а проектировщик не долго думая, просто прописал в проекте кучу сенсоров сетевой системы обнаружения атак и все. В рамках аудита, мы выясняли, причину такого решения, и почему проектант даже имеющийся у заказчика Stealthwatch (решение класса Network Traffic Analytics, NTA) не включил в список технологий обнаружения. Разумеется, все остальные варианты обнаружения вредоносной активности также не были рассмотрены проектироващиком, который почему-то посчитал, что обнаружение атак - это только классические сетевые СОВы (СОА), которые появились в то время, когда основным источником при обнаружении атак был сетевой трафик и, иногда, системные логи.
С тех пор ситуация сильно поменялась и к источникам, по которым можно обнаруживать проявления вредоносной активности, добавилось куча всего другого - файлы, Web-трафик, Netflow (и вообще flow-протоколы), URL, домены, активность пользователя и активность приложений. И это еще не полный перечень.
Другая проблема в обнаружении атак в том, что эти решения обычно ставят на периметра корпоративной или ведомственной сети, в то время как они сегодня давно не ограничены одной площадкой или одним выходом в Интернет. У вас есть внутренняя сеть и куча способов проникновения в нее, минуя периметр. У вас есть Wi-Fi, у вас есть АСУ ТП, у вас есть облака, у вас есть 4G и еще куча точек и отрезков контроля. Обратите внимание, что я специально упомянул не только точки, которые можно контролировать на предмет вредоносной активности, но и отрезки, на которых это можно сделать.
В итоге, если попробовать уйти от устаревшего толкования термина "обнаружение атак" и наполнить его новым смыслом, лучше отражающем реалии современной ИБ, чем далекие от идеала и почти всегда запаздывающие нормативные документы, то у нас получается вот такая матрица, где крестик означает возможность мониторинга чего-то плохого и скрытого в файлах, DNS-запросах, URL, мета-данных Web-трафика, почтовых сообщениях и т.п.
Да ну, фигня это все, можете сказать вы. У меня есть МСЭ, СОВ и антивирус, да еще и сертифицированный VPN; зачем мне еще что-то? Они прекрасно справляются со своими задачами. Ну еще WAF куплю в 2020-м. Как вообще вышеприведенную матрицу транслировать в приоритезированный список технологий обнаружения атак, которые надо внедрять в организации? Я бы начал с матрицы MITRE ATT@CK, которая описывает самые распространенные тактики, техники и процедуры киберпреступников. Существует маппинг TTP из нее с источниками данных, позволяющих выявлять плохих парней. Обратите внимание, что на первом месте у нас мониторинг процессов, файлов, параметров командной строки, API, реестра и сетевого трафика. Сетевой трафик вообще на последнем месте в Топ7 источников.
Для упрощения можно посмотреть Топ10 источников данных для мониторинга от Red Canary и посмотреть, что из этого вы мониторите, после чего уже принимать взвешенное решение о том, какие источники данных у вас не охвачены и какие технологии нужны для их охвата.
Комментариев нет:
Отправить комментарий
Примечание. Отправлять комментарии могут только участники этого блога.