В чем плюс безопасности из облака?

Существует несколько видов облачных сервисов безопасности из облака

• Облачная защита: WAF, Anti-DDoS, когда атакующий трафик даже не доходит до ресурсов вашей компании, а чистится где-то в облаке;
• Внешний Security Operation Center (SOC), когда вы можете отправлять события безопасности в сервисную компанию в облаке и она будет выявлять инциденты и оповещать вас;
• Managed Detection and Response (MDR) - это тот же внешний SOC в задачу которого входит еще и реагировать на найденные инциденты;
• Облачная защита сотрудников и офисов от угроз, реализованная в облаке в виде внешнего сервиса Secure Access Service Edge (SASE) включающего в себя защиту и собственных облачных ресурсов через Cloud Access Service Broker (CASB), что для многих выглядит как защита все-в-одном работающая облаке в некоторой точке в любой стране, к которой сотрудник или офис подключается по VPN или через прокси-сервер и через этот облачный фильтр потребляем ресурсы Интернет и собственные ресурсы компании;
• Система хранения и обработки событий в облаке (Data Lake, XDR, SIEM, UEBA) когда вы не готовы хранить свои же события и когда вы не готовы администрировать средства защиты - здесь за размер и доступность хранилища и за работоспособность продуктов ИБ отвечает внешний поставщик - вы просто пользуетесь. В общем Security as a service по модели Software as a service. Сплошной SecaaS.

Первое замечательное свойство всех этих облачных сервисов:

- внешний SOC, SASE, MDR всегда может переварить больше событий, больше очистить трафика, чем куплено. Это даже вписывают в SLA. На собственном SIEM или NGFW эти события или трафик просто будут удалены по причине физической невозможности обработки данного трафика. Вы прекращаете битвы с поставщиками оборудования за то, что вам привезли NGFW не той модели или SIEM или DLP не тянут нагрузки. В облаке автоматически масштабируется нагрузка.

Второе свойство, которое может понравиться:

- это сервис, который уходит в OPEX и можно его поменять и гибко масштабировать.
Пример: Если вчера 1% сотрудников были дома и пользовались имеющимся VPN, а завтра надо чтобы все 100% остались дома и подключились по VPN - вам не надо спешно докупать новых 100 VPN шлюзов - вы просто доплачиваете за подписку!

Какие трудности переживает сейчас любой SOC

Какие трудности переживает сейчас любой SOC, включая ГосСОПКУ?

• мало сотрудников
• много событий
• мало времени на расследование и тем более Threat Hunting
• много утилит, что скорее плохо, чем хорошо, между ними нет интеграции.

По данным уже расследованных взломов обнаружение факта что вас взломали происходит через 2-6 месяцев после взлома и это при наличии в крупных компаний таких передовых продуктов, как EDR,  UEBA, NTA, SOAR и других.

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

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

На диаграмме ниже показано как раскрывает причинно-следственную связь продукт XDR компании Palo Alto Networks. По сути он разворачивает последовательность действий, которые предшествовали обнаружению и блокированию атаки. Если вы увидели, например, событие что локальная защита заблокировала вирус и затем попросили продукт рассказать историю, то на экране появляется картинка что же было до того как случилось. И это можно сделать нажатием одной кнопки, а не блужданием по всем утилитам и логам, что есть в компании. В данном случае - человек получил фишинговое письмо и кликнул на ссылку в нем:

Но у всего есть цена. Такое быстрое расследование инцидентов возможно, если все события заранее собирались и заранее сопоставлялись друг с другом. Ведь по-сути на экране набор совершенно нормальных событий - работа браузера, работа архиватора, работа скриптов. И только в совокупности эти события представляют собой угрозу, а по отдельности - нет.

Сколько нужно места, чтобы хранить эту всю информацию до того момента как она понадобится. Вот что сказали сотрудники исследовательской лаборатории Palo Alto Networks, приехавшие из Тель-Авива: "Для хранения событий 200 рабочих станций выделяется 1 террабайт на 1 месяц в Cortex Data Lake". А поскольку компании сейчас гораздо крупнее и распределены по всему миру, то можно представить что места требуются уже даже не террабайты, а петабайты. 

Единственным адекватным решением, которое сегодня видят разработчики - использовать для хранения журналов и событий облачные хранилища, предоставляемые крупными провайдерами: Google Cloud, Microsoft Azure, Amazon AWS и другие. Компания Palo Alto Networks предоставляет такое хранилище для журналов NGFW, UEBA, NTA, EDR/AET, облачных приложений под торговой маркой Cortex Data Lake. И на основе этого хранилища можно реализовать различные аналитические решения, как например было реализовано решение Cortex XDR.

Особенностью аналитики XDR, является то, что события анализируются поведенческими правилами, созданными на основе опыта реальных сотрудников, которые много лет расследуют инциденты и они заложили в поведенческие индикаторы (BIOC) свой опыт, которые позволяет по косвенным признакам распознать, что начинается взлом компании. Также вы можете заложить и свой опыт создав такие правила в самом интерфейсе продукта. 

Одновременно в мире идет работа над способами обмена информацией о расследованных инцидентах и индикаторами атак, которые уже были совершены. Для этого компании составляют Playbook действий хакеров и делятся друг с другом, например, лаборатория UNIT42 компании Palo Alto Networks свои исследования выкладывает тут https://pan-unit42.github.io/playbook_viewer/

Методики работы атакующих записываются в специальных TTP, что означает Tactics, Techniques, Procedures. И даже по набору TTP можно различать этих атакующих и можно отличать даже что за кампанию они сейчас развернули и на кого она нацелена.

И одновременно продукты безопасности встраивают в себя алгоритмы обмена и проверки таких индикаторов атак. Примерами таких стандартов обмена являются:

• TAXII™ = Trusted Automated eXchange of Indicator Information
• STIX™ = Structured Threat Information eXpression
• СybOX™ = Cyber Observable eXpression

Существует глобальная база TTP - MITRE ATT&CK  и по ней ваши blue и read team могут проверять готовность компании противостоять описанным методикам и техникам взлома.

Недавно было проведено тестирование продуктов по безопасности, насколько эффективно они работают и по результатам всех опережает продукт TRAPS который обладает уникальными функциями защиты рабочих станций и одновременно является сенсором событий для Cortex XDR: