Продолжаем цикл «Будущее архитектуры безопасности». В прошлой публикации мы разобрались, зачем компаниям вообще смотреть в сторону Cybersecurity Mesh Architecture (CSMA): сетчатый подход помогает связать разрозненные средства защиты в работающую систему и снизить зависимость от «зоопарка» инструментов.

В этой части опустимся на землю и разберём что именно сегодня сломано в типовой архитектуре ИБ: почему сигналы не доходят до точек принятия решений, откуда берутся фрагментированные политики, ручные корреляции, разношёрстные консоли и растущий технический долг. На этом фоне покажем, как CSMA адресует каждый из этих болей через пять уровней - от интеллектуальной аналитики безопасности (SAIL) до централизованной политики и операционных дашбордов.

Стартуем с ключевого слоя - SAIL: чем он отличается от привычных SIEM/XDR, какую роль играют стандарты (OCSF, CAEP), и как единая модель рисков переводит защиту из реакции в упреждение.

Архитектура

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

1. Управление политиками является фрагментированным и, следовательно, менее эффективным и сложным в администрировании и аудите.
   

2. Централизованной базы данных угроз нет, если только вы ее не создаёте самостоятельно, чего я на протяжении всей своей карьеры не наблюдал.

3. Неэффективная и, зачастую, ручная корреляция между несколькими инструментами реагирования на инциденты.

4. Способы устранения неполадок являются слишком ручными и непоследовательными, включая неправильную настройку и отсутствие элементов управления. Это приводит к ошибкам, когда интеграция является неполной или вообще отсутствует.

5. У разных поставщиков разные консоли управления, инфраструктура, хранилища данных, агенты, отчеты и языки сценариев, для управления которыми требуется специалист.

6. Все точечные решения требуют определенного уровня административных знаний или навыков, если не на уровне инфраструктуры, то, по крайней мере, на уровне конфигурации.

7. Технический долг, связанный с наличием слишком большого количества плохо интегрированных средств обеспечения безопасности, является операционным бременем.

Пять уровней CSMA

CSMA состоит из пяти уровней, которые помогают решать задачи, перечисленные выше:

1. Интеллектуальный уровень аналитики безопасности (SAIL)

2. Уровень управления инфраструктурой

3. Identity fabric layer

4. Уровень централизованного управления политикой, состояние устройства и плейбуками (PPPM)

5. Уровень операционных DashBoard

Интеллектуальный уровень аналитики безопасности (SAIL)

Сегодня многие организации полагаются на централизованную обработку данных об угрозах,
SIEM и, возможно, SOAR, а также аналитику поведения пользователей и организаций (UEBA). Проблема в том, что при этом генерируется много данных, и большая их часть не нужна для защиты. Принципы, лежащие в основе CSMA, предписывают использование скоринговых расчетов для определения общего риска, что позволяет принимать упреждающие меры на основе тенденций и скоординированных выводов о рисках с помощью инструментов архитектуры (см. рисунок ниже). Для выполнения функций, требуемых принципами CSMA, продукты SAIL должны обладать следующими характеристиками:

1. Стандарты или функции нормализации для преобразования используемых данных о действиях и контексте, а также вызовов API в общую структуру, доступную для всех других компонентов. К ним относятся:

• Каталог готовых коннекторов (out of the box OOTB) для подключения к другим решениям безопасности.

• Возможность подключаться к соответствующим корпоративным пулам/хранилищам данных или другим бизнес-каналам и использовать их для повышения безопасности аномальных событий.

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

2. Возможность создания классификатора, который записывает источник данных, помечает и классифицирует данные на основе типа и функции. Это включает:

• Функции обнаружения, которые идентифицируют ВСЕ активы (такие как конечные точки,приложения и сети), чтобы их можно было представить в цифровом виде при моделировании рисков, где мы используем агрегированные оценки рисков, сигналы, индикаторы компрометации (IOCs), аналитику угроз (TI) и инциденты, собранные с помощью точечных инструментов.

3.Механизм оценки рисков, который динамически вычисляет показатели риска для поведения, активности, истории и критичности. Это многоуровневый механизм, который включает:

• Поддержка нескольких форм управления рисками (централизованного, распределенного и федеративного).

• Несколько моделей управления рисками, каждая из которых настроена для выявления определенных категорий рисков. Уровень SAIL должен учиться и адаптироваться к изменениям в окружающей среде и ландшафте угроз.

• Централизованная функциональность для сбора оценок рисков, сигналов, IoC, аналитических данных об угрозах и инцидентах из продуктов point для их проверки с
  целью уменьшения ложных срабатываний и ложноотрицательных результатов. Снижение уровня “шума” оповещений является ключевой задачей.

4. Возможность идентификации целей, которая определяет наиболее вероятные направления деятельности. Это позволит реализовать следующее:

• Используйте исторические цепочки тактик, методов и процедур (TTP) и MITRE для определения целей.

