Мониторинг безопасности облаков. Часть 2

Итак, я продолжу статью, посвященную мониторингу безопасности облачных провайдеров. В первой части ^[1] я рассказывал об опыте Cisco в работе с внешними облачными сервисами, а также о наблюдениях Cisco, с которым мы столкнулись при построении или аудите SOCов наших заказчиков. Взяв в первой части в качестве примера три самых популярных решения от компаний Amazon, Microsoft и Google, которые являются IaaS/PaaS-платформами, сегодня наступила пора поговорить о мониторинге SaaS-платформ — Dropbox, Salesforce.com, Slack и Apple Business Manager, а также о том, какие SIEM сегодня лучше всего подходят для мониторинга облачных платформ.

Пример: Мониторинг ИБ в SaaS на базе Dropbox

Если на базе AWS, Azure или GCP вы можете создать почти полный аналог своей корпоративной инфраструктуры, только в облаке, то есть облачные сервисы, которые выполняют одну конкретную задачу, например, файловое хранилище, как это делает Dropbox. Этот сервис давно вышел за рамки обычной пользовательской хранилки, предоставляя своим корпоративным пользователям целый набор защитных механизмов:

• идентификацию и аутентификацию пользователей
• контроль доступа к файлам
• удаленное удаление данных
• управление доверенными устройствами
• интеграцию с внешними решениями по ИБ (DLP, SSO, DRM, eDiscovery, SIEM и т.п.)
• регистрация событий безопасности.

Ведущиеся Dropbox Business (ни в версии Basic, ни в Pro такой возможности нет) журналы регистрации фиксируют следующие типы событий безопасности:

• настройки парольной защиты
• удачные и неудачные попытки входа в файловое хранилище
• контроль привилегированного доступа и действий администраторов
• действия с файлами (добавление, редактирование, удаление, перенос, загрузка и т.п.)
• подключение к файловому хранилищу приложения третьих фирм
• устройства, с которых осуществляется доступ к Dropbox
• добавление/удаление участников в группы доступа
• создание папок/файлов, доступных извне

Анализировать события безопасности в Dropbox вы можете либо через административную консоль Dropbox Business (но не ждите больших откровений в ней), либо воспользовавшись внешним решением по мониторингу, которое оперирует Dropbox Business API. Доступ к логам доступен не в любом тарифе Dropbox Business, а только начиная с лицензии Advanced (вспомните Office365, у которого тоже доступ к логам начинается не с базовой бизнес-лицензии). Как и в случае с AWS стоит поинтересоваться, ваш SIEM поддерживает работу с Dropbox? Например, Splunk имеет отдельный модуль для работы с Dropbox, который за счет REST API позволяет отслеживать следующие события безопасности:

• вход в систему
• активность по добавлению/удалению/запросам пользователей
• активность устройств, подключающихся к Dropbox
• активность по обмену файлами внутри компании и за ее пределами
• активность в приложении
• и т.п.

У других SIEM встроенной поддержки Dropbox нет — придется писать собственный коннектор.

Пример, мониторинг ИБ в SaaS на базе Slack и Salesforce.com

Мы понимаем, что сегодня представлено огромное количество облачных платформ, которые могут быть использованы бизнесом для решения своих задач и которые хотелось бы мониторить с точки зрения их безопасности. В каждую из таких платформ мы погружаться не будем (да и задачи такой я не ставил, желая только обратить внимание на особенности задачи мониторинга ИБ облачных платформ), но попробуем завершить рассмотрение примером конкретных платформ еще двумя распространенными в бизнесе решениями — Slack и Salesforce.com.

Slack интегрируется с 50+ инструментами безопасности (от защиты контента и обеспечения приватности до мониторинга сертификатов и контроля доступа), но с точки зрения мониторинга широкого спектра событий безопасности у Slack готовых интеграций маловато — на сайте этот перечень ограничен мало известным у нас Symantec CloudSOC, Cisco CloudLock (о нем пойдет речь чуть ниже) и Chronicle. Вот, пожалуй, и все. Но имея сертификации ISO 27001, SOC2/3, Fed-RAMP и ряд других, Slack не мог не реализовать расширенный функционал по мониторингу своей инфраструктуры, часть которого доступна и заказчикам. В частности с помощью Audit Logs API (доступен только для пользователей Slack Enterprise Grid и недоступен в планах Free, Standard, Plus) можно “вытягивать” широкий спектр данных из вашей инфраструктуры Slack и загружать ее в свой SIEM, связанных с активностью пользователей, но не с мониторингом контента (для этих задач надо использовать специализированные DLP или eDiscovery-решения). При этом у Slack нет схожего с AWS GuardDuty механизма — он отдает события “как есть” и не говорит вам, плохие они или хорошие, это можете определить только вы сами, путем написания собственных правил корреляции в вашем SIEM или используя внешние решения, которые имеют набор предопределенных шаблонов несанкционированной активности в Slack (как, например, в Cisco CloudLock).

