Журнал "Information Security/ Информационная безопасность" #3, 2019

В реальном мире часто бывает, что несколько ролей выполняет один-единствен- ный сотрудник либо некото- рые задачи и процессы могут быть общими для всей филиальной сети и выпол- няться только на уровне головной компании. Понять, правильно ли это или нет, как раз и поможет данный метод. для обучения сотрудников по ИБ (Awareness) может привле- каться отдел кадров, для напи- сания регламентов в части выполнения законодательных требований – юридический отдел, в части физической без- опасности – служба безопасно- сти. Для отдельных задач в RACI-матрицах могут появлять- ся и подрядные организации. Для примера возьмем две ситуации ниже. Первая ситуация: часть функ- ционала ИБ делегирована на ИТ-подразделение. Допустим, ИТ-администратор СУБД- и Microsoft-систем одновременно занимается администрировани- ем антивирусной защиты (АВЗ). Очевидно, что администриро- вание АВЗ для данного сотруд- ника будет вторичной задачей. Более того, руководитель ИБ в данном контексте вообще не несет ответственности за работу АВЗ (за ИТ-сотрудника и его работу будет отвечать руково- дитель ИТ). Но если расписать все задачи работы с АВЗ (про- работка политик и задач, мони- торинг состояния на конечных хостах, мониторинг оповеще- ний, сбои в работе, обновления версий, мониторинг статей "про вирусы"…), станет очевидным, что такое распределение обя- занностей может быть критич- ным для данного процесса ИБ и в какой-то момент стать при- чиной серьезного инцидента. Таким образом, мы можем составить две RACI-матрицы (текущую и целевую) и обосно- вать перенос функционала на ИБ-подразделение. В то же время в зависимости от размера инфраструктуры может получиться так, что сотруднику ИБ по задачам адми- нистрирования АВЗ для выпол- нения обязанностей требуется в среднем всего 2–3 часа в рабо- чий 8-часовой день. Рациональ- ным тут будет дополнить функ- ционал сотрудника, например настройкой сканера уязвимостей и обработкой результатов. В дан- ном случае его общая квалифи- кация (по уязвимостям и зло- вредному ПО) будет работать здесь только в плюс (в отличие от ИТ-специалиста по СУБД и Microsoft). При этом само закры- тие уязвимостей уже будет в зоне ответственности ИТ-под- разделения (по консультациям сотрудника ИБ и информирова- нию руководителя ИБ о закрытии уязвимости). Возможна и обратная ситуа- ция, когда в ИБ-подразделении включены дублирующие роли по администрированию ИТ-систем (например, сетевой инфраструк- туре). Такое возможно, когда подразделения не хотят иметь общие зоны ответственности (ИТ-специалист отвечает, чтобы сеть не упала, а ИБ – настраива- ет сегментацию и системы без- опасности). Рационально ли это? Не всегда. В данном случае можно распределить зоны ответ- ственности между ИТ- и ИБ- руководителями по конкретным задачам, как раз используя RACI- матрицу, но при этом оставив одного высококвалифицирован- ного специалиста по сетевой инфраструктуре вместо двух. Проработка процессов ИБ и их задач – достаточно сложная, комплексная работа, которая требует глубоких знаний в обла- сти ИБ/ИТ и в целом работы бизнес-процессов компании. Описанный выше метод состав- ления RACI-матриц позволяет структурировать текущие про- цессы ИБ и найти их изъяны (нехватку кадров, нехватку ква- лификации, нехватку ресурсов, отсутствие зон ответственно- сти…), что в дальнейшем помо- жет наглядно обосновать необходимые изменения. l • 45 УПРАВЛЕНИЕ www.itsec.ru Задача/Роль (сотрудник) Специа- Оператор Техни- Админи *** Менеджер Руково- Руково Руково- лист системы ческая стратор инциден- дитель дитель дитель по ИБ монито- под- ИТ-инфра- тов ИБ ГК ИТ- ИБ- ИБ ГК ринга держка структуры филиала филиала Разработка и редакция политики *** R AC и процедур управления инцидентами ИБ Адаптация политики I I I I *** IС C R A и процедур для филиала Разработка технических правил R I CI CI *** I I A мониторинга событий ИБ Мониторинг событий ИБ. I R I I *** A Регистрация событий ИБ и их классификация как инцидентов Реагирование на инцидент ИБ I R *** CI A I со стороны хоста пользователя Реагирование на инцидент ИБ I R *** CI A I со стороны инфраструктурного сервера *** *** *** *** *** *** *** *** *** *** Ведение типовых сценариев *** R I A реагирования на инциденты ИБ Ведение реестра инцидентов ИБ *** R I A и написание отчетности по всем филиалам и головной компании *** – нужно расширить в зависимости от вариантов и типов инцидентов. Табл. 2. RACI-управление инцидентами ИБ Ваше мнение и вопросы присылайте по адресу is@groteck.ru