5 вещей, которые вы обязаны требовать от своих ИБ-поставщиков
| |
01 августа 2017 |
|
Просматривал тут фотки на iPhone и наткнулся на одну, которую я сделал на прошедшем
Gartner Security & Risk Management Summit.
"А ведь она стоит отдельной заметки", подумал я и вот эта заметка. На
этом слайде самой первой презентации, открывающей конференцию Gartner,
докладчик выделил пять ключевых вещей, которые сегодня необходимо
требовать от поставщиков решений по безопасности, с которыми вы
сотрудничаете или планируете сотрудничать (особенно во втором случае).
- Открытый API. Даже в такой консервативной области как
промышленные сети сегодня нельзя встретить производителя, который бы
по-прежнему держался за принцип "security through obscurity" и
использовал проприетарные технологии и протоколы в своих решениях. Чего
уж говорить о мире обычном, который гораздо обширнее, чем промышленные
сети. Сегодня нет в мире поставщика, который был бы монополистом в
области ИБ (как бы этого не хотелось) и который мог бы закрыть своими
продуктами все потребности своих заказчиков. Кто-то специализируется на
защите сетей, кто-то на защите облаков, кто-то на защите оконечных
устройств. А заказчики используют все эти решения у себя и не хотят
иметь дело с зоопарком. Мы в своем исследовании состояния ИБ в 2016-м
году получили цифры, которые показаны на иллюстрации ниже - больше
половины заказчиков используют от 6 до 50 различных поставщиков средств
ИБ, а число заказчиков, использующих от 6 до 50 средств защиты еще выше,
65%. Это говорит только о том, что средства защиты должны иметь
открытые API для взаимодействия либо между собой напрямую, либо через
некоторые средства оркестрации или управления. Особенно это важно
сейчас, когда в России стали появляться и собственные системы управления
событиями безопасности, и отдельные заказчики строят на базе open
source собственные решения по ИБ и хотят пользоваться теми
возможностями, которые им предоставляют имеющиеся у них иные средства.
- Поддержка современных практик ИТ.
Ну тут, вроде, как и не требуются отдельные пояснения. Если заказчик
внедрил виртуализацию или планирует уйти в облака, если его руководство
требует себе мобильное устройство, а вся компания стремится в BYOD, то
средство защиты должно поддерживать все эти инициативы. А иначе зачем
нужны такие "вериги" на ногах ИТ, которые только мешают, а не
способствуют бизнесу?
- Поддержка адаптивных политик. Статика уходит в прошлое...
Сигнатуры, жестко прописанные ACL, статические политики МСЭ вида "IP1
может получить доступ к IP2 по протоколу HTTP, а IP2 к IP1 - не может"
уже не учитывают динамическую картину мира. Я эту заметку начинал писать
в Питере на рабочем ноутбуке, продолжил в Интернет-кафе в отпуске,
завершил на смартфоне во время поездки в метро, а отшлифовал уже дома на
планшетнике. Чтобы описать эту картину в старой, статической парадигме,
необходимо множество правил, которые должны быть размещены на всем
протяжении моего движения от устройства, с которого я пишу, до блога. А
промежуточных коммутаторов и маршрутизаторов, межсетевых экранов и точек
беспроводного доступа может быть на пути несколько. А теперь перемножим
это число на количество сотрудников в компании и получим колоссальное
количество правил, которые надо поддерживать в актуальном состоянии. В
замкнутой и неизменяемой среде это еще возможно, а вот в динамической, с
постоянно путешествующими сотрудниками, использующими личные
устройства, такая статическая схема уже не срабатывает. Нужна адаптивная
или контекстно-ориентированная политика, отвечающая на вопросы - кто,
что, куда, откуда, как, когда и зачем. Вот, например, как это сделано
внутри самой Cisco. У нас, правда, масштаб немного иной, но все-таки.
Статика уходит в небытие и вендора должны поддерживать динамически
изменяемые политики.
- Полный доступ к данным без штрафов. Вы знаете, сколько
событий безопасности (записей в логах) хранят ваши средства защиты? Сто
тысяч? Миллион? Миллиард? У нас внутри Cisco только сетевых событий
ежедневно регистрируется
1,2 триллиона (!). Чьи это события? Вендора средства защиты/сетевого
оборудования или ваши? Вероятно второе. А значит мы хотели бы иметь к
ним доступ, чтобы, возможно, проанализировать их самостоятельно, без
участия вендорв, собравшего нам исходные данные, на основании которых он
принимает решения о тех или иных нарушениях политики ИБ. И доступ этот у
нас должен быть полный, без ограничений, без запретов в
дизассемблировании или иных нарушений всяческих законов об
интеллектуальной собственности (речь в данном случае идет о данных, а не
о самом коде ПО или железе). Отсюда требование, перекликающееся с
первым, наличие доступа к полным логам и собранным данным, которые можно
выгрузить или к которым можно получить доступ собственным средствам
аналитики ИБ. Особенно в контексте повального увлечения в России
разрабатывать собственные SIEMы.
- Использование множества методов обнаружения. Это требование в условиях современного
динамичного ландшафта угроз вполне логично и очевидно. Антивирус не
должен бороться с вредоносным ПО только с помощью сигнатур, а IDS должна
использовать еще и анализ аномалий. EDR должен уметь анализировать
сетевые потоки данных, а также при необходимости интегрироваться с
песочницами. Эффективное средство защиты сегодня оперирует не одним,
пусть и хорошим, механизмом детектирования вредоносной активности, а
сразу несколькими. Не сработал один, поймал второй. Не поймал второй,
зафиксировал атаку третий. А иначе средства защиты превращаются в
красивую и дорогостоящую игрушку, которую, чтобы крикнуть "Мама", еще
надо ухитриться поместить в определенное и только такое положение.
Понятно, что эта пятерка - не догма, а руководство к действию, как писал
Фридрих Энгельс в позапрошлом столетии. Но выглядит она достаточно
здраво и ее стоит взять на вооружение при общении со своими поставщиками
средств защиты информации. Лишними эти требования уж точно не будут.
Источник
Адрес: 105082, Россия, г. Москва, 2-й Ирининский пер, д. 3
Оставить свой комментарий:
Комментарии по материалу
Данный материал еще не комментировался.