Как создать свою систему Threat Intelligence? Часть 3

Как создать свою систему Threat Intelligence? Часть 3
Закончить трилогию, посвященную вопросу создания собственной системы Threat Intelligence, мне хотелось бы перечислением потенциальных проблем, которые могут подстерегать создателей:
  1. Отсутствие нормальной автоматизации. Обычно, при проявлении угрозы или возникновении инцидента, обмен сведениями идет по обычному телефону или e-mail, что плохо масштабируется и совсем неоперативно.
  2. Конкуренция. Это госорганам нет смысла конкурировать между собой и поэтому для них нет проблемы обмениваться угрозами и делать их достоянием узкого круга лиц, допущенных к системе ИБ-аналитики. По крайней мере в Сиэтле, где была создана такая система (Public Regional Information Security Event Management, PRISEM), конкуренции между федеральными и муниципальными органами не было. Поэтому система сбора и обмена информацией об угрозах, предусмотренная 31-м Указом Президента, имеет право на жизнь. А вот с коммерческими организациями, которые в теории могут использовать знание об инцидентах друг у друга во вред "коллегам", все может быть сложнее. Правда, у российских госорганов может быть опасение, что их накажут за низкий уровень защищенности и они будут препятствовать передаче событий в централизованное хранилище.
  3. Отсутствие доверенных источников информации об угрозах. Это проблема и проблема серьезная. Есть такие ресурсы как, например, www.malwaredomains.com . Есть и платные сервисы, распространяющие такие сведения, например,  ETPro  и  IQRisk . Но насколько они полны и релевантны? Какое влияние на них имеют спецслужбы? Насколько они учитывают региональную специфику? Насколько оперативно они обновляются?
  4. Юридическая неопределенность. А что думают ваши юристы по поводу передачи достаточно чувствительной информации третьим лицам? А PR и внутренний контроль? Не видят ли они препятствия к передаче такой информации?
  5. Доверие. Очевидно, что оператор системы ИБ-аналитики должен быть лицом, которому доверяют все участники. Никто не хочет, чтобы информация об угрозах, с которыми приходится сталкиваться, стала достоянием гласности по халатности или банального желания заработать на "горяченьком".
  6. Объем. "Сколько вешать в граммах?" Каков объем информации достаточен для передачи в систему ИБ-аналитики? Как не передать слишком много или слишком мало? Как не утонуть в потоке событий?
  7. Отсутствие мотивации. "Почему я должен передавать информацию о моих проблемах кому-то?" Как замотивировать участников системы обмена информацией об угрозах? Одно дело, когда это стандартная функция средства защиты (как, например, подсистема глобальной корреляции в Cisco IPS), о которой могут и не догадываться пользователи, и совсем другое дело, когда речь идет о сознательной передаче чувствительной информации. Что я получу взамен, если буду передавать сведения об инцидентах? Что я могу потерять, если не буду этого делать?

Проблем немало, но это не значит, что не надо даже начинать процесс создания такой системы. В современных условиях, когда ландшафт угроз меняется постоянно, а о новых угрозах становится известно ежечасно, по старинке бороться с ними становится невозможно. Нужна автоматизация и централизация процесса сбора и обмена информацией об угрозах ИБ. И система ИБ-аналитики, вендорская или государственная, отраслевая или собственная, должна решать эту задачу.
Threat Intelligence управление инцидентами угрозы
Alt text
Обращаем внимание, что все материалы в этом блоге представляют личное мнение их авторов. Редакция SecurityLab.ru не несет ответственности за точность, полноту и достоверность опубликованных данных. Вся информация предоставлена «как есть» и может не соответствовать официальной позиции компании.

SOC как супергерой: не спит, не ест, следит за безопасностью!

И мы тоже не спим, чтобы держать вас в курсе всех угроз

Подключитесь к экспертному сообществу!