Обожаю канцелярит. Вот эти все чумовые законы, методические разъяснения, инструкции и т.д. и т.п., написанные нечеловеческим языком для людей. Глубоко в подсознании живет мыслишка, что эти документы созданы где-то в чертогах инопланетного разума с планеты Нибиру. А если за этой нечитаемой клинописью спрятаны важные процессы? Например, в кибербезопасности важно, чтобы каждый сотрудник четко понимал, что и в какой момент он должен сделать. Иначе атака может привести к трагическим последствиям. Понятные инструкции по реагированию на инцидент – это половина успеха или даже больше. Поэтому мы решили поделиться с читателями Хабра нашим подходом к написанию плейбуков. Кстати, некоторые лайфхаки нам подсказали наши заказчики.

Одна популярная сетевая энциклопедия пишет: «Инструкция — документ, содержащий правила, указания или руководства, устанавливающие порядок и способ выполнения или осуществления чего-либо». Всеобъемлюще, согласитесь. Инструкции на все случаи жизни сопровождают нас от детского сада и до самого конца. Парадокс закачается в том, что их никто не читает, ибо сложно и противоестественно. А даже если и читает, то запоминает в них ровно то, что «болит» в данный момент. Но несмотря на то, что эти документы никто не читает, они необходимы. И хотелось бы, чтобы они были не только крайне важными, но и понятными для всех. А в идеале – запоминающимися. Эффективная инструкция — это не простая формальность, а шаг к успешности и возможной автоматизации рабочего процесса.

За более чем 8 лет существования Solar JSOC через нас прошло какое-то запредельное количество документов совершенно разных заказчиков (от банков до крупных энергетических холдингов). И, независимо от масштаба, почти везде было одно и то же: куча неработоспособной устаревшей внутренней документации, которой никто не пользуется, потому что сложно, нечитаемо и вообще – Нибиру. Нас такое, конечно, не устраивало, но поделать ничего было нельзя, ведь документы-то не наши. Но работа внешнего SOC сильно зависит от того, насколько «зрелый» персонал на стороне заказчика отвечает за кибербезопасность. Это же не игра в одни ворота, когда мы отдаем уведомление, а его «поглощает» Черная дыра. В итоге родилась инструкция в картинках в понятной нотации BPMN. Она же – комикс для взрослых дядек, она же – плейбук она же – Гога, она же – Жора.

Что есть в плейбуке

Как написано выше, плейбук – это графическая схема, отображенная в визуально понятной нотации BPMN, где прописаны роли участников, их действия (activity, операции), шлюзы, потоки данных и все то, что авторы нотации придумали. Чтобы схему понимали вообще все потребители, мы подписываем каждое графическое отображение максимально понятным и емким термином (да, у нас есть огромный внутренний глоссарий вот этого всего на 47 листов).

Условно плейбуки можно разделить на два типа: технический и бизнесовый.  Первый описывает технологическую цепочку при работе с инцидентом и направлен на группу реагирования со стороны заказчика. Второй представляет собой описание цепочки вовлеченных в инцидент подразделений, и его потребителем является скорее линейный менеджмент. Но, как говорил Базз Лайтер, «бесконечность не предел». Мы стали совмещать в плейбуках оба этих варианта с указанием времени исполнения каждой из операций, сделав процесс чуть более прозрачными для бизнес-подразделений.

К указанию внутреннего SLA мы были вынуждены прийти, когда в нашей жизни в качестве потребителей информации появились подразделения экономической безопасности. У нас был запущен пул сценариев, направленных на контроль международных телефонных звонков для VoIP. А все же представляют сотрудников СЭБ одинаково? Обратная связь – не для этих отличных парней. Что туда попало, то пропало. К тому же часто они не знают, что именно нужно делать с точки зрения ИБ. Отсюда появляется более подробная детализация действий для каждого из участников процесса: куда сходить, что сделать на том или ином этапе и как быстро. Все прозрачно: вот информация на вход, вот перечень действий, вот время, за которое их надо выполнить, вот выход. Получился практически устав, в котором описаны все нюансы взаимодействия между подразделениями. Но надо сделать оговорку, что это будет работать ровно в том случае, когда у СЭБ и службы ИБ есть единое руководство (а это, как правило, так).