Каждое событие в журнале регистрации Slack имеет 4 ключевых элемента — действие (action), пользователь, его сгенервший (actor), сущность (entity), связанная с событием (рабочее пространство, приложение, пользователь, канал, файл), и местоположение (context), в рамках которого это действие произошло (отдельное рабочее пространство или вся организация). Всего Slack фиксирует около 70 различных действий. Например, вот так выглядит событие регистрации пользователя в Slack:

{
   "entries":[
	  {
		 "id":"0123a45b-6c7d-8900-e12f-3456789gh0i1",
		 "date_create":1521214343,
		 "action":"user_login",
		 "actor":{
			"type":"user",
			"user":{
			   "id":"W123AB456",
			   "name":"Charlie Parker",
			   "email":"bird@slack.com"
			}
		 },
		 "entity":{
			"type":"user",
			"user":{
			   "id":"W123AB456",
			   "name":"Charlie Parker",
			   "email":"bird@slack.com"
			}
		 },
		 "context":{
			"location":{
			   "type":"enterprise",
			   "id":"E1701NCCA",
			   "name":"Birdland",
			   "domain":"birdland"
			},
			"ua":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.186 Safari/537.36",
			"ip_address":"1.23.45.678"
		 }
	  }
	]
}

С Salesforce ситуация аналогичная — с помощью API вы можете получить доступ ко всей пользовательской активности в этой облачной CRM и в частности к следующим событиям:

• вход в систему
• выход из системы
• выгрузку отчетов
• вызовы API
• URI (web-клики в Salesforce Classic)
• Lightning (web-клики в Lightning Experience и мобильном приложении Salesforce)
• загрузки страниц Visualforce
• выполнение Apex
• И др.

Помимо этого, вы имеете возможность мониторить безопасность вашего экземпляра Salesforce и работать с журналами регистрации событий в консоли администратора Salesforce. У вас есть 4 возможности:

• Мониторинг всех попыток доступа к порталу SFDC. Страница Login History показывает 20000 записей о входе в портал за последние 6 месяцев (с указанием метода входа HTTP — GET, POST или иные). Если нужна более длинная история, то соответствующий лог может быть выгружен в формате .csv или .gzip.
• Мониторинг работы с полями в CRM. Через консоль администратора вы можете отслеживать историю работы со стандартными и пользовательскими полями облачной CRM за последние 18 месяцев, а через API получить доступ к двухлетней истории изменений полей. Вы также может архивировать эту историю на срок до 10 лет и при необходимости получать к ней доступ.
• Мониторинг административных изменений. С помощью функции Setup Audit Trail вы можете следить за более чем 100 действиями всех ваших администраторов (особенно если их несколько) за последние 180 дней.
• Мониторинг транзакций. С помощью сервиса Transaction Security вы можете перехватывать в реальном времени события Salesforce и применяя к ним соответствующую логику обработки генерить уведомления и сигналы тревоги.

Недавно Salesforce разработала специализированное решение для мониторинга безопасности своей платформы — Salesforce Shield. Оно включает в себя три компонента — управление шифрованием всей хранимой информации, мониторинг безопасности и использования данных, и управление политиками безопасности. В случае с мониторингом ИБ, данная функция в Salesforce Shield сродни расширениям Azure Monitor, которые не просто показывают вам события, но и за счет их обработки и визуализации подсказывают на что обратить внимание. Например, вы можете узнать, с каких устройств и платформ пользователи чаще всего заходят в SFDC? Или когда чаще всего и откуда заходят пользователи в свою копию Salesforce (это можно помочь выявить нетипичные точки входа)? Кто просматривает конфиденциальную информацию? Кто чаще всего выгружает отчеты к себе на компьютер? Ответы на эти вопросы можно получить с помощью 16 предустановленных панелей, на вход которых проанализированные данные подает отдельно лицензируемая подсистема Einstein Event Monitoring Analytics (красивое название, не так ли). С ее помощью можно также моделировать и свои дашборды, выгружать данные во внешние системы BI и т.п.

