Критическая информационная инфраструктура — что это и что в нее входит?

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

КИИ — основа кибербезопасности

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

Развитие ИИ = развитие фишинга и DDoS-атак

Социальная инженерия также выходит на качественно новый уровень. Как насчет того, чтобы получить голосовое сообщение или видео от родственника или начальника. Уверен ли каждый из нас, что он вычислит такое мошенничество? Такими же темпами развиваются и более «серьезные» атаки ‎на отдельные IT-компании, программы, облачные хранилища и другие системы.

Один из графиков, показывающих последствия атак на IT-компании и их соотношение в 2023 году. Источник — отчет Positive Technologies.

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

Вот как выглядит схема атаки на цепочку поставок в упрощенном виде. Источник: Microsoft Blog.

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

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

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

 

Схематическое изображение субъектов критической информационной инфраструктуры.

 

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

 

В этой схеме видно место разработчика ПО. ЗОКИИ — значимый объект КИИ. ФСТЭК — Федеральная служба по техническому и экспортному контролю.

Принципы безопасной разработки: Secure by design‎

Для безопасной разработки существуют отдельные стандарты ГОСТ, которые регулярно обновляются. Есть и стандартные правила, которые актуальны независимо от принятых нормативов. Вот наиболее важные из них:

1. При работе необходимо пользоваться руководством по безопасной разработке и анализу угроз.
2. Требуется фиксировать архитектуру документально.
3. На каждом этапе нужно предусматривать требования к испытанию ПО и проводить анализ на критические и другие уязвимости.
4. После реализации разработчик должен обеспечить поддержку ПО, выявлять уязвимости и предлагать меры по защите — своевременно информируя компанию-заказчика. Также это необходимо при завершении поддержки ПО.

 

Более простой подход, помогающий соответствовать принципам безопасной разработки критических информационных инфраструктур, — Secure by design. Эта культура подразумевает возможность встраивать механизмы защиты в архитектуру уже на первых шагах разработки.

Принципы Secure by design:

1. Ответственность за риски — назначайте ответственных за управление киберрисками на всех этапах жизненного цикла продукта.
2. Безопасные источники — проверяйте безопасность сторонних продуктов, используемых в разработке, и делитесь результатами анализа с поставщиками.
3. Оценка рисков — регулярно анализируйте риски и разрабатывайте защитные меры, учитывая меняющийся пул угроз.
4. Интеграция защиты — закладывайте в архитектуру механизмы для обнаружения и реагирования на уязвимости.
5. Гибкая архитектура — создавайте решения, способные адаптироваться к новым требованиям и угрозам.
6. Минимизация поверхности атаки — упрощайте архитектуру для снижения потенциальных рисков.
7. Многоуровневая защита — внедряйте несколько уровней контроля для повышения устойчивости системы.
8. Безопасные изменения — учитывайте влияние обновлений на безопасность на всех этапах проектирования и внедрения.

Внедрение принципов Secure by design на разных этапах

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

 

1. Проектирование и аналитика

На этапе проектирования полезно применять подход Domain-Driven Design, сосредотачивающий внимание на предметной области и ее ограничениях. Создание доменных моделей помогает углубиться в изучение предметной области, определить единый язык и контексты и выявить граничные состояния системы.

 

2. Разработка

Реализация Secure by Design в разработке базируется на нескольких ключевых пунктах:

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

 

3. Тестирование

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

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

Заключение

Ответственные за безопасность — не только те, кто имеет непосредственное отношение к разработке, а все участники процесса. Разработка согласно принципам КИИ будет проще, если использовать принципы Secure by Design. Внедрять их нужно на каждом этапе разработке и учитывать возможные изменения в процессе обновлений и использования ПО. Задумываться о безопасности приложений и других решений нужно начиная с первых шагов: тогда получится минимизировать возможные уязвимости.

Специалисты ГК «Цифра» позаботятся о безопасности: оставляйте заявку, и мы предложим вам готовое решение.