Колонка Андрея Жданухина, руководителя группы аналитики L1 GSOC «Газинформсервис»
Внешний наблюдатель видит центр мониторинга (SOC) как могучую стену, которая защищает замок. Есть множество систем активной защиты, точек мониторинга как внутри, так и снаружи, постоянная бдительность, да и «свет горит даже ночью». Однако все это просто складывается в схему «Технологии + Процессы + Люди = SOC». Если с первыми двумя все относительно предсказуемо, то третий элемент — живой, а значит, самый сложный в управлении.
Разберем две системные проблемы, которые возникают, когда про человеческий фактор забывают, — и решения, которые мы применяем в GSOC.
Проблема первая: «тонуть в тысячах срабатываний»
Расхожая фраза «аналитики ежедневно обрабатывают тысячи срабатываний» для меня — маркер системной ошибки. Так быть не должно. Даже если SOC мониторит тысячи организаций, ежедневный поток в тысячи инцидентов — это работа на износ. Ни о каком соблюдении SLA (соглашении об уровне предоставляемых услуг) речи уже не идет.
У этой проблемы есть несколько путей решения:
1. Работа с экспертизой обнаружения атак. При множестве ложноположительных срабатываний следует предъявлять требования не к аналитикам, которые не успевают их качественно отработать, а к контенту обнаружения, задействованному в ваших средствах защиты.
При возникновении проблем такого рода сначала стоит покопаться в правилах корреляции, потратить время на анализ ложных сработок и попробовать скорректировать детектирующую логику или добавить исключения на спамящую активность. Затем изучить результаты своей работы: к какому сокращению нагрузки удалось прийти после первой итерации работ по снижению ежедневных сработок? Далее необходимо получить обратную связь от аналитиков SOC: насколько стало проще справляться с потоком во время смены?
И на основе этих двух результатов постараться найти оптимальное значение подозрений на инциденты (на основе вашей экспертизы обнаружения), которое необходимо поддерживать в дальнейшем для качественного оказания услуг. А также следует сделать процесс постоянного анализа результатов работы экспертизы обнаружения атак, уделяя внимания этой активности не меньше, чем разработке и улучшению этой экспертизы.
2. Поднятие «болевого порога». Массовые срабатывания часто следствие гиперконтроля — попытки уследить за всем сразу. Однако в реальности необходимо понимать, что лучше выставить приоритеты и уделить наибольшее внимание определенным сегментам или типам атак, нежели в одинаковой мере отсматривать все.
Конечно, такой подход всегда будет нести за собой риски, но нужно быть готовым идти на них. Потому что в результате они наоборот повысят вашу способность к обнаружению реальных атак. Примерно как в системе «20–80», где приоритетный контроль за срабатываниями в 20 % инфраструктуры организации позволит защитить от 80 % атак на нее. Но я не призываю отказаться от мониторинга остальных 80 % организации, разговор лишь о приоритетах.
Чтобы понять, как и где именно следует поднять «болевой порог», есть следующие способы:
- Провести оценку рисков с Заказчиком/Организацией. Буквально устроив диалог с топ-менеджментом, уже можно получить результаты в духе: «этих атак мы боимся, а эти нас не особо интересуют».
- Построить ландшафт угроз организации. Здесь следует подключить аналитику угроз, изучить источники Threat Intelligence информации на предмет атак по отрасли / местоположению / типу активов организации. Из чего можно будет выставить приоритеты к мониторингу, а также подтверждение к вашим решениям.
3. Расширение штата аналитиков SOC. Действительно, если регулярное выполнение первого и второго способа не приводят к должному результату, абсолютно нормально задуматься над тем, чтобы расширить свой штат аналитиков SOC, например точечно добавить сотрудников в смены на каждую линию.
Также не стоит исключать методы простой реорганизации текущего штата, при которой аналитик закрепляется за обработкой подозрений на инциденты от конкретного Заказчика или средства защиты (SIEM, IDS). Это все тоже способствует устранению расфокусировки при большой нагрузке и снижению среднего времени на обработку срабатывания.
Проблема вторая: выгорание, если работать 24/7
Проблемы с выгоранием знакомы каждому коллективу, и всем руководителям приходится с этим бороться. Везде применяются разные способы.
В нашей практике есть три работающих способа его тормозить. Нельзя гарантировать, что наши пути решения помогут кому-либо еще, но ознакомиться с ними будет не лишним!
1. Выполнение всех возможных шагов, снижающих поток ложноположительных срабатываний. Чтобы первая проблема из этого материала не стала причиной выгорания сотрудников, уделять внимание их нагрузке стоит постоянно. Даже если в какой-то момент показалось, что ситуацию с множеством срабатываний удалось решить, процесс по контролю нагрузки должен выполняться регулярно.
2. Развитие профессиональных качеств и помощь в реализации амбиций. Почти любая дежурная работа в информационной безопасности сопряжена с высокой ответственностью за результат, что нередко может вызывать стресс. Для того чтобы у аналитика не возникло чувство, что на работе его просто используют, пока он окончательно не выгорит, следует всегда способствовать его карьерному развитию.
В этом помогают карьерные треки, которые показывают, что работа выполняется не зря и она может привести к конкретным результатам. Соответственно, отличным вариантом будет подключение сотрудника к задачам отдела или направления, которое наиболее близко ему по духу или в которое он наиболее стремится. Даже работа в качестве помощника позволит ему улучшить свои профессиональные навыки, и он сможет применять их в своей ежедневной работе. И, конечно, участие в развитии SOC помогает понять свою роль в этой постоянно функционирующей системе центра мониторинга.
3. Конечно, не стоит забывать про обычные коммуникации. Отвлеченные разговоры тоже очень важны, как и проведение тимбилдингов. Создание обстановки, при которой аналитик не чувствует себя роботом, постоянно разбирающим подозрения на инциденты, дает возможность развивать личностные отношения в коллективе. Постепенно такой подход дает плоды, сотрудники начинают себя чувствовать более уверено и осознавать свою ценность не только как работники, но и как важная часть коллектива, который занимается сложной работой в обеспечении информационной безопасности.
Подводя итог, можно сказать, что технологии и процессы — это каркас. Но расследуют инциденты и реагируют на угрозы люди. На практике только за счет слаженной командной работы можно добиться ключевых целей SOC, связанных с качественным расследованием инцидентов и оперативным реагированием. «Слаженная командная работа» — не метафора и не клише, а единственный способ.
