XDR: как подготовиться к внедрению такого решения

XDR (от англ. Extended Detection and Response, «расширенные обнаружение и реагирование») – последнее время мы всё чаще слышим про эту аббревиатуру, и этот класс защитных решений действительно набирает популярность. Много говорится о его преимуществах, но недостаточно внимания уделяется деталям внедрения и подготовки к эксплуатации решениям такого класса. В этой статье мы поговорим об этом подробнее.

Как оценить, есть ли потребность в XDR

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

Своевременно проверить возможность реализации таких рисков можно, например путём организации внешнего аудита с проведением тестирования на проникновение (pentest). Таким образом можно наглядно показать проблемные зоны и направления, на которых необходимо расширить возможности обнаружения и реагирования.

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

Что требуется для внедрения XDR

1. Технологии

После осознания потребности в XDR логичный этап – подбор решения, с помощью которого будет реализована комплексная защита. Для того чтобы эффективно выявлять киберинциденты на всех уровнях инфраструктуры, в первую очередь, должен быть организован соответствующий технологический стек. Как минимум это — сбор, агрегация, нормализация и корреляция событий, анализ сетевого и почтового трафика, решения по защите узлов сети и анализ телеметрии с них. Необходимы инструменты детектирования потенциально вредоносной активности, например антивирусные движки, песочница (Sandbox), репутационные списки, IDS, сопоставление анализируемой информации с хакерскими техниками и тактиками. Кроме того, должна быть организована технологическая возможность реагирования на всех обозначенных потоках данных.

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

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

2. Процессы

Помимо технологий в компании, которая планирует внедрение XDR, должен быть определённый уровень зрелости ИБ (или намерение его достичь). В первую очередь речь идёт о процессах Security Operation Center (SOC) и менеджменте инцидентов ИБ. То есть в компании необходимо составить подробный перечень процессов, перечень вовлечённых в них лиц с их обязанностями и иметь в штате компетенции, которые будут этим процессам соответствовать. Только после подготовительной работы можно запускать и поддерживать эти процессы, уже основываясь на технологическом стеке.

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

3. Инфраструктура

Не менее важно перед внедрением XDR оценить готовность ИТ-инфраструктуры и ресурсов для внедрения всех технологий. Ведь каждое решение — это, как правило, отдельная подсистема, состоящая из нескольких компонентов, и каждый компонент может требовать отдельного сервера. Что касается готовности самой ИТ-инфраструктуры — она должна соответствовать требованиям каждого конкретного решения (ресурсы CPU/RAM/HDD, поддерживаемые операционные системы, уровень доступов и пр.). Очевидно, что, чем меньше ресурсов требуют решения, тем лучше. Зрелость самого ИТ-подразделения так же имеет немаловажную роль. Устаревшее оборудование, неверные настройки, устаревший софт приведут к усложнению внедрения XDR.

4. Соблюдение требований регуляторов

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

В ряде ключевых требований (например, приказы ФСТЭК России N 21, N 17, N 31 и N 239) по отдельности обозначено большинство из тех средств защиты информации, которые требуются для реализации XDR. Разница в том, что в этой концепции отдельные инструменты становятся цельной экосистемой.

Для того, чтобы ИБ-специалистам было проще отслеживать вопросы регулирования, «Лаборатория Касперского» запустила ресурс «Регуляторный хаб знаний в области информационной безопасности». На нём собрана вся актуальная информация о требованиях регуляторов по всем основным отраслям и есть удобная система фильтров для подбора необходимого набора информации и мер по обеспечению соответствия регулированию.

Экосистемный подход

Существует несколько классификаций типов XDR и подходов к его реализации: открытый/закрытый, нативный/гибридный, мультивендорный/моновендорный. Их плюсы и минусы можно изучить в специальных статьях. XDR может быть любой, в том числе гибко видоизменяющийся, но один из главных принципов эффективной защиты – экосистемность. То есть, все средства в его составе должны быть интегрированы и создавать единую среду противостояния киберугрозам.

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

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

• запретить отправителей зловреда и фишинга;
• проверить на всех ли атакуемых сработали СЗИ;
• заблокировать флешки или USB порты;
• запретить запуск конкретных файлов;
• заблокировать учетные записи тех, кто был под атакой;
• изолировать те узлы, которые потенциально были атакованы;
• заблокировать все IP адреса тех, кто пытается использовать уязвимости;
• отправить всех, кто получил зловредные письма на дополнительные обучения.

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

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

Таким образом для данной концепции большим плюсом будет моновендорный подход. А если XDR-концепция заявлена самим вендором, это ещё лучше, это значит, что в своих решениях производитель предусмотрел соответствующие кросс-продуктовые сценарии. Для окончательного выбора уже следует взвешивать такие факторы, как функциональные возможности отдельных продуктов внутри XDR, лицензирование, стоимость, опыт и знания самого вендора, география присутствия, штат сотрудников и независимые оценки решений. Хорошая практика для фактической оценки функциональных возможностей — проведение пилотных проектов.

Российским пользователям доступна возможность построить XDR с помощью решений отечественных вендоров. Например, ещё в конце 2021 года «Лаборатория Касперского» в рамках новой линейки для защиты бизнеса представила рынку решение Kaspersky Symphony XDR на основе собственных продуктов – тот самый экосистемный подход для гибкого построения всеобъемлющей информационной безопасности.

Заключение

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

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