Как перезагрузить ИБ с помощью процессного моделирования

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

1. Введение
2. Что даёт процессное моделирование
3. Когда использовать процессное моделирование
4. Шесть шагов процессного моделирования
   
   1. 4.1. Шаг № 1. Определяем нотацию и инструментарий автоматизации
   2. 4.2. Шаг № 2. Закладываем основы процессного подхода к управлению
   3. 4.3. Шаг № 3. Определяем правила моделирования
   4. 4.4. Шаг № 4. Рисуем целевое состояние процессов
   5. 4.5. Шаг № 5. Детализируем процессы в документации
   6. 4.6. Шаг № 6. Определяем области контроля и измеряем
5. Выводы

Введение

Мы регулярно проводим аудиты ИБ в различных компаниях: помогаем клиентам оценивать их уровень защищённости, закрывать регуляторные требования, планировать развитие ИБ и обосновывать штат ИБ-специалистов. Подолгу находясь на площадках заказчиков и вникая в их проблемы, мы выделили ключевые сложности, с которыми сталкивается практически любое ИБ-подразделение независимо от отрасли и размера компании.

Чем занимается ИБ? Отсутствие чёткого понимания конечного перечня обязанностей как у самих ИБ-специалистов, так и у смежных подразделений снижает эффективность работы службы ИБ. Система постановки этих задач требует конкретики, а когда «границы размыты», образуются так называемые «слепые пятна».

Как должен функционировать конкретный процесс? Отсутствие зафиксированных целей, результатов и описания процессов в совокупности с ситуацией, когда они держатся на инициативе (в головах) одного или нескольких специалистов, приводит к снижению их управляемости.

Как и с кем взаимодействует ИБ? У ИБ-специалистов немало смежных областей со службой безопасности, ИТ- и HR-подразделениями: управление уязвимостями, мониторинг DLP, работа с коммерческой тайной и другие. При отсутствии чёткого деления задач образуются зоны нераспределённой ответственности. Из-за этого сложно понять, на ком и по какой причине «зависает» процесс.

Как улучшать бизнес-процесс, если непонятно, что измерять? Отсутствие метрик процессов и инструмента измерения не позволяет «держать руку на пульсе», понять, где и из-за чего возникают проблемы, а также показать руководству, что компания стала более защищённой.

Одна из причин, которая объединяет эти проблемы, — непонимание собственных бизнес-процессов. В результате компании управляют ИБ ситуационно, решая проблемы по мере поступления, хотя куда эффективнее перейти к процессному менеджменту.

Что даёт процессное моделирование

Главная особенность процессного управления — в том, что оно помогает посмотреть на деятельность компании как на единую систему взаимосвязанных элементов: процессов, в том числе сквозных, проходящих через несколько подразделений. Если понимание этих взаимосвязей затруднено, начинаются проблемы с качеством в той или иной области. Например, низкое качество управления источниками ИБ-событий прямо влияет на процесс управления инцидентами, что в конечном счёте снижает эффективность всех усилий.

Метод, позволяющий перейти на процессное управление, визуализировать и понять свои процессы, называется процессным моделированием.

Вот пример визуализации процесса «проведение аудита ИБ» в нотации функционального моделирования IDEF0. С её помощью можно легко отобразить используемые ресурсы, регламентирующие документы, инструментарий для автоматизации, ожидаемые результаты и связи со смежными процессами. Схематичное изображение всех этапов убирает «слепые пятна» и упрощает восприятие конкретной области или задачи.

Рисунок 1. Визуализация проведения аудита ИБ в нотации IDEF0

Когда использовать процессное моделирование

По нашему опыту, есть три основных сценария, когда стоит использовать процессное моделирование.

Первый — когда подразделение ИБ только появилось и надо сделать сразу правильно. По нашей практике, это — весьма редкий случай.

Второй — решение частных задач. Это может быть детализация конкретного процесса, например по предоставлению удалённого доступа, или разработка отдельных схем для улучшения читаемости организационно-распорядительной документации (ОРД).

Третий — «перезагрузка ИБ». Она требуется, когда ИБ выстроена, но присутствуют системные или повторяющиеся проблемы и нужно понять, где они возникают и как их устранить. С этой проблемой мы встречаемся чаще всего, и об этом будет наша статья. Кстати, для первого сценария наши рекомендации тоже подойдут.

