В последнее время я стал часто слышать вопрос о том, а какой должна быть правильная структура службы ИБ? Причин учащению таких вопросов я вижу три - законодательство по КИИ, требующее создания служб ИБ, активность по SOCам и инициативы по цифровой трансформации. Это все немного разные причины обращения к вопросу формирования служб ИБ, но результат у них всех один и тот же. В первом случае, одинокий безопасник, часто находящийся в составе ИТ, смог донести до руководства требования приказов ФСТЭК, заодно и припугнув 10-тилетним лишением свободы за несоблюдение законодательства. Во втором случае, возникает непонимание, куда в действующей структуре ИБ, которая ориентирована на предотвращение угроз и выполнение требований compliance, необходимо поместить центр мониторинга. В третьем варианте, компании, активно внедряющие блокчейн, машинное обучение, Интернет-вещей и иже с ними, понимают, что существовавшая до этого структура службы ИБ не способствует адекватной защите новых прорывных технологий. И вот начинаются метания о правильной структуре службы ИБ.
Сразу надо сказать, что "правильной", единственно верной структуры не существует и не может быть в принципе, так как ее формирование зависит от множества факторов - зрелости, отношения к рискам, корпоративной культуры, использования аутсорсинга, распределенной структуры, наличия дочерних и зависимых обществ, функциональности ИТ-службы, подчиненности и т.п. Я бы выделил несколько функциональных блоков, которые должны реализовываться в рамках корпоративной ИБ. Это именно функциональные блоки, за которыми может следовать и оргштатное разделение ( а может и нет). Как мне кажется, тут выделены ключевые направления деятельности службы ИБ - защита данных и инфраструктуры, контроль доступа, мониторинг и реагирование на ИБ, администрирование, управление ИБ, названное на картинке модным термином "GRC", и архитектурный блок.
Кто-то функцию мониторинга и реагирования на инциденты целиком отдает на аутсорсинг, а кто-то создает под это направление отдельный центр (а кто-то нет). Где-то антивирусной защиты, управлением уязвимостями и управлением доступом занимается ИТ, а где-то это по-прежнему функция ИБ. Да те же межсетевые экраны. В одних компаниях их эксплуатацию давно отдали в службу ИТ, а в других ими "рулят" безопасники. Все очень условно и общих правил формирования службы ИБ не существует. Есть, однако, несколько аксиом, которые должны быть соблюдены:
Разбив на функциональные блоки структуру своей службы ИБ (ориентируясь на картинку выше), вы можете уже детализировать их наполнение и смотреть, что должно быть сделано в рамках, например, блока повышения осведомленности или управления рисками или разработки архитектуры. Например, это может выглядеть вот так (я эту схему рисовал для одного из проектов по проектированию SOC).
Обратите внимание на второй справа блок "Business Enablement". Он отвечает за уже набившую оскомину тему привязки ИБ к бизнесу и, в данном случае, за безопасность проектов по цифровой трансформации, которые реализовывались у заказчика. В итоге у вас может родиться вот такая структура службы ИБ.
Да вы охренели?! - скажете вы. Если каждый прямоугольник рассматривать как отдельную штатную единицу, то кто же мне даст 50 человек для обеспечения ИБ? Вспомните последние две аксиомы, которые я описал выше. Не пытайтесь делать все и не смотрите, как сделано у других. Я привел эту схему в качестве примера, в котором реализовано почти все описанные выше функциональные блоки. Вы, например, в вашем случае можете взять только ключевые функции и распределить их между, допустим, тремя специалистами по ИБ, включая и руководителя ИБ.
Вот как-то так получается с оргструктурой службы ИБ. Универсального ответа нет, но есть на что ориентироваться.
Сразу надо сказать, что "правильной", единственно верной структуры не существует и не может быть в принципе, так как ее формирование зависит от множества факторов - зрелости, отношения к рискам, корпоративной культуры, использования аутсорсинга, распределенной структуры, наличия дочерних и зависимых обществ, функциональности ИТ-службы, подчиненности и т.п. Я бы выделил несколько функциональных блоков, которые должны реализовываться в рамках корпоративной ИБ. Это именно функциональные блоки, за которыми может следовать и оргштатное разделение ( а может и нет). Как мне кажется, тут выделены ключевые направления деятельности службы ИБ - защита данных и инфраструктуры, контроль доступа, мониторинг и реагирование на ИБ, администрирование, управление ИБ, названное на картинке модным термином "GRC", и архитектурный блок.
Нет, постойте, скажете вы. А защита АСУ ТП где? А где контроль облачных сред? Правильно. Поэтому я написал в самом начале, что не бывает универсальной структуры. Все очень сильно зависит от окружения. У кого-то безопасность АСУ ТП - это прерогатива не службы ИБ, а службы АСУ ТП. У кого-то нет облаков и им не нужен отдельный функциональный блок, связанный с ними. А вот, например, в Cisco, пользующейся услугами около 700 облачных провайдеров по миру, служба ИБ содержит отдельное подразделение, которое отвечает именно за это, очень важное для нашего бизнеса направление. А кто-то создает отдельный блок, связанный с защитой прорывных технологий - блокчейна, больших данных, машинного обучения и т.п.
Кто-то функцию мониторинга и реагирования на инциденты целиком отдает на аутсорсинг, а кто-то создает под это направление отдельный центр (а кто-то нет). Где-то антивирусной защиты, управлением уязвимостями и управлением доступом занимается ИТ, а где-то это по-прежнему функция ИБ. Да те же межсетевые экраны. В одних компаниях их эксплуатацию давно отдали в службу ИТ, а в других ими "рулят" безопасники. Все очень условно и общих правил формирования службы ИБ не существует. Есть, однако, несколько аксиом, которые должны быть соблюдены:
- следуйте за процессами
- разделяйте реализацию и надзор
- не пытайтесь делать все - делегируйте
- не смотрите, как у других.
Разбив на функциональные блоки структуру своей службы ИБ (ориентируясь на картинку выше), вы можете уже детализировать их наполнение и смотреть, что должно быть сделано в рамках, например, блока повышения осведомленности или управления рисками или разработки архитектуры. Например, это может выглядеть вот так (я эту схему рисовал для одного из проектов по проектированию SOC).
Обратите внимание на второй справа блок "Business Enablement". Он отвечает за уже набившую оскомину тему привязки ИБ к бизнесу и, в данном случае, за безопасность проектов по цифровой трансформации, которые реализовывались у заказчика. В итоге у вас может родиться вот такая структура службы ИБ.
Да вы охренели?! - скажете вы. Если каждый прямоугольник рассматривать как отдельную штатную единицу, то кто же мне даст 50 человек для обеспечения ИБ? Вспомните последние две аксиомы, которые я описал выше. Не пытайтесь делать все и не смотрите, как сделано у других. Я привел эту схему в качестве примера, в котором реализовано почти все описанные выше функциональные блоки. Вы, например, в вашем случае можете взять только ключевые функции и распределить их между, допустим, тремя специалистами по ИБ, включая и руководителя ИБ.
Вот как-то так получается с оргструктурой службы ИБ. Универсального ответа нет, но есть на что ориентироваться.
