КИИ. Что это за зверь и надо ли нам его бояться
Всем привет!
Меня зовут Елена Галата. Сегодня я бы хотела поговорить о том, что такое КИИ и как это понятие связано с компаниями, которые занимаются разработкой промышленного ПО. Я уже много лет в разработке и в последнее время занимаюсь приложениями, в основном связанными со сбором данных с различных приборов, АСУТП, и других информационных систем предприятий. Поскольку наши компоненты довольно часто работают в зоне критической инфраструктуры заказчиков, тема КИИ мне близка. Сама по себе это довольно обширная и сложная область, но я хотела бы затронуть ее небольшую часть, касающуюся разработки ПО.
Ну и зачем об этом говорить?
Почему вообще важна тема работы КИИ с точки зрения безопасности?
Если говорить коротко, то КИИ — это системы и сети, которые имеют жизненно важное значение для функционирования целых отраслей или даже страны. Защита их от кибератак фактически является защитой национальных интересов. А число кибератак у нас в стране (и не только у нас) растет катастрофически. Причем в 2023 году произошел качественный скачок: атаки стали гораздо более изощренными технологически и дорогими с точки зрения реализации. Направлены они на разрушение целых инфраструктур, блоков экономики. Еженедельно где-то в стране происходит подобный инцидент.
Фишинг, социальная инженерия и DDoS-атаки вышли на новый уровень с развитием технологий искусственного интеллекта. Активно начали процветать дипфейки, когда, например, злоумышленники используют генеративные технологии, чтобы выдавать себя за руководителей компаний. Вот интересный доклад на эту тему: «Начальная дипфейкология, как сделать, как распознать».
Переходя от общих тенденций к тому, что непосредственно касается компаний-разработчиков промышленного ПО, хотела бы в качестве примера привести график последствий атак на ИТ-компании из отчета Positive Technologies за 2023 год.
График последствий атак на ИТ-компании (доля успешных атак). Источник: Positive Technologies
В отчете говорится, что в 2023 году было выявлено огромное количество уязвимостей в решениях, ИТ- и ИБ-системах. Это негативно отразилось на устойчивости к кибератакам различных организаций — государственных и коммерческих. Мишенями для атаки, к слову, выступают не только сами организации, но и их поставщики, в том числе разработчики ПО. Злоумышленники, стремясь навредить той или иной организации, могут сделать это через ее цепочку поставок, например, через ИТ-поставщиков.
К сожалению, такой тренд сохраняется и в 2024 году. Мы все под атакой, и нам всем (ИТ-компаниям) необходимо работать над повышением защищенности и наших продуктов, и наших инфраструктур.
Что такое КИИ?
Ну, а теперь к главному вопросу этой статьи. Что же такое КИИ и как с этим связаны мы — разработчики промышленного ПО?
В РФ история КИИ официально началась в 2017 году, когда был подписан федеральный закон № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации». Он вступил в силу с 1 января 2018 года. За его исполнение отвечают ФСТЭК и ФСБ.
Вместе с законом 187-ФЗ появились:
— ГосСОПКА, государственная система обнаружения, предупреждения и ликвидации последствий компьютерных атак на информационные ресурсы РФ;
— Национальный координационный центр по компьютерным инцидентам (НКЦКИ), который координирует деятельность субъектов КИИ, и на его технической инфраструктуре базируется функционирование системы ГосСОПКА;
— целая плеяда указов, приказов и прочих документов по защите КИИ (указы Президента РФ № 250 от 01.05.2022 и № 166 от 30.03.2022, приказы ФСТЭК России № 235 от 21.12.2017 и № 239 от 25.12.2017, приказы ФСБ России № 367 от 24.07.2018 и № 282 от 19.06.2019 и прочие).
Разбирать все это в деталях мы не будем. Давайте просто посмотрим, что в этих документах вообще подразумевается под понятием КИИ и какие еще официальные термины с этим связанны. Так как термины официальные, их определения возьмем в том виде, как они закреплены в 187-м ФЗ.
Критическая информационная инфраструктура (КИИ) — объекты критической информационной инфраструктуры, а также сети электросвязи, используемые для организации взаимодействия таких объектов.
Объекты критической информационной инфраструктуры — информационные системы, информационно-телекоммуникационные сети, автоматизированные системы управления субъектов критической информационной инфраструктуры.
Субъекты критической информационной инфраструктуры — государственные органы, государственные учреждения, российские юридические лица и (или) индивидуальные предприниматели, которым на праве собственности, аренды или на ином законном основании принадлежат информационные системы, информационно-телекоммуникационные сети, автоматизированные системы управления, функционирующие в сфере здравоохранения, науки, транспорта, связи, энергетики, государственной регистрации прав на недвижимое имущество и сделок с ним, банковской сфере и иных сферах финансового рынка, топливно-энергетического комплекса, в области атомной энергии, оборонной, ракетно-космической, горнодобывающей, металлургической и химической промышленности, российские юридические лица и (или) индивидуальные предприниматели, которые обеспечивают взаимодействие указанных систем или сетей.
Схема субъектов и объектов КИИ
Объекты КИИ делятся на незначимые и значимые. Часто последние обозначаются аббревиатурой ЗОКИИ. Каждому значимому объекту КИИ назначается категория значимости от 1 до 3: первая — самая высокая, третья — самая низкая. Категория зависит от того, какой вред (социальный, политический, экономический, экологический и пр.) возможен при несанкционированном вмешательстве или повреждении объекта КИИ. В зависимости от категории значимости определяются необходимые меры защиты.
Как это касается разработчиков ПО?
А где же в этой схеме мы, те, кто занимается разработкой промышленного ПО? Как это касается нас, если мы не являемся субъектами КИИ?
Дело в том, что системы, которые мы разрабатываем, должны работать в компаниях-субъектах КИИ. То есть наши заказчики выставляют нам требования по безопасности разрабатываемого ПО, которые мы обязаны выполнять, поскольку в итоге все объекты КИИ должны быть защищены, и эта защита контролируется, в частности, ФСТЭК.
Место компании-разработчика ПО в обеспечении безопасности КИИ
Кстати, скоро ожидается принятие новой редакции ГОСТа по безопасной разработке — ГОСТ Р 56939, которому нам надо будет соответствовать. И особенно это касается тех, кто пойдет на сертификацию ФСТЭК.
А сейчас коротко можно обозначить всего три пункта, которым мы — разработчики ПО для заказчиков-субъектов КИИ — должны следовать:
1.Обязательно иметь руководство по безопасной разработке и анализу угроз, а также зафиксированную документально архитектуру.
2. Должны быть требования к испытанию ПО и анализ на наличие уязвимостей.
3. Ну и мы должны осуществлять поддержку нашего ПО, информировать заказчика о найденных уязвимостях, мерах по их устранению и об окончании поддержки ПО с нашей стороны.
Конечно, соответствовать всем требованиям безопасной разработки достаточно сложно, но здесь и сейчас я бы хотела поговорить про простые шаги, как каждый из нас, кто участвует в процессе разработки программных продуктов, может минимизировать риски безопасности. В этом нам поможет культура Secure by design.
Культура Secure by design
Простыми словами Secure by design можно описать как встраивание защитных механизмов в архитектуру и код на начальных этапах разработки, что помогает избежать потенциальных угроз и усилить защиту данных.
Принципы Secure by design в разных источниках описываются по-разному. Вот наиболее важные из них.
Принять ответственность за риски кибербезопасности
Назначьте ответственных за управление рисками кибербезопасности для сервиса на протяжении всего его жизненного цикла. Это должны быть заинтересованные лица старшего звена — с опытом, знаниями и полномочиями для руководства работой в области безопасности.
Использовать безопасные источники технологических продуктов
При использовании в создаваемых решениях продуктов сторонних производителей проводите комплексную проверку безопасности и постоянно оценивайте платформы, программное обеспечение и код на наличие уязвимостей. Делитесь результатами проверки с поставщиками, чтобы помочь им повысить безопасность продукта.
Применять подход, основанный на оценке риска
Определите подверженность проекта рискам и проводите оценку рисков кибербезопасности для создания средств защиты, соответствующих меняющемуся ландшафту угроз.
Встраивать в продукты компоненты безопасности для обнаружения и реагирования на уязвимости
Проектируйте продукты с учетом неизбежности уязвимостей и инцидентов в системе безопасности. Интегрируйте соответствующие функции ведения журнала безопасности, мониторинга, оповещения и реагирования.
Проектировать гибкие архитектуры
Внедряйте цифровые сервисы и обновляйте устаревшие компоненты, чтобы упростить интеграцию новых средств контроля безопасности в ответ на изменения бизнес-требований, киберугрозы и уязвимости.
Минимизировать поверхность атаки
Применяйте только те программы, данные и аппаратные компоненты, которые необходимы для работы цифровых сервисов по назначению, чтобы снизить киберриски.
Использовать многоуровневую защиту
Создайте многоуровневые элементы управления для всей системы, чтобы злоумышленникам было сложнее полностью скомпрометировать ее в случае сбоя или преодоления защиты одного из элементов управления.
Вносить изменения безопасно
Внедряйте практики безопасности в проектирование, разработку, тестирование и развертывание, чтобы убедиться, что влияние изменений на безопасность продукта учитывается наряду с другими факторами.
Как внедрить принципы Secure by design в проектирование, разработку и тестирование
На первый взгляд, следование принципам Secure by Design кажется сложным, но на самом деле есть простые шаги, которые приблизят нас к этому идеальному миру. Я хочу рассмотреть их на примере трех этапов процесса разработки ПО: проектирование/аналитика, разработка и тестирование.
Проектирование/Аналитика
На этом этапе здорово поможет объектно-ориентированное проектирование — Domain-Driven-Design (DDD). Оно подразумевает максимальное внимание к деталям, предметной области и ее ограничениям.
Создание доменных моделей — это хорошая возможность приобрести глубокие знания в предметной области, определиться с семантикой единого языка, контекстами и другими элементами DDD. Проработка деталей на этом этапе упростит не только реализацию компонентов для разработчиков, но и понимание того, какие события или граничные значения могут привести систему в неопределенное или нерабочее состояние.
Разработка
Для реализации концепции Secure by design в разработке есть много достаточно простых и где-то даже очевидных правил, которым можно и нужно следовать. Например:
— Использование контрактов — это эффективный способ определения четких обязанностей для объектов и методов. И объекты должны содержать поля в точности тех типов, которые необходимы для обеспечения их функций. Указание, например, для количества каких-то элементов поля типа целое, а не беззнаковое целое, может привести к непредсказуемому результату в случае указания отрицательного значения.
— Необходимо помнить о данных и валидации их корректности, то есть проверки происхождения, размера данных, лексического содержимого, синтаксического формата и семантики. И надо помнить, что проверка на ранних этапах обходится дешевле и служит защитой для последующих (более ресурсоемких) проверок.
— Всегда в любых ситуациях пользовательский ввод должен быть санитаризирован, то есть тщательно проверен на корректность.
— Для защиты конфиденциальных данных можно использовать, например, объекты одноразового чтения.
— Исключения, возникающие в ходе работы приложения, должны разделяться на технические и по бизнес-требованиям. В технические нельзя включать бизнес-данные, даже если они на первый взгляд не выглядят конфиденциальными, поскольку при изменении контекста они вполне могут стать таковыми. В случае бизнес-исключений порой проще и безопаснее рассматривать их как нормальные, а не исключительные ситуации.
— Доступность как важный аспект безопасности может обеспечиваться такими шаблонами, как предохранители, отсеки и таймауты.
Тестирование
В тестировании нужно обязательно обращать внимание на проверку граничных значений, некорректного и экстремального ввода. А еще необходимо тестировать значения по умолчанию, проверять конфигурацию, в которую можно внести изменения намеренно, ненамеренно или по недопониманию.
Механизмы переключения функциональности также требуют тщательной проверки. Хорошей практикой является наличие теста на каждый переключатель.
Ну и нельзя забывать о проверке доступности и, конечно, о максимальной автоматизации тестов, где это возможно.
В конце не могу не коснуться Open Source как неотъемлемой части компонентов наших разрабатываемых систем. Мы знаем, сколько у такого ПО плюсов и минусов, и знаем, что стоит относиться к этому серьезно: обязательно проверять ПО на лицензионную доступность и наличие уязвимостей или добавленного вредоносного кода, а также следовать рекомендациям сообщества Open Source Software Foundation.
Вместо заключения
Выводы из моей длинной статьи:
— Работать над проектами для субъектов КИИ на самом деле может быть проще, чем кажется, если на каждом этапе создания ПО задумываться о принципах Secure by design.
— Основное — это внедрять практики безопасности в процессы проектирования, разработки, тестирования и развертывания, чтобы учитывать влияние изменений на ИБ наряду с другими факторами.
— Чем раньше задумываться о безопасности приложения, тем легче можно будет эту безопасность обеспечить.
— Раннее обнаружение проблемы в ИБ снижает стоимость ее устранения.
— Все участвующие в разработке ПО должны принимать во внимание вопросы безопасности, даже если они на первый взгляд и не имеют к ним отношения.
Отдельно выделю главный вывод:
Разработчикам промышленного ПО не надо бояться работать с субъектами КИИ, надо просто двигаться в сторону безопасной разработки. Поможет в этом культура Secure by Design и ряд подходов, которые минимизируют количество уязвимостей и сокращают поверхность атаки.
