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

SecOps

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как-то так…

Оцените статью
Бизнес без опасности
Есть что добавить? Добавьте!

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