Создание службы ИБ: от одного специалиста до полноценного департамента

Создание службы ИБ: от одного специалиста до полноценного департамента

Что такое служба информационной безопасности и какие задачи она решает

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

Задачи службы ИБ охватывают три ключевых направления: предотвращение инцидентов, обнаружение атак и реагирование на них. К первому направлению относятся разработка политик безопасности, управление уязвимостями, контроль доступа. Второе направление включает мониторинг событий безопасности, анализ аномалий. Третье направление - это расследование инцидентов, устранение последствий, взаимодействие с правоохранительными органами при необходимости.

Ключевые функции службы ИБ в организации

Функциональная модель службы ИБ строится вокруг жизненного цикла управления рисками. Идентификация активов - первая функция, включающая инвентаризацию систем, классификацию данных, определение критичности. Без понимания того, что защищать, невозможно выстроить адекватную защиту.

Оценка рисков - вторая базовая функция. Служба ИБ анализирует угрозы, уязвимости и потенциальный ущерб для каждого актива. Результатом становится реестр рисков с приоритизацией по критичности. Этот документ определяет, куда направить ресурсы в первую очередь.

Внедрение контролей - третья функция, охватывающая технические и организационные меры защиты. Техническому контролю подлежат межсетевые экраны, системы обнаружения вторжений, защиты веб-приложений, антивирусных средств защиты, DLP-решения (предотвращение утечек конфиденциальной информации из информационной системы), средства шифрования, PAM-системы (управление привилегированным доступом) и прочие модули, входящие в комплексную систему защиты информационной безопасности. Организационные меры - это политики, регламенты, обучение персонала, проверки контрагентов.

Мониторинг и реагирование - четвертая функция, обеспечивающая непрерывный контроль состояния безопасности. Служба ИБ отслеживает события в инфраструктуре, выявляет аномалии, расследует инциденты. Скорость реагирования напрямую влияет на размер ущерба от атаки. Применяются решения класса SIEM-систем (сбора и анализа событий информационной безопасности), XDR (+EDR)  – (обеспечение мониторинга, обнаружения и реагирования на угрозы на конечных устройствах).

Комплаенс (compliance, соответствие стандартам) - пятая функция, связанная с выполнением требований регуляторов и стандартов. В российских условиях это 152-ФЗ о персональных данных, 187-ФЗ о критической информационной инфраструктуре, приказы ФСТЭК России 117, 21 отраслевые требования ЦБ РФ для финансового сектора.

Чем служба ИБ отличается от ИТ-отдела

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

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

Поэтому совмещение функций ИТ и ИБ в одном подразделении создает конфликт интересов. Сотрудник, который сам настраивает систему, не должен сам же проверять ее безопасность. Принцип разделения обязанностей (separation of duties) - фундамент эффективного контроля.

С чего начинается ИБ - этап единственного специалиста

Запуск функции ИБ обычно начинается с найма одного специалиста по информационной безопасности. Этот человек становится универсалом, совмещающим роли аналитика, инженера, консультанта и менеджера. Главная задача на этом этапе - не пытаться закрыть все направления, а сфокусироваться на критичных рисках и выстроить фундамент для дальнейшего развития.

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

Приоритетные задачи для одного специалиста ИБ

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

Приоритет номер один - защита периметра и контроль доступа. Настройка межсетевого экрана, сегментация сети, внедрение парольной политики, отключение неиспользуемых учетных записей. Эти меры закрывают до 80% типовых векторов атак при минимальных затратах.

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

Приоритет номер три - Security awareness. Обучение сотрудников распознавать фишинг и социальную инженерию дает измеримый эффект. По данным Verizon DBIR 2024, человеческий фактор присутствует в 68% успешных атак (Источник: Verizon, 2024). Простой тренинг и тестовые фишинговые рассылки снижают этот риск.

Какие процессы запустить в первую очередь

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

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