Пример: мониторинг ИБ в iPhone и iPad

Опа… А причем тут iPhone и мониторинг облаков, спросите вы. Тут все просто. Например, ни один SIEM на момент написания заметки не имел коннектора к платформе Apple Business Manager (или Apple School Manager, который больше известен в ВУЗах США), которая позволяет управлять корпоративными устройствами Apple — iPhone, iPad, Mac. Для этой задачи вы можете задействовать какое-либо из MDM-решений, а можете Apple Business Manager (в случае участия в программе Apple Device Enrolment Programme или Volume Purchase Programme, которые в России не действуют). MDM-решения могут быть установлены локально и интегрировать их с вашим SIEM в принципе большого труда не составляет, как собственно и облачные MDM (например, Cisco Meraki), а вот история с Apple Business Manager имеет ярко выраженный облачный окрас и в контексте данной статьи интересно посмотреть, как один из крупнейших ИТ-производителей решает проблему предоставления возможности мониторинга безопасности своих решений.

Вообще, именно с этой точки зрения решения компании Apple в России не очень известны (хотя на Западе мы с ними, в проектах по SOC, сталкиваемся). Отсюда сложившееся мнение, что Apple — это чисто консьюмерская компания, которая не повернулась лицом к корпоративным заказчикам с точки зрения интеграции в их SOCи. Это так и не так одновременно. Дело в том, что имея достаточно мощную систему защиты iOS и MacOS, Apple продолжает оставаться закрытой коиманией и не очень активно допускает внешние стороны к информации о безопасности своих продуктов. Хотя картина постепенно меняется. Например, Apple Business Manager позволяет вам увидеть информацию об активности на корпоративных Apple-устройствах, которая объединена в три блока информации — событие, статус и дата начала события (с датой окончания, увы, проблемы). К контролируемым событиям (у Apple School Manager их чуть больше, но они связаны с занятиями студентов/учеников) относятся:

• Email new sign-ins
• Create new sign-ins
• Email new verification codes
• Assign roles
• Delete accounts
• Deactivate accounts
• Reactivate accounts
• Assign devices
• Unassign devices
• Release devices
• Unassign and delete server
• Reassign and delete server.

Если честно, то не так уж и много информации. Работать с ней можно либо в панели управления Apple Business Manager, либо выгружая как .csv файл к себе на компьютер для последующего анализа. Надо признать, что основная ориентация данной возможности у Apple все-таки ориентирована на поиск проблем в ИТ-плоскости, чем на решение вопросов безопасности — никакой автоматизации сбора логов или анализа у Apple нет. Гораздо больше информации вы можете вытянуть в случае интеграции Apple Business Manager с каким-либо MDM-решением — тогда вы можете получать информацию об активных пользователях, идентификаторах пользователей и устройств, в том числе адрес Wi-Fi, данным по установленным приложениям и их версиям, наличии неустановленных обновлений, операторе связи, персональной точке доступа, включенной функции “Найти iPhone”, шифровании данных, джейлбрейке, установленных сертификатах, наличии и настройках персонального МСЭ, настройках PIN-когда, наличии удаленного управления и т.п. Этого достаточно для задач мониторинга ИБ, но потребует определенных телодвижений, чтобы интегрировать ваши корпоративные Apple-устройства в ваш SOC.

SIEM для мониторинга облаков

