Что такое критическая информационная инфраструктура?

1. Масштаб киберугроз

В 2024 году в России было зафиксировано значительное количество хакерских атак на объекты критической информационной инфраструктуры (КИИ). Согласно данным компании RED Security SOC, на объекты КИИ пришлось около 64% от общего числа кибератак за год.
Общее количество кибератак в России в 2024 году выросло в 2,5 раза по сравнению с предыдущим годом и достигло почти 130 тысяч случаев. Учитывая, что 64% из них были направлены на объекты КИИ, можно подсчитать, что на критическую информационную инфраструктуру было совершено примерно 83 тысячи атак.

Если рассматривать только высококритичные атаки, то их доля, направленная на объекты КИИ, составила 68%34. Всего за год было зафиксировано около 26 тысяч высококритичных инцидентов, что означает примерно 17,7 тысяч высококритичных атак на объекты КИИ.
Медианное ежемесячное количество кибератак в 2024 году составляло около 10 тысяч, при этом в феврале было отражено более 12 тысяч атак. Аналитики отмечают, что давление на КИИ в киберпространстве значительно усилилось по сравнению с 2023 годом, когда на эти отрасли приходилось только 47% от общего числа атак.

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

2. Геополитическая напряженность и технологический суверенитет

После 2022 года тема защиты КИИ в России приобрела новый масштаб. В условиях санкционного давления и ограничения импорта западного оборудования и ПО вопрос перехода на отечественные решения и повышение устойчивости КИИ стал приоритетом государственной политики.

3. Законодательное регулирование

В 2017 году вступил в силу Федеральный закон № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации». Он определяет правовые и организационные основы защиты КИИ.

С 2025 года в силу вступили обновлённые подзаконные акты, включая:

• методику категорирования объектов КИИ;
• требования по обеспечению безопасности (в т.ч. в рамках жизненного цикла ПО);
• требования к отечественному происхождению средств защиты.

Невыполнение требований влечёт за собой административную и уголовную ответственность, вплоть до закрытия доступа к объекту КИИ и отзыва лицензий.

Согласно статье 2 Федерального закона № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации», критическая информационная инфраструктура — это совокупность информационных систем, автоматизированных систем управления и телекоммуникационных сетей, задействованных в сферах, жизненно важных для общества и государства: обороне, здравоохранении, энергетике, транспорте, банковской системе и других. Эти системы оказывают прямое влияние на национальную безопасность, экономическую стабильность, устойчивость управления и жизнеобеспечение населения.

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

Объект КИИ — это?

Объект КИИ — это конкретная система или элемент инфраструктуры, который подпадает под определение критической в соответствии с законом. Признаками объекта КИИ являются:

• принадлежность к одной из ключевых отраслей (энергетика, транспорт, здравоохранение, финансы, связь и др.);
• участие в управлении физическими или информационными процессами, критически важными для общества;
• возможность нанести значительный ущерб при нарушении его функционирования (материальный, социальный, экологический или иного характера);
• прохождение процедуры категорирования (1, 2 или 3 категория в зависимости от потенциального ущерба).

Объекты КИИ могут включать:

• серверы, базы данных и облачные инфраструктуры;
• системы автоматизации и управления (АСУ ТП, SCADA);
• информационные системы госуслуг;
• сети связи и передачи данных;
• специализированные программные продукты, участвующие в управлении критическими процессами.

Субъекты КИИ — это?

Субъекты КИИ — это организации, на которых лежит ответственность за эксплуатацию и защиту объектов КИИ. Это могут быть:

• юридические лица, включая государственные и частные компании;
• индивидуальные предприниматели, если им принадлежат или переданы на обслуживание объекты КИИ;
• органы государственной власти и местного самоуправления.

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

• проводят категорирование объектов по степени критичности;
• реализуют защитные меры в соответствии с требованиями ФСТЭК, ФСБ и другими регуляторами;
• обеспечивают устойчивость функционирования систем даже в условиях внешнего воздействия (в том числе кибератак);
• участвуют в ежегодной отчётности, проверках и учениях.

Субъекты КИИ несут ответственность за выполнение всех требований законодательства. Невыполнение этих обязательств влечёт за собой серьёзные последствия: от административных штрафов до уголовной ответственности и приостановки деятельности.

