Полезность экосистемного подхода к кибербезопасности
Содержание:
Эпоха экосистем
Идея построения экосистем стала трендом в современной бизнес-среде. Мы можем наблюдать, как крупнейшие компании выстраивают экосистемы вокруг собственных продуктов и услуг, создавая тем самым дополнительную ценность для клиентов, а для себя – новые конкурентные преимущества. Наличие единой точки доступа к многочисленным сервисам, которые связаны между собой «бесшовно», а также более привлекательные условия использования продуктов экосистемы, нежели чем приобретение аналогичных услуг по-отдельности от других поставщиков – это действительно удобно и выгодно. При этом само по себе явление экосистем нельзя назвать новым: в России есть много всем известных компаний, которые стали развивать экосистемный подход в секторе B2C (Business to Consumer) еще несколько лет назад, а сегодня создание экосистем становится естественным этапом развития игроков на рынке B2B (Business to Business).
Экосистемы в бизнесе
Что же такое экосистема? Экосистема – это набор технологий и сервисов одной компании, которые работают как «единый организм», подпитывают и дополняют друг друга.
Если разбираться на привычных нам примерах, то экосистемы бывают внешними и внутренними. Внешние экосистемы строят как правило компании из B2C отраслей — ритейл, телеком, банки и др. К внешней экосистеме могут быть подключены как собственные сервисы, так и сервисы компаний-партнеров. Практически все мы сталкиваемся с ними в нашей повседневной жизни: при заказе такси, доставке еды и товаров, оплате услуг, планировании поездок и т. д.
Создание внутренних экосистем предполагает объединение одной компанией только своих продуктов и сервисов, чтобы предоставить клиентам максимальную функциональность в рамках единого решения. Такой подход характерен, как правило, для сегмента B2B. Яркий тому пример – отрасль информационной безопасности, где крупнейшие производители решений кибербезопасности все больше фокусируются на развитии экосистем на базе собственных технологий, стремясь обеспечить более эффективную защиту заказчиков от киберугроз.
Экосистемы кибербезопасности
Развитию экосистем в отрасли информационной безопасности способствовало не столько веяние высокотехнологичной моды, сколько вызовы нового времени: в условиях постоянного нарастания компьютерных угроз компании нуждаются в комплексном и стратегически продуманном подходе к построению центров мониторинга информационной безопасности (Security Operation Center, SOC) и обеспечению эффективной защиты. Такой подход основан на решении ряда разноплановых задач кибербезопасности с помощью тесной взаимосвязи различных технологий и выстроенных между ними процессов. Поэтому рынок планомерно движется к появлению экосистем, на базе которых можно обеспечивать комплексное управление процессами ИБ.
В настоящий момент есть разные подходы к тому, по какому принципу строятся экосистемы кибербезопасности и что входит в это понятие на самом деле. Опираясь на практику нашей компании в создании экосистемы, я продемонстрирую на реальных примерах разницу между применением экосистемного подхода и использованием набора ИБ-продуктов от различных вендоров в процессах SOC. И, очертив грань между этими двумя понятиями, отвечу, пожалуй, на самый главный вопрос читателей: какое преимущество получают компании, выбрав экосистемы для обеспечения кибербезопасности своего предприятия?
Набор продуктов vs Экосистема
Ниже на рисунке предоставлен перечень ключевых продуктов и технологий, лежащих в основе любого SOC.
При классическом подходе каждый из этих продуктов на своем этапе защиты выполняет конкретную функцию, в то время как при экосистемном подходе все эти технологии глубоко интегрированы между собой и работают как «единый организм», дополняя и обогащая друг друга.
Далее будут приведены примеры процессов SOC на базе представленных выше технологий с учетом их различных взаимосвязей. Каждый из этих примеров мы рассмотрим с точки зрения применимости к понятию экосистемного подхода.
Пример 1. Сбор инвентаризационной информации
Когда мы говорим о защите информации внутри организации, важно понимать, что конкретно необходимо защищать. Не владея этими данными, не получится эффективно решить ни одну задачу кибербезопасности: будь то реагирование на инциденты, управление уязвимостями или любой другой ИБ-процесс.
На рисунке 2 мы видим классический пример набора продуктов, где присутствуют разрозненные системы со своими датасетами и задачами. Где-то эти задачи могут пересекаться. Однако эти системы не владеют никакой информацией друг о друге и, следовательно, никак не используют возможности друг друга.
А теперь добавим в этот же пример компонент Agent, который обладает возможностями интеграции, транспарантным взаимодействием и связан с компонентом Security Asset Management. Agent и его управляющий сервер ресурсно-сервисной модели не ведет, но при этом сообщает в компонент Asset Management обо всех изменениях на хосте, как только они произошли. Тут стоит обратить внимание, что не сам Security Asset Management обратился к Agent, а именно Agent сообщил в Asset Management об изменениях.
Похоже это на экосистему? На мой взгляд да, но с большой натяжкой.
Перейдем к следующему примеру.
Пример 2. Работа Threat Intelligence
Threat Intelligence (TI) – это вспомогательный набор технологий, позволяющий с минимальными затратами повысить качество детектирования и реагирования на инциденты. При детектировании (Detect) TI дает возможность получить актуальную информацию об индикаторах компрометации (IoC) то есть о том, что нужно искать. А при реагировании на инциденты (Response) – позволяет «объяснить», чем опасны IoC, кто за ними стоит, а в некоторых случаях и то, какие цели преследует злоумышленник.
Как уже было сказано выше, в рамках этого процесса присутствуют компоненты Detect и Response, которые обращаются к одним и тем же внешним и внутренним ресурсам за одними и теми же данными: Detect – за листами IoC, Response – за контекстом по IoC. По сути, на рисунке мы видим одни и те же данные, которые нужно два раза загрузить в системы. При этом дублирование происходит на импорте данных из внешних источников. Именно поэтому, на мой взгляд, схема выше больше похожа на набор продуктов, а не на экосистему.
Рассмотрим несколько видоизмененный пример, который, как мне кажется, уже можно назвать экосистемой.
На этом этапе у нас появился компонент TI в процессах Detect, все также называющийся Internal TI-сервис. Но именно Internal TI занимается сбором индикаторов для контекста, чтобы потом из него и единого централизованного места все данные попадали в нужные системы. В нашем случае сами индикаторы компрометации попадают в Detect, а контекст в Response.
На рисунке 5 мы видим, что исчезла необходимость дублирования запросов к внешним платным сервисам. Компоненты Detect и Response взаимодействуют с единой базой знаний, а в идеальном случае еще и обогащают её TI-сработками, то есть новыми индикаторами компрометации.
Далее разберем пример обнаружения и реагирования на инциденты на конечных точках сети.
Пример 3. Реагирование с помощью EDR
Представим обычную ситуацию: произошел инцидент и на него нужно отреагировать, то есть локализовать инцидент, ликвидировать его последствия и вернуть системы к нормальной работе. Как правило, в контексте локализации и ликвидации используется инвазивное реагирование на конечном узле. Наиболее ярким примером этого процесса является работа компонента EDR (Endpoint Detection and Response). В нашем с вами случае мы имеем компонент SOAR, в котором уже находится информация о самом инциденте и о компоненте EDR, используемом для его локализации и ликвидации последствий.
Если вы когда-то сталкивались с историей SOAR/EDR, то взглянув на рисунок 6, согласитесь, что в рамках процесса реагирования нам нужно как-то донести управляющие воздействия на конечный узел. Из вводных мы имеем только агентское решение. По своему опыту могу сказать, что для этого нам необходимо повторить часть функционала EDR, а именно: подключиться к EDR, проверить есть ли на этом хосте Agent, а также проверить наличие или отсутствие задач на Endpoint, после чего дождаться своей очереди, и только потом уже создать задачу и проверять статус «до победного». И, возможно, когда-то позже мы все-таки получим результат. В целом это работает, но точно не как экосистема.
Пример на рисунке 7 еще более фантастичный – центр администрирования агента EDR не имеет интерфейса взаимодействия или взаимодействовать с ним просто странно. Для решения задачи реагирования SOAR должен иметь прямой сетевой доступ до конечного узла, чтобы, повторяя функционал EDR, дать задание агенту на узле. Очевидными минусами такого подхода являются необходимость создания «спрута», имеющего прямой сетевой доступ до каждого конечного узла в организации, и повторение функционала EDR с риском сбоев в самой консоли управления EDR.
Поэтому, конечно, это – набор продуктов.
А как в таком случае должна работать экосистема?
На рисунке 8 видно, что компонент SOAR дает задание компоненту EDR или Endpoint security. Дальше уже компонент Endpoint сообщает о статусах, проблемах и результатах. И именно из-за этой двухсторонней и по сути транспорентной интеграции представленную выше архитектуру процессов SOC мы можем назвать экосистемой.
Выводы
Разобрав несколько основных примеров, перейдем к выводам и попробуем очертить грань между набором продуктов и экосистемой. Для этого еще раз взглянем на наш первый рисунок с набором технологий, участвующих в процессах любого SOC.
На нем показан классический подход к решению ИБ-задач, при котором каждая технология на определенном этапе защиты выполняет свою конкрентную функцию. Рассмотренные примеры показывают, что где-то функционал этих технологий может пересекаться, но говорить про их взаимосвязь, как при экосистемном подходе, довольно сложно.
А теперь посмотрим, как выглядят процессы SOC, при которых технологии, участвующие в этих процессах, интегрированы между собой на каждом этапе защиты.
Повторюсь, что экосистема – набор технологий и сервисов одной компании, дополняющих друг друга. И основное отличие экосистемы от набора продуктов заключается в том, что в экосистеме присутствует интеграционный слой, который позволяет открыто и прозрачно использовать все технологии без необходимости создания функциональных колодцев в виде воспроизведения работы одного компонента другим, как это было в примере с EDR.
Как мы видим на рисунке 10, все компоненты взаимодействуют друг с другом, создавая дополнительный синергетический эффект с остальными элементами экосистемы. Все данные подгружаются в единое пространство, а работа с этими данными происходит транспарентно, прозрачно и без функциональных колодцев.
Почему экосистема – это хорошо?
Примеры, описанные выше, так или иначе уже реализуются в рамках экосистемы нашей компании. На этом рисунке можно увидеть, что практически все технологии, лежащие в ее основе, идентичны набору продуктов для управления процессами SOC.
И здесь мы подошли к главному вопросу статьи: какое преимущество получают компании, выбрав экосистемы?
На основании нашего многолетнего практического опыта, можем отметить следующие преимущества экосистемного подхода перед использованием набора отдельных продуктов:
- Все технологии экосистемы глубоко интегрированы и взаимосвязаны между собой, что позволяет решить задачи на стыке технологий, которые обычно остаются за пределами зон ответственности вендоров, и, как следствие, ложатся на инженеров Заказчика.
- За счет интеграции и тесной взаимосвязи внутри экосистемы технологии обогащают друг друга дополнительными функциональными возможностями по аналитике, детектированию, реагированию, расследованию, проведению организационных мероприятий и комплексному управлению ИБ. Чего крайне сложно добиться при интеграции продуктов нескольких вендоров.
- Экосистемный подход отличается своей гибкостью. То есть компании могут закупить и использовать лишь те технологии и в том объеме, который необходим на данном этапе и соответствует текущему уровню зрелости организации. Кроме того, экосистемы позволяют легко и безболезненно масштабироваться в будущем: поэтапно наращивать и расширять функционал SOC, дополняя его новыми технологиями по мере роста бизнеса и его потребностей. При внедрении экосистемы компании также получают долгосрочный план развития SOC и построения эффективной ИБ-защиты.
- Еще одно важное преимущество, которое сложно достичь, используя продукты разных поставщиков, – это комплексная поддержка работоспособности и связности технологий. Потому что все вопросы, связанные с эксплуатацией и развитием технологий экосистемы, решаются на стороне одного вендора. Сводятся к минимуму ситуации, при которых, например, после обновления версии одного продукта Заказчик неожиданно остается без подключенного к нему средства реагирования.
Вместо заключения
Забегая вперед, отвечу на вопрос, который может возникнуть при прочтении этой статьи: а что же плохого в наборе продуктов? На самом деле ничего. Набор продуктов – это хорошее подспорье. Однако продукты решают отдельно взятые задачи. Как только встает вопрос о работе этих продуктов в связке, то вместе с этим возникают функциональные колодцы, нестандартные и трудно поддерживаемые решения, которые являются неотъемлемыми частями совместной работы набора продуктов от разных производителей. Если же компания принимает решение о самостоятельном устранении проблем, то вместо простого применения продуктов кибербезопасности, она становится «вендором» с необходимостью поддержки совместимости используемых решений и устранением других проблем, возникающих на стыке технологий.
В свою очередь, применение экосистемного подхода в построении SOC исключает ограничения, связанные с использованием технологий различных вендоров, и позволяет подойти к вопросам кибербезопасности комплексно, высвобождая тем самым ресурсы организаций на решение более приоритетных бизнес-процессов.
Автор:
Григорий Ревенко, директор Центра экспертизы компании R-Vision.
Интернет-портал «Безопасность пользователей в сети Интернет»
admin@safe-surf.ru
https://safe-surf.ru
