Если перефразировать (от обратного) основную аксиому планиметрии, то допустимо утверждать, что помимо кратчайшего расстояния между двумя точками в пространстве существует бесконечное множество других, отличающихся друг от друга, путей. Эту метафору объективно можно применить и в жизни, в отношении последовательных сценариев создания и развития центров мониторинга информационной безопасности.
При прочих равных условиях не существует двух одинаковых SOC. За каждым SOC в РФ стоит своя история, свой сценарий развития, свой путь между двумя точками на временном отрезке существования.
Что касается пути становления SOC Газпромбанка с 2009 года по настоящее время, то назвать его кратчайшим и оптимальным просто язык не поворачивается. За более чем десять лет мы смогли превратить дежурную смену с базовым opensource-инструментарием для мониторинга доступности и работоспособности технических средств защиты информации в один из лидирующих ситуационных центров по информационной безопасности в финансовой отрасли России. Постараюсь не пересекаться с автором сборника лучших практик по SOC-строению от CISCO и приведу лишь несколько лайфхаков, которые реально помогли нам достичь нужного эффекта при создании SOC в Газпромбанке.
Не бойтесь пилотировать, пробовать и внедрять новые инструменты сбора и мониторинга событий: часто синергетический эффект от использования той или иной подсистемы наступает намного позже, чем вы ожидаете при планировании, но это не повод забывать про обновление и развитие источников атомарных событий и алгоритмов обработки цепочек.
Наличие двух и более альтернативных центров компетенций внутри SOC не только вредно, но и полезно: в аргументированном диалоге (не путать с конфликтом) между участниками с различными точками зрения часто рождается именно то решение (как в организационном, так и в техническом плане), которое станет стратегически верным в данных обстоятельствах.
Бесполезность организационных каналов поступления в SOC информации о событиях с признаками инцидентов (по телефону, электронной почте, в диалоге с коллегой) сильно преувеличена: по опыту, именно полученные без использования технических средств данные об инцидентах в целевых системах становятся бесценной базой для формирования наиболее эффективных правил и цепочек для SIEM (в силу своей очевидности для обывателей).
С самого начала создания SOC важно учесть и иметь организационную и штатную возможность разделить процессы выявления, обработки, учёта и расследования инцидентов: объединение в одних руках (в силу ограничения штатного расписания) этих процессов негативно сказывается на общей эффективности работы SOC и не позволит быстро (в терминах проектного управления) запустить потоковую обработку инцидентов.
Качество визуализации в дашбордах для первой линии и наличие мультиканальной системы уведомлений так же важны, как и чёткая логика сбора и обработки событий с признаками инцидентов: можно накапливать бесконечное количество атомарных событий с высокой степенью детализации, но без понятной дежурным инженерам подсистемы визуализации и своевременных уведомлений эти события не будут иметь никакой превентивной ценности для организации в целом до момента фактического поступления в SOC сообщения об инциденте по альтернативным каналам.
.png)