Красные флаги: как поймать хакеров и остановить киберинцидент
Прошлый год запомнился крупными инцидентами в области кибербезопасности. Некоторые из них были связаны с вымогательством, компрометацией учетных записей и уязвимостями в конфигурациях облачных платформ. Так, летом 2024 года масштабную утечку данных пережил американский оператор связи AT&T. Хакеры получили доступ к данным о 110 млн пользователей через уязвимость в облачном хостинге Snowflake. Злоумышленники угрожали оператору опубликовать их, что переросло в общенациональную проблему. В России, по данным Infowatch и Positive Technologies, в 2024 году утекло более 1 млрд строк персональных данных. Каждая вторая успешная атака на бизнес приводит к утечке.
Проблема состоит в том, что не все команды понимают, как действовать во время ИБ-инцидентов. По оценке «Лаборатории Касперского», в 42% организаций, подвергшихся компрометации данных в 2022 году, не было контактного лица, ответственного за обработку инцидентов. В зависимости от того, как у компании организована инфраструктура — в облаке или на собственных серверах, используются разные подходы к управлению инцидентами. Разберемся в этих отличиях.
Облако VS собственная инфраструктура
Собственная инфраструктура компании включает в себя серверы и рабочие станции, сетевое оборудование, сетевые службы и сервисы, программное обеспечение. Все это специалисты по безопасности окружают средствами защиты, например межсетевыми экранами для фильтрации трафика. Компания защищает корпоративный периметр самостоятельно: управляет доступом к данным, отвечает за безопасность приложений, сетевую и физическую безопасность.
В облачной инфраструктуре у компании нет доступа к управлению оборудованием и базовой сетью. Все ресурсы виртуализированы и описаны программно, то есть представляют собой записи в базе данных облачного провайдера. Жизненный цикл и правила взаимодействия виртуальных ресурсов описаны в приложениях. Управляют ими через программный слой, который называется control plane.
Такая организация процесса повышает наблюдаемость инфраструктуры. ИБ-специалист видит, какие ресурсы подключены, кто их потребляет, какие доступы выданы сотрудникам. Уменьшаются риски явления Shadow IT, когда сотрудники устанавливают ПО в обход IT-службы и создают уязвимости, или в компании появляются серверы без владельцев. На облачной платформе по умолчанию активированы механизмы безопасности — например, сервисы для сбора и выгрузки аудитных логов, которые используются при расследовании инцидентов.
В то же время, несмотря на то что потребление облачных ресурсов растет, не все IT-специалисты обладают опытом работы с ИБ в облаке. Это приводит к ошибкам и угрозам безопасности. По оценке аналитиков Cloud Security Alliance (специализируются на ИБ облачных платформ), самые распространенные — ошибки конфигурации и недостаточный контроль изменений, управление идентификацией и доступом, небезопасные интерфейсы и API, небезопасные ресурсы сторонних поставщиков, несанкционированный общий доступ к ресурсам.
Как определить, что вас пытаются взломать
Даже когда происходит крупная атака, компания часто не сразу ее замечает или списывает проблемы на технические сложности. Вот типичные сигналы, которые позволяют обнаружить злоумышленника в облачной инфраструктуре компании.
- Появление нового приглашения в организацию. Доступ в облако невозможно получить просто так: нужно, чтобы его предоставил участник организации, у которого есть такие права. Полезно отслеживать сам факт появления новых пользователей.
- Отключение защитных механизмов. Например, это может быть группа безопасности сетевых взаимодействий. Так злоумышленник может сделать ресурс доступным из интернета напрямую. Ему становятся видны другие части облака, или он может создать уязвимость, о которой будет знать только он.
- Создание сервисных аккаунтов с неограниченными правами. Хакер получает права администратора и доступ ко всем ресурсам, включая данные, которые можно зашифровать, продать или использовать, чтобы остановить работу всего бизнеса.
- Появление связности между тестингом и продом. Ресурсы, которые используются для бизнес-задач, и ресурсы для разработки в облаке «живут» отдельно. Разработчики не должны иметь доступа к реальным бизнес-данным, но до них очень хотят добраться злоумышленники.
Что делать, если все-таки взломали
Первое — сообщить о подозрительной активности команде Security Operation Center облачного провайдера. Провайдер может на основании внутренней информации и механизмов сделать выводы о вредоносных действиях или неавторизованной активности. Например, определить, какие сервисные аккаунты выглядят подозрительно, подсказать, какие ошибки и уязвимости использовали для доступа в облако, а в случае заражения вредоносным кодом — помочь снять образ памяти. У крупных облачных провайдеров есть пошаговые инструкции и описания работы скриптов для устранения уязвимостей.
Второе — определить критичность инцидента. Уровни критичности оцениваются исходя из потенциального урона и финансовых потерь компании. Выделяют четыре уровня: низкий, средний, высокий и критичный. Подключение злоумышленника к офисному принтеру — это низкий уровень инцидента. В 2021 году хакеры атаковали промышленное предприятие Colonial Pipeline. Это крупнейший в США трубопровод, который обеспечивает 45% топливных потребностей Техаса. Трубопровод был полностью остановлен на несколько дней, что привело к дефициту бензина, резкому росту цен и панике на заправках. Инцидент такого уровня можно отнести к критичному. Если уровень критичный, то начать работать по плану реагирования нужно сразу после обнаружения инцидента.
Третье — установить облачные ресурсы, которые были скомпрометированы или атакованы. На этом этапе используются облачные логи, системы анализа данных, такие как, например, сервисы по сбору событий безопасности в облаке. К примеру, мы используем для этой задачи сервис Audit Trails. Такие сервисы помогают собрать события и отправить их в систему класса «управление информацией и событиями по безопасности» (Security Information and Event Management) для анализа. Они помогут выявить потенциальные инциденты, понять логику действий и цели злоумышленника: деградация сервиса, кража данных или использование сервисов для дальнейших атак.
Четвертое — устранить первичные последствия атаки. Определив, с каким именно сервисным аккаунтом происходит инцидент, можно изолировать этот сегмент облака и ограничить его доступ к другим ресурсам. Цель активности — «запереть» хакера и не дать атаке распространиться. Для этого можно использовать сетевые группы безопасности и добавить возможность назначать разные сегменты VPN для различных ресурсов.
В облаке остановить действия злоумышленников можно автоматически, заранее продумав плейбуки. Плейбук — это набор инструкций, выполнение которых запускается на сервере при наступлении определенных условий. Например, если произошло событие, которое относится к «красным флагам», то с помощью триггеров можно настроить вызов облачной функции, которая обновит правила сетевого доступа или отберет права у сервисного аккаунта.
После того, как вы определили, каким образом злоумышленник получил доступ к облаку и остановили его продвижение, вы проверяете, где он мог оставить возможности вернуться: поменять настройки, получить доступ администратора, мог ли он повлиять на логи, чтобы вы не увидели, что он делал на виртуальной машине.
Пятое — организовать расследование инцидента, собрать фактуру и доказательства. Если у компании сильная экспертиза по ИБ, то она может провести расследование своими силами. В других случаях бизнес обращается к облачному провайдеру или к компании, которая специализируется на расследованиях киберинцидентов.
В расследовании применяют два вида доказательств: снапшоты дисков и снапшоты памяти. Снапшот — мгновенный снимок состояния сетевого диска, копия его файловой системы. Такие снимки помогают зафиксировать состояние диска или памяти, не нарушая их работу. Снапшоты можно использовать в том числе в суде.
Расследование может занять длительное время, так как для этого может потребоваться проанализировать память, диски и множество логов, чтобы восстановить всю картину. Из облачных инструментов можно применить решения Cloud Security Posture Management. С их помощью можно выявить базовые ошибки конфигурации системы. Например, это может быть включение серийной консоли для виртуальной машины, выдача публичного адреса внутреннему ресурсу или избыточных прав пользователю. Ошибки фиксируют для того, чтобы было невозможно использовать тот же вектор атаки в будущем.
Иногда расследование инцидента может конфликтовать с задачей по скорейшему устранению последствий атаки. Компании важно решить, будет ли она в дальнейшем обращаться в правоохранительные органы или важнее как можно быстрее восстановить работу бизнеса. При зачистке системы в том числе устраняются и следы, по которым можно найти IP-адрес злоумышленника.
Шестое — восстановление после атаки. На этом этапе помогают такие сервисы, как Cloud Backup и инфраструктура в облаке, описанная в парадигме Infrastructure as a Code, что позволяет пересоздать ресурсы максимально быстро с нужными настройками. Специалисты создают машиночитаемые описания для развертывания этих ресурсов. Все необходимые действия прописываются в файле и запускаются в специальной программе. Это избавляет от ручной работы и ошибок.
Что сделать, чтобы ИБ-инцидентов было меньше
После расследования важно обновить процедуры стандартов безопасности. Иногда устраняются шероховатости в процессах и лишние шаги, иногда пересматривается модель нарушителя и планы меняются существенно. Если процессы не регламентированы, это приводит к повторению инцидентов.
Информация об инциденте полезна не только CISO (chief information security officer, директор по информбезопасности), но и DevOps (многопрофильные специалисты, которые умеют программировать, автоматизировать процессы и знают, как работают разработчики и менеджеры) и разработчикам. Работая в команде, вы соберете полные данные: восстановите хронологию инцидента, определите его причины, проанализируете процесс реагирования и поймете, как улучшить его в будущем.
Мнение редакции может не совпадать с точкой зрения автора