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

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

Построение системы обеспечения информационной безопасности объектов КИИ (СОИБ КИИ) — это не спринт, а затяжной марафон. Вот только самые основные этапы. 

1. Обследование объектов критической информационной инфраструктуры (ОКИИ) и их категорирование.

2. Формирование требований к СОИБ КИИ (модель угроз, частное техническое задание). 

3. Разработка СОИБ КИИ и подготовка технической документации.

4. Внедрение СОИБ КИИ и ввод в эксплуатацию.

5. Аудиты и поддержание СОИБ в актуальном состоянии. 

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

Мы не будем подробно разбирать каждый из перечисленных этапов, иначе статья рискует превратиться в «Войну и мир». Вместо этого сразу перейдем к полезным лайфхакам, основанным на нашем проектном опыте.

В одних случаях субъект КИИ самостоятельно берет на себя значительную часть задач по защите такой инфраструктуры, в других всё ложится на плечи привлеченного интегратора. Наиболее активное участие интегратора требуется на начальных этапах — обследовании инфраструктуры, категорировании. Поэтому большинство наших лайфхаков касается именно этих стадий.

1. Определитесь, действовать своими силами или привлечь интегратора 

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

Как правило, интегратор помогает заказчику:

• определить объекты КИИ;

• провести категорирование в соответствии с требованиями законодательства;

• спроектировать и внедрить СОИБ КИИ;

• провести аудит СОИБ.

За самим заказчиком остается курирование бизнес-процессов, критических процессов и сопровождение системы. 

Но как же не ошибиться с выбором исполнителя? Вот на что стоит обратить внимание.

• Наличие лицензии ФСТЭК. 

• Реализованные проекты. Желательно, чтобы у интегратора был успешный опыт защиты объектов КИИ в вашей отрасли. 

• Наличие специалистов с сертификатами по ключевым для вашей сферы СЗИ.

• Перечень услуг: если среди них много актуального для вашей организации, это еще один плюсик к карме интегратора. 

• Партнерские отношения с вендорами, решения которых востребованы в вашей отрасли.

2. Четко закрепите основной состав команды проекта

Лучше закрепить костяк команды проекта приказом. К примеру, мы как интегратор прописываем в документе руководителя проекта, архитектора, главного инженера. Одновременно просим заказчика указать ответственных лиц с его стороны, чтобы при возникновении проблем мы не стучались во все двери подряд, а обращались в «единое окно».

В целом же список ответственных за ОКИИ и средства защиты в ходе эксплуатации описан в законодательстве.

• 2-й раздел Приказа ФСТЭК № 235 «Требования к силам обеспечения безопасности значимых объектов КИИ» разъясняет, какие подразделения и специалистов необходимо задействовать в проекте. 

• Указ президента РФ № 250 «О дополнительных мерах по обеспечению информационной безопасности Российской Федерации» возлагает ответственность за защиту таких объектов на заместителя генерального директора организации. 

Как правило, от организации на разных этапах проекта участвуют:

• безопасники;

• сотрудники службы эксплуатации;

• сетевые администраторы;

• инженеры АСУ ТП;

• «владельцы» (кураторы) всех ключевых бизнес-процессов;

• финансовый блок и бухгалтерия; 

• отдел по гражданской обороне и чрезвычайным ситуациям (ГОЧС). 

Желательно, чтобы на этапе проектирования привлекались технические руководители, стоявшие у истоков защищаемых объектов. Они смогут разъяснить устройство и особенности информационных систем, не ограничиваясь дежурной фразой «так исторически сложилось». 

3. Минимизируйте административные и коммуникативные барьеры

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

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

Многие сисадмины вовсе воспринимают наших аудиторов злобными ревизорами. Или же нас представляют «эффективными менеджерами», которые урежут админам доступы и усложнят работу. На самом деле наша цель — защитить объекты КИИ, а не устроить публичную порку администратору. К тому же усиление ИБ не снижает удобство администрирования — совсем напротив. Например, внедрение централизованной системы управления учетными записями упрощает сисадмину контроль домена и помогает администрировать некоторые СЗИ, такие как IDM.

Возможно, еще перед привлечением интегратора коллегам из ИТ и ИБ стоит провести установочные встречи между собой, чтобы согласовать спорные моменты. Не помешает разъяснить сисадминам выгоды усиления ИБ.  

