Наверно, все SOC-аналитики спят и видят, как их детектирующие правила отлавливают модные техники проправительственных APT-группировок, а расследования приводят к обнаружению эксплойтов для zero-day уязвимостей. К сожалению (или к счастью), большая часть инцидентов, с которыми приходиться сталкиваться среднему специалисту по реагированию, намного менее романтичны: использование непереименованных PsExec’ов для распространения, классических методов обхода UAC для повышения привилегий и огромное количество уязвимостей, для которых давно выпущены заплатки.



Вспоминая прошлые инциденты, невольно приходишь к выводу, что почти каждый из них можно было относительно легко предотвратить, если… Если все делать так как уже много раз описано в разных руководствах и лучших ИБ-практиках. Поэтому сегодня хочется не только рассказать об одном нашем недавним кейсе по реагированию на инцидент, но и напомнить о необходимости ставить патчи даже на «системах, разработанных под ключ».

До сих пор достаточно часто встречается заблуждение о том, что информационная безопасность должна быть функцией, но никак не процессом. Как правило, это выглядит следующим образом: «Сделайте нам безопасно, а мы потом сами будем все поддерживать». Особенности бизнеса в области ИБ таковы, что сервисная компания-интегратор, которая «делает безопасно», не станет спорить с заказчиком. Сделает и пойдет дальше — нести ИБ в массы. А заказчик после подписания актов сдачи работ и выплаты денег по контракту останется в наивной уверенности, что у него все отлично, ИБ построена на века. Сюрприз, как говорится, будет потом. Потому что информационная безопасность — это активный, постоянно меняющийся процесс, который нельзя зафиксировать раз и навсегда. И вот об этой «маленькой особенности» потребители зачастую забывают. ИБ, как и любой бизнес-процесс, состоит из множества элементов, без которых он не работает. Один из них — патч-менеджмент.

Как можно понять из названия, патч-менеджмент представляет собой процесс управления обновлениями программного обеспечения, предназначенного для устранения дыр в безопасности или поддержания адекватного уровня безопасности (характерно для серверного ПО или ОС), а также для решения проблем с прикладным ПО.

Из кейса

Территориально распределенная закрытая сеть на решениях Microsoft, состоящая из примерно 200 хостов. Два из них несут на борту по второй сетевой карте и имеют выход в Интернет. По всем параметрам инфраструктура должна попадать под требования №187-ФЗ «О безопасности критической информационной инфраструктуры». В силу специфики основного ПО обслуживанием инфраструктуры занимаются две сервисные компании. На момент подключения «пожарной команды» Solar JSOC инфраструктура не функционировала уже более 2 суток.

Необходимость установки «заплаток», особенно тех из них, которые направлены на обновления безопасности, говорилось много и часто. Если в любом поисковике вбить «Patch Management Policy», выдача составит порядка 100 миллионов результатов, по которым можно отследить первые активные обсуждения, начатые аж в далеком 2006 году. В начале 2007 года SANS опубликовал документ с названием «Patch Management. Part of standard operations…», в самом начале которого вполне доходчиво объясняется, что такое патч-менеджмент и зачем он нужен. Причем поясняется языком, доступным не только техническому специалисту, но и менеджеру, далекому от ИТ. Более современный документ «NIST Special Publication 800-40 Revision 3. Guide to Enterprise Patch Management Technologies» датируется 2013 годом и там по-прежнему подчеркивается необходимость применения критичных обновлений. Даже так любимый в России стандарт ISO/IEC 27001:2015 содержит подраздел 12.6. «Управление технологическими уязвимостями», целью которого является предотвращение использования обнаруженных уязвимостей.