Процесс управления доступом - третий обязательный элемент. Кто имеет доступ к каким системам, как предоставляется и отзывается доступ, как происходит согласование. Интеграция с HR-процессами найма и увольнения предотвращает ситуации, когда уволенный сотрудник сохраняет доступ к корпоративным ресурсам.

Типичные ошибки на старте

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

Ошибка вторая - изоляция от бизнеса. Специалист ИБ работает в вакууме, не выстраивает отношения с руководителями подразделений, не объясняет смысл ограничений. Результат - саботаж политик безопасности, обход контролей, конфликты. Коммуникация с бизнесом - такая же важная компетенция, как техническая экспертиза.

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

Как определить оптимальный размер команды ИБ

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

Базовый принцип: минимальная команда ИБ должна обеспечивать покрытие критичных функций без единой точки отказа. Один человек - это точка отказа по определению. Команда из двух специалистов позволяет организовать взаимозаменяемость и разделение зон ответственности.

Факторы, влияющие на численность службы ИБ

Размер организации - первый фактор. Количество сотрудников определяет объем работы по управлению доступом, обучению, контролю конечных (endpoint)-устройств. Количество ИТ-систем определяет объем работы по контролю уязвимостей (vulnerability management) и мониторингу.

Отраслевая специфика - второй фактор. Финансовый сектор, здравоохранение, критическая инфраструктура имеют жесткие регуляторные требования, предполагающие расширенный штат ИБ. Например, компания из 500 человек в банковской сфере нуждается в большей команде ИБ, чем производственное предприятие аналогичного размера.

Модель бизнеса - третий фактор. Онлайн-сервис с миллионом пользователей предъявляет иные требования к ИБ, чем офлайн-бизнес с локальной инфраструктурой. Обработка платежных данных, персональных данных клиентов, интеллектуальной собственности - каждый тип данных добавляет требования к защите.

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

Формулы и бенчмарки расчета штата

Отраслевой бенчмарк: соотношение ИБ-специалистов к общей численности персонала варьируется от 1:200 в низкорисковых отраслях до 1:50 в высокорисковых.

Функциональный расчет: определяются необходимые функции ИБ, оценивается трудоемкость каждой, рассчитывается требуемое количество FTE (full-time equivalent). Мониторинг 24/7 требует минимум 5 человек для организации сменной работы. Compliance с несколькими стандартами требует выделенного специалиста.

Когда пора расширять команду

Сигнал первый: накопление технического долга. Уязвимости не закрываются вовремя, инциденты не расследуются до конца, документация устаревает. Это индикатор перегрузки текущей команды.

Сигнал второй: регуляторные требования. Появление новых обязательств - субъект КИИ, требования ЦБ, сертификация по ISO 27001, соответствия требованиям ГИС - означает дополнительный объем работы, который не покрывается текущим штатом.

Сигнал третий: рост бизнеса. Удвоение числа сотрудников, выход в новые регионы, запуск новых сервисов, онлайн-каналов - каждое изменение увеличивает поверхность атаки и требует адекватного усиления защиты.

Сигнал четвертый: инциденты. Серьезный инцидент - утечка данных, успешная атака, штраф регулятора - часто становится триггером для расширения команды ИБ. Лучше инвестировать в предотвращение инцидентов, чем платить за их устранение.

Этапы масштабирования службы ИБ - от 1 до 15+ человек

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

Команда из 2-3 специалистов - первое расширение

Переход от одного специалиста к команде из 2-3 человек - первый качественный скачок. Появляется возможность разделить зоны ответственности: один сотрудник фокусируется на операционной безопасности (мониторинг, реагирование), второй - на управление и внедрение. 

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

Ключевые задачи этапа: формализовать процессы, внедрить базовую автоматизацию (например, SIEM), наладить регулярную отчетность для руководства. Команда из 3 человек способна поддерживать ИБ-функцию для компании до 300-500 сотрудников при умеренном уровне рисков.

Команда из 5-7 человек - формирование направлений