Шесть шагов процессного моделирования

Шаг № 1. Определяем нотацию и инструментарий автоматизации

Первый этап моделирования начинается с выбора инструментов. Мы опускаем случай, когда в компании уже полноценно используется процессное управление, отрисована часть корпоративных процессов, есть инструмент и методология и подошла очередь процессов ИБ. В таких случаях подразделение ИБ, как правило, использует наработки коллег. Мы расскажем о ситуации, когда в компании не было практики моделирования и необходимо начинать всё с нуля.

Сперва нужно выбрать «язык» графического описания модели, то есть нотацию моделирования. Остановимся на наиболее распространённых нотациях: IDEF0, BPMN 2.0 и EPC.

• IDEF0 даёт возможность взглянуть на модель процесса «сверху вниз» и понять основные укрупнённые составляющие моделируемого процесса. Однако с помощью этой нотации проблематично детализировать крупный процесс до конкретных процедур и отразить временную составляющую.
• BPMN 2.0 и EPC избавлены от недостатков IDEF0, но в то же время из-за сложной детализации сложно удержать в голове общую картину взаимосвязей всех процессов между собой.

Использование той или иной нотации зависит от поставленных задач:

• Если вам необходимо выделить ключевые составляющие процесса, согласовать работу между несколькими структурными подразделениями, лучше всего подойдёт IDEF0. Нотация закрепит, какие ресурсы и информация нужны для его запуска, в том числе от смежных подразделений.
• Когда требуется согласовать отдельные шаги процесса, берите BPMN или EPC. В них будут чётко отображены ключевые роли и последовательность выполнения задач, поэтому каждому участнику процесса будет понятно, за какую часть работ он несёт ответственность.

Мы рекомендуем использовать связку «от общего к частному», сочетая нотации IDEF0 и BPMN 2.0. Первая поможет согласовать процесс общими блоками, определить необходимые для него информацию и ресурсы, заложить основу. С помощью второй можно будет уже каждый блок детализировать на рабочий процесс (workflow), разграничить ответственность до конкретных ролей, а процесс — до конкретных шагов.

Определившись с нотацией, выбираем средство моделирования. Среди них бывают средства, ориентированные на конкретную нотацию, и универсальные комбайны, например Business Studio. Мы рекомендуем обратить внимание на комплексные платные решения, так как они значительно упрощают моделирование, отслеживают ошибки и обладают множеством полезных опций.

Таблица 1. Достоинства и недостатки средств моделирования

Шаг № 2. Закладываем основы процессного подхода к управлению

После выбора нотаций и средства моделирования приступаем к работе над процессами: сначала проводим их инвентаризацию и «диагностику». Задача этого шага — в том, чтобы зафиксировать то, что есть сейчас, понять, кто за это отвечает, и разложить полученную информацию «по полочкам», т. е. по процессам.

В результате мы должны получить перечень или каталог процессов «в первом приближении» — по сути, каркас нашей дальнейшей работы. Затем необходимо провести работы по его «перезагрузке»: дополнению, перегруппировке, декомпозиции. Для этого можно использовать большое количество международных фреймворков: ISO/IEC 27001:2013, NIST Special Publication 800-53, O-ISM-3 и другие.

Эти стандарты помогают выстроить управление ИБ «сверху вниз», учитывают современные тенденции ИБ и ландшафт угроз и позволяют ничего не забыть. У каждого фреймворка есть сильные и слабые стороны, поэтому мы рекомендуем собрать из предлагаемых ими «кубиков» свой каркас, оптимизированный под специфику вашего бизнеса и функционирования ИБ.

Мы также рекомендуем декомпозировать выделенные на этом шаге процессы на два уровня, когда «родительский» процесс 1-го уровня делится на один или несколько более детальных процессов 2-го уровня. Такой пример приведён на рисунке ниже.

Рисунок 2. Пример карты процессов ИБ

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

Шаг № 3. Определяем правила моделирования

Перед тем как начать рисовать, необходимо установить «правила игры». Любой язык моделирования налагает строгие ограничения и правила, которых нужно придерживаться. Также необходимо закрепить единые правила использования нотаций и варианты отхождения от них. Всё это можно прописать в соглашении о моделировании.