Из кейса
По информации, предоставленной сервисными компаниями: на протяжении последних 48 часов почти все хосты сети испытывают нагрузки CPU в районе 100% и вызывают BSOD. Многочисленные попытки использования сертифицированного антивирусного ПО результатов не принесли: фиксируются множественные повторные заражения ВПО Trojan.Equation. Более того, обнаружен откат антивирусных баз на декабрь 2017 года. Отсутствует доступ по RDP. И в качестве вишенки на торте: данные по количеству АРМ, полученные как от интеграторов, так и от пострадавшей стороны, расходятся. Последняя инвентаризация проводилась за несколько лет до инцидента уже уволившимся сисадмином. Какое-либо подобие планов обеспечения непрерывности отсутствует.



Однако добытая разрозненная информация позволяет сделать предварительные выводы о способе распространения вируса по сети и дать первые рекомендации по противодействию.

Одна из основных — отключить протоколы SMBv.1 и SMBv.2, чтобы остановить распространение ВПО по сети.

С момента поступления запроса о помощи до выдачи рекомендаций прошло около 3 часов.

Наиболее известные широким массам вирусные атаки — WannaCry и NotPetya. Оба вируса используют уязвимость протокола SMB в Windows-системах и были опубликованы группировкой ShadowBrokers в апреле 2017 года. При этом месяцем ранее компания Microsoft выпустила патч, закрывающий уязвимость EternalBlue, в своем бюллетене безопасности MS17-010. А «бахнуло» в мае–июне 2017 года. Последствия этих вирусных атак были бы не такими критичными, если б пострадавшие не проигнорировали критичное обновление и вовремя установили «заплатку». К сожалению, известны также случаи, когда критичные патчи вызывали сбои в работе стороннего программного обеспечения, но последствия не были настолько глобальными, как в случаях с массовыми вирусными атаками.

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

Из кейса

«Пожарная команда» Solar JSOC выявила множественные попытки заражения обследуемой инфраструктуры вирусами-криптомайнерами, один из которых использовал для своего распространения уязвимость EternalBlue.

Анализ логов и сэмплов из карантина антивирусной защиты также показал наличие в пострадавшей инфраструктуре ВПО WannaMine, которое предназначено для майнинга криптовалюты Monero. Одной из особенностей обнаруженного вируса является механизм распространения, аналогичный ранее появившемуся WannaCry. Также в директориях SpeechsTracing обнаружены файлы, полностью идентичные архиву, который был опубликован ShadowBrokers за полтора года до этого.

При проведении работ по нейтрализации вирусной атаки в зараженной инфраструктуре были установлены множественные обновления, выпущенные Microsoft с 2016 года по сегодняшний день.

С момента подключения к работе специалистов JSOC до вывода инфраструктуры в «боевой» режим прошло порядка 50 часов. Причем бОльшая часть времени ушла на согласование действий между пострадавшей стороной, сервисными компаниями и нашей командой.

Практика показывает, что многих проблем можно было избежать, если не стараться доходить до всего своим умом. Не стоит уповать на то, что «у нас свой, особенный, путь». В цифровую эпоху эта парадигма не работает. Сейчас написано огромное количество рекомендаций и мануалов по предотвращению катастроф различного генезиса. Тем более, что при современных технологиях сделать это относительно несложно. Я еще с детства помню отличную фразу Службы 01: «Пожар легче предотвратить, чем потушить», которая как нельзя лучше отражает здравый подход к патч-менеджменту.

Как поставить обновления на поток

В первую очередь необходимо выстроить процесс управления обновлениями в инфраструктуре для оперативного закрытия старых и противодействия новым уязвимостям в ОС, компонентах прикладного и системного ПО, а именно:

• разработать и ввести в действие регламент управления обновлениями ОС, компонентов прикладного и системного ПО;
• провести работы по разворачиванию и настройке в серверном сегменте Windows Server Updates Services (WSUS) — сервиса обновлений операционных систем и продуктов Microsoft;
• осуществлять непрерывный контроль актуальности установленных в инфраструктуре пострадавшей стороны обновлений и оперативно устанавливать новые критические обновления безопасности.