При численности 5-7 человек появляется полноценная организационная структура. Выделяется руководитель службы ИБ - либо CISO, либо начальник отдела ИБ. Формируются направления работы с закрепленными ответственными.

Типичная структура:

✓ Руководитель службы ИБ (1 человек)
✓ Направление мониторинга и реагирования (2 человека)
✓ Направление комплаенса и аудита (1-2 человека)
✓Направление технической безопасности (1-2 человека)


На этом этапе появляется внутренняя специализация. Один сотрудник развивает экспертизу в сетевой безопасности, другой - в защите приложений, третий - в комплаенс. Это повышает глубину экспертизы, но создает зависимость от конкретных людей.

Ключевые задачи этапа: внедрить полноценный SOC (хотя бы в режиме 8x5), запустить программу управления уязвимостями с покрытием всех критичных систем, выстроить регулярный цикл аудитов и проверок.

Департамент ИБ - 10+ специалистов

При численности свыше 10 человек служба ИБ трансформируется в департамент с несколькими отделами. Появляется многоуровневая иерархия: руководитель департамента (CISO), руководители направлений, специалисты.

Типичная структура департамента ИБ:

• CISO (директор по информационной безопасности).
• Отдел оперативной безопасности (SOC): руководитель + 4-6 аналитиков.
• Отдел governance и compliance: руководитель + 2-3 специалиста.
• Отдел технической безопасности: руководитель + 2-4 инженера.
• 1-2 архитектора ИБ.

На этом этапе становится экономически оправданным SOC в режиме 24x7. Появляются роли второй и третьей линии поддержки: аналитики L1 обрабатывают инциденты, L2 расследуют подтвержденные инциденты, L3 занимаются активным поиском скрытых угроз и расследованием инцидентов.

Ключевые задачи этапа: обеспечить покрытие всех функций ИБ собственными ресурсами, внедрить продвинутые инструменты (SOAR, threat intelligence платформы), выстроить метрики и KPI для каждого направления.

Организационная структура и модели подчинения службы ИБ

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

Варианты подчинения CISO в организации

Подчинение CIO (ИТ-директору) - распространенная модель, особенно на ранних этапах развития ИБ. Преимущества: тесная интеграция с ИТ, упрощенное бюджетирование, техническая синергия. Недостаток: конфликт интересов между доступностью и безопасностью решается в пользу ИТ.

Подчинение CEO (генеральному директору) - модель, подчеркивающая стратегическую важность ИБ. CISO участвует в управленческих совещаниях, имеет прямой доступ к первому лицу. Эта модель рекомендуется для компаний, где информационная безопасность критична для бизнеса.

Подчинение CFO (финансовому директору) - модель, связывающая ИБ с управлением рисками и compliance. Характерна для финансового сектора, где CFO часто отвечает за операционные риски.

Подчинение совету директоров - модель для крупных публичных компаний. CISO докладывает напрямую комитету по аудиту или комитету по рискам совета директоров. Обеспечивает независимость ИБ от операционного менеджмента.

"Подчинение CISO должно обеспечивать независимость от тех, чью деятельность он контролирует. Когда CISO подчиняется CIO, возникает системный конфликт интересов" - позиция ISACA и большинства фреймворков корпоративного управления.

Централизованная и распределенная модели

Централизованная модель предполагает концентрацию всех функций ИБ в едином подразделении. Все специалисты ИБ подчиняются CISO, вся экспертиза сосредоточена в одном месте. Преимущества: единые стандарты, эффективное использование ресурсов, четкая ответственность. Недостаток: удаленность от бизнес-подразделений, риск бюрократизации.

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

Гибридная модель сочетает центральную команду ИБ (стратегия, стандарты, SOC) с распределенными специалистами в подразделениях (операционная поддержка). Эта модель оптимальна для крупных холдингов и географически распределенных организаций.

Взаимодействие с ИТ, юристами и бизнес-подразделениями

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

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