Примеры субъектов КИИ:

• крупные энергокомпании и сетевые операторы;
• телекоммуникационные провайдеры и сотовые операторы;
• железнодорожные и авиационные перевозчики;
• больницы, медицинские холдинги и фармацевтические компании;
• государственные учреждения, федеральные и региональные органы власти;
• банки, страховые компании, участники национальной платёжной системы.

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

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

Почему это важно?

• Комплексность систем КИИ. Многие объекты КИИ — это сложные распределённые системы с многочисленными интеграциями, где уязвимость в одном компоненте может повлиять на всю инфраструктуру.
• Высокие требования к надёжности. Программное обеспечение для КИИ должно работать без сбоев в экстремальных условиях и быстро восстанавливаться после инцидентов.
• Соответствие законодательству. Разработчики должны учитывать требования Федерального закона № 187-ФЗ, ГОСТы и другие нормативные документы, которые регламентируют безопасность ПО и информационных систем.

Типичные ошибки разработчиков, угрожающие безопасности КИИ

• Жёстко заданные учётные данные. Встроенные в код пароли или ключи доступа создают прямую уязвимость.
• Отсутствие проверки и фильтрации данных. Это может привести к инъекциям SQL, XSS, RCE и другим атакам.
• Использование устаревших или неподдерживаемых библиотек и компонентов. Они могут содержать известные уязвимости.
• Недостаточное логирование (журналирование операций) и мониторинг. Без подробного аудита сложно выявлять и анализировать инциденты.
• Отсутствие шифрования и неправильное управление ключами. Это увеличивает риск утечек конфиденциальных данных.

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

• Основы законодательства и стандарты в области безопасности КИИ: Федеральный закон № 187-ФЗ, ГОСТ Р 56939-2016 (информационная безопасность), ГОСТ Р 57580 (управление уязвимостями), рекомендации OWASP (Top 10 уязвимостей веб-приложений).
• Принципы Secure by Design — как интегрировать безопасность в каждую фазу разработки.
• Методы статического и динамического анализа кода для выявления потенциальных уязвимостей.
• Практики безопасного программирования, включая управление сессиями, аутентификацию, авторизацию, обработку ошибок.
• Особенности тестирования безопасности: fuzzing, пентесты, анализ логов.

Влияние на конечный результат

От качества разработки напрямую зависит устойчивость КИИ к современным вызовам. Надёжно спроектированное и реализованное ПО снижает риски аварий и взломов, обеспечивает сохранность данных и бесперебойную работу критически важных сервисов.

Таким образом, разработчики должны не просто писать код, а создавать надёжные, устойчивые и безопасные решения, которые станут крепким фундаментом для всей критической инфраструктуры.

Понятие и суть

Secure by Design — это системный и комплексный подход к созданию программного обеспечения и информационных систем, при котором безопасность становится не дополнением или исправлением после обнаружения уязвимостей, а заложенной изначально, фундаментальной характеристикой продукта. Такой подход предполагает, что безопасность интегрируется на каждом этапе жизненного цикла ПО — от постановки требований и проектирования архитектуры до реализации, тестирования и сопровождения.

Идея Secure by Design возникла как ответ на постоянное увеличение числа и сложности кибератак, когда попытки защитить систему "постфактум" уже неэффективны. В случае критической информационной инфраструктуры (КИИ), где малейший сбой или нарушение безопасности может привести к масштабным последствиям для общества и государства, такой подход становится обязательным.

Основные принципы Secure by Design

1. Безопасность с самого начала — безопасность является неотъемлемой частью всех стадий разработки. Даже на этапе анализа требований закладываются меры защиты, учитывающие потенциальные угрозы.
2. Принцип наименьших привилегий — каждый компонент, пользователь и сервис получают только те права доступа и возможности, которые строго необходимы для выполнения их функций. Это ограничивает потенциальный ущерб от взлома или ошибки.
3. Модульность и изоляция — система строится из независимых модулей, изолированных друг от друга, чтобы нарушение одного из них не приводило к краху всей системы.
4. Защита по умолчанию (Fail-safe defaults) — все функции и действия по умолчанию считаются запрещёнными, если не разрешены явно. Это исключает случайные или несанкционированные действия.
5. Многоуровневая защита (Defense in Depth) — вместо одной линии обороны используется несколько независимых уровней защиты: аутентификация, шифрование, мониторинг, сегментация сети и др.
6. Постоянное тестирование и аудит безопасности — регулярное проведение статического и динамического анализа кода, тестов на проникновение, fuzz-тестирования помогает выявлять уязвимости на ранних этапах.
7. Мониторинг и оперативное реагирование — встроенные механизмы мониторинга безопасности и логирования позволяют быстро обнаружить и реагировать на инциденты.
8. Обратная связь и улучшение — инциденты и выявленные уязвимости анализируются, а выводы интегрируются в последующие версии продукта, что ведёт к постоянному повышению безопасности.