• Определите доступные меры по смягчению последствий, которые у Вас есть, чтобы разорвать цепочку атак

5. Функция реагирования, которая создает предлагаемые ответные действия на основе доступных API (или, в будущем, модельного контекстного протокола [MCP]). Это включает:

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

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

6. Аналитический подход, основанный на фактических данных, который помогает количественно оценить ситуацию с угрозами в конкретной организации, а затем помогает Компании выполнять конкретный план по снижению ее подверженности угрозам и, следовательно, повышению отказоустойчивости. Это включает в себя определение способов уменьшения подверженности атакам путем определения категорий изменений в политиках доступа.

7. Базовая модель структуры данных для обеспечения безопасности и идентификации. Обратите внимание, что для этого не требуется объединять все данные в единое хранилище данных. Для этого требуется доступ к нужным данным в нужное время.

Новый подход в CSMA

• Состязательная разведка - это концепция изолированного цифрового двойника вашей
  среды, в котором темный ИИ (ИИ, который не связан этическими нормами и получает информацию об угрозах из таких источников, как dark web) имитирует атаки на вашу среду. Это похоже на то, что делают поставщики cyberrange сегодня. Затем результаты отправляются в реальном времени с помощью SAIL в ядро системы безопасности, чтобы определить дополнительные пути возможных атак. В настоящее время только поставщики cyberrange являются примерами того, как начать использовать эту функцию.

• Безопасность ИИ необходима, поскольку Компании будут допускать большую автоматизацию через ИИ в SAIL. Эта функция дает организациям уверенность в том, что модели ИИ и принимаемые на их основе решения безопасны для бизнеса и ИТ-инфраструктуры организации. Это также значительно снизит риск повреждения модели со стороны инсайдеров.

• Модели рисков, основанная на рисках из более низких сред, таких как dev, test and preproduction, являются важными сигналами о том, что SAIL необходим для моделирования уровня риска новых сервисов, переходящих в production. Эти проверки низших сред (такие как статическое тестирование безопасности приложений [SAST], динамическое тестирование безопасности приложений [DAST] и другие проверки безопасности приложений) помогут обеспечить соблюдение минимальных политик безопасности до того, как объекты будут запущены в эксплуатацию.

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

Ключевая особенность этого уровня заключается в его способности получать поведенческие сигналы (как исходные, так и оповещения от других инструментов) из множества различных продуктов и применять матрицу оценки рисков на основе взаимосвязей. Это позволит получать различные типы прогнозов и точек принятия решений. Критические сигналы - это те, при которых объект ведет себя ненормально, и затем они проверяются по внешним каналам, таким как:

• Help desk for device fails.

• Travel systems for impossible logins.

• HR for insider risk

• News

• Finance feeds for other anomalous behavior

Этот уровень является развитием того, что сегодня делают поставщики SIEM, SOAR, UEBA и XDR. Эта система динамического подсчета рейтинга доверия позволяет этому уровню инициировать защитные действия до того, как произойдет атака. Чтобы обеспечить ввод данных в сетку, события, оценки и результаты, полученные с помощью отдельных инструментов, должны обрабатываться на уровне нормализации. Эти сигналы должны охватывать множество объектов и ресурсов, включая:

• Люди (например, сотрудники, подрядчики, партнеры, клиенты).

• Машины (например, устройства и рабочие нагрузки, такие как приложения и службы).

• Сети, к которым имеется доступ.

• Устройства (например, тип, операционная система, уровень доверия и местоположение).

• Киберфизические системы (CPS), которые включают в себя IoT, OT и IIoT-управление доступом в Интернет

• Местоположения источников IP-адресов Интернета в течение жизненного цикла (например, действительные, поддельные и заведомо неверные IP-адреса)

• Источники данных и хранилища

• Сторонние сервисы

• Облако (например, SaaS, IaaS и PaaS)

• Приложения

• Физический контроль доступа

• Цепочка поставок

• Криптография (например, PKI, ключи, секреты)

• Информация о местоположении

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

Давайте рассмотрим сценарий, в котором глобальный администратор вашей компании подвергается атаке на многих фронтах с использованием различных тактик, и посмотрим, как может отреагировать сеть. Злоумышленники запускают следующий набор целенаправленных атак:

• Многоканальные фишинговые атаки по электронной почте, мобильным каналам связи, каналам голосовой связи, каналам совместной работы и системам видеозвонков.

• DeepFakes, созданные с помощью искусственного интеллекта.

• Атака методом перебора или по словарю на вашу службу каталогов с попыткой входа в систему в качестве глобального администратора

• Распределенный отказ в обслуживании (DDoS) - маскировка, скрывающая реальную цель атаки.

• Атаки программ-вымогателей на уровне устройств, как на мобильные устройства пользователя, так и на ноутбуки.