Надо отметить, что Amazon, как и многие другие публичные облака, уделяя очень большое внимание своей безопасности, все-таки фокусируется преимущественно на механизмах обнаружения и предотвращения достаточно простых угроз в своей инфраструктуре, а также на предоставлении доступа к событиям, которые можно анализировать с помощью внешних решений. Наиболее близко к созданию системы мониторинга и анализа событий безопасности в облачной среде подошла компания Microsoft, но использование ее решения потребует от вас дополнительных финансовых вложений. Если вы используете только облака этой компании, то возможно вы можете и ограничиться Azure Security Center с расширениями. Но если у вас мультиоблачная среда, то стоит рассмотреть применение самостоятельных решений — SIEM, которые, возможно, вы уже используете для мониторинга ИБ своей внутренней инфраструктуры. И вот тут вам необходимо понять, насколько выбранный или выбираемый вами SIEM поддерживает используемое вами облако (и его различные сервисы) в качестве источника данных. Например, Splunk, QRadar, ArcSight, ELK поддерживают AWS и это прямо заявлено в документации на эти системы мониторинга, а тот же RuSIEM или PT SIEM не поддерживает.

При этом стоит учитывать, что разные SIEM могут по-разному забирать данные из разных облачных сервисов. Возьмем к примеру ELK и Amazon. Многие облачные сервисы и приложения могут форвардить свои события в корзину S3, а Logstash может потом забирать их по запросу. Упоминаемый ранее AWS CloudWatch может также отдавать данные в S3, а может стримить их в AWS Lambda (и Logstash их забирает для анализа) или размещенный в облаке ElasticSearch. Ну и, конечно, есть приложения которые могут напрямую отдавать данные в ELK, минуя S3, Lambda или CloudWatch. IBM QRadar забирает данные того же AWS GuardDuty через сервис AWS CloudWatch, логи Amazon VPC Flow Logs через публикацию их в корзине S3 с последующим захватов в QRadar, а данные с AWS CloudTrail либо через корзину S3, либо через AWS CloudWatch. В зависимости от того, какие данные вам нужны для мониторинга, это знание может помочь вам не сделать роковую ошибку, выбрав SIEM, который после внедрения не сможет работать с нужными вами облачными приложениями и сервисами.

Несмотря на популярность AWS или Azure, у ряда SIEM нет встроенных коннекторов для работы с облаками Amazon и Microsoft, но есть возможность создать свой собственный — самостоятельно или с помощью производителя, как, например, в случае PT SIEM с Custom Connector. При этом стоит обратить внимание, что AWS — это не самый правильный пример для получения представления о том, как SIEM работают с облаками. AWS является самой популярной облачной бизнес-платформой в мире и поэтому с ней стараются интегрировать свои продукты многие производители, в том числе и в области ИБ. Но даже в этом случае, надо все-таки признать, что в целом SIEM сегодня не так уж и часто позволяют вам мониторить облачные платформы. Например, IBM QRadar работает только со следующими облачными сервисами (не считая облачные ИБ-сервисы типа Cisco Umbrella, Cisco Meraki, Cisco Threat Grid и т.п.):

• AWS GuardDuty и AWS CloudTrail (другие сервисы AWS пока не поддерживаются)
• Box
• Cloudera
• MS Azure
• Salesforce.

Список не очень большой. У того же Splunk база модулей для работы с облаками гораздо шире. Помимо вышеупомянутых для IBM Qradar решение от Splunk поддерживает также:

• Office365
• ServiceNow
• Amazon Kinesis
• Slack
• JIRA
• Google Drive
• Google Cloud
• Nagios
• G Suite App
• Docker
• Kubernetes
• и др.

Обратите внимание, что GCP пока не поддерживает никто.

Используя расширение Splunk App for AWS (для ArcSight или QRadar идея будет схожая) можно реализовать, например, следующие сценарии мониторинга (use case), которые позволят ответить на важные с точки зрения ИБ вопросы:

• Кто добавил правило в группу безопасности, которая защищает наши сервера приложений?
• Откуда приходит в VPC заблокированный трафик?
• Какова была активность конкретного пользователя до и после инцидента?
• Уведомить меня, когда группа безопасности допускает доступ со всех портов
• Какие группы безопасности определены, но не связаны ни с каким ресурсом?
• Уведомить меня, когда будет произведен доступ к консоли с внешнего для организации IP-адреса
• Уведомить меня, когда будет зафиксирован User Agent, типичный для web-атак
• Когда превышаются ресурсы конкретного инстанса на X%?

