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 должен уметь анализировать сетевые потоки данных, а также при необходимости интегрироваться с песочницами. Эффективное средство защиты сегодня оперирует не одним, пусть и хорошим, механизмом детектирования вредоносной активности, а сразу несколькими. Не сработал один, поймал второй. Не поймал второй, зафиксировал атаку третий. А иначе средства защиты превращаются в красивую и дорогостоящую игрушку, которую, чтобы крикнуть "Мама", еще надо ухитриться поместить в определенное и только такое положение.

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