Взаимодействие с бизнесом - наименее формализованная, но наиболее важная область. CISO должен говорить на языке бизнеса: не "мы внедрили SIEM", а "мы сократили время обнаружения атаки с 72 до 4 часов, что снижает потенциальный ущерб на 60%". Security Business Partners - роль, обеспечивающая трансляцию между технической командой ИБ и бизнес-заказчиками.

Какие роли и компетенции нужны в команде ИБ

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

Как использовать гибридную модель - инхаус плюс аутсорсинг

Чистая инхаус-модель подразумевает выполнение всех функций ИБ собственными силами. Чистая аутсорсинг-модель передает все на внешних провайдеров. На практике оптимальный результат дает гибридная модель, сочетающая преимущества обоих подходов.

Какие функции передать на аутсорсинг

Функции, оптимальные для аутсорсинга:

• Мониторинг 24x7 (SOC) - требует большой команды для сменной работы
• Пентесты - требуют специализированной экспертизы, проводятся периодически
• Выявление угроз - агрегация данных эффективнее на больших масштабах
• Forensics и incident response - требуют редкой экспертизы, нужны эпизодически

Функции, которые лучше сохранить инхаус:

• Стратегия и управление- требуют глубокого понимания бизнеса
• Risk management - интеграция с бизнес-процессами
• Security architecture - долгосрочные решения, контекст организации
• Awareness - корпоративная культура, внутренние коммуникации

Критерии принятия решения:

1. Критичность функции для бизнеса (критичное - инхаус)
2. Требуемая частота (постоянно - инхаус, эпизодически - аутсорс)
3. Уникальность контекста (уникальный - инхаус, стандартный - аутсорс)
4. Экономика (дешевле снаружи - аутсорс, с учетом качества)

Managed SOC и MSSP-провайдеры

MSSP (Managed Security Service Provider) - провайдер, оказывающий услуги мониторинга и управления безопасностью. Managed SOC - флагманский сервис большинства MSSP.

Типичный объем услуг MSSP:

• Сбор и анализ логов

• Мониторинг инцидентов 24x7

• Первичное реагирование на инциденты

• Отчетность и рекомендации

• Управление SIEM-инфраструктурой

При выборе MSSP следует оценивать: Соглашение об уровне сервиса (SLA) по времени реагирования, глубину анализа (не только L1), интеграцию с инхаус-командой, возможность кастомизации правил, прозрачность ценообразования.

Важные детали при работе с MSSP:

✓ Данные остаются собственностью заказчика
✓ Четко определить границы ответственности
✓ Регулярные обзорные совещания (review meetings)
✓ План выхода (exit strategy) на случай смены провайдера
✓ Соответствие провайдера регуляторным требованиям

Бюджетирование и обоснование затрат на службу ИБ

Бюджет службы ИБ - постоянный предмет переговоров между CISO и финансовым руководством. Умение обосновать затраты в терминах бизнес-ценности - ключевая компетенция руководителя ИБ.

Структура бюджета ИБ - CAPEX и OPEX

CAPEX (капитальные затраты):

• Приобретение средств защиты (SIEM, DLP, NGFW, PAM, и пр. СЗИ, СКЗИ)
• Лицензии на ПО (единоразовые)
• Оборудование SOC
• Проектирование и внедрение

OPEX (операционные затраты):

• Фонд оплаты труда команды ИБ
• Подписки и ежегодные лицензии
• Услуги MSSP и консультантов
• Обучение и сертификация
• Аудиты и пентесты

Соотношение CAPEX/OPEX варьируется в зависимости от зрелости ИБ. На этапе становления преобладает CAPEX (инвестиции в инфраструктуру). На зрелом этапе доля OPEX растет (поддержка и развитие).

Бенчмарки по отраслям:

Отрасль	% от ИТ-бюджета
Финансы	10-15%
Здравоохранение	7-12%
Ритейл	5-8%
Производство	4-7%
Среднее	6-10%

Как обосновать бюджет руководству