Некоторые SIEM, специально разработанные для корпоративной сети, могут иметь архитектурные проблемы с облаками. Вам, как минимум, надо будет открыть на периметровом МСЭ ряд правил для всех ваших облачных систем, отдающих логи в ваш SIEM. Еще одной проблемой, и более серьезной, является тот факт, что наличие коннекторов для работы с облаками, еще не означает, что SIEM готов к использованию в этой роли. Если мы обратим внимание на упомянутых в начале 6 компонентов системы мониторинга, то окажется, что коннектор к SIEM помогает вам решить две необходимых, но явно недостаточных задачи, — сбор и обработку событий ИБ. Хранение обеспечивается самим SIEM, а вот с анализ у нас остается под большим вопросом. Если у обычного корпоративного SIEM соотношение действительно полезных и работающих правил корреляции “из коробки” к общему их числу составляет 20 к 80, то для мониторинга облачной ИБ это соотношение будет где-то 5 к 95, а то и меньше. Поэтому не стоит забывать, что наличие SIEM, работающей с облаками, — это еще не все, что нужно для мониторинга их реальной безопасности. Вам потребуется гораздо больше усилий (не говоря уже о квалифицированном персонале) по написанию правил корреляции событий для вашего облака, для ваших облаков, а также для облаков и корпоративной среды (ведь вы наверняка захотите коррелировать данные о местонахождении пользователя, подключившегося к облачной платформе, с данными корпоративных средств защиты).

Если с мониторингом IaaS/PaaS ситуация обстоит более менее хорошо — число источников, объем создаваемых логов и типы событий достаточны для их анализа, то у многих SaaS это все еще вызывает сложности. Поэтому хочу обратить внимание на следующие активности/события, которые доступны у большинства серьезных SaaS-игроков и которые необходимо анализировать в вашем SIEM при мониторинге SaaS:

• Доступ пользователей и администраторов
  • Удачные и неудачные попытки входа
  • Время и место входа
  • Тип и атрибуты устройства входа
  • Неудачные попытки входа, за которыми последовала удачная
  • SSO-активность
  • AD-активность
• Поведение пользователей
  • Файловая активность пользователей (скачивание, удаление, копирование, печать, перенос, отправка)
  • “Расшаривание” файлов с внешними и внутренними пользователями
  • Создание открытых/разделяемых ссылок
  • Активность с неавторизованных/недоверенных мобильных устройств
  • Сетевая активность
• Доступ третьих лиц по API
  • Изменения в привилегиях по использованию API
  • Активность, связанная с сертификатом OAuth
  • Активность, связанная с токеном OAuth.

Как минимум, анализ этих событий, которые отдаст вам, например, Salesforce.com, Box или Dropbox, позволят выявлять большое число инцидентов с вашими облачными данными и пользователями.

Чем объяснить такой разрыв в возможностях по мониторингу корпоративных и облачных сред с помощью SIEM? Слабой распространенностью облаков? Мы понимаем, что это не так. Скорее вопрос в зрелости заказчиков, которые уже готовы к облакам, но не готовы к мониторингу их безопасности, о чем я писал в самом начале статьи. А без этого не набирается нужного количества бизнес-кейсов и разработчики SIEM не спешат по своей инициативе внедрять поддержку облаков в свои продукты; особенно в условиях регулярного изменения механизмов работы и отдачи событий безопасности у облачных провайдеров (вспомним историю с AzLog у Azure).

Что делать, когда у вашего провайдера нет инструментов мониторинга

А что если у вашего облачного провайдера есть логи, но нет собственных инструментов их анализа и мониторинга, ваш SIEM не поддерживает выбранное вами облако и возможности написать коннектор к нему нет? Есть вариант, который позволяет использовать специализированных посредников, которые используя имеющийся облачный API (он должен быть) получают доступ к вашему облачному провайдеру и затем, вытягивают из него логи, применяют к ним различные аналитические инструменты, выявляя различные инциденты и иные нарушения, данные о которых затем могут быть отданы в ваш SIEM.

Примерами таких посредников являются либо решения класса Cloud Access Security Broker, CASB (например, Cisco CloudLock), либо некоторые решения класса Multi-Factor Authentication, MFA с продвинутыми возможностями по контролю доступа (например, Cisco Duo). Правда, CASB или MFA, решая одну проблему, добавляют другую — получение еще одной консоли управления, которую необходимо интегрировать в ваш SOC. Но решить эту проблему обычно попроще. SIEM, часто не имея коннектора к облаку, умеют работать со средствами ИБ, включая CASB и MFA (все-таки это их основная задача). В этом случае помогают API в CASB и MFA, которые позволяют отдавать собранные и проанализированные события безопасности в корпоративные SIEM и встраивать их в ваши SOC. Получается трехзвенная система, в которой SIEM, не имеющий интегрироваться с облаком напрямую, использует для этого CASB/MFA (в вышеописанном случае с Cisco Stealthwatch Cloud та же история).

