Распределение обязанностей в процессах ИБ (RACI)

Как будет выглядеть самая тривиальная модель распределения обязанностей? Вот у нас есть отдел ИБ: начальник, Вася, Петя и Ваня. Руководитель ИБ говорит: "Вася, ты будешь у нас за антивирусы и по уязвимостям, Петя, ты занимаешься сетями и их безопасностью, Ваня, ты в ответе за мониторинг событий ИБ, а я буду согласовывать доступы и спрашивать вас "как дела?". Есть ли тут процессы? Как будет развиваться работа? Думаю, в данном варианте все будет сводиться к личностным качествам каждого сотрудника и "понятийному" взаимодействию. Да и в такой схеме не учитываются смежные подразделения, которые могут быть напрямую завязаны на задачи ИБ.

Как же нам это переродить в процессную деятельность? Давайте для начала ответим на вопросы: какие процессы и зачем они нужны? За базовую модель можно взять тот же стандарт ISO 27001, разбавив его своим восприятием работы ИТ и ИБ в конкретной компании. Сформируем табл. 1 с процессами и их целями.

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

Рассмотрим типовую структуру холдинговой компании и ее подразделений

Пусть у нас имеется головная компания (ГК) и ее филиалы. При этом каждый филиал имеет свою инфраструктуру ИТ.

Посмотрим, как можно интерпретировать наши процессы в форме RACI-матрицы. Рассмотрим процесс управления инцидентами ИБ, приведенный в табл. 2.

Давайте разберемся, как это читать. Менеджер инцидентов ИБ ГК подготавливает документы, которые будут определять сам процесс управления инцидентами ИБ, при этом он консультируется у руководителя ИБ ГК, и за само написание документов также ответственен руководитель ИБ головной компании. Руководитель ИБ филиала адаптирует их для самого филиала, при этом уточняя детали у своего руководителя ИТ и консультируясь с менеджером по инцидентам ГК, а ответственным за адаптацию и ввод документов в действие будет руководитель ИБ ГК. После написания документа с ним ознакомляются все вовлеченные сотрудники.

Руководитель ИБ филиала ставит задачи по настройке системы мониторинга, специалист эти задачи выполняет, консультируясь у профильных ИТ-специалистов. По результатам всех настроек все вовлеченные ИТ-специалисты информируются.

Далее происходит мониторинг событий ИБ, их эскалация до инцидента, а затем реагирование на сам инцидент со стороны профильного ИТ/ИБ-специалиста по рекомендациям менеджера инцидентов ИБ. По результатам инцидента ИБ пишется отчет и ведется реестр менеджером инцидентов ИБ ГК по каждому филиалу, ответственным за это является руководитель ИБ ГК. Менеджером инцидентов ИБ также ведется реестр типовых сценариев реагирования на инциденты ИБ. Результатом всей деятельности может являться то, что самые критичные инциденты и отчеты по ним обсуждаются на планерках руководства головной компании.

По каждой задаче нам необходимо определить, кто ее исполняет (R – Responsible), кто ответственен за результат (A – Accountable), кто консультирует до исполнения (C – Consult before doing), кто должен быть оповещен после исполнения (I – Inform after doing). Таким образом, мы получим так называемую матрицу RACI распределения обязанностей.

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

Для примера возьмем две ситуации ниже.

Первая ситуация: часть функционала ИБ делегирована на ИТ-подразделение. Допустим, ИТ-администратор СУБД- и Microsoft-систем одновременно занимается администрированием антивирусной защиты (АВЗ). Очевидно, что администрирование АВЗ для данного сотрудника будет вторичной задачей. Более того, руководитель ИБ в данном контексте вообще не несет ответственности за работу АВЗ (за ИТ-сотрудника и его работу будет отвечать руководитель ИТ). Но если расписать все задачи работы с АВЗ (проработка политик и задач, мониторинг состояния на конечных хостах, мониторинг оповещений, сбои в работе, обновления версий, мониторинг статей "про вирусы"…), станет очевидным, что такое распределение обязанностей может быть критичным для данного процесса ИБ и в какой-то момент стать причиной серьезного инцидента. Таким образом, мы можем составить две RACI-матрицы (текущую и целевую) и обосновать перенос функционала на ИБ-подразделение.

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

В то же время в зависимости от размера инфраструктуры может получиться так, что сотруднику ИБ по задачам администрирования АВЗ для выполнения обязанностей требуется в среднем всего 2–3 часа в рабочий 8-часовой день. Рациональным тут будет дополнить функционал сотрудника, например настройкой сканера уязвимостей и обработкой результатов. В данном случае его общая квалификация (по уязвимостям и зловредному ПО) будет работать здесь только в плюс (в отличие от ИТ-специалиста по СУБД и Microsoft). При этом само закрытие уязвимостей уже будет в зоне ответственности ИТ-подразделения (по консультациям сотрудника ИБ и информированию руководителя ИБ о закрытии уязвимости).

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

Проработка процессов ИБ и их задач – достаточно сложная, комплексная работа, которая требует глубоких знаний в области ИБ/ИТ и в целом работы бизнес-процессов компании. Описанный выше метод составления RACI-матриц позволяет структурировать текущие процессы ИБ и найти их изъяны (нехватку кадров, нехватку квалификации, нехватку ресурсов, отсутствие зон ответственности…), что в дальнейшем поможет наглядно обосновать необходимые изменения.