4. Сформируйте компетентную комиссию по категорированию объектов КИИ

Невозможно качественно провести категорирование без «владельцев» ключевых бизнес-процессов. Только они в курсе всех нюансов и «подводных камней».  

Мы как интегратор в первую очередь рекомендуем включать в комиссию представителей подразделений, предоставляющих необходимую для работы информацию: руководителей финансового блока, ГОЧС, ИБ-службы, отдела эксплуатации, главного инженера АСУ ТП. Подключаются все ответственные лица, чья деятельность связана с объектами КИИ. Притом категорирование — не задача из серии «сделал и забыл». Члены комиссии несут ответственность за предоставленную информацию. 

5. Не занижайте категорию значимости объектов КИИ

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

Для справки: 

Всё, что связано с категорированием, прописано в Постановлении Правительства № 127 «Об утверждении правил категорирования объектов критической информационной инфраструктуры Российской Федерации».  

Для каждой категории КИИ предусмотрены обязательные меры безопасности:

• I категория (К1) — до 75 требований, входящих в базовый набор мер, установленных регулятором.

• II категория (К2) — до 65 требований из базового набора мер.

• III категория (К3) — базовые меры (до 55 требований: НСД, антивирус, SIEM, оргмеры).

• Обнаружение вторжений (СОВ) — начиная со II категории значимости. 

Учитываются 14 типов негативных итогов прекращения или нарушения работы объектов КИИ для граждан и государства (сбои связи, удары по местным и федеральным бюджетам и пр.). 

Если объект КИИ не отвечает указанным критериям и не подпадает ни под одну из трех категорий, он признается незначимым и не требует особых мер защиты. Также в дополнение к вышеописанным требованиям с недавнего времени добавились отраслевые особенности категорирования объектов КИИ, о которых пойдет речь ниже.  

Часто категорию занижают не из злого умысла, а по ошибке. Например, масштабы возможных негативных последствий оцениваются уже с учетом применения организационных и технических мер. Между тем пункт 14.1 Правил категорирования объектов КИИ гласит, что модель угроз должна учитывать наихудшие сценарии: целенаправленные компьютерные атаки, прерывание критических процессов, максимальный ущерб и т. д. Если несоответствия вскроются, проблемы возникнут и у самого субъекта КИИ, и у проводившего категорирование подрядчика.   

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

6. Защищайте даже объекты, которые относятся к КИИ лишь косвенно  

Казалось бы, «КИИ или не КИИ» — никакой не философский вопрос. Достаточно посмотреть, какой у организации номер в ОКВЭД (Общероссийский классификатор видов экономической деятельности) и относится ли он к такой инфраструктуре. Но не всё так просто: например, микрофинансовые организации часто открещиваются от статуса КИИ, ссылаясь на ОКВЭД 64.92.7. В то же время ФЗ № 187 «О безопасности критической информационной инфраструктуры Российской Федерации» по умолчанию относит всю финансовую сферу к критической инфраструктуре. 

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

Чтобы перекрыть такие лазейки, с сентября 2025 года в ФЗ № 187 внесли изменения, согласно которым правительство устанавливает отраслевые перечни типовых объектов КИИ для каждой сферы (здравоохранение, транспорт и т. д.). Эти списки определят, какие именно информационные системы, сети и автоматизированные системы управления подлежат особой защите и категорированию по критериям вышеупомянутого Постановления № 127. Так, «легким движением руки» незначимая инфраструктура может превратиться в значимую, вне зависимости от ОКВЭД компании.  

Правда, на сегодняшний день выпущены далеко не все отраслевые перечни. Но вступление в силу списков для всех критических отраслей — вопрос не столь далекой перспективы. К слову, недавно вышел такой отраслевой перечень для финансовой сферы. 

Мы рекомендуем применять минимальный базовый набор мер из приказа ФСТЭК 239 (соответствующий III категории значимости) даже для объектов, которые лишь опосредованно относятся к КИИ или признаны незначимыми по итогам категорирования. Это позволит подстраховаться на случай вышеописанных изменений в законодательстве.  

7. Предоставляйте интегратору исчерпывающую информацию о своих процессах и ОКИИ

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

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