Подход через оценку рисков. Оценка потенциального ущерба от реализации рисков, расчет снижения риска от предлагаемых мер. Формула: ожидаемый ущерб = вероятность x последствия. Инвестиции в ИБ снижают вероятность и последствия.

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

Подход через бенчмарк. Сравнение с аналогичными компаниями по отрасли и размеру. Аргумент: "Компании нашего уровня инвестируют X% в ИБ, мы инвестируем Y% - это создает риски".

Подход через инциденты. Анализ произошедших инцидентов (своих или чужих), расчет фактического или потенциального ущерба. Наиболее убедителен после реального инцидента.

Метрики ROI для инвестиций в ИБ

Традиционный ROI (возврат на инвестиции) для ИБ рассчитывается сложно, поскольку измеряется предотвращенный ущерб, а не прямой доход. Применяются адаптированные метрики:

ROSI (Return on Security Investment): ROSI = (Ожидаемый ущерб без меры - Ожидаемый ущерб с мерой - Стоимость меры) / Стоимость меры

Пример расчета:

• Ожидаемый ущерб от ransomware без DLP: 10 млн руб./год
• Ожидаемый ущерб с DLP: 2 млн руб./год
• Стоимость DLP: 3 млн руб.
• ROSI = (10 - 2 - 3) / 3 = 167%

Альтернативная точка зрения: ROI для ИБ - не лучшая метрика. Безопасность - это управление рисками, а не инвестиционный проект. Правильный вопрос не "какой ROI", а "какой уровень риска приемлем для бизнеса". Бюджет ИБ - это цена снижения риска до приемлемого уровня.

Как добиться результата - KPI и оценка эффективности службы ИБ

Измерение эффективности службы ИБ - нетривиальная задача. Отсутствие инцидентов может означать хорошую защиту, а может - плохой мониторинг. Система KPI должна охватывать разные аспекты деятельности и давать объективную картину.

Операционные метрики ИБ

MTTD (Mean Time to Detect) - среднее время обнаружения инцидента. Измеряется от момента начала атаки до момента ее выявления.
MTTR (Mean Time to Respond) - среднее время реагирования. Измеряется от момента обнаружения до момента локализации угрозы.
Vulnerability remediation rate - доля закрытых уязвимостей в установленный срок.  
Patch compliance - доля систем с актуальными обновлениями безопасности.   
Phishing click rate - доля сотрудников, кликнувших по тестовым фишинговым письмам.

Отчетность для руководства

Отчетность для руководства должна быть на языке бизнеса, а не технических деталей. Рекомендуемая структура ежемесячного отчета CISO:

Executive summary (1 абзац): ключевое сообщение, главные риски, требуемые решения.

Risk dashboard (1 страница): визуализация топ-5 рисков с динамикой, статус критичных проектов, ключевые метрики.

Incident overview: количество инцидентов по категориям, крупные инциденты с оценкой потенциальных последствий (impact assessment), тренды.

Compliance status: статус выполнения регуляторных требований, предстоящие аудиты, выявленные несоответствия.

Resource utilization: статус бюджета, потребности в ресурсах, обоснование дополнительных инвестиций.

Периодичность отчетности: ежемесячный отчет для CFO/CEO, ежеквартальный отчет для совета директоров, нерегламентированные (ad hoc) отчеты по крупным инцидентам.

Регуляторные требования к службе ИБ в России

Российское законодательство предъявляет специфические требования к организации защиты информации. Знание регуляторного ландшафта - обязательная компетенция для руководителя ИБ в российской компании.

Требования 152-ФЗ и 187-ФЗ

152-ФЗ "О персональных данных" обязывает операторов ПДн обеспечить безопасность персональных данных. Ключевые требования:

• Назначение ответственного за организацию обработки ПДн
• Разработка политики обработки ПДн
• Определение угроз безопасности
• Применение мер защиты в соответствии с уровнем защищенности
• Уведомление Роскомнадзора об утечках в течение 24 часов

