Своя команда или аутсорс ИБ: как выбрать критерии

Статья «Стратегия ИБ: план на год и бюджет» разбирает, как расставить приоритеты и посчитать бюджет в целом. Один из пунктов этого бюджета — решение, что делать своими силами, а что отдать подрядчику. Это решение принимают один раз для каждой функции, а не на каждом проекте заново, и стоит сверяться с ним при пересмотре стратегии.

Статья опирается на логику направления «Стратегия кибербезопасности» из методики зрелости Группы Сбер (источник); это методика для крупных компаний, мы используем её как ориентир и пересказываем своими словами.

Что должно получиться

Уровень	Что это значит на практике
2. Гигиенический	По каждой функции ИБ осознанно решено, кто её выполняет — своя команда, подрядчик или сочетание — и решение зафиксировано, а не меняется стихийно от проекта к проекту

Критерии сформулированы нами по мотивам методики, это ориентир, а не оценка соответствия.

Что нельзя передать полностью ни при каком подрядчике

Независимо от того, сколько функций отдано на аутсорс, внутри компании должны остаться:

Ответственность за решение. Подрядчик может обнаружить инцидент и дать рекомендацию, но решение «отключаем систему или нет» принимает сотрудник компании, который знает бизнес-контекст и несёт ответственность перед руководством.
Понимание, что вообще происходит. Хотя бы один человек внутри должен уметь прочитать отчёт подрядчика и задать содержательный вопрос, а не просто переслать отчёт руководству без разбора.
Контроль над критичными данными и доступами. Ключи шифрования, корневые учётные записи, доступ к резервным копиям — не передаются подрядчику полностью без возможности компании действовать самостоятельно при разрыве отношений с ним.

Критерии для каждой функции

Функция	Когда разумно держать внутри	Когда разумно отдать подрядчику
Круглосуточный мониторинг (SOC)	Крупная команда, сервисы критичны 24/7, достаточно бюджета на смены	Небольшая команда: содержать круглосуточную смену своими силами дороже и менее эффективно, чем подключить внешний SOC
Реагирование на инциденты	Базовые первые шаги (изоляция хоста, сбор журналов) — всегда своими силами, это вопрос скорости	Глубокое расследование сложных инцидентов (криминалистика, реверс-инжиниринг вредоносного ПО) — разумно привлекать по необходимости, содержать такую экспертизу постоянно дорого для небольшой компании
Тест на проникновение	Почти никогда полностью своими силами: независимость взгляда — часть ценности пентеста	Почти всегда подрядчик — см. как заказать пентест
Архитектурные решения и приоритеты	Всегда внутри: только сотрудник компании видит бизнес-контекст, бюджет и приоритеты целиком	Консультация по отдельному сложному решению — допустимо, финальное решение не передаётся
Базовая настройка и поддержка систем (hardening, патчи)	Если внутри уже есть системные администраторы — обычно эффективнее делать самим, зная специфику систем	Если своей команды администрирования нет вообще — разумно отдать вместе с поддержкой инфраструктуры целиком

Типовые модели сочетания

Один ответственный внутри + внешний SOC. Частый вариант для небольшой компании: ответственный за ИБ внутри принимает решения и работает с подрядчиками, круглосуточный мониторинг и часть реагирования — у внешнего поставщика.
Своя команда + периодический внешний аудит. Для компании с развитой собственной командой: повседневная работа внутри, а независимая проверка (пентест, аудит архитектуры) — снаружи для свежего взгляда.
Полный аутсорс с одним координатором. Для очень маленькой компании: почти все технические функции у подрядчика, внутри — один человек, который формулирует задачи подрядчику и принимает решения по его рекомендациям.

Риски, которые стоит явно учесть

Зависимость от одного подрядчика. Что произойдёт, если договор прекратится завтра — есть ли план перехода, остаются ли у компании собственные данные и доступы, или всё придётся восстанавливать с нуля.
Доступ подрядчика к данным компании. Оцените и зафиксируйте в договоре так же, как для любого поставщика: оценка рисков поставщиков.
Разрыв ответственности. Без явного распределения (кто есть «отвечающий» за конкретное решение, см. матрицу ответственности) при инциденте компания и подрядчик могут одновременно считать, что решение принимает другая сторона.

Диагностика

Симптом	Причина и что делать
Решение о привлечении подрядчика принимается заново на каждом проекте	Нет зафиксированной модели сочетания. Определите её один раз на уровне стратегии и сверяйтесь при планировании
Никто внутри компании не может прочитать отчёт подрядчика содержательно	Экспертиза полностью передана наружу. Оставьте внутри хотя бы одного человека, способного разобраться в отчёте и задать вопросы
При смене подрядчика компания теряет доступ к собственным данным и журналам	Доступы и ключи были только у подрядчика. При заключении договора зафиксируйте, что критичные доступы остаются у компании
Подрядчик и внутренняя команда спорят, кто должен был среагировать на инцидент	Нет явного распределения ответственности по типам решений. Пропишите это в матрице ответственности заранее, не во время разбора инцидента

Где это в модели зрелости

Материал относится к направлению «Стратегия кибербезопасности» (материалы направления, карта зрелости). Уровень 2 требует, чтобы распределение функций между своей командой и подрядчиками было осознанным решением, а не стечением обстоятельств: это напрямую влияет на бюджет и на то, кто реально отвечает за каждое решение.

Как проверить

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