Многие центры безопасности смыслом своей работы, а то и жизни делают борьбу с хакерами и атаками. Дело действительно важное и интеллектуально очень емкое. Исследуем данные Threat Intelligence, собираем атрибуцию на группировки и её TTP (tactics, techniques and procedures), разрабатываем отдельные сценарии и правила выявления инцидентов, внедряем мощные технологические решения. Это огромный и важный кусок работы любой команды по безопасности, а уж тем более любого зрелого SOC.
Но периодически все классические подходы к безопасности через мониторинг просто умножаются на ноль, когда в жизнь приходит большая и неприятная массовая атака. Та самая, о которой узнаёт даже ваша бабушка. Условно назовем такую атаку медиакиберпандемией, чтобы не путать с регулярными рассылками Cobalt или хитрыми инструментами Silence (для бывалых они уже стали чем-то вроде белого шума). Речь о Heartbleed, Shellshock, WannaСry, уязвимости в оборудовании Cisco и прочих. Что их отличает от прочих кибердиверсий? Как в этом случае стоит (или не стоит) вести себя SOC и просто ИБ-службе компании? Давайте разбираться под катом.
Новая угроза или старая проблема?
Если посмотреть на такие инциденты внимательнее, достаточно быстро становится понятно, что отличает их от всех остальных: за каждым из них стоит некоторая фундаментальная критическая уязвимость. Eternal Blue собрал свой урожай в 2017 году, маскируясь под разными именами (DoublePulsar, WannaCry, NotPetya), апрель 2018 года бушевал уязвимостью CVE-2018-0171, время BlueKeep пока не пришло (но это не точно). В итоге отличие от продвинутых атак — в ключевых составляющих:
- быстрый и удручающе массовый способ доставки вредоноса (вплоть до прямого проникновения через периметр),
- бронебойное орудие (уязвимость широкого охвата, высокой критичности, серьезного «проникающего» эффекта),
- примитивный инструментарий (а зачастую и цели).
Образно говоря, речь идет о молоте, а не о рапире. К сожалению, вендоры могут косячить не дают нам скучать, и злоумышленники получают в свои руки такие молоты достаточно часто. За каждой большой и массовой атакой стояла своя большая и страшная уязвимость от одного из вендоров. В таких условиях отслеживание критических уязвимостей и своевременная работа с ними становятся одними из основных аспектов деятельности ситуационного центра информационной безопасности, который так часто приравнивают к Security Operations Center.
Тут я, наверное, мог бы перейти к рекомендациям и скучно закончить этот пост… если бы по ходу прошедших медиакиберпандемий мы не столкнулись с несколькими возражениями аудитории.
Просто добавь воды поставь патчи
Очень популярное возражение: «Да какой же (тут меня покарала цензура) умник вывесил сервис в интернет без патчей?!», «Уязвимости уже столько времени — неужели не могли вовремя обновиться?» и так далее.
Если у тебя, хаброчитатель, обновление инфраструктуры выполняется одним нажатием кнопки из WSUS или SCCM или пользователей так мало, что можно все поставить руками, то можешь пролистать сразу к концу статьи — быть может, часть советов окажутся полезными. Но в больших корпоративных средах путь джедая безопасника — от поступления информации об уязвимости до ее закрытия — достаточно длинный.
Что стоит на пути офицера ИБ?
- Огромный парк рабочих станций, которые никогда не бывают доступны одновременно, а у части пользователей еще и невозможна их автоматическая перезагрузка.
- Необходимость тестирования патчей ОС и оборудования на совместимость с прикладным ПО, специализированными протоколами и т.д.
- Нагрузочное тестирование по ключевым системам, чтобы патч не прикончил случайно быстродействие системы (кто не помнит историю Spectre/Meltdown, прошу сюда xakep.ru/2018/01/10/meltdown-spectre-slowdown).
- Простой бизнес-процессов и сервисов, который даже в корпоративной среде согласовать непросто, а когда речь касается уязвимостей в оборудовании АСУ ТП… ну это вообще отдельная история.
Вообще надеюсь, что в ближайшее время (это обещание-спойлер) мы напишем отдельную статью или цикл по теме управления уязвимостями в корпоративных средах. Пока же ограничимся статистикой — сколько времени в среднем нужно компании на работу с уязвимостями:
Как видим, меньше чем за 40 дней редкая крупная птица компания закрывает проблемы уязвимостей. Поэтому большим организациям приходится думать о компенсирующих мерах, приоритетах и прочих палках и веревках, требующих проработки для решения проблемы новых критичных уязвимостей.
Волки, волки, или Без сплойта нещитово
Казалось бы, при всех ранее названных проблемах и сложностях обновления имеет смысл патчить только самые критичные бреши. Или, как написано в комментарии одного из экспертов к нашей новости про BlueKeep-1, только те, для которых уже есть готовый эксплойт в паблике. Позиция действительно имеет право на существование: зачем зря гонять айтишников и портить с ними отношения? И басню про мальчика, которую мы обозначили в названии раздела, наверняка все знают, но, как всегда в такой ситуации, есть нюанс.
И заключается он в том, что мы из года в год видим многократное развитие инструментария киберпреступников и темп применения «новинок» в даркнете. Это говорит о том, что только что написанный эксплойт под уязвимость в самое кратчайшее время может уже использоваться в атаке на инфраструктуры компаний. И в этом случае возможности подготовиться, собраться и принять меры противодействия у корпоративного безопасника уже просто не остается. Для иллюстрации небольшая статистика:
Time2Attack
Это выдержка из большой аналитики по тому, какие интервалы времени проходят между фактической публикацией уязвимости с начала и до появления публичного эксплойта, а потом от эксплойта до первой публичной (известной) атаки злоумышленников. Оставим пока за скобками ситуацию с BlueKeep, который действительно пока в свободной природе никак себя не проявил, но по всем остальным ситуация достаточно показательная: речь, как правило, идет не о месяцах, а о неделях до появления эксплойта, и о днях с момента его первого использования. Особенно печально ситуация смотрится для уязвимости Adobe (CVE-2018-15982), которая использовалась в атаке уже через сутки после появления эксплойта. Скроллим пост немного наверх и видим, что в среднем мы просто не успеем поставить патчи на инфраструктуре, если будем ждать эксплойта. Поэтому в реалиях нашей жизни без него вполне «щитово» и лучше проявить заботу о своей инфраструктуре раньше, не опасаясь потенциальных проблем с ИТ-подразделениями.
Несколько полезных/бесполезных (нужное подчеркнуть) советов
К чему приводят нас все эти рассуждения? Что в идеале компании нужно иметь карту или методику реагирования на каждую выявленную критическую уязвимость? В каждом случае она будет индивидуальна до дьявола, но я хочу поделиться несколькими полезными советами от себя.
- Отслеживаем уязвимости на регулярной основе, начинаем «паниковать» до появления эксплойта — процесс организовать не так сложно, как кажется. Собираем информацию с сайтов вендоров (patch Tuesday и т.д.), новостных лент, подписываемся на несколько тематических Хабра-аккаунтов и других блогов, добавляем рассылки от специфических для инфраструктуры вендоров и хотя бы раз в день с утра читаем опубликованную информацию. Как правило, это неплохой первый шаг, чтобы оставаться в курсе.
- Проверяем периметр организации на открытые сервисы — сложность инфраструктур сейчас все выше, да и контроль за работами ИТ-подразделений усложнен (поэтому RDP на периметре даже в крупных компаниях не удивляет). Значит, нужно проверять свои внешние адреса аккуратным сканом хотя бы разово по факту обнаружения критичной уязвимости, а в идеале делать это регулярно (инструментов море — от почти бесплатного shodan до коммерческих сервисов). И да, к этому процессу стоит относиться примерно как к чистке зубов.
NB! Конечно, это будет работать, только если мы на самом деле знаем свой внешний периметр и внешние адреса и занимаемся его инвентаризацией.
- При уязвимостях RCE на операционной системе или офисном ПО в зону патчинга необходимо включать в первую очередь рабочие станции. Конечно все самое критичное хранится в серверном сегменте, но первой точкой поражения при закрытом периметре с высокой вероятностью станут пользователи (посредством фишинговых писем, зараженных флешек и т.д.) и уже от них эпидемия будет расползаться по сети. Плюс установка патчей на АРМ, как правило, проходит менее болезненно с точки зрения согласования и цикла тестирования.
- Если мы используем СОА/IPS между сетями, ждем от вендоров сигнатуры по выявлению признаков эксплуатации уязвимостей или пишем ее сами (если обладаем требуемой экспертизой). Изоляция угрозы в конкретном сегменте существенно сократит область поражения.
- Но тем не менее не успокаиваемся, пока мы не поставили патчи на всей инфраструктуре. Вектора доставки ВПО и атаки злоумышленников крайне разнообразны, а гарантию в нашей жизни уже не дает даже сберегательная книжка.
Надеюсь, что наши рекомендации помогут кому-то быстрее отбиваться от очередных зомби массовых атак.
Автор: SolarSecurity
