Приказ ФСТЭК №235 и СОБ в финансовом секторе: где заканчивается ИТ и начинается ИБ

Если Приказ №239 - это про то, что защищать и какими мерами, то Приказ №235 - про то, кто за это отвечает и как должна быть устроена сама система обеспечения безопасности (СОБ). На бумаге разница выглядит академической. На практике именно 235-й порождает самые живые конфликты внутри организаций - потому что задевает организационную структуру, зоны ответственности и бюджеты.

Мы закончили проектирование СОБ для клиента из финансового сектора - банк, два категорированных значимых объекта. Категорирование завершили ещё весной, по 239-му часть работ уже шла параллельно. Пришло время разобраться с 235-м.

Что требует 235-й

Если коротко: приказ требует создать подразделение по безопасности (или назначить ответственных), обеспечить его ресурсами, квалификацией и полномочиями. Звучит разумно. Трудности начинаются, когда переходишь от требований к конкретной организации с её историей, структурой и уже сложившимся распределением ролей.

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

235-й в такую картину вписывается плохо.

Где конкретно возникло трение

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

У клиента обнаружили три конкретных узла, где это требование конфликтовало с реальностью:

• Управление привилегированными учётными записями. Администраторы систем - в ИТ. Аудит их действий - в ИБ. Но технически аудит был настроен теми же администраторами, которых нужно было контролировать. Формально всё есть, фактически независимость нулевая.

• Мониторинг и SIEM. SIEM-система исторически выросла из мониторинга инфраструктуры - то есть из ИТ-задачи. Правила корреляции писали ИТ-специалисты, они же обрабатывали алерты. ИБ получала сводки. Это не то же самое, что владеть процессом мониторинга.

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

Как проектировали СОБ

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

Потом разработали модель СОБ с явно прописанными границами:

• Управление доступом к критическим системам - только ИБ или ИТ под контролем ИБ с записью и согласованием. Администраторы не выдают права сами себе.
• SIEM и правила корреляции - ИБ становится владельцем платформы. ИТ предоставляет данные (источники, логи), но не управляет логикой обнаружения.
• Первичное реагирование - регламент переписан: при инциденте на значимом объекте ИБ получает уведомление одновременно с ИТ, а не после. Решение об изоляции и расследовании - за ИБ.

Это не было встречено с распростёртыми объятиями. ИТ-блок воспринял часть изменений как недоверие. Долгий разговор с руководством обеих служб и явная поддержка со стороны CISO клиента помогли двинуться дальше.

Про штатную численность и квалификацию

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

Картина оказалась смешанной: часть команды с актуальными курсами ФСТЭК, часть - с устаревшими или без профильного обучения вообще. В рамках проектирования СОБ составили план обучения на ближайший год с конкретными программами и сроками. Это не красивая бумага для регулятора - без выполнения плана при аттестации СОБ вопросы будут.

Где сейчас

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

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

Инструментов для этого у ФСТЭК не написано. Это та часть работы, которую приходится делать самим.

По аудиту и проектированию СОБ для субъектов КИИ готовы делиться опытом.