Что может пойти не так

Но здесь есть «чуть-чуть» подводных камней. Плейбук в нашем понимании – это описание процесса реагирования на инцидент информационной безопасности. А у процессов всегда должен быть владелец. И вот он, первый камень: какой процесс выбрать – крупноблочный или состоящий из множества блоков?

В первом случае в руках одного сотрудника сконцентрировано сразу много действий. Таких блоков в компании обычно не очень много, и найти владельца какого-то процесса всегда проще. Но такой подход, увы, не дает достаточного уровня декомпозиции.

Дробление процессов на мелкие блоки с этой точки зрения удобнее – можно определить конкретное действие за конкретным человеком. Но как потом этого человека найти? А что если кто-то из множества владельцев не захочет менять процесс в угоду кибербезопасности? Или не захочет работать в навязанных SLA?  

Вот другой пример из нашей практики. У одного из заказчиков было большое количество филиалов по всей необъятной Родине. И вот в одном из филиалов выявили вирусную атаку на инфраструктуру. На месте за реагирование на инцидент отвечал сотрудник ИТ-подразделения, который работал от «звонка до звонка». Когда коллеги из ИБ просили его отреагировать на инцидент, он заявил, что у него закончился рабочий день и он идет домой. И ушел. Естественно, начался незапланированный «забег по потолку», звонки между высокими начальниками, в результате которых строптивца вернули обратно и заставили работать, но время было упущено и была совершена куча ненужных телодвижений.

Мораль: необходимо для всех участников процесса зафиксировать зоны ответственности, временные рамки и осуществлять дальнейший контроль (как угодно: в виде отчетов, в системах IRP или SD).

Второй подводный камень – особенности конкретной инфраструктуры. Сделать «сферического коня в вакууме» не сложно, но это не будет работать. Нужно обязательно провести аудит и опросить владельцев процессов перед их моделированием. Нельзя взять какой-то готовый подход, который где-то сработал, и бездумно его применить в другой инфраструктуре.

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

Есть еще один подводный камень. Вполне очевидно, что входы и выходы процессов будут одинаковы, но вот внутреннее содержимое будет сильно разниться. Тут влияет абсолютно все: уровень автоматизации в части реагирования, количество задействованных подразделений (в том числе и подрядных организаций), зоны ответственности конкретных участников и многое другое. И вот на этом этапе начинаются «подпрыгивания» у методолога: надо всё и всех учесть и сделать процесс рабочим. Упрощение задачи подсказал один из заказчиков: надо просто сделать каталог атомарных действий, из которых потом на месте собрать пазл для каждой конкретной компании. Очевидное решение, которое лежало на поверхности, и до которого мы не додумались. Зато теперь все стало быстрее и легче, а заодно и появилась возможность ввести автоматизацию в системах IRP,

Признаться честно, с первого раза мы никогда не попадали в ожидания заказчика. Причины были разные, но все больше они относились к рабочим моментам и всегда были поправимы.

Как проверить эффективность инструкции

Когда плейбук готов, его остается только протестировать. Это, как правило, мы отдаем на откуп заказчикам, ведь ему дальше «жить» по этим процессам. Кто-то проходит по всем этапам с секундомером, кто-то разрезает (буквально – ножницами) распечатку по границам дорожек и пулов и раздает своим работникам со словами: «Вам понятно, что здесь нарисовано?». А дальше идет по всей цепочке процесса, после чего возвращается к нам с комментариями по результатам тестов и дальше мы выходим на второй круг. Еще один вариант тестирования – попытаться имплементировать плейбук в IRP. Но это отдельная достаточно сложная задача, которая требует другого подхода к формированию действий: они должны быть понятны для логики работы именно IRP, а не человека.

Вместо резюме

Словом, инструкции нужны и важны. Но они должны быть читаемыми и понимаемыми и не содержать канцелярита; инструкции должны быть адаптированы под конкретного потребителя, который ими пользуется. Короче, они должны быть в картинках.

Роман Семенов, руководитель отдела методологии и консалтинга Solar JSOC, "Ростелеком-Солар"