Проблемы SOC

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

Причины популярности SOC

Стремление компаний иметь собственный центр мониторинга кибербезопасности стало массовым явлением в последние 5–7 лет. Для этого есть объективные причины:

1. SOC-технологии приобрели понятное представление для заказчиков. Выросло количество специалистов в данной области, готовых предложить свои знания и навыки.

2. Процессы, связанные с информационной безопасностью в компаниях, приобрели зрелый статус, стали повсеместной нормой.

3. Ужесточились требования регуляторов в области информационной безопасности. Теперь в организациях должны присутствовать конкретные ответственные лица из числа управленцев компании, отвечающие за кибербезопасность. (Указ Президента РФ от 01.05.2022 г. № 250).

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

Для создания центра мониторинга и кибербезопасности компания может действовать несколькими способами:

• SOC out-source. В этом случае компания частично или полностью передает управление кибербезопасностью сторонним организациям. Чаще всего это реализуется на базе облачных технологий. Этот вариант выбирают те, кому нужен быстрый результат и у кого отсутствует необходимость в проведении работ исключительно внутри компании.

• SOC on-premise. Собственный центр, построенный внутри организации и использующий свои ресурсы. Этот вариант характерен для компаний с разветвленной инфраструктурой и имеющих в распоряжении крупные ИТ-ресурсы. Здесь играет немалую роль и нежелание компании передавать управление кибербезопасностью сторонним организациям: ввиду наличия регуляторных ограничений или использования собственных внутренних политик.

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

Основные проблемы SOC

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

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

3. Игнорирование или недооценка очевидных рисков при работе над проектом. SOC на базе собственных ресурсов компании – это долго строящийся проект, реализация которого может занять не один год. За это время может сильно измениться состав команды, работающей над ним. Могут уйти ключевые сотрудники, что вызовет период простоя. Такой сценарий увеличит сроки и вложения компании в реализацию проекта, причем велика вероятность, что он не будет выполнен на должном уровне.

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

Как устранить проблемы SOC?

Самостоятельно или с привлечением внешнего эксперта по консалтингу необходимо решить следующие задачи:

• Подготовить команду для проекта на стороне заказчика.

• Создать целевой образ SOC, принимая во внимание специфику работы организации и конкретные цели, которые требуется достигнуть.

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

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

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

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

• Бизнес-лидер команды. Отвечает за командную работу, поддерживает связь с заказчиком.

• Руководитель. Управляет человеческими и финансовыми ресурсами, расставляет приоритеты в работе, проверяет текущие результаты.

• Архитектор проекта. Опытный эксперт, обладающий разносторонними навыками в таких областях, как ИБ, ИТ.

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

Успешная практика SOC предполагает проведение ряда мероприятий для создания и развития проекта:

• Изучение рисков кибербезопасности.

• Оценка зрелости SOC.

• Создание планов, программ, направленных на развитие и совершенствование проекта.

• Разработка, внедрение регламентов, политик, методологических документов.

• Проектирование, интеграция с SOC различных инструментов информационной безопасности по типу SIEM, IRP, DLP.

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

• Создание метрик, KPI для оценки эффективности.

• Создание контента с его последующей передачей системам, включенным в состав SOC.

• Тренинговое сопровождение участников команды разработки проекта.

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

Практические примеры решения проблем SOC

1. Установка правил корреляции или контента SIEM. Практика показывает, что в большинстве случаев после установки SIEM-системы используются дефолтные правила корреляции. Это чревато увеличением числа ложных срабатываний, пропуском действительно важных инцидентов. Необходимо проводить индивидуальную настройку интеграционных проектов согласно ситуации и особенностям работы компании, а не использовать стандартные сценарии. То же самое касается контента. Помимо правил сюда должна быть включена и структура их организации: списки, листы и прочее. Структура находится в связке с рабочими процессами SOC, поэтому ее можно изучать и оценивать в рамках проекта. Рационально проведение параллельной подготовки рабочих процессов вместе с контентом, когда, например, аналитики изучают инциденты, а инженеры контент.

2. Реагирование на инциденты. Для этого процесса необходимо разработать готовые схемы или плейбуки, чтобы своевременно и точно реагировать на инцидент. В крупных SOC количество детектирующих правил близится к нескольким сотням, и все их необходимо своевременно актуализировать, что при таком объеме непросто. Для оптимизации и удобства их использования лучше создать каталог атомарных правил, которые при необходимости объединяются в единый плейбук – его будет проще поддерживать в актуальном состоянии, обновлять или изменять.

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

SOC on-premise – это сложно и дорого для большинства заказчиков. Если выбирать этот вариант, нужно снизить риски и найти для этого надежного партнера. Например, обратить внимание на Solar JSOC – крупнейший в России коммерческий центр противодействия кибератакам с более чем 10-летней историей. Опыт проектов федерального масштаба, практика противодействия самым высококвалифицированным группировкам, передовые технические решения и отлаженная методология делают Solar JSOC надежным партнером в построении собственного центра кибербезопасности.