Где начало того конца, которым оканчивается начало?
Козьма Прутков
Работа аналитика SOC должна быть формализована, чтобы гарантировать идентичную интерпретацию идентичных ситуаций разными аналитиками. Однако, ситуаций может быть великое множество, не исключая тех, которые не известны на момент подготовки руководств и инструкций, что приводит к огромному количеству документации, которую, во-первых, невозможно поддерживать в актуальном состоянии (ну или трудоемкость будет неадекватна решаемой задаче), а, во-вторых, огромное количество разнородных инструкций создаст необоснованную когнитивную нагрузку на аналитиков, приводящую к преждевременному утомлению и раннему выгоранию, а то и способно полностью парализовать работу аналитиков. Итого, отсутствие инструкций - это плохо, но и их чрезмерное количество - тоже не лучше, и следует найти баланс.
Для поиска баланса попробуем идти от решаемой проблемы. Начать можно с пропусков инцидентов, неполных расследований.... в общем, с ошибок. Как понимание условия сложной задачи - уже более половины ее решения, так и определение наших страхов (== ошибок) уже прекрасное начало. Для принятия решения ошибка\не ошибка нужно принципиальное понимание что такое инцидент и каковы его характеристики, т.е. каким критериям должна удовлетворять наблюдаемая активность, чтобы считаться инцидентом, а чтобы съесть такого большого слона, как всевозможные инциденты, по частям, поможет классификация как минимум, по критичности, а может, и по типу\природе возникновения.
Итак, теперь мы знаем что мы ищем (что такое инцидент и какова их классификация) и знаем как выглядит недоработка со стороны аналитика (какие ошибки возможны). Вопросы классификации инцидентов и ошибок аналитиков принципиальны, здесь очень важно самому не допустить ошибку, поэтому лучше, если эти классификации будут взяты не из практики: оглянувшись назад на зарегистрированные кейсы и прошлые разборы залетов.
К сожалению, повторимость результата может гарантировать только документация, и чтобы она обладала следующими важными свойствами, структура документации должна быть иерархичной:
- иерархическую документацию проще актуализировать: общие принципы практически никогда не будут меняться, детальные плейбуки могут меняться, но их не будет много;
- она лучше откладывается в памяти исполнителей, так как в подавляющем большинстве наше мышление работает от общего к частному;
- и связанное с предыдущим - в иерархической документации проще что-либо найти.
Обычно выделяют три уровня иерархии документации, думаю, это действительно удобно:
- Общие принципы принятия решения - относятся ко всем типам инцидентов, включая возможные неклассифицируемые ситуации, но в опоре на эти принципы аналитик сможет принять правильное решение;
- Руководства - относятся к одному или нескольким типам инцидентов, например, ко всем инцидентам высокой критичности;
- Плейбуки - пошаговые инструкции для каких-то конкретных ситуаций.
Работая на крупном промышленном предприятии я стремился разработать как раз все три уровня документации, но это имело негативную обратную сторону - устаревшие документы было трудоемко актуализировать, а неактуальные документы скорее вредили, чем способствовали, что приводило к перегибам, когда, вроде как, документы необходимо исполнять, но их исполнение ведет к необоснованным ресурсным потерям. Наиболее часто нуждались в обновлении документы среднего уровня (стандарты, в этой статье выше названы как "руководства") и низкого уровня (процедуры, но здесь - "плейбуки").
Уже работая в поставщике ИТ-решений, мы учли этот негативный опыт и сфокусировались на разработке высокоуровневых принципов, а низкий и средний уровень отдали на решение исполнителей. Понятно, что первое время наблюдался значительный рассинхрон, а опытные SOCоводы высказывали претензии, что в нашем SOC так мало формализовано (должен сознаться, что меня это не сильно задевало, я прекрасно понимал, что чем дольше будет существовать наш SOC, тем большим количеством правил, инструкций, процедур, регламентов, чеклистов и т.п. мы обрастем, поэтому спешить их клепать впрок, например, выписывая из популярных книжек, - точно не надо). Разнообразие инициативных идей аналитиков мы попытались компенсировать перепроверкой друг за другом и регулярными коллективными разборами ошибок, в результате которых вносились изменения в программу онбординга и разрабатывались чеклисты, являющиеся по сути заплатками на проблемные места. При этом, мы пытаемся следить, чтобы заплаток не было сильно много и они по возможности не противоречили "здравому смыслу". Кстати, Здравый смысл - это как раз содержание высокоуровневых принципов, а заплатки - это уточнения некоторых моментов в наших принципах здравого смысла. Описываемый мной здесь fuck-up-driven management, возможно, противоречит попыткам проактивной адресации всевозможных негативных ситуаций, однако, имеющийся опыт показывает, что все предусмотреть крайне сложно (я бы сказал, невозможно, причем чем сложнее работа, тем невозможнее ее полностью формализовать), а проблемы, взятые из практики, тем более несколько раз повторенные разными исполнителями, точно заслуживают нашего управляющего воздействия.
Управление, основанное на ошибках заслуживает отдельной статьи, но, поскольку мы здесь его рассматриваем как разумный компромисс между тотальной формализацией и полным ad-hoc, остановлюсь на ряде моментов, релевантных обсуждаемой теме.
Фокусировка на системных ошибках. В рамках ретро надо в первую очередь фокусироваться на повторяющихся ошибках. Даже если есть острый соблазн объяснить сложившуюся ситуацию недоработкой со стороны исполнителя, всегда следует непредвзято проанализировать возникшую проблему и поискать точки улучшения, которые можно было бы закрыть чеклистом или корректировкой общих принципов, желательно обновлять существующие, чтобы не размножать нормативку.
Автоматизация и подсказки играют важнейшую роль. Все что можно автоматизировать, надо автоматизировать, и все, что можно не держать в памяти, не нужно держать в памяти (постоянно что-то помнить - энергозатратная операция, ребята будут уставать, перегреваться и выгорать). Интерфейсы аналитика нужно по-максимуму оснастить контекстными подсказками. Сейчас модно говорить о ML-copilot-тах (на слайде 15 я рассказывал про нашего Мерлина, что-то похожее из себя представляет и Кира), однако, начать можно с классических запрещений средствами интерфейса недопустимых ситуаций, контекстными всплывашками, и прочими решениями на уровне UX. Действия аналитиков в интерфейсе можно логировать, а на этих логах обучать модельки, которые потом смогут подсказывать шаги новичкам. Это компенсирует отсутствие каких-то пошаговых руководств.
Ну и в заключении хочется отобрать еще одну важную мысль у будущей статьи об управлении, основанном на ошибках (вдруг, я так и не напишу эту статью) - это культура обучения на ошибках. Аналитики должны понимать, что ошибки разбираются не для того, чтобы найти крайнего и его наказать (тем более, что отрицательная мотивация в моем понимании не работает), но для улучшения процессов, чтобы впредь подобные ошибки не происходили. Аналитики не должны бояться спрашивать и ошибаться. Конечно, необходимо соблюдать разумный баланс, и откровенное разгильдяйство, конечно же, должно пресекаться, однако, распознавание явного вредительства - это совсем уже другая история.
Ну и где же граница? Мир немного сложнее, поэтому идеальное решение кроется в комбинации описанных здесь подходов. Инструкции\руководства - основные принципы работы, позволяющие интерпретировать любую ситуацию, а также покрывающие повторяемые, однозначные ситуации. Наставничество и ретро - для разбора серых зон, обучения, корректировки инструкций\руководств. Количество и\или процент ошибок аналитиков следует измерять во времени, и это будет нашей метрикой качества: доля ошибок должна снижаться. Автоматизация - для снижения когнитивной нагрузки.