Правда, CASB тоже не панацея. Далеко не все облачные провайдеры имеют в своих платформах API, которые позволяют отдавать данные в корпоративные SOC и SIEM. Обычно именно этот признак выделяет корпоративные решения. Иногда даже у популярных облачных решений таких API нет, как можно было увидеть в самом начале, когда я упоминал Битрикс, “Мой офис” или решения СКБ Контур.

Пример: Мониторинг ИБ с помощью Cisco CloudLock

Cisco CloudLock ^[2] — это базирующееся на API решение, которое интегрируется с широким спектром существующих популярных облачных SaaS-платформ, таких как G Suite, Salesforce, Office 365, Dropbox, Box, ServiceNow, Slack, Okta и др., а также с IaaS/PaaS-платформами, такими как Salesforce и AWS. В отличие от проксирующих CASB, решение на базе API позволяет работать с данными, которые уже загружены в облако, анализировать межоблачный трафик, контролировать доступ с мобильных и неуправляемых корпоративных и личных устройств. При этом Cisco CloudLock, который постепенно становится составной частью Cisco Umbrella ^[3], не вмешивается в работу пользователя и подключается к контролируемым облакам за счет имеющегося у них API, который позволяет отслеживать такие нарушения, как:

• подбор пароля
• вход с нетипичного местоположения (кража учетной записи)

  

• нарушение правил работы с конфиденциальной информацией (хранение в облаке информации, которая не должна там находиться)

  

• вредоносное ПО в облаке
• утечка данных

  

• нарушение требований нормативных актов
• доступ с запрещенных или просроченных приложений.

  

Доступ к этим инцидентам возможен как из самого сервиса Cisco CloudLock, так и через SIEM, в которые CloudLock отдает необходимую информацию, через имеющийся API. На текущий момент Cisco CloudLock может интегрироваться с Splunk, QRadar и Arcsight.

SOC

Итак, мы получили некоторое представление о том, как устроен мониторинг ИБ в популярных в России облачных средах. Теперь вы понимаете, какие данные и как вы можете загрузить к себе в SIEM. Но значит ли это, что вы можете говорить о выстроенной системе мониторинга ИБ облаков? Конечно же нет. Достаточно вспомнить, что согласно популярной, но не совсем верной концепции, SOC — это комбинация людей, процессов и технологий. Мы же выше говорили только о технологиях. Настало время немножко поговорить и о других компонентах.

Начнем с того, что сегодня облачный мир не имеет явного фаворита и лидера. Для разных задач компании используют разные облака. Выше я приводил пример Cisco, которая в своей деятельности использует около 700 облачных провайдеров по миру. И все они разные, с разными подходами к обеспечению ИБ и ее мониторингу. Чтобы интегрировать их все в наш центр мониторинга ИБ, необходимо посмотреть за пределы способов загрузки данных в SIEM и выстроить полноценную мультиоблачную стратегию мониторинга, в которой состоит обязательно предусмотреть следующие этапы:

1. Определение сценариев, которые мы планируем отслеживать в наших облаках (разработка use case). Посмотрите выше пример с use case для Splunk. Таких сценариев у вас может быть несколько десятков, а может и сотен. Большинство из них не будет отличаться от тех, что вы используете в корпоративной сети, но какие-то булут иметь ярко выраженный облачный “привкус”. Например, хотите ли вы отслеживать доступ сотрудников облачного провайдера к вашим данным и ресурсам? Внутри вашей инфраструктуры такого use case быть не может. А вот контроль доступа привилегированных пользователей — сценарий одинаковый и для внутренней сети, и для облака.

   

