В современных компаниях процессы ИТ и информационной безопасности тесно взаимосвязаны, но часто управляются изолированно. ИТ-команды сосредоточены на обеспечении доступности и производительности инфраструктуры, в то время как специалисты по безопасности концентрируются на защите от угроз. В идеале их усилия должны дополнять друг друга, но на практике разрыв между этими направлениями создает серьезные проблемы.
Основная из них заключаются в том, что ИТ внедряет изменения, не всегда учитывая требования безопасности, а ИБ не всегда понимает, где и когда надо вводить контрольные механизмы и ограничения, в результате чего снижается реальная устойчивость компании к киберугрозам.
Кроме того, ИТ и ИБ могут руководствоваться разными стандартами и фреймворками: ITIL, COBIT, ISO 20000 — для ИТ; ISO 27001, NIST CSF — для ИБ. Эти стандарты слабо связаны между собой, что приводит к разным KPI, разным приоритетам и даже разному языку общения между командами.
Ситуация усугубляется еще и тем, что сами процессы в компании могут быть слабо формализованы или не описаны вообще. В ИТ отсутствие регламентов приводит к хаотичным изменениям инфраструктуры, неучтенным рискам и "серым" зонам ответственности. В ИБ неформализованные процессы выливаются в декларативные политики безопасности, которые невозможно последовательно применять на практике. Формализация в данном случае — не бюрократия, а необходимое условие для управляемой и безопасной инфраструктуры.
Почему ИБ и ИТ работают разрозненно
Именно с такой ситуацией мы и столкнулись на проекте по построению процессов ИБ у одного заказчика. Заказчик представляет из себя крупную ритейловую компанию со всеми вытекающими – разветвленная ИТ-инфраструктура (включая собственные и арендованные ЦОДы), множество самых разнообразных процессов от собственной разработки до SOC-a, большой штат (более 1000) опытных специалистов в ИТ и ИБ. Но процессы ИТ при этом формализованы частично, работа часто ведется интуитивно и несогласованно. Как итог – пробелы в обеспечении безопасности и постоянная необходимость «тушения пожаров» как со стороны ИТ, так и со стороны ИБ.
Таким образом, необходимость формализации процессов давно назрела и стала очевидной не только руководству, но и рядовым исполнителям. Был инициирован соответствующий проект, выделены ресурсы. Однако масштаб задач был таков, что охватить все процессы одновременно не представлялось возможным и нужно было оценить их значимость и расставить приоритеты, сосредоточившись в первую очередь на тех ИТ-процессах, которые критически влияют на непрерывность бизнеса компании и ее киберзащищенность. Такой подход позволяет добиться максимального эффекта при ограниченных ресурсах, закладывая основу для последующей полномасштабной трансформации всех ИТ-процессов.
Для системного решения данной задачи было предложено разработать Карту воздействия процессов ИТ на непрерывность и киберзащищенность. Этот инструмент позволил:
Выявить, визуализировать и оценить связи между процессами ИТ и ИБ;
Установить четкие и понятные критерии определения значимости процессов ИТ;
Подход к разработке карты можно условно разбить на несколько шагов:
Построение модели SIPOC по процессам;
Построение перекрестной матрицы взаимного влияния процессов;
Оценка полноты описания процессов и соответствия лучшим практикам;
Оценка значимости каждого процесса.
Шаг 1. Построение модели SIPOC
Напомню, что модель SIPOC — это инструмент описания процессов, который в сжатом виде фиксирует ключевые элементы: Поставщиков (Suppliers), Входы (Inputs), сам Процесс (Process), Выходы (Outputs) и Клиентов (Customers).
Был проведен экспресс-анализ, в рамках которого для каждого процесса были определены входящие и исходящие процессы и данные (артефакты).
Результаты по всем процессам были сведены в таблицу (матрицу SIPOC), выдержка из которой представлена ниже.
Как видно из таблицы, процесс Управление изменениями взаимодействует с тремя процессами-поставщиками (Управление непрерывностью, конфигурациями и обращениями) и двумя процессами-потребителями (Управление обновлениями и конфигурациями). Аналогично, у процесса Управления конфигурациями есть три процесса-поставщика и три процесса-потребителя. В столбцах «Вход артефакт» и «Выход артефакт» указаны соответствующие артефакты (информация, документы, запросы, отчеты итп), которые передаются между взаимодействующими процессами.
Шаг 2. Построение перекрестной матрицы
Для подсчета количества взаимных связей между процессами была построена перекрестная матрица, в строках и столбцах которой указаны процессы ИТ и ИБ, а на пересечении – признак наличия связи в соответствии с моделью SIPOC (1 – связь есть, пусто – связи нет).
Дополнительно путем опроса экспертов были выделены:
«важные» процессы, которые сфокусированы на эксплуатации и соблюдении требований SLA;
процессы, влияющие на киберзащищенность, нарушение функционирования которых может потенциально повлиять на реализацию рисков кибербезопасности.
Пример перекрестной матрицы представлен ниже.
В примере отражена только малая часть процессов. В реальности матрица включала в себя более 50-ти процессов. Поэтому что все расчеты выполнялись с использованием MS Excel, что делает модель достаточно гибкой, легко актуализируемой и адаптируемой под происходящие изменения.
Как интерпретировать результаты Давайте рассмотрим подробнее принцип формирования перекрестной матрицы на примере процесса Управление конфигурациями (строка 5).
В соответствии с моделью SIPOC, полученной на шаге 1, данный процесс является потребителем данных от пяти процессов-поставщиков:
Управление изменениями.
Управление инцидентами.
Контроль защищенности.
Управление доступом.
Управление угрозами.
Поэтому в ячейках на пересечении со столбцами соответствующих процессов (G5, I5, K5, L5, M5) проставляется «1».
В ячейках O5, P5 и Q5 автоматически рассчитывается количество входящих связей (проставленных единиц) от ИТ-процессов, важных ИТ-процессов и ИБ-процессов соответственно. Так, у процесса Управление конфигурациями получилось всего 5 процессов-поставщиков: 2 ИТ-процесса (O5), из которых оба важные (P5), и 3 ИБ-процесса (Q5).
После заполнения аналогичным образом связей по остальным процессам в строках 15, 16 и 17 автоматически будет рассчитано количество исходящих связей. Так, у процесса Управление конфигурациями получилось всего 4 процесса-потребителя: 3 ИТ-процесса (E15), из которых 2 важных (E16), и 1 ИБ-процесс (E17).
Таким образом нам удалось подсчитать количество входящих и исходящих связей для процессов ИТ и ИБ, в том числе с «важными» процессами
Шаг 3. Оценка полноты описания процессов и соответствия лучшим практикам
Следующим этапом стала оценка того, насколько существующие регламентные документы соответствуют лучшим практикам управления ИТ-процессами. Здесь нам на помощь приходит COBIT.
COBIT (Control Objectives for Information and Related Technologies) — это международный фреймворк для управления ИТ с фокусом на информационную безопасность и управление киберрисками. Многие компании используют его, как руководство для построения ИТ-процессов. Процессы обеспечения безопасного управления корпоративной информацией и технологиями согласно COBIT 2019 разделены на 5 категорий (доменов), включающих в себя 40 процессов, которые покрывают практически полный спектр всех целей и задач ИТ.
В рамках экспресс-анализа существующих регламентных документов для каждого процесса ИТ и ИБ было определено какую долю соответствующих требований COBIT они покрывают.
Результат оценки полноты покрытия требований COBIT на примере процесса Управления непрерывностью представлен ниже.
Шаг 4. Оценка значимых процессов
Как и говорилось ранее, карта воздействия процессов ИТ на непрерывность и киберзащищенность позволяет ранжировать процессы ИТ по значимости для определения порядка их формализации.
Значимость каждого процесса рассчитывается в процентах как среднее арифметическое следующих показателей:
Важность процесса, % – может принимать 2 значения: 100%, если процесс помечен как «Важный», 0%, если нет.
Влияние на киберзащищенность, % - может принимать 2 значения: 100%, если процесс помечен как влияющий на киберзащищенность, 0%, если нет.
Влияние на смежные процессы ИТ, % - среднее по двум показателям:
a) Степень влияния, % - доля ИТ-процессов-потребителей для данного процесса от максимально возможного количества ИТ-процессов-потребителей у других ИТ-процессов. b) Комплексность взаимодействия, % - доля смежных (входящих и исходящих) ИТ-процессов для данного процесса от максимально возможного количества смежных ИТ-процессов у других ИТ-процессов.
Влияние на важные процессы ИТ, % - среднее по двум показателям:
Влияние на процессы ИБ, % - доля смежных (входящих и исходящих) ИБ-процессов для данного процесса от максимально возможного количества смежных ИБ- процессов у других ИТ-процессов.
Оценка полноты покрытия, % - доля требований COBIT, не определенных в описаниях и документации по процессу.
Пример полученной таблицы с расчетом значимости процессов ИТ приведен ниже.
Как видим из примера, наиболее значимым у нас получился процесс Управление инцидентами за счет того, что он является важным, влияющим на кибербезопасность и имеет большое количество связей с другими ИТ и ИБ-процессами, в том числе важными. При этом, например, процесс Управление ИТ-услугами оказался значительно ниже по значимости, несмотря на то, что имеет максимальное из всех процессов количество связей с другими ИТ-процессами, так как он не имеет признаков «важности» и влияния на кибербезопасность. Аутсайдером списка является процесс Управление мощностями – он не отмечен, как важный и влияющий на киберзащищенность и имеет малое количество связей со смежными ИТ и ИБ-процессами.
Заключение
Ключ к эффективному взаимодействию – не в победе одной стороны над другой, а в построении прозрачных процессов, понятных обеим командам. Карта воздействия процессов ИТ на непрерывность и киберзащищенность помогает обоснованно расставить приоритеты формализации процессов на основе четких и понятных критериев определения значимости процессов ИТ.
В этой статье я поделился практическим подходом, который был разработан совместно с заказчиком (и дорабатывается до сих пор). Он не претендует на истину в последней инстанции — скорее, на стартовую точку для обсуждения и дальнейшего совершенствования.
Внедряйте системные подходы, учитесь друг у друга – и тогда ваши ИТ и ИБ станут не «оппозицией», а союзниками в борьбе за устойчивость бизнеса.