Не всегда принимаются во внимание уже применяемые средства защиты, что приводит к дисбалансу: в проект закладываются лишние СЗИ или, напротив, не включаются нужные.  

Вот почему мы проводим тщательные стартовые обследования объектов, интервьюируем ответственных специалистов, просим заказчика заполнить подробные опросные листы. Также запрашиваем имеющиеся регламенты по парольным политикам, правилам доступа и т. д. Всё это — информационная база для построения надежной системы защиты.   

8. Наладьте оповещение по проекту внутри организации

Это особенно актуально для организаций с распределенной инфраструктурой. Так, в горнодобывающей отрасли вахтовые поселки разбросаны по всей стране. Руководство может находиться в Москве, а инженеры АСУ ТП — в далекой Якутии. Информация доползает до них со скоростью улитки даже со всеми технологиями связи.

Доходит до курьезов: аудиторы прибыли на объект, а сотрудники на местах даже не слышали о начале проекта. Операторы АСУ ТП могут неделями находиться на удаленных производственных площадках и не иметь постоянного доступа к корпоративным системам коммуникации. В таких условиях даже заранее отправленные уведомления нередко остаются незамеченными.

Необходимо учитывать этот фактор и закладывать временной лаг на оповещение специалистов отдаленных объектов.

9. Оповещайте команду проекта об изменениях

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

Во избежание подобного рассинхрона нужно еще на этапе проектирования СОИБ КИИ обсудить с коллегами все смежные проекты по кибербезу. Разграничьте сферы ответственности, «забронируйте» места под оборудование. Договоритесь «на берегу», что в случае изменений и отхода от планов коллеги предупредят об этом команду построения СОИБ КИИ.  

10. Не относитесь предвзято к российским решениям при защите объектов КИИ

Курс на импортозамещение в сфере КИИ взят давно. А недавние сентябрьские изменения в законодательстве устанавливают порядок и сроки окончательного перехода на решения из реестра отечественного ПО. Однако многие организации держатся за зарубежные СЗИ, используя для этого любые лазейки (например, аргумент, что компания не ведет закупки по ФЗ № 223 «О закупках товаров, работ, услуг отдельными видами юридических лиц» и, соответственно, не должна импортозамещаться).

Главный лайфхак здесь — не думать о российских решениях свысока. Многие разработчики реализовали всё необходимое для надежной защиты объектов КИИ.

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

11. Контролируйте реальное соответствие СОИБ КИИ требованиям безопасности 

Система защиты объектов КИИ — не муха в янтаре. В компании могут внедряться новые информационные системы, которые также требуют категорирования и защиты, осваиваться смежные отрасли и т. д. Для понимания, как реагировать на такие изменения и развивать СОИБ КИИ, необходимо периодически проводить аудит ее текущего состояния. Вот несколько простых, но полезных советов в контексте таких регулярных проверок. 

• Ориентируйтесь на список технических и организационных мер из приказа ФСТЭК № 239. 

• Оцените эффективность СОИБ КИИ по «Методике оценки показателя состояния технической защиты информации и обеспечения безопасности значимых объектов критической информационной инфраструктуры РФ».

• Проверьте наличие сертифицированных средств защиты (например, сертифицированных криптографических СЗИ). 

• Проанализируйте работу системы мониторинга и реагирования (налажен ли сбор и корреляция событий ИБ, кто анализирует алерты об инцидентах, заключено ли соглашение с центром ГосСОПКА или выбран ли уполномоченный провайдер SOC). 

• Привлекайте к аудитам сторонних экспертов. Это можно делать точечно или на постоянной основе. Взгляд со стороны поможет избежать эффекта «замыленного глаза» и рассмотреть систему защиты комплексно. 

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

К тому же заказчику не помешает и самому разбираться в основных законодательных и технических нюансах защиты КИИ, чтобы не ошибиться в выборе того же интегратора, удостовериться в корректности предложенного проектного решения. Нужно ли импортозамещаться в части применяемых СЗИ, стоит ли категорировать ту или иную информационную систему? Такие решения и львиная доля ответственности за них ложатся на организацию, которая является субъектом КИИ.  

Если у вас остались вопросы, или вы хотите поделиться собственными кейсами по теме защиты объектов КИИ, не стесняйтесь и пишите в комментариях.