Эксперты компании «Акстел-Безопасность» рассказали в телеэфире, организованном с участием Anti-Malware.ru, о своём опыте строительства SOC. Представитель Positive Technologies представил обобщённую модель организации центров реагирования на киберинциденты, а эксперт из «Финтех Айкью» поделился советами по выбору подходящей модели SOC.
- Введение
- Методика построения внутреннего SOC
- Опыт привлечения внешнего SOC
- Подход Positive Technologies к созданию SOC
- Выбор между собственным и аутсорсинговым SOC
- Оценка эффективности работы SOC
- Метрики для оценки эффективности
- Выводы
Введение
Современные реалии ИТ-мира требуют повышения защищённости и безопасности информационных систем. Результатом происходящих изменений стал быстрый рост количества центров реагирования на киберинциденты (SOC).
Хотя уже накоплен богатый опыт создания SOC в России, единой методологии их строительства и эксплуатации пока нет. Чаще всего пользуются различными рекомендациями, которые позволяют подготовить необходимый для SOC набор функций, выбрать подходящую модель его устройства.
В прямом эфире с Ильёй Шабановым, руководителем Anti-Malware.ru, встретились эксперты компаний «Акстел-Безопасность», Positive Technologies и «Финтех Айкью». Они поделились своим опытом, видением того, как построить SOC, как обеспечить его эффективную эксплуатацию. Дискуссия помогла узнать об этапах подготовки инфраструктуры, получить практические рекомендации по созданию внутреннего (in-house) SOC, а также выяснить, когда выгодно отдать SOC на аутсорсинг.
Методика построения внутреннего SOC
Строительство любой системы безопасности начинается с внедрения SIEM (Security Information and Event Management) — решений для сбора и анализа информации о событиях. Об этом рассказал Михаил Кравченко, руководитель центра мониторинга и расследования киберинцидентов «Гелиос» компании «Акстел-Безопасность».
Михаил Кравченко
Однако практика показывает, что после внедрения этих инструментов очень быстро приходит понимание недостаточности собираемых данных. Требуется опыт эффективной работы с инцидентами. В противном случае формируются негативные мнения:
- «SIEM имеется, но она неинформативна».
- «Хотя антивирус и файрвол уже работают, непонятно, что делать дальше».
- «Нет понимания, какими источниками данных нужно пользоваться для эффективного применения составляющих SOC».
- «Внутри компании отсутствует полная видимость инфраструктуры, а это порождает риск не заметить кибератаку».
Чтобы мониторинг ИБ смог заработать, команде внутреннего SOC необходимо получить для начала базовые знания о работе с программным окружением. Они должны понимать, какие процессы и службы работают в информационных системах, какие порты должны быть открыты, какой объём трафика характеризует «нормальную работу» ИТ-систем, какие протоколы используются в системе и т. д.
Рисунок 1. Концепция мониторинга событий в SOC
Оценив объём предстоящих работ, многие компании приходят к мысли о необходимости дополнения выстроенной системы безопасности. Как правило, это происходит через подключение внешнего SOC (аутсорсинг).
Для реализации этой гибридной модели потребуется провести подготовку инфраструктуры:
- выполнить категоризацию объектов;
- выделить важные с точки зрения бизнеса ресурсы;
- закрыть слепые зоны, невидимые для внешнего SOC;
- сконфигурировать систему мониторинга в соответствии с итогами проведённого анализа.
Рисунок 2. Процесс подготовки инфраструктуры к подключению SOC («Акстел-Безопасность»)
Когда сбор первичной информации завершён, переходят к следующему этапу строительства SOC: подготовке описания процесса по управлению инцидентами, основных документов по формализации задач расследования и реагирования. Потребуется создать:
- Классификатор — документ с определением критериев и порядка выявления инцидентов в зависимости от их значимости, а также того, какие процессы и активы каждый инцидент затрагивает.
- Порядок расследования — регламент работ, включая сбор доказательств и анализ причин.
- Регламент реагирования.
- План восстановления после инцидента.
- Другие документы, с учётом особенностей компании.
Особое внимание уделяют подготовке плейбуков — документов с описанием типовых сценариев и плана восстановления после инцидента. Эта подготовительная работа сделает систему защиты более надёжной.
Необходимо также заранее обдумать источники информации о событиях, угрозах, идентификаторах атак, предписаниях и комментариях ФинЦЕРТ и НКЦКИ. К списку источников могут быть добавлены внутренние и сторонние системы, которые также способны поставлять информацию об активах.
Кроме того, нужно назначить команду для выполнения намеченных работ. Важно при этом предусмотреть план обучения сотрудников.
Когда основные документы подготовлены, начинается рассмотрение задач по автоматизации рутинных процессов: устранения уязвимостей, реагирования на наступление тех или иных событий и пр.
Заключительным этапом строительства SOC является проведение киберучений.
Опыт привлечения внешнего SOC
Нюансом взаимодействия по этой модели является распределение ответственности за отработку инцидентов между участниками. Сложность состоит в том, что не всегда удаётся легко определить, насколько полным является охват активов ИТ-инфраструктуры компании. Очень часто оказывается, что её отдельные элементы по той или иной причине весьма трудно сделать видимыми для внешнего SOC. Это может приводить к тому, что часть атак окажутся вне поля зрения последнего, и тогда придётся выяснять, кто виноват, если они окажутся результативными. Подготовка инфраструктуры к взаимодействию с SOC как раз и призвана решать такие проблемы.
Рисунок 3. Кто отвечает за инцидент при стороннем мониторинге ИБ (опрос Anti-Malware.ru)?
Преимуществом модели является то, что специалисты внешнего SOC, часто обладающие расширенной экспертизой в области ИБ, могут выявить проблемы в работе внутренних ИБ-процессов организации, а также помочь их устранить. Кроме того, следует отметить, что вся накопленная экспертиза по отражению кибератак остаётся на стороне заказчика.
Подход Positive Technologies к созданию SOC
О подходе Positive Technologies к строительству SOC рассказал Константин Смирнов, советник управляющего директора экспертного центра безопасности PT ESC.
Константин Смирнов
В Positive Technologies вместо термина «SOC» часто используют понятие «центр противодействия киберугрозам» (ЦПК). ЦПК отличается от обычного SOC конкретным целеуказанием, ориентацией на предотвращение недопустимых событий. Далее в тексте эти термины будут использоваться равнозначно, но об этом различии стоит всегда помнить.
Прежде всего, под ЦПК в Positive Technologies понимают совокупность программных и программно-аппаратных средств, персонала, утверждённых процессов и процедур, которые позволяют не только своевременно обнаружить риски, но и ликвидировать последствия киберинцидентов до нанесения компании непоправимого ущерба. Таким образом, цель строительства ЦПК состоит в том, чтобы сделать инциденты максимально редкими. Если компания встречается с ними и часть из них вызывают ущерб, то в задачу ЦПК входит обязанность минимизировать последний и не допустить его разрастания до критического для компании уровня.
Согласно структурированной модели ЦПК по версии Positive Technologies, в центре системы — совокупность процессов ИТ и ИБ. Они инициируют те или иные операции силами «внешней» поддержки.
Рисунок 4. Структура SOC по версии Positive Technologies
Представленная модель вполне универсальна. В своей версии Positive Technologies использует собственные ИБ-продукты, которые закрывают задачи в той или иной нише. Тем самым вендор показывает, что за счёт синергии и единого подхода можно достичь более высокой эффективности в сравнении с теми случаями, когда взамен будут применяться аналогичные альтернативные продукты.
Формально, жёстких требований к списку применяемых в ЦПК продуктов нет. В целом подход Positive Technologies можно назвать классическим. Функциональное наполнение определяется прежде всего задачей, которую выполняет ЦПК (недопущение событий с непоправимым ущербом).
С точки зрения Positive Technologies, главное при построении ЦПК — определение недопустимых событий, возникновению которых противостоит центр. Недопустимыми, в трактовке Positive Technologies, являются события, которые возникают в результате кибератаки и делают невозможным достижение операционных и (или) стратегических целей организации либо приводят к значительному нарушению её основной деятельности.
Управление выполнением этой задачи может быть выражено через четыре различные модели работы ЦПК: сервисную, ролевую, процессную и операционную. Эти модели закладываются с учётом индивидуальных особенностей организации-клиента уже на стадии проектирования ЦПК и поддерживаются в актуальном состоянии на протяжении всего его жизненного цикла.
Рисунок 5. Составные проекции (модели) работы SOC (Positive Technologies)
Дадим пояснения:
- Сервисная модель задаёт список функций, которые должен выполнять ЦПК.
- Операционная модель называет составляющие ЦПК. В ней могут быть отражены такие важные вещи, как инсорсинг / аутсорсинг, приоритет ввода в эксплуатацию и пр.
- Процессная модель определяет, какие процессы подлежат внедрению и в каком порядке, какие взаимосвязи между ними будут существовать.
- Ролевая модель характеризует участников процессов.
Рисунок 6. Сервисная модель ЦПК (Positive Technologies)
Формируемая сервисная модель является высокоуровневой. Она показывает сервисы, предоставляемые внешним потребителям. По сути, эта модель отражает ценность ЦПК. По каждому сервисов создаётся «карточка», где отражаются:
- параметры сервиса;
- область его применения;
- метрики;
- технологии, поддерживающие сервис;
- параметры и результаты оказания услуг.
Рисунок 7. Типовая карточка для отдельного сервиса SOC (Positive Technologies)
Операционная модель SOC играет существенную роль не только на стадии проектирования, но и в процессе эксплуатации SOC, поскольку даёт наглядное представление о зрелости выстроенной системы.
Эта модель может быть использована для оценки зрелости различных функциональных областей ЦПК, в т. ч. для планирования трансформации центра (ответственные, сроки, приоритеты и пр.)
Рисунок 8. Типовая операционная модель ЦПК (Positive Technologies)
Ролевая модель позволяет определить, кто и за какую функциональную область или сервис отвечает, а также кто участвует в процессах. Для каждой роли можно сделать описание, которое может лечь в основу штатного расписания и использоваться при поиске и найме.
Рисунок 9. Пример ролевой модели при построении ЦПК (Positive Technologies)
Выбор между собственным и аутсорсинговым SOC
Сложность и высокие трудозатраты при строительстве SOC неизбежно вызывают вопрос: а не выгоднее ли перейти на аутсорсинг?
По мнению Михаила Оглоблина, директора по информационной безопасности компании «Финтех Айкью», любая из моделей SOC имеет право на существование. Выбор зависит от инфраструктуры, бизнес-целей компании, существующих бизнес-кейсов.
Собственный (in-house) SOC — это самое простое и распространённое решение. Он органично смотрится внутри крупной компании, где уже сформировалось стратегическое видение того, куда надо развиваться и с какими рисками предстоит бороться. Обычно уже имеется собственная команда ИБ с соответствующими инструментами. Выбор этого направления становится логичным, если рассматривать развитие SOC в долгосрочной перспективе.
В то же время, отметил Михаил Оглоблин, в нынешних непростых условиях многим компаниям часто требуется выстроить периметр защиты «здесь и сейчас». В этом случае приоритетным становится выбор коммерческого SOC (аутсорсинг).
Михаил Оглоблин
Такой выбор хорош для молодых и динамично развивающихся проектов, вчерашних стартапов. Достигнув миллионных оборотов в бизнесе, они нуждаются в быстром росте. Но даже при наличии собственных ИБ-команд эти компании часто не успевают за темпами роста. Характерным для них явлением становится возникновение протяжённых, распределённых периметров с многочисленными сервисами, которые требуют срочной защиты.
В такой ситуации абсолютно нет времени на строительство собственного SOC и планирование его поэтапного роста. Сильное давление оказывают и регуляторные предписания. Например, в финансовой сфере наличие SIEM и центра реагирования — обязательное требование для всех участников рынка.
Рисунок 10. Основные вопросы перед привлечением внешнего SOC
На практике встречается также модель гибридного SOC. Там часть функций берёт на себя внутренняя команда, а остальные передаются на аутсорсинг.
Гибридная модель помогает, в частности, решить задачу развития компетенций внутри собственной команды ИБ. Сотрудничая с командой внешнего SOC, ибэшники получают новые навыки и быстро повышают свой уровень.
Гибридная модель SOC может также применяться в том случае, если развитие собственного центра мониторинга зашло в тупик. Тогда постепенный переход на аутсорсинг является целью на дальнюю перспективу, а комбинированная схема играет роль временного промежуточного звена.
Рисунок 11. Наиболее предпочтительная модель SOC (опрос Anti-Malware.ru)
Оценка эффективности работы SOC
Когда SOC построен, важно оценить его эффективность. Как выстроен процесс оценки? На какие метрики следует опираться? Ответы на эти вопросы дал Максим Прокопов, руководитель по направлению ИБ компании «Акстел-Безопасность».
Максим Прокопов
Прежде всего он отметил, что оценка зависит от степени развития SOC. Максим Прокопов выделил четыре основных уровня:
- «в начале пути»,
- «в начале эксплуатации»,
- «на этапе становления»,
- «развитый SOC».
Для проверки эффективности эксперты «Акстел-Безопасности» подготовили собственные наборы сценариев, взяв за основу техники из MITRE ATT&CK.
50 наиболее часто встречающихся техник применяют для оценки эффективности SOC уровня «в начале пути». Второй уровень проверки охватывает уже 200 наиболее часто встречающихся проверок и предназначен для использования на стадии «в начале эксплуатации». Третий уровень охватывает 800 проверок. Самый полный набор из 1500 сценариев применяется для оценки эффективности развитых SOC.
Эти наборы позволяют провести тестирование на проникновение, закрыть явные векторы атак и собрать аналитику по источникам событий. Проводится аудит источников, оцениваются методы сбора данных о событиях и объём собираемой информации, проверяются зоны видимости при логировании и пр. Проверки помогают оценить качество выстроенной защиты, при необходимости закрыть явные бреши, используя инструменты харденинга — например, усилить пароли, перевести все учётные записи на 2FA, реализовать ряд других мер базовой защиты.
Второй, более мощной формой оценки SOC служат киберучения. Они годятся для проверки развитых центров мониторинга. Оценивание проводится сразу по всем направлениям (эшелонам защиты).
Рисунок 12. Эшелоны защиты SOC-центра во время проведения киберучений («Акстел-Безопасность»)
Одно из интересных направлений — это проверка защиты от социотехнической инженерии. Она охватывает сразу несколько эшелонов: антиспам, почтовый антивирус, EDR, HIPS, NTA / NDR, NGFW и т. д. Тестирование осуществляется в тесном взаимодействии с командой ИБ заказчика, которая видит, как развивается атака, что происходит в инфраструктуре. Вместе с командой «Акстел-Безопасности» они выбирают решения позволяющие предотвратить риски. Таким образом ИБ-команда заказчика узнаёт, как можно обойти выстроенную ими защиту и что необходимо предпринимать, чтобы повышать уровень защищённости.
На киберучениях также применяются средства автоматизации. У «Акстел-Безопасности» имеются собственные наработки в этом направлении, применяется свой инструментарий.
Среди других форм проверки, используемых на киберучениях, можно выделить ролевые игры (сценарии создаются совместно с заказчиками) и различные методы физического преодоления периметра, помогающие оценить живучесть системы защиты при воздействии источников угроз изнутри.
Максим Прокопов особо отметил, что для проверки защищённости развитых SOC на киберучениях необходимо привлекать сильные команды атакующих (Red Team). Их задачи выходят за рамки проверки на быстрые, очевидные кибератаки: «красные» применяют необычные векторы атак, разрабатывают собственные эксплойты, проводят обфускацию («запутывание») трафика, выполняют другие мероприятия, препятствующие лёгкому обнаружению атакующих.
В задачу Red Team входит также помощь заказчику. Команда помогает обучать его службу ИБ, рассказывает, как реагировать на угрозы и как оценивать уровень реальной готовности противостоять им. Для усиления защищённости «красные» помогают выставить ханипоты — различные ловушки на периметре. Кроме того, они предоставляют различные новые индикаторы компрометации, учитывающие специфику компании-заказчика.
Метрики для оценки эффективности
Самыми важными метриками, которые позволяют оценить общий уровень эффективности SOC и степень совершенства его работы, Максим Прокопов назвал время обнаружения, видимость инфраструктуры, степень охвата техник и тактик атак. К числу дополнительных метрик он отнёс готовность к атакам «нулевого дня» (отражает уровень использования средств ИИ, уровень и качество применения статистики), время и качество обновления экспертизы, а также ресурсоёмкость и уровень автоматизации. Эти метрики оцениваются отдельно, они важны для того, чтобы понимать затраты на строительство SOC.
Выводы
Строительство SOC проходит в несколько этапов. Если в начале пути основной акцент делается на составлении списка угроз и недопустимых для компании событий, то в дальнейшем модель SOC прорабатывается сразу по нескольким направлениям. Эффективность выстроенной системы защиты может быть оценена на проверках и в ходе киберучений. Каждый из этих этапов требует высокого уровня экспертизы и большого опыта. Но если все каноны соблюдены, то такой SOC может эффективно противостоять любым кибератакам.
