5 вещей, которые вы обязаны требовать от своих ИБ-поставщиков

Стратегия
Просматривал тут фотки на iPhone и наткнулся на одну, которую я сделал на прошедшем Gartner Security & Risk Management Summit. «А ведь она стоит отдельной заметки», подумал я и вот эта заметка. На этом слайде самой первой презентации, открывающей конференцию Gartner, докладчик выделил пять ключевых вещей, которые сегодня необходимо требовать от поставщиков решений по безопасности, с которыми вы сотрудничаете или планируете сотрудничать (особенно во втором случае).

  1. Открытый API. Даже в такой консервативной области как промышленные сети сегодня нельзя встретить производителя, который бы по-прежнему держался за принцип «security through obscurity» и использовал проприетарные технологии и протоколы в своих решениях. Чего уж говорить о мире обычном, который гораздо обширнее, чем промышленные сети. Сегодня нет в мире поставщика, который был бы монополистом в области ИБ (как бы этого не хотелось) и который мог бы закрыть своими продуктами все потребности своих заказчиков. Кто-то специализируется на защите сетей, кто-то на защите облаков, кто-то на защите оконечных устройств. А заказчики используют все эти решения у себя и не хотят иметь дело с зоопарком. Мы в своем исследовании состояния ИБ в 2016-м году получили цифры, которые показаны на иллюстрации ниже — больше половины заказчиков используют от 6 до 50 различных поставщиков средств ИБ, а число заказчиков, использующих от 6 до 50 средств защиты еще выше, 65%. Это говорит только о том, что средства защиты должны иметь открытые API для взаимодействия либо между собой напрямую, либо через некоторые средства оркестрации или управления. Особенно это важно сейчас, когда в России стали появляться и собственные системы управления событиями безопасности, и отдельные заказчики строят на базе open source собственные решения по ИБ и хотят пользоваться теми возможностями, которые им предоставляют имеющиеся у них иные средства.

  2. Поддержка современных практик ИТ. Ну тут, вроде, как и не требуются отдельные пояснения. Если заказчик внедрил виртуализацию или планирует уйти в облака, если его руководство требует себе мобильное устройство, а вся компания стремится в BYOD, то средство защиты должно поддерживать все эти инициативы. А иначе зачем нужны такие «вериги» на ногах ИТ, которые только мешают, а не способствуют бизнесу?
  3. Поддержка адаптивных политик. Статика уходит в прошлое… Сигнатуры, жестко прописанные ACL, статические политики МСЭ вида «IP1 может получить доступ к IP2 по протоколу HTTP, а IP2 к IP1 — не может» уже не учитывают динамическую картину мира. Я эту заметку начинал писать в Питере на рабочем ноутбуке, продолжил в Интернет-кафе в отпуске, завершил на смартфоне во время поездки в метро, а отшлифовал уже дома на планшетнике. Чтобы описать эту картину в старой, статической парадигме, необходимо множество правил, которые должны быть размещены на всем протяжении моего движения от устройства, с которого я пишу, до блога. А промежуточных коммутаторов и маршрутизаторов, межсетевых экранов и точек беспроводного доступа может быть на пути несколько. А теперь перемножим это число на количество сотрудников в компании и получим колоссальное количество правил, которые надо поддерживать в актуальном состоянии. В замкнутой и неизменяемой среде это еще возможно, а вот в динамической, с постоянно путешествующими сотрудниками, использующими личные устройства, такая статическая схема уже не срабатывает. Нужна адаптивная или контекстно-ориентированная политика, отвечающая на вопросы — кто, что, куда, откуда, как, когда и зачем. Вот, например, как это сделано внутри самой Cisco. У нас, правда, масштаб немного иной, но все-таки. Статика уходит в небытие и вендора должны поддерживать динамически изменяемые политики.
  4. Полный доступ к данным без штрафов. Вы знаете, сколько событий безопасности (записей в логах) хранят ваши средства защиты? Сто тысяч? Миллион? Миллиард? У нас внутри Cisco только сетевых событий ежедневно регистрируется 1,2 триллиона (!). Чьи это события? Вендора средства защиты/сетевого оборудования или ваши? Вероятно второе. А значит мы хотели бы иметь к ним доступ, чтобы, возможно, проанализировать их самостоятельно, без участия вендорв, собравшего нам исходные данные, на основании которых он принимает решения о тех или иных нарушениях политики ИБ. И доступ этот у нас должен быть полный, без ограничений, без запретов в дизассемблировании или иных нарушений всяческих законов об интеллектуальной собственности (речь в данном случае идет о данных, а не о самом коде ПО или железе). Отсюда требование, перекликающееся с первым, наличие доступа к полным логам и собранным данным, которые можно выгрузить или к которым можно получить доступ собственным средствам аналитики ИБ. Особенно в контексте повального увлечения в России разрабатывать собственные SIEMы.
  5. Использование множества методов обнаружения. Это требование в условиях современного динамичного ландшафта угроз вполне логично и очевидно. Антивирус не должен бороться с вредоносным ПО только с помощью сигнатур, а IDS должна использовать еще и анализ аномалий. EDR должен уметь анализировать сетевые потоки данных, а также при необходимости интегрироваться с песочницами. Эффективное средство защиты сегодня оперирует не одним, пусть и хорошим, механизмом детектирования вредоносной активности, а сразу несколькими. Не сработал один, поймал второй. Не поймал второй, зафиксировал атаку третий. А иначе средства защиты превращаются в красивую и дорогостоящую игрушку, которую, чтобы крикнуть «Мама», еще надо ухитриться поместить в определенное и только такое положение.
Понятно, что эта пятерка — не догма, а руководство к действию, как писал Фридрих Энгельс в позапрошлом столетии. Но выглядит она достаточно здраво и ее стоит взять на вооружение при общении со своими поставщиками средств защиты информации. Лишними эти требования уж точно не будут.

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

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