Теперь давайте предположим, что отдельные продукты security point сохранили свою собственную оценку для того типа ресурсов, которые они поддерживают (например, оценку для пользователя, устройства или облачного приложения). Точечные продукты также могут анализировать установленные закономерности и выявлять отклонения от нормы или обнаруживать то, что может выглядеть как признак компрометации.
Отдельные продукты уведомляли бы уровень аналитики о своих результатах, которые затем были бы нормализованы. Затем CSMA на своем уровне аналитики увидела бы, что общие показатели риска увеличиваются, и могла бы активно инициировать согласование с конкретными продуктами. Это предотвратит любой ущерб или отправит администратору высокоприоритетное предупреждение для дальнейшего расследования, в зависимости от уровня риска и политики.

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

Инструменты анализа безопасности, такие как SIEM и XDR, нуждаются в совершенствовании, чтобы они были последовательно настроены для обнаружения атак на ранних этапах процесса, блокируя доступ до или вскоре после совершения атаки.

Инструменты безопасности в целом также должны продолжать совершенствоваться для выявления несоответствий и пробелов в конфигурациях безопасности .

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

Мы уже наблюдаем некоторые примеры этого. Например, инструменты cloud security posture management (CSPM), SaaS security posture management (SSPM) и cloud infrastructure entitlement management (CIEM) могут предлагать изменения в конфигурации политик.

Необходимо совершенствовать инструменты для поддержки более глубокого обмена сигналами тревоги (используя все еще формирующиеся стандарты, такие как Профиль оценки непрерывного доступа [CAEP]), чтобы при обнаружении пробела больше инструментов могли автоматически адаптироваться совместно для устранения этого пробела.

Концепция зональной защиты также является новой для архитектуры CSMA. Ключевым моментом здесь является то, что организации могут иметь множество операционных групп в ИТ и в бизнесе, которые защищают различные объекты или группы объектов. Зона является логической границей, помогающей SAIL определить, что подвергается атаке - будь то вся организация или ее части. Преимуществом понимания этих зон является автоматизация рекомендуемых действий по блокированию. Это позволяет SAIL настраивать автоматизацию защитных блокировок на более детальном уровне. На рисунке показаны некоторые примеры типов зон, которые могут быть определены в вашей организации.

Продукты безопасности, соответствующие требованиям CSMA

При оценке существующих и будущих продуктов security point аналитические и консалтинговые компании рекомендует определить их соответствие требованиям стандарта CSMA. Соответствуют ли они таким стандартам, как OCSF и MITRE ATT&CK, с точки зрения взаимодействия с другими поставщиками, совместимыми с CSMA? На какой версии архитектуры они работают в настоящее время? Каков их план действий в отношении будущих функций CSMA? Согласованы ли они с другими крупными поставщиками в экосистеме CSMA?

Ключевым моментом для этих унифицированных продуктов безопасности является возможность подключения к вашему основному поставщику, что обеспечивает возможности SAIL и помогает автоматизировать защиту во время атаки. Более совершенные продукты должны обеспечивать двунаправленную связь с SAIL. Это важно для понимания изменений в поведении, происходящих практически в режиме реального времени, чтобы SAIL мог обрабатывать цепочки атак и сопоставлять шаблоны. Внедрение таких стандартов, как OCSF и MITRE ATT&CK, имеет решающее значение для интеграции продуктов point с вашим поставщиком SAIL и передачи им сигналов.

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

Вместо заключения

Текущая реальность ИБ - это фрагментированные продукты, ручные связки и «шумные» алерты. SIEM/XDR важны, но в одиночку не закрывают разрыв между сигналами и решениями. CSMA даёт системный способ собрать разрозненные средства в согласованную архитектуру: общий язык данных и идентичности, централизованная аналитика (SAIL), единые политики и управляемая автоматизация ответа. Это не «ещё одна коробка», а эволюционная модель, которая позволяет переводить защиту из реакции в упреждение.

Что делать дальше

1. Инвентаризировать средства защиты, источники телеметрии и точки принятия решений; зафиксировать «боли» (политики, корреляция, дублирующие агенты).

2. Спроектировать зонирование (бизнес- и техзоны) и карту зависимостей: где какие сигналы нужны по факту.

3. Определить «ядро» аналитики (SAIL) и требования к интеграциям: поддержка OCSF/CAEP, MITRE ATT&CK, двусторонние API.

4. Внедрить нормализацию данных и шину событий как обязательный слой (до единого хранилища не обязательно).

5. Запустить пилоты адаптивного доступа/реагирования на 1–2 критичных сценариях (например, компрометация админа, эксфильтрация данных).

6. Ввести метрики CSMA: снижение шума алертов, MTTD/MTTR, доля автоматических ответов, покрытие зон, воспроизводимость плейбуков.

Дальше в цикле разберём каждый уровень CSMA и практические паттерны внедрения. Вопросы и кейсы приветствуются.

Кому интересно - присоединяйтесь в Telegram-канал https://t.me/zero_trust_SDP.