Что делать, если взломали вашего антивирусного вендора?

Представьте, что взломали антивирусного вендора, чьи решения вы используете в своей организации, о чем хакеры написали у себя в Telegram-канале. Ну или не антивирусного вендора, а производителя средств управления идентификацией и аутентификацией. Или производителя СКЗИ, не суть важно. Какие ваши действия, как специалиста по ИБ, должны быть? Понятно, что быстрыми, скоординированными и основанными на минимизации возможных последствий для компании и ее клиентов. Но что конкретно надо сделать? В качестве базового плана действий можно рассмотреть следующий набор действий:

Содержание

Сбор данных и оценка ситуации

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

  Иногда хакеры либо откровенно лгут, либо преувеличивают свои успехи. Хотя исходить, конечно, надо их худшего. Возможно, что хакеры что-то и скроют, оставляя себе задел на будущее. Это тоже нельзя сбрасывать со счетов! Как и то, что вендор будет говорить «Ничего страшного не произошло — все под контролем».

• Анализ влияния на инфраструктуру. Проверить, каким образом взлом может повлиять на безопасность вашей компании. Если использовались уязвимые компоненты антивируса, например, в песочнице, или он имел был установлен на целевых и ключевых системах, это увеличивает риск реализации недопустимых или нежелательных событий.
• Оценка воздействия на клиентов. Оцените, могли ли зараженные обновления повлиять на безопасность данных ваших клиентов или пользователей.

Ограничение распространения проблемы

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

  Вендор предоставляет такую информацию на странице для скачивания обновлений?

• Сравнение баз данных. Используйте независимые источники для получения и проверки антивирусных баз данных. Если возможно, свяжитесь с надежными партнерами или используйте архивные «чистые» базы данных для сравнения.
  

  У многих антивирусных вендоров это не предусмотрено архитектурой!

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

  Скорее всего вы не сможете этого сделать, но не упомянуть о такой возможности я все равно должен был.

• Аудит безопасности. Проведите детальный аудит всех систем, на которых был установлен антивирус или к которым у него был доступ, для выявления возможных признаков компрометации. Если вы не можете этого сделать сами, то стоит пригласить фирму, оказывающую услуги по ретроспективному анализу (compromise assessment).
• Проверка контроля доступов. Убедитесь, что антивирус или связанные с ним системы не имеют доступа к ключевым и целевым системам. При необходимости — отключите/пересмотрите доступы. Если обновления антивируса были установлены уже после того, как произошел инцидент, необходимо изолировать обновленные системы для предотвращения возможной активации вредоносного кода или дальнейшего заражения инфраструктуры.
• Проверка управляемого доступа. Особенно внимательно отнеситесь к ситуации, если антивирусный вендор имел функционал удаленного доступа к вашей инфраструктуре для управления, обновления, внедрения и т.п. Аналогично, внимание стоит уделить ситуациям, когда пострадавший антивирус входит в состав получаемой вами MDR-услуги.
• Анализ безопасности каналов передачи данных. Проверьте, как антивирусные обновления распространяются внутри инфраструктуры компании, и убедиться в том, что каналы передачи данных (HTTP/HTTPS, FTP и т.д.) защищены и не были скомпрометированы.
• Обновление серверов дистрибуции. Если компания-производитель антивируса использует зеркальные сервера или CDN для доставки обновлений, проверьте их также на предмет возможной компрометации.

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

Оперативные действия

• Команда реагирования на инциденты. Настройте внутреннюю команду реагирования на инциденты для быстрого анализа ситуации и проведения расследования возможных последствий. Поднять имеющийся на такой случай playbook или близкий к нему (например, playbook по угрозе вредоносного кода или по вторжению в инфраструктуру).
• Обновление сигнатур и правил в системах обнаружения атак (IDS/IPS, EDR, SOC). Обновите все сигнатуры на системах обнаружения угроз, включая создание специальных правил для мониторинга активности, связанной с уязвимыми компонентами антивируса и его эксплуатации хакерами, а также усильте мониторинг коммуникаций с ресурсами пострадавшего вендора (на уровне сети, а также на уровне email). Убедитесь, что мониторинг охватывает сетевые активности и системные вызовы, которые могут свидетельствовать о выполнении вредоносного кода, загруженного через обновления антивируса.
  

  Тут без решений класса NTA/NDR/EDR не обойтись!

• Разработка плана действий: Разработайте краткосрочные меры для обеспечения защиты, включая сценарии реагирования на возможные дальнейшие атаки, если злоумышленники попробуют использовать другие точки входа.

Планирование восстановления

• Откат обновлений. Если будет подтверждена компрометация обновлений, необходимо оперативно откатить их до последней проверенной «чистой» версии.
• Переход на резервные системы. Рассмотрите временное использование резервных систем защиты (например, другого антивирусного решения, встроенных механизмов ОС или более строгих правил МСЭ и EDR) на период, пока проблема с основным антивирусом не будет решена.
  

  Выбор в качестве альтернативы бесплатного антивируса может быть плохой идеей.

Коммуникации

• Коммуникация с руководством. Инициируйте план уведомления руководителей компании о происшествии, включая потенциальные риски и план действий для минимизации последствий. Дайте рекомендации по действиям в случае, если информация станет публичной.
• Оповещение сотрудников. Информируйте смежные команды (ИТ, сетевиков, DevOps и т.п.) о мерах безопасности, которые следует соблюдать в связи с инцидентом. Возможно, потребуется временная приостановка работы определенных систем до окончания разбирательства.
• Подготовка к публичным заявлениям. Если есть угроза, что данные компании или клиентов могли быть скомпрометированы в результате компрометации антивируса, подготовьте заявления для клиентов и партнеров с разъяснением ситуации и предпринимаемых мер. Это поможет минимизировать репутационные потери.

Обновление и патчинг систем

• Мониторинг уязвимостей. Следите за обновлениями и патчами от производителя антивируса. Как только они станут доступны — немедленно примените их, предварительно проверив на наличие вредоносной функциональности.
  

  Можно воспользоваться советами из методики ФСТЭК по тестированию обновлений безопасности.

Долгосрочные действия

• Переоценка надежности антивирусного вендора. Рассмотрите возможность смены антивирусного решения, если инцидент окажется значительным, а реакция вендора на него неудовлетворительной.
• Повышение зрелости кибербезопасности. Инцидент может служить поводом для пересмотра текущей архитектуры безопасности, включая внедрение дополнительных уровней защиты и мониторинга.
• Повышение безопасности цепочки поставки. Инцидент с имплантом в CI/CD у антивирусного вендора требует усиления контроля за всеми элементами цепочки поставки программного обеспечения, включая регулярный аудит сторонних поставщиков и их обновлений, а также разработку playbook для инцидентов с подрядчиками.
• Обучение и информирование сотрудников. Проведите обучение сотрудников о новых угрозах, связанных с инцидентами в сфере кибербезопасности, и как правильно реагировать на возможные риски.

Оценка юридических и регуляторных последствий

• Юридическая оценка. Свяжитесь с юридической службой для оценки нарушения возможных регуляторных требований, связанных с инцидентом.
  

  Уточните у регулятора, повлияет ли отключение вами антивируса на ваше соответствие его требованиям?

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

Как-то так…