187-ФЗ "О безопасности КИИ" устанавливает требования для субъектов критической информационной инфраструктуры. Ключевые требования:

• Категорирование объектов КИИ
• Создание системы безопасности значимых объектов
• Подключение к ГосСОПКА
• Реагирование на инциденты с уведомлением НКЦКИ
• Назначение ответственного лица по безопасности КИИ

Для субъектов КИИ наличие выделенной службы ИБ - фактически обязательное требование, учитывая объем организационных и технических мер.

Основные стандарты/требования ФСТЭК и ЦБ РФ

Требования ФСТЭК России:

• Приказ 21 - меры защиты ПДн по уровням защищенности

• Приказ 17/117 - меры защиты ГИС и ИС

• Приказ 239 - требования к защите значимых объектов КИИ

• Методика оценки угроз безопасности информации (2021)

Требования ЦБ РФ (для финансового сектора):

• ГОСТ Р 57580.1 - требования к защите информации
• Положение 683-П - требования к защите информации в банках
• Положение 747-П - требования для НФО

Финансовые организации обязаны проводить ежегодную оценку соответствия ГОСТ Р 57580.1 силами внешнего оценщика. Результаты оценки влияют на возможность осуществления отдельных операций.

Подготовка к проверкам регуляторов

Проверки Роскомнадзора (по 152-ФЗ) фокусируются на документальном обеспечении: политики, согласия, уведомления. Типичные нарушения: отсутствие локальных актов, неактуальные согласия на обработку, несоответствие целей/оснований обработки, отсутствие уведомления в реестре операторов.

Проверки ФСТЭК ГИС и КИИ. Фокусируются на технических мерах защиты и их соответствии категории объекта. Типичные нарушения: неполнота мер защиты, отсутствие документации, ошибки при категорировании.

Подготовка к проверке включает:

1. Внутренний аудит - выявление несоответствий
2. Устранение критичных нарушений
3. Актуализация документации
4. Подготовка персонала к интервью
5. Формирование пакета документов для проверяющих

FAQ - частые вопросы о создании службы ИБ

Сколько специалистов ИБ нужно для компании из 500 человек?

Ориентировочно 3-5 специалистов при среднем уровне рисков. Точное число зависит от отрасли, регуляторных требований и зрелости ИБ. Финансовый и ИТ-сектор требует большего штата, производство - меньшего.

С какой должности начать формирование службы ИБ?

Первым нанимается универсальный специалист с опытом 3-5 лет, способный закрыть базовые задачи: аудит текущего состояния, внедрение базовых контролей, разработка политик. Это не junior-позиция.

Должна ли служба ИБ подчиняться ИТ-директору?

Подчинение CIO - распространенная, но не оптимальная модель. Создает конфликт интересов между доступностью и безопасностью. Рекомендуется подчинение CEO или CFO для обеспечения независимости.

Как обосновать руководству необходимость расширения команды?

Через метрики перегрузки: накопление технического долга, увеличение времени реагирования, рост количества неприоритезированных рисков. Через внешние факторы: новые регуляторные требования, рост бизнеса, произошедшие инциденты.

Что выгоднее - своя команда или аутсорсинг?

Гибридная модель оптимальна для большинства организаций. Стратегические функции и governance - инхаус. Операционные функции с высокой трудоемкостью (SOC 24x7) или требующие редкой экспертизы (пентесты) - аутсорс.

Какие сертификации нужны руководителю службы ИБ?

CISSP - де-факто стандарт для CISO-позиций. CISM подтверждает управленческие компетенции. Для российского рынка полезны сертификаты/дипломы образовательных программ, согласованных со ФСТЭК по направлениям деятельности организации.

Как измерить эффективность службы ИБ?

Через операционные метрики (MTTD, MTTR, patch compliance) и стратегические показатели (уровень зрелости, coverage, risk reduction). Отсутствие инцидентов само по себе - не показатель эффективности.