Пример 4
Title: Проблемы SOC: как настроить, запустить центр мониторинга безопасности?
Description: Проблемы SOC: с чем сталкиваются компании при запуске собственного центра мониторинга безопасности? Обзор типичных проблем, путей их решения. Как создать эффективный, работающий корпоративный SOC?
Одной из распространенных практик кибербезопасности является создание организациями собственных центров мониторинга безопасности и противодействия кибератакам (SOC). Использование собственных специалистов по кибербезопасности и решение проблем за счет собственных ресурсов – хорошая практика, однако она имеет и обратную сторону. Проблемы SOC не всегда очевидны на раннем этапе. Обычно они вскрываются спустя какое-то время, требуют немало сил на их решение.
Желание компаний располагать центром мониторинга и кибербезопасности стало массовым явлением в последние 5-7 лет. Для этого есть объективные причины:
1. SOC-технологии приобрели понятное представление для заказчиков. Выросло количество специалистов в данной области готовых предложить свои знания и навыки.
2. Процессы, связанные с информационной безопасностью в компаниях, приобрели зрелый статус, стали обязательным явлением.
3. Ужесточились требования регуляторов в области информационной безопасности. Теперь в организациях должны присутствовать конкретные ответственные лица из числа управленцев компании, отвечающие за кибербезопасность. (Указ Президента РФ от 01.05.2022 г. № 250).
4. Выросло количество кибератак и объектов, которым они подвержены. Сегодня любая компания может стать целью киберпреступников. Это правомерно как в отношении государственных, так и частных компаний в коммерческой сфере деятельности.
Для создания центра мониторинга и кибербезопасности компания может действовать несколькими способами:
· SOC out-source. В этом случае компания частично или полностью передает управление кибербезопасностью сторонним организациям. Чаще всего это реализуется на базе облачных технологий. Этот вариант выбирают те компании, которым нужен результат на данный момент времени и отсутствует необходимость в проведении части работ исключительно внутри компании.
· SOC on-premise. Собственный центр, построенный внутри организации и использующий свои ресурсы. Характерны для компаний с разветвленной инфраструктурой располагающих крупными ИТ-ресурсами. Также здесь играет немалую роль нежелание компании передавать управление кибербезопасностью сторонним организациям ввиду наличия регуляторных ограничений или использования собственных внутренних политик.
Возможен и третий вариант – гибридная модель, которая сочетает оба подхода. Ей прогнозируют развитие в будущем за счет оптимального подхода к использованию текущих ресурсов. Пока данные модели встречаются на практике нечасто ввиду необходимости тесного партнерства и зрелости как со стороны заказчика, так и партнера, осуществляющего интеграцию.
1. Недостаток понимания у заказчика целевого образа SOC, его функционала, размахов предстоящей деятельности. Это усложняет этап проектирования, повышает риски того, что результат не будет соответствовать ожиданиям. Во избежание этой проблемы рекомендуется заранее подготовить план создания и развития проекта, создать техническую архитектуру, нарисовать подробную и актуальную карту рабочих процессов, провести экспертизу сотрудников, установить зоны ответственности.
2. Доминирование технических решений в проекте над процессной, методологической составляющими. Это проявляется закупкой дорогостоящего оборудования и решений вроде SIEM, IRP с вовлечением их в рабочий процесс, но в тоже время наблюдается использование малоопытного и необученного персонала, который не готов пользоваться этими решениями без обучения и периода тестирования. Это приводит к нерациональному использованию финансовых средств без возможности их возвращения в ближайшее время.
3. Игнорирование или недооценка очевидных рисков при работе над проектом. SOC на базе собственных ресурсов компании – это долго строящийся проект, реализация которого способна занять не один год. За это время может сильно измениться состав команды, работающей над ним. Могут уйти ключевые сотрудники, что вызовет период простоя. Такой сценарий увеличит сроки и вложения компании в реализацию проекта, причем велика вероятность, что он не будет реализован на должном уровне.
4. Низкий уровень взаимодействия и доверия между разными специалистами и отделами, занимающимися реализацией проекта. Зачастую ввиду огромных объемов работ, их дифференциации, подразделения, которые занимаются претворением поставленных задач в реальность сосредоточены на решении отдельных вопросов и закрытия собственных промежуточных задач с последующей передачей проекта в другие руки. Это чревато вскрытием в процессе работы недоработок, слабых мест, что в будущем обязательно скажется в эксплуатации SOC.
· Подготовить команду для проекта на стороне заказчика.
· Создать целевой образ SOC принимая во внимание специфику работы организации и конкретные цели, которые требуется достигнуть.
· Снабдить команду, работающую над реализацией проекта необходимым материалом, готовыми практиками, опытными решениями.
· Вести сопровождение деятельности команды по ходу разработки и практического внедрения созданного проекта.
· Следить за уровнем профессионализма членов команды, проводить обучение, совершенствование навыков, если этого требует развитие проекта.
Команда проекта становится основной движущей силой для достижения цели, поэтому нельзя забывать о поддержании ее укомплектованности и профессионализме. Важно сохранить большую часть участников до успешного завершения проекта. Ключевыми позициями в команде считаются:
1. Бизнес-лидер команды. Отвечает за командную работу, поддерживает связь с заказчиком.
2. Руководитель. Управляет человеческими и финансовыми ресурсами, расставляет приоритеты в работе, проверяет текущие результаты.
3. Архитектор проекта. Опытный эксперт, обладающий разносторонними навыками в таких областях как ИБ, ИТ.
4. Методолога. Специалист ответственный за методическое обеспечение деятельности внутри проекта, так и в других подразделениях, принимающих участие в работе.
Успешная практика SOC связана с проведением таких мероприятий по ходу создания и модернизации проекта как:
· Изучение рисков кибербезопасности.
· Создание планов, программ, направленных на развитие и совершенствование проекта.
· Разработка, внедрение регламентов, политик, методологических документов.
· Проектирование интеграция с SOC различных инструментов информационной безопасности по типу SIEM, IRP, DLP.
· Создание, внедрение, автоматизация плейбуков с целью повышения скорости реагирования на инциденты.
· Создание метрик, KPI для оценки эффективности.
· Создание контента с его последующей передачей системам, включенным в состав SOC.
· Сопровождение тренингами участников команды разработки проекта.
Описанные действия и подходы позволяют создать индивидуальный конструктор для нового проекта и реализовать его максимально полно. При этом нужно понимать, что существует множество факторов, которые могут препятствовать воплощению в жизнь даже хорошо проработанной концепции и программы проекта.
Практические примеры решения проблем SOC
1. Установка правил корреляции или контента SIEM. Практика показывает, что в большинстве случаев после установки SIEM-системы используются дефолтные правила корреляции. Это чревато увеличением числа ложных срабатываний, пропуском действительно важных инцидентов. Необходимо проводить индивидуальную настройку интеграционных проектов согласно ситуации и особенностям работы компании, а не использовать стандартные сценарии. Тоже самое касается контента. Помимо правил сюда должны быть включена и их структура организации: списки, листы и прочее. Структура находится в связке с рабочими процессами SOC, поэтомуее можно изучать, оценивать в рамках проекта, принимать решение о целесообразности использования в конкретном случае. Рациональнее всего будет проведение параллельной подготовки рабочих процессов вместе с контентом, когда, например, аналитики изучают инциденты, а инженеры контент.
2. Реагирование на инциденты. Этот момент рекомендуется обыграть с помощью готовой схемы или плейбука, чтобы своевременно и точно отреагировать на инцидент. В крупных SOC их количество близко к нескольким сотням, что затрудняет быстрый поиск и использование. Для того чтобы оптимизировать этот момент лучше всего сделать каталог атомарных правил, которые при необходимости объединяются в единый плейбук. В этом случае можно снизить количество плейбуков в системе, поддерживать их в актуальном состоянии на постоянной основе.
3. Наладить общее взаимодействие между разными командами. Ввиду разнообразия подходов и специфике работы мнения, опасения экспертов из разных подразделений могут отличаться. Важно проводить совместные собрания, где обсуждаются общие вопросы, происходит обмен опытом между специалистами. Тем самым станет проще обнаружить и устранить проблемные места в проекте, оптимизировать его реализацию.
SOC on-premise – это сложно, дорого для большинства заказчиков. Если выбирать его, тогда нужно снизить риски и найти для этого надежного партнера (Ссылка на нашу страницу про Построение SOC …через две недели будет релиз страницы). В качестве альтернативного варианта можно попробовать решение SOC out-source. Также не забывайте про такое решение как DLP-системы. Они не теряют своей актуальности. Например, Solar Dozor может пригодиться для проверки коммуникации персонала, выявления внутреннего мошенничества, обнаружения и предотвращения утечек информации.