Тут один российский разработчик решил выпустить решение класса CDR (Cloud Detection & Response) и я сразу вспомнил, с какими сложностями мы сталкивались в Cisco, когда занимались мониторингом безопасности облаков. У Cisco было (думаю, что сейчас не меньше) под тысячу облачных провайдеров, услугами которых она пользовалась и был свой фреймворк, которым она руководствовалась, делая выбор в пользу того или иного облака. И мониторинг ИБ был одним из важных его элементов. И я хочу вспомнить, как мы тогда оценивали функционал облаков с этой точки зрения.
Если зайти чуть издалека, то с точки зрения сетевой инфраструктуры у нас превалирует стек TCP/IP на базе Ethernet и поэтому средства класса NDR, анализирующие сетевые аномалии и угрозы в таких сетях, вполне способны занимать (и занимают) свою нишу на рынке ИБ. Схожая ситуация с мониторингом конечных устройств — несмотря на обилие операционных систем в мире, в корпоративной среде пальму первенства занимает Microsoft с Windows, что и обусловило появление решений класса EDR, преимущественно для продукции гиганта из Редмонда.
А вот с облаками ситуация иная — явного лидера как не было, так и нет. Amazon, Microsoft, Azure тянут одеяло на себя, по своему выстраивая свои облачные решения. И поэтому, в отличие от решений EDR и NDR, которые действительно могут быть самостоятельными продуктами, в отношении CDR таким похвастаться нельзя.
Но как же тогда мониторить безопасность облачных сред?
CDR сегодня, — это скорее набор технологий и инструментов, направленных на решение общей задачи — обнаруживать и реагировать. И тут впору вновь вернуться к истокам и посмотреть на эту задачу с инженерной, а не продажной точки зрения. Можно провести аналогию с сетевой инфраструктурой, которую принято делить на 3 плоскости/уровня:
- Data plane — отвечает за передачу сетевых пакетов между устройствами в сети. Тут у нас как раз и появляется стек TCP/IP, Ethernet, а в промышленных сетях так вообще свои имена и лидеры — Modbus, DNP3, Profibus, CAN, WirelessHART, HART, Fieldbus и т.п.
- Control plane — отвечает за маршрутизацию и коммуникации между устройствами в сети.
- Management plane — отвечает за управление и мониторинг сетевых операций.
Когда-то, с точки зрения кибербезопасности, обнаружение и реагирование в сетевой инфраструктуре рассматривалось серьезными сетевыми вендорами именно с такой точки зрения. Но потом все захотели простоты и одной магической коробки и Cisco, Juniper и иже с ними стали скупать нишевых ИБ-вендоров для удовлетворения своих стратегий роста. Но с облаками пока ситуация не вышла на определенное плато и поэтому там до сих пор идея с тремя плоскостями, на которых и реализуются функции D&R (Detection & Response), является единственно возможной.
Конечно, при условии, что мы говорим о контроле мультиоблачных сред, включая и один единственный SaaS. Если мы сделали ставку всего на одно облако или один SaaS, то там можно говорить и о каком-то коробочном решении (хотя даже в этом случае не всегда).
Возвращаясь к трем плоскостям, как они могут быть применены к облачным средам в контексте ИБ?
А если наложить на это еще и три основных типа облачных сред (IaaS, PaaS и SaaS), то получается, что у нас действительно нет какого-то одного (или хотя бы двух-трех) решений, которые можно было бы отнести к классу CDR. Да, с маркетинговой точки зрения это можно сделать, но по сути, мы должны будем выстраивать функцию мониторинга и реагирования в зависимости от того, какими облаками мы располагаем сейчас и какие планируем использовать в будущем. И так как далеко не все облачные провайдеры достаточно зрелы, чтобы закладывать в свои архитектуры вопросы ИБ, то построение на их основе чего-то безопасного является очень непростой задачей.
В качестве подспорья можно посмотреть на прилагаемую табличку, которая классическую модель разделения ответственности между клиентом и облачным провайдером транслирует на область мониторинга и реагирования. И если включить этот вопрос в процедуру выбора провайдера облачных услуг, то их число может существенно сократиться. В России, кстати, на момент закрытия российского офиса Cisco, так и не было выбрано ни одного отечественного облака для внутренних нужд, так как все они не соответствовали разработанному в компании фреймворку.
Эта табличка дает высокоуровневый взгляд на возможности построения функции обнаружения и реагирования для разных облачных моделей — детали будут зависеть от конкретного провайдера. В одном случае, вы сможете анализировать логи в реальном времени, но не сможете реализовать реагирование в таком же режиме. В другом случае, вы даже логи сможете только выкачивать в ручном режиме, по команде администратора. В третьем случае, вы сможете даже свой NGFW поставить в облако для реализации функции блокирования несанкционированных попыток доступа к облачным ресурсам, но оркестратор у вас должен быть все равно свой.
Я, когда писал заметку, специально поглядел на то, как описывают свои механизмы безопасности Яндекс.Облако и VK Cloud. Ну что вам сказать, «искусство, по-прежнему, в большом долгу«. Яндекс в этом вопросе продвинулся дальше, разработав целый стандарт по защите своей облачной инфраструктуры (доступна версия стандарта 1.3). VK Cloud просто перечислил требования ФСТЭК, которым они соответствуют, не уточнив, как именно эти меры реализованы. В разделе документации про «Безопасность платформы» тоже не ахти как много деталей. Аналогичная история и с Cloud.ru.
Яндексу, который из всех российских облаков продвинулся дальше всех, пока не хватает системы управления ИБ своей облачной инфраструктуры; по аналогии с аналогичными решениями от Amazon или Microsoft.
Так что, когда вы увидите, что кто-то говорит про решения класса CDR, стоит вспомнить, что я написал, и посмотреть более пристально на предлагаемое вам решение.
Заметка Существуют ли решения класса Cloud Detection & Response? была впервые опубликована на Бизнес без опасности .
