9 сентября, 2021

Почему «Компьютер инженера Гарина» лучше, чем «192.168.3.28»

Инвентаризация в ИБ крайне важна, особенно при выявлении и реагировании на компьютерные атаки и инциденты. Однако вряд ли хоть в одной компании собираются все необходимые для этого данные. С таким заявлением выступил представитель компании «Перспективный мониторинг» Георгий Караев на практической конференции ТехноФест, организованной компаний «ИнфоТеКС».

«Под инвентаризацией активов я подразумеваю информационные активы, то есть объекты сети, данные по которым необходимо постоянно собирать, актуализировать и хранить в каком-то едином месте. Сбор данных необходимо осуществлять не только с серверного оборудования, то есть не только с физических серверов, но и программную составляющую. То есть требуется сбор и программного обеспечения, и инвентаризация информационных систем. В принципе, это любая сущность, которая может быть тем или иным способом идентифицирована в вашей информационной сети», — пояснил спикер.

 

Практика по мониторингу информационной безопасности

Чтобы не быть голословным, Георгий Караев привел несколько примеров, когда инвентаризация существенно помогает при выявлении и реагировании на компьютерные атаки и инциденты.

 

Пример 1.

Допустим, на периметре информационной сети стоят IDC и средства обнаружения вторжений, анализируется трафик, детектируются какие-то события. И вдруг происходит какое-то событие, фиксируется подозрение на компьютерную атаку — происходит какая-то эксплуатация Apache. Не имея инвентаризационных данных, ИБ-специалист инициирует расследование: начинает регистрацию карточки инцидента, начинает выяснять, на каком ip это произошло, отправляет запрос ИТ-инженеру. В свою очередь ИТ-инженер тоже начинает по своим табличкам искать, вспоминать, что это за ip-шник, заходит на него, понимает, что это сервер какого-то финансового отдела, на котором Apache и нет.

«Получается, происходит фолз позитив срабатывание. Время потрачено на пустое разбирательство. То есть зная все это заранее (если бы оператор знал, что этот сервер имеет такое ПО) оператор бы даже не среагировал и пометил бы данное событие как фолз», — рассказал Георгий Караев.

 

Пример 2.

Происходит такая же ситуация, как в Примере 1, но в компании есть инвентаризационные данные и есть данные по уязвимостям. «Как правило, процесс инвентаризации очень тесно связан с уязвимостями, то есть у нас есть перечень программного обеспечения, есть соответствующие версии программного обеспечения, соответственно, мы можем понять, какие уязвимости характерны для этого ПО», — пояснил спикер.

В этом случае, имея данные инвентаризации, можно сразу в SIEM сказать, что не нужно информировать об инциденте, если произошла какая-то атака и на узле эта уязвимость не актуальна. Тогда даже оператор не обратит внимание на этот фолз и сосредоточится на чем-то более важном. Кроме того, с инвентаризационными данными в SIEM-системе можно настраивать свои правила корреляции таким образом, чтобы сократить количество фолзов.

 

Пример 3.

Предположим, на периметре стоят средства обнаружения вторжения и IDC и смотрят какие-то белые ip-адреса сети, а пользователи ходят в интернет через прокси. Тогда получается, что события, которые приходят от IDC оператору, все с единым адресом прокси компании.

«И как понять, кто стоит за конкретным узлом или конкретной машиной? Чтобы избегать подобные ситуации, сразу понимать, что происходит, нужно как минимум включать логирование на SIEM, которое показывало бы соответствие хотя бы с внутренним ip-адресом. И плюс инвентаризационные данные — что стоит за этими данными, внутренним адресом в сети. Мы тем самым улучшаем и увеличиваем нашу эффективность при реагировании», — отметил Георгий Караев.

 

Что полезно собирать

По словам спикера, полезно собирать следующее:

  • Физическое расположение
  • Состояние
  • IP адрес
  • DNS Hostname
  • Приоритет
  • Описание
  • MAC адрес
  • NetBIOS/Directory Domain
  • ОС (название/версия)
  • Адрес NAT
  • Влияние на бизнес
  • Сетевое расположение/Владелец
  • Информация по SNMP
  • История IP адресов
  • Контакт для эскалации
  • Ответственный
  • Функциональное назначение
  • Дата регистрации
  • Уязвимости (CVE)
  • Открытые порты

«Это перечень того, что полезно собирать для информационного ресурса. Если вот это все у вас есть, то низкий поклон. Потому что такого, мне кажется, нет ни у кого, чтобы все и сразу было вместе», — сказал Георгий Караев.

 

Некоторые пояснения

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

«Важный момент (и это мало у кого есть) — это влияние на бизнес, то есть что будет, если этот конкретный актив сломается, перестанет функционировать, как это повлияет на бизнес. Это важный момент для реагирования и регистрации инцидента, потому что мы можем на определенный инцидент дать время, потому что этот узел для нас совсем не важен, а есть узлы, которые довольно критические, и необходимо принимать довольно оперативно решения и быстро реагировать», — пояснил Георгий Караев.

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

Смотрите также