Почему Secure by Design критически важен для КИИ

Критическая информационная инфраструктура — это сердце национальной безопасности, устойчивости экономики и социальной стабильности. Нарушения в работе систем КИИ могут вызвать:

• перебои в энергоснабжении и водоснабжении,
• сбои в транспорте и логистике,
• утечку или потерю медицинских данных,
• финансовые потери и экономический ущерб,
• даже угрозу жизни людей.

Безопасность в КИИ требует не только надёжных средств защиты, но и продуманного, продвинутого подхода к созданию самих систем. Secure by Design позволяет:

• снизить количество уязвимостей в ПО и архитектуре;
• уменьшить риски инцидентов безопасности;
• снизить затраты на исправление ошибок и последствий атак;
• обеспечить соответствие нормативным требованиям (например, требованиям ФЗ № 187-ФЗ);
• повысить доверие пользователей и государственных органов к системам.

Внедрение принципов Secure by Design — это комплексный и многоступенчатый процесс, который охватывает все этапы создания программного обеспечения и систем, включая проектирование, разработку, тестирование и сопровождение. Чтобы защитить критическую информационную инфраструктуру (КИИ) эффективно, необходимо внедрять меры безопасности изначально, а не добавлять их после появления проблем.

1. Этап проектирования

На этом этапе важно заранее определить, какие угрозы могут повлиять на систему, и заложить защитные меры в архитектуру. На Западе для этого применяются методики моделирования угроз — STRIDE и PASTA, позволяющие системно выявлять потенциальные направления атак и оценивать их влияние. В России согласно «Требованиям по обеспечению безопасности КИИ» (Приказ ФСТЭК России от 25.12.2017 № 239) ввиду отсутствия специальной методики оценки угроз и составление модели угроз для объектов КИИ используется "Методический документ. Методика оценки угроз безопасности информации" (утв. ФСТЭК России 05.02.2021), где относительно документа 2007 года акцент сменился с вероятности реализации угрозы на оценку вреда и возможности реализации.

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

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

2. Этап разработки

В процессе кодирования применяются безопасные шаблоны программирования и лучшие практики — например, валидация входных данных, безопасное управление сессиями, шифрование данных. Чтобы минимизировать ошибки, важно регулярно использовать инструменты статического анализа кода (SAST), которые автоматически выявляют потенциальные уязвимости.

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

3. Этап тестирования

После создания ПО проводится динамический анализ (DAST), который позволяет выявлять уязвимости уже в работающей системе через имитацию атак. Для обнаружения скрытых ошибок используется fuzz-тестирование — подача случайных или некорректных данных, чтобы проверить устойчивость приложения.

Кроме того, организуются регулярные пентесты — тесты на проникновение с привлечением как внутренних, так и внешних специалистов. Важна интеграция проверок безопасности в процессы CI/CD, чтобы автоматизировать контроль качества и безопасность на каждом этапе выпуска ПО.

4. Внедрение и сопровождение

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

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

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

Критическая информационная инфраструктура — это цифровой фундамент государства. Её надёжность — вопрос национальной безопасности и устойчивого развития экономики.

КИИ — это не абстрактное понятие. Это конкретные системы, в которых работают ваши алгоритмы, сервисы, API и модули. Если вы разрабатываете ПО, влияющее на транспорт, энергетику, медицину, госуслуги — вы работаете с КИИ.

Применение подхода Secure by Design — это не только способ снизить количество инцидентов, но и обязательное требование времени. Сегодня каждый разработчик должен мыслить как архитектор безопасности.

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

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