Полезно также разработать краткие памятки по нотации — так проще будет объяснять схему при её обсуждении. Кроме того, можно упростить дальнейшие этапы работ, если потратить время на подготовку рабочей области в ПО — например, наполнить репозиторий объектов существующей оргштатной структурой и типами используемой ОРД.

Шаг № 4. Рисуем целевое состояние процессов

Когда предварительная карта процессов и инструмент готовы, можно приступать к основному и самому длительному этапу: моделированию или визуализации самих процессов.

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

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

Важный шаг этого этапа — обеспечить взаимосвязь рисуемых процессов ИБ со смежными корпоративными процессами, закрепить или перераспределить ответственность, чтобы процессы ИБ не «висели в воздухе». Для этого и нужна визуализация: у смежных подразделений появляется понимание того, как работает вся цепочка процесса, какая информация поступает от ИБ и почему она должна поступать, какие ответные действия ждёт ИБ и в какие сроки. Для закрепления ответственности как за «свои», так и за смежные процессы используются RACI-матрицы, которые разрабатываются и обсуждаются совместно со схемами.

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

Шаг № 5. Детализируем процессы в документации

Параллельно с отрисовкой схем нужно зафиксировать их целевое состояние и основные атрибуты в документации. При формализации целевого состояния рекомендуем обратить внимание на то, с помощью чего процесс автоматизируется, какую отчётность он создаёт, какая документация должна быть создана в его рамках, какими навыками должны обладать участники процесса и т. д. Это удобно сделать в карточке или паспорте процесса.

Оптимально, если в этом документе будут следующие пункты:

• краткое описание процесса;
• цели и задачи, границы процесса;
• взаимосвязь с другими процессами;
• владелец процесса и RACI-матрица;
• используемые средства автоматизации;
• показатели эффективности;
• области улучшения процесса;
• отчётность.

Цель — в том, чтобы сопроводить наши схемы кратким описанием, зафиксировать все особенности процесса в одном месте. После того как процессы будут отрисованы, можно приступать к «перезагрузке» комплекта нашей ОРД по информационной безопасности. Сопоставление «процесс ИБ — документ, регламентирующий процесс» поможет сделать комплект документов связным и ничего не забыть.

Шаг № 6. Определяем области контроля и измеряем

На заключительном этапе «перезагрузки» необходимо определить области измерения, которые помогут нам понять, работают ли процессы так, как мы их смоделировали, улучшаются ли они со временем.

В общем виде оценка ИБ состоит из трёх компонентов: модель оценки, критерии и свидетельства. Вот несколько примеров параметров, которые можно измерять, чтобы «держать руку на пульсе»:

• метрики процессов ИБ;
• степень приближения процесса ИБ к целевому состоянию;
• потери от ИБ-инцидентов;
• уровень удовлетворённости бизнеса;
• степень снижения рисков.

Чтобы увязать параметры в своей методологии перезагрузки, мы используем собственную модель — «модель здоровья». Это — математический аппарат, который позволяет получить интегрированный уровень здоровья ИБ (как правило, для топ-менеджмента) и детальные оценки для каждого процесса. В качестве инструмента визуализации могут использоваться как Excel, так и системы BI.

Выводы

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

Вот несколько причин, почему мы рекомендуем использовать именно процессный подход.

• Он визуализирует взаимодействие между разрозненными подразделениями: что, кому / от кого, для чего они передают или принимают. Проще взаимодействовать с ИТ и другими подразделениями — прозрачно, что мы «отдаём» и «получаем». Вдобавок мы устраняем зоны неопределённой ответственности, которые иногда возникают на стыках подразделений.
• Позволяет упростить процессы и выявить дублирующие функции.
• Упрощает разработку документации. Правильно смоделированные процессы — это половина работы.
• Позволяет наглядно увидеть деятельность ИБ, понять последовательность и взаимосвязь процессов, а также возможности улучшения. Все процессы ИБ визуализированы.

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

Авторы:

Александр Морковчин, эксперт Центра информационной безопасности компании «Инфосистемы Джет»

Глеб Карманов, консультант Центра информационной безопасности компании «Инфосистемы Джет»