Почему ИТ и информационная безопасность часто оказываются по разные стороны баррикад — и как превратить их в союзников? IT-World разбирается, как выстроить эффективное взаимодействие между командами через коммуникации, метрики и матричную структуру управления. Практические подходы показывают, как согласовать интересы бизнеса, ИТ и ИБ без конфликтов и потери эффективности.
Отношения между айтишниками и безопасниками во многом являются результатом того, как осознается потребность в обеспечении ИБ. Регуляторные требования укорачивают этот путь, добавляя ИБ прямо в те процессы, которые уже есть в компании, но суть дела не меняют.
Почему ИТ появляется раньше, чем ИБ
При формировании нового продукта основное внимание уделяется бизнес-ценности: как быстро вывести продукт на рынок, какие функции удовлетворят клиентов и как оптимизировать операционные расходы. Именно здесь появляются первые требования к информационным системам, и их реализует ИТ. После формирования бизнес-процесса приходит время повышения эффективности за счет цифровой трансформации: ручные операции заменяются программными решениями, данные централизуются. И опять функция ИТ доминирует. И только когда процесс устоится, он привлекает внимание к рискам: утечка данных, несанкционированный доступ, отказ оборудования и т. д. Только на этом этапе формируется реальная необходимость внедрять меры ИБ — от политики доступа до комплексных систем мониторинга.
Исторически роль обеспечения безопасности зачастую ложилась на плечи ИТ-отделов: они отвечали за установку патчей, резервное копирование, настройку сетевых экранов и т. п. И это объясняет, почему многие специалисты по ИТ уже обладают глубокими знаниями в области защиты данных. И почему к специалистам ИБ со стороны ИТ иногда возникает недоверие. А если судить по картам компетенций специалистов, то провести границу между информационными технологиями (ИТ) и информационной безопасность (ИБ) довольно сложно. Часто для работы нужны одни и те же навыки. И все же цели у ИТ и ИБ разные.
Внутри любой компании ИТ-системы управляют ключевыми ресурсами: от корпоративной сети до облачных платформ и устройств конечных пользователей. Именно этот контроль делает ИТ центральным элементом безопасности — в случае сбоев, атак или ошибок конфигурации последствия могут быть катастрофическими. Когда ИТ отвечает одновременно за эффективность процессов и их защиту, возникают конфликты интересов. И давайте поговорим о том, как мы решали этот вызов.
Как это работает на практике
У нас накопилось множество примеров, как может быть организовано взаимодействие между ИТ и ИБ. Но самый главный пример — это собственный опыт. Для решения собственных задач и ИТ, и ИБ реализованы как услуги для бизнес-подразделений. По этим услугам разработаны SLA и предусмотрены разные форматы взаимодействия. Такая модель показала высокую эффективность, но были и подводные камни. Пришлось придумать, как обеспечить готовность к оперативным изменениям в СМИБ только ресурсами vCISO и замотивировать бизнес-подразделения.
Внутренняя организация предоставления услуг была устроена так, что ИБ оказалось в подчинении ИТ. И на старте в ряде случаев ИБ попадала в ситуации, когда процессы ИБ уже выполняются специалистами из ИТ, причем хорошо, но не в полном объеме, а никаких точек влияния на них нет. Преодолевая этот вызов, мы применили универсальный подход к управлению коммуникациями с заинтересованными лицами. Заодно интегрировав его в оценку требований заинтересованных лиц по ISO27001. Подход не сложный, всего пять шагов:
- Сформировать матрицу ответственности RA на основании перечня контролей в заявлении о применимости. Это урезанный вариант RACI, поскольку на данном этапе важны лишь роли, непосредственно выполняющие задачи.
- Для каждого ИТ-подразделения необходимо посчитать количество задач, которые они уже решают или могут решать. Объем таких задач служит оценкой доступных ресурсов конкретного заинтересованного лица (ЗЛ). Чем больше задач, потенциально решаемых подразделением, тем выше оценка. Для дальнейших вычислений оценку нужно привести к виду шкалы от 0 до 10. Сделать это можно, разделив объем задач на их общее количество, — так мы получим процент. А умножив на 10, получим необходимую оценку.
- Для каждого ИТ-подразделения необходимо определить уровень заинтересованности в эффективном исполнении задач ИБ. Даже если нет никаких данных, оценку можно получить экспертно. А чтобы уйти от субъективности, мы подготовили чек-лист, который заодно заполняли на внутренних аудитах ИБ. В первую версию чек-листа вошли экспертные оценки: знание применимых требований по ИБ, наличие актуальной документации, готовность к диалогу, готовность проводить встречи, время ответа на почту менее двух дней. Позднее к нему добавился NPS-опросник и еще ряд воспроизводимых метрик. Но на старте хватило и такого.
- Определить стратегию коммуникаций. Это автоматическое вычисление. На основании двух оценок мы получаем четыре варианта: вовлекать (высокое влияние), активно вовлекать (высокие влияние и интерес), информировать (низкие влияние и интерес), оказывать внимание (высокий интерес).
- Стратегия представляет собой набор тактик, для которых нужно сформулировать применимые способы реализации. Нужно подобрать процессы, информацию и формат коммуникаций для каждой тактики. Для каждой стратегии свой набор:
- a. вовлекать: держать в курсе; формировать ожидания;
- b. активно вовлекать: держать в курсе; формировать ожидания; согласовывать; работать с обратной связью; вовлекать;
- c. информировать: держать в курсе;
- d. проявлять внимание: держать в курсе; формировать ожидания; работать с обратной связью; вовлекать.
Следование такому подходу позволяет выстроить осмысленные коммуникации. В конце концов, мы работаем с большой сложной системой, изменить которую порой просто невозможно. У ИБ нет ресурса по перестраиванию процессов, но есть возможность дополнить существующую модель информационными потоками, теми самыми коммуникациями. Это позволяет обеспечить совершенствование процессов ИБ. Если так вышло, что ИБ оказалось в составе ИТ, то, следуя такому подходу, мы можем выстроить матричную структуру.
Почему одной схемы коммуникации недостаточно
В идеальной ситуации, если коллеги из ИТ с высокой долей пересечения по задачам уже активно интересуются вопросами ИБ, то их можно добавлять в процессы в роли C (консультирующих), если пересечения нет, то вовлечение стоит ограничить ролью I (информированием). Со временем такой интерес даже может создать амбассадоров.
Гораздо сложнее, когда коллеги из ИТ не заинтересованы или изначально настроены враждебно. В этом случае начать стоит с базовых коммуникаций. Проведения вебинаров, организации внутреннего или внешнего обучения для таких специалистов. Со своей стороны желательно полностью освоить пул технологий, которым владеют коллеги и уметь говорить с ними на одном языке. Для нас важно, что в перспективе сформировать у ИТ интерес к ИБ реально.
Разумеется, нам попадались примеры, где ИБ и ИТ не дружили, и это довольно опасная ситуация. Особенно когда дело доходит до административного разделения ответственности. Получается, что ИТ и ИБ работают параллельно. Средства защиты иногда могут «сами» выключаться. Политики не исполняются, а «бумажки» никому не нужны. Доводить до подобного определенно не стоит.
KRI и KPI как инструмент договоренности
Но вернемся к коммуникациям. Чтобы матричная структура работала не как клуб друзей по интересам, а как единый отлаженный механизм, нужна понятная и прозрачная система принятия решений. Достичь этого можно путем формирования показателей. И в первую очередь нас интересуют два вида показателей:
- Ключевые индикаторы риска (Key Risk Indicators, KRI). Идея этой группы показателей состоит в том, чтобы обосновать, что мы собираемся делать что-то, потому что возникает либо предрисковое состояние (предикативный показатель), либо что риск уже реализован (индикативный показатель), и мы разбираем инцидент.
- Показатель управления (это уже Key Performance Indicators, KPI). Эта группа показателей устанавливает ожидаемую эффективность защитных механизмов.
Один и тот же показатель может попасть и в первую, и во вторую группу. А отличие будет состоять только в его цели. Для примера: процент покрытия инфраструктуры средствами антивирусной защиты может показывать нашу эффективность, а может указывать на вероятность заражения вредоносным ПО. В первом случае беспокоиться нужно подразделению ИБ, во втором и ИБ, и ИТ.
Показатель будет работать, только если его легко посчитать и он действительно нужен для принятия решений. А еще лучше, если решения на основании показателя будет принимать само заинтересованное лицо. Обсуждение именно таких показателей позволяет достигать общих целей. А совместное решение с гораздо большей вероятностью будет реализовано, нежели спущенное сверху. А для информирования подобные показатели создадут нужную прозрачность.
Подводя итог, можно определить матричную структуру как наиболее жизнеспособную. Именно в ней есть шанс превратить каждого сотрудника в «безопасника». В конечном счете решающим фактором станет наличие коммуникации в виде вполне конкретных мероприятий и корректно сформулированные роли матрицы RACI.