2. Обновление процессов мониторинга ИБ и разработка соответствующих playbook’ов и runbook’ов, учитывающих облачную специфику.
3. Идентификация данных, которые нужны для наших use case, и мест их нахождения. Тут нам понадобятся знания о вашем облаке или облаках, примерно такие, как были описаны выше в статье. Тот же Amazon выделяет три так называемых домена инцидентов — сервисный (инциденты в этом домене воздействуют на учетные записи пользователей, биллинг, метаданные ресурсов и т.п.), инфраструктурный (эти инциденты затрагивают данные и сетевую активность, например, трафик Amazon EC2 в VPC) и прикладной (инциденты, связанные с ПО, размещенном в облаке). В зависимости от того, какой из доменов для вас имеет больший приоритет, вы будете выбирать разные источники данных для мониторинга.
4. Определение инструментария, который позволит вам собирать, обрабатывать, обогащать и анализировать данные, а также реагировать на них и строить отчеты по результатам анализа.
5. Определение индикаторов, которые позволят выявлять случившиеся инциденты или готовящиеся атаки. Эти индикаторы могут быть найдены в логах вашего облачного провайдера, в информации биллинга, в данных Threat Intelligence, получаемых об облачного провайдера или извне, в партнерских инструментах, доступных в вашем облаке (тот же Cisco Stealthwatch Cloud), у поддержки облачного провайдера (например, служба техподдержки Amazon Web Services может уведомлять вас об обнаруженной ими подозрительной активности), от ваших клиентов или партнеров, сообщивших вам о чем-то подозрительном. Для каждого из этих источников вам понадобится описать свои регламенты взаимодействия и работы с ними.
6. Обучение персонала или привлечение аутсорсинговой компании, которая возьмется для нас за мониторинг наших облаков.
7. Регистрации нужных данных, для чего вы можете обойтись только встроенными возможностями, предоставленными облачным провайдером, или вам надо будет посмотреть в сторону какого-либо внешнего решения. Это может быть как коммерческое решение, так и какой-нибудь бесплатный osquery.
8. Обеспечение целостности данных мониторинга на стороне облачного провайдера, путем настройки соответствующих прав доступа к ним (например, по принципу WORM — Write Once, Read Many), использования специализированных сервисов по шифрованию данных (например, AWS Key Management System) или выгрузки во внешнее защищенное хранилище (например, Amazon S3 Glacier).
9. Обогащение данных контекстом, например, от сервисов Threat Intelligence, которые могут быть как предоставленными самим облаком (например, GCP или Azure), так и внешними. В последнем случае вам придется решить вопрос с тем, где будет происходить процесс обогащения. Скорее всего, вы уже не сможете ограничиться встроенными возможностями по анализу событий, которые вам предоставляет ваш поставщик услуг.
10. Анализ собранных данных с помощью встроенных возможностей облака или с помощью вашей системы анализа (SIEM), в том числе и с применением дополнительных посредников типа CASB или облачного NTA (например, Cisco Stealthwatch Cloud).

    

11. Threat Hunting, то есть проведение ручного расследования ситуаций, которые вызывают подозрения и для которых используемый инструментарий не предоставил достаточных данных. Это, кстати, еще одна непростая тема — как проводить расследование инцидентов в облачных средах. Мы ее оставим для следующего раза.
12. Реагирование на выявленные события.

При этом стоит учитывать, что часть этих компонентов будут пересекаться с другими задачами по мониторингу, которые могут стоять перед вашей организацией — мониторингом SLA, мониторингом доступности, мониторингом производительности приложений, мониторингом использования для последующего биллинга и т.п. Поэтому выстраивая систему мониторинга ИБ вашего облака, сначала уточните, что уже сделано, а что планируется делать вашими коллегами из других подразделений — возможно вам удастся воспользоваться уже сделанными наработками или инструментарием или разделить ряд задач с другими.

Вроде как ничего особенного и нового я не написал. Если ваш SOC спроектирован правильно изначально, то добавление любой новой контролируемой сущности (будь то облако, АСУ ТП или мобильные устройства), не должно приводить к сильной переделке ранее разработанных документов и процессов. Мы когда проектируем SOCи или проводим их аудит стараемся изначально учесть все эти аспекты в своей работе.

Заключение

Резюмируя, стоит вновь повторить, что мониторинг ИБ облачных сред — это тема относительно новая даже для “старичков” облачного рынка. Поэтому в этом сегменте постоянно происходят изменения и то, что еще недавно было невозможно, появляется в портфолио облачного провайдера. Это же относится и к функциям по мониторингу ИБ. Независимо от того, о каком из провайдеров мы говорим, они могут вам предоставить один из нескольких вариантов мониторинга:

• Просмотр сырых данных через панель управления облаком — ни на какую аналитику ИБ в этом случае вам рассчитывать не приходится.
• Регулярная выгрузка сырых данных к себе для последующей загрузки в свой SIEM или иную систему анализа событий ИБ. В этом случае все зависит от того, насколько ваша система анализа “понимает” загружаемые в нее события и имеет соответствующие правила для анализа/корреляции.
• Доступ через API, позволяющий непрерывно “вытягивать” данные из вашего облака в вашу систему анализа. От предыдущего варианта данный отличается только оперативностью мониторинга.
• Анализ событий безопасности с помощью встроенных аналитических инструментов безопасности облачного провайдера.
• Доступ через посредников, которые собирают данные интересующего вас облака, обогащают их дополнительными сведениями и применяют различные аналитические инструменты и алгоритмы, после чего отдают результат анализа в ваш SIEM или систему анализа событий ИБ.

Все эти пять варианто отличаются по сложности работы с ними, цене и оперативности мониторинга и реагирования. Какой из них выбрать, я сказать не могу, так как это очень сильно зависит не только от того, с каким облаком вы работаете, но и какова ваша стратегия мониторинга. ИБ. Могу только помочь со списком вопросов, которые стоит задать себе и своему облачному провайдеру, с которым вы решите “связать свою жизнь”:

• Вы работаете/планируете работать с одним облаком или с несколькими?
• Какие механизмы защиты предлагает ваш облачный провайдер? От этого зависит, что вы можете мониторить, а что нет.
• У вашего провайдера есть сертификация ISO 27001, Fed-RAMP, SOC2/3? Это может служить неким подтверждением того, что какие-то механизмы регистрации событий и мониторинга ИБ провайдер все-таки обеспечивает.
• Какие события и в каком формате их отдает ваш облачный провайдер? Не по всем защитным механизмам могут быть журналы регистрации и не все форматы поддерживает используемая вами сейчас система анализа.
• Что пишется в журналы регистрации? Какие поля в них присутствуют и есть ли подробное их описание (желательно с примерами кода)?
• Возможность доступа к логам включена в купленную/покупаемую вами лицензию? Как было видно выше, многие функции по мониторингу или расширенной аналитике ИБ доступны только за дополнительные деньги, что увеличивает совокупную стоимость владения облаком.
• Какие возможности по мониторингу ИБ есть у вашего провайдера? Он только собирает логи или может выявлять в них события безопасности? Он имеет возможность корреляции событий ИБ? Он обеспечивает возможность threat hunting? Он имеет интеграцию с каким-либо источником Threat Intelligence?
• Как долго ваш провайдер хранит логи? Какие возможности по долгосрочному хранению логов предоставляет/рекомендует провайдер?
• Есть ли у вашего провайдера API для доступа к событиям?
• Ваш SIEM работает с вашим облаком по умолчанию? Какие логи/API он поддерживает (все или только часть)?
• Как коррелируются “облачные” события в вашей SIEM? Есть уже предопределенные правила корреляции или use case для вашего облака или их придется писать самому?
• У вашего SIEM есть возможность написать свой коннектор? Кто его пишет — вы или производитель SIEM?
• Ваш SIEM может работать с CASB?
• Ваш SIEM имеет TI-источники по облачным угрозам?

Вот небольшой список вопросов, ответы на которые позволят вам начать выстраивать процесс мониторинга ИБ облачных сред, которые решили использовать вы или ваш бизнес. Чем раньше вы поинтересуетесь ответами на эти вопросы, тем дешевле вам обойдется выстраивание системы мониторинга и тем меньше инцидентов будет происходить с вашими ресурсами, отданными внешним облачным провайдерам. Как показывает опыт Cisco по построению или аудиту SOC, даже самые успешные центры мониторинга ИБ, эффективно справляющиеся с инцидентами внутри корпоративной сети, не всегда заранее закладывают в свою архитектуру возможности по мониторингу облаков, что приводит к необходимости ее перестройки. Надеюсь описанные в этих двух частях наблюдения и рекомендации помогут в обеспечении кибербезопасности.

Автор: Алексей Лукацкий

Источник ^[4]