Наверно, все SOC-аналитики спят и видят, как их детектирующие правила отлавливают модные техники проправительственных APT -группировок, а расследования приводят к обнаружению эксплойтов для zero-day уязвимостей. К сожалению (или к счастью), большая часть инцидентов, с которыми приходиться сталкиваться среднему специалисту по реагированию, намного менее романтичны: использование непереименованных PsExec’ов для распространения, классических методов обхода UAC для повышения привилегий и огромное количество уязвимостей, для которых давно выпущены заплатки.
Вспоминая прошлые инциденты, невольно приходишь к выводу, что почти каждый из них можно было относительно легко предотвратить, если… Если все делать так как уже много раз описано в разных руководствах и лучших ИБ-практиках. Поэтому сегодня хочется не только рассказать об одном нашем недавним кейсе по реагированию на инцидент, но и напомнить о необходимости ставить патчи даже на «системах, разработанных под ключ».
До сих пор достаточно часто встречается заблуждение о том, что информационная безопасность должна быть функцией, но никак не процессом. Как правило, это выглядит следующим образом: «Сделайте нам безопасно, а мы потом сами будем все поддерживать». Особенности бизнеса в области ИБ таковы, что сервисная компания-интегратор, которая «делает безопасно», не станет спорить с заказчиком. Сделает и пойдет дальше — нести ИБ в массы. А заказчик после подписания актов сдачи работ и выплаты денег по контракту останется в наивной уверенности, что у него все отлично, ИБ построена на века. Сюрприз, как говорится, будет потом. Потому что информационная безопасность — это активный, постоянно меняющийся процесс, который нельзя зафиксировать раз и навсегда. И вот об этой «маленькой особенности» потребители зачастую забывают. ИБ, как и любой бизнес-процесс, состоит из множества элементов, без которых он не работает. Один из них — патч-менеджмент.
Как можно понять из названия, патч-менеджмент представляет собой процесс управления обновлениями программного обеспечения, предназначенного для устранения дыр в безопасности или поддержания адекватного уровня безопасности (характерно для серверного ПО или ОС), а также для решения проблем с прикладным ПО.
Необходимость установки «заплаток», особенно тех из них, которые направлены на обновления безопасности, говорилось много и часто. Если в любом поисковике вбить «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. «Управление технологическими уязвимостями», целью которого является предотвращение использования обнаруженных уязвимостей.
Наиболее известные широким массам вирусные атаки — WannaCry и NotPetya. Оба вируса используют уязвимость протокола SMB в Windows-системах и были опубликованы группировкой ShadowBrokers в апреле 2017 года. При этом месяцем ранее компания Microsoft выпустила патч, закрывающий уязвимость EternalBlue, в своем бюллетене безопасности MS17-010. А «бахнуло» в мае–июне 2017 года. Последствия этих вирусных атак были бы не такими критичными, если б пострадавшие не проигнорировали критичное обновление и вовремя установили «заплатку». К сожалению, известны также случаи, когда критичные патчи вызывали сбои в работе стороннего программного обеспечения, но последствия не были настолько глобальными, как в случаях с массовыми вирусными атаками.
На волне хайпа вокруг майнинга криптовалют уязвимости в сетях компаний становятся по-особенному привлекательными: можно использовать чужие ресурсы для необходимых вычислений, доводя хосты до физического уничтожения.
Практика показывает, что многих проблем можно было избежать, если не стараться доходить до всего своим умом. Не стоит уповать на то, что «у нас свой, особенный, путь». В цифровую эпоху эта парадигма не работает. Сейчас написано огромное количество рекомендаций и мануалов по предотвращению катастроф различного генезиса. Тем более, что при современных технологиях сделать это относительно несложно. Я еще с детства помню отличную фразу Службы 01: «Пожар легче предотвратить, чем потушить», которая как нельзя лучше отражает здравый подход к патч-менеджменту.
В первую очередь необходимо выстроить процесс управления обновлениями в инфраструктуре для оперативного закрытия старых и противодействия новым уязвимостям в ОС, компонентах прикладного и системного ПО, а именно:
• разработать и ввести в действие регламент управления обновлениями ОС, компонентов прикладного и системного ПО;
• провести работы по разворачиванию и настройке в серверном сегменте Windows Server Updates Services (WSUS) — сервиса обновлений операционных систем и продуктов Microsoft;
• осуществлять непрерывный контроль актуальности установленных в инфраструктуре пострадавшей стороны обновлений и оперативно устанавливать новые критические обновления безопасности.
Вспоминая прошлые инциденты, невольно приходишь к выводу, что почти каждый из них можно было относительно легко предотвратить, если… Если все делать так как уже много раз описано в разных руководствах и лучших ИБ-практиках. Поэтому сегодня хочется не только рассказать об одном нашем недавним кейсе по реагированию на инцидент, но и напомнить о необходимости ставить патчи даже на «системах, разработанных под ключ».
До сих пор достаточно часто встречается заблуждение о том, что информационная безопасность должна быть функцией, но никак не процессом. Как правило, это выглядит следующим образом: «Сделайте нам безопасно, а мы потом сами будем все поддерживать». Особенности бизнеса в области ИБ таковы, что сервисная компания-интегратор, которая «делает безопасно», не станет спорить с заказчиком. Сделает и пойдет дальше — нести ИБ в массы. А заказчик после подписания актов сдачи работ и выплаты денег по контракту останется в наивной уверенности, что у него все отлично, ИБ построена на века. Сюрприз, как говорится, будет потом. Потому что информационная безопасность — это активный, постоянно меняющийся процесс, который нельзя зафиксировать раз и навсегда. И вот об этой «маленькой особенности» потребители зачастую забывают. ИБ, как и любой бизнес-процесс, состоит из множества элементов, без которых он не работает. Один из них — патч-менеджмент.
Как можно понять из названия, патч-менеджмент представляет собой процесс управления обновлениями программного обеспечения, предназначенного для устранения дыр в безопасности или поддержания адекватного уровня безопасности (характерно для серверного ПО или ОС), а также для решения проблем с прикладным ПО.
Из кейса
Территориально распределенная закрытая сеть на решениях 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, которое предназначено для майнинга криптовалюты Manero. Одной из особенностей обнаруженного вируса является механизм распространения, аналогичный ранее появившемуся WannaCry. Также в директориях SpeechsTracing обнаружены файлы, полностью идентичные архиву, который был опубликован ShadowBrokers за полтора года до этого.
При проведении работ по нейтрализации вирусной атаки в зараженной инфраструктуре были установлены множественные обновления, выпущенные Microsoft с 2016 года по сегодняшний день.
С момента подключения к работе специалистов JSOC до вывода инфраструктуры в «боевой» режим прошло порядка 50 часов. Причем бОльшая часть времени ушла на согласование действий между пострадавшей стороной, сервисными компаниями и нашей командой.
Практика показывает, что многих проблем можно было избежать, если не стараться доходить до всего своим умом. Не стоит уповать на то, что «у нас свой, особенный, путь». В цифровую эпоху эта парадигма не работает. Сейчас написано огромное количество рекомендаций и мануалов по предотвращению катастроф различного генезиса. Тем более, что при современных технологиях сделать это относительно несложно. Я еще с детства помню отличную фразу Службы 01: «Пожар легче предотвратить, чем потушить», которая как нельзя лучше отражает здравый подход к патч-менеджменту.
Как поставить обновления на поток
В первую очередь необходимо выстроить процесс управления обновлениями в инфраструктуре для оперативного закрытия старых и противодействия новым уязвимостям в ОС, компонентах прикладного и системного ПО, а именно:
• разработать и ввести в действие регламент управления обновлениями ОС, компонентов прикладного и системного ПО;
• провести работы по разворачиванию и настройке в серверном сегменте Windows Server Updates Services (WSUS) — сервиса обновлений операционных систем и продуктов Microsoft;
• осуществлять непрерывный контроль актуальности установленных в инфраструктуре пострадавшей стороны обновлений и оперативно устанавливать новые критические обновления безопасности.
