О мерах по безопасной разработке ПО для значимых объектов КИИ

Историческая справка и область действия

В 2017 году был опубликован Федеральный закон от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации», который регулирует отношения в области обеспечения безопасности критической информационной инфраструктуры Российской Федерации (далее – КИИ). Позже ФСТЭК России выпустила приказ от 25.12.2017 № 239 «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации» (далее – Приказ № 239), в котором определены технические и организационные меры по обеспечению безопасности значимых объектов КИИ. В 2020 году приказом ФСТЭК России от 20.02.2020 № 35 в Приказ № 239 внесен, в частности, пункт 29.3, который предъявляет требования к прикладному ПО, обеспечивающему выполнение функций значимых объектов КИИ по их назначению, то есть ПО, которое используется для автоматизации критических процессов в значимых объектах КИИ. Например, это может быть следующее ПО, если оно установлено на значимых объектах КИИ:

• SCADA-системы в АСУ ТП (InTouch, Citect, SIMATIC WinCC, TRACE MODE и иные);
• программные продукты для автоматизированных банковских систем (ЦФТ-Банк, RS-Bank, Diasoft FA и прочие);
• биллинговые системы (FORIS BSS/OSS, Comverse One и прочие);
• BPM-системы (ELMA, Creatio, Directum и прочие)
• ERP-системы (BAS, 1С, SAP и иные).

Требования к прикладному ПО вступают в силу с 1 января 2023 года.

В этой статье будут разобраны требования к прикладному ПО значимых объектов КИИ. Также вы можете посмотреть другие статьи и вебинары по теме защиты КИИ на нашем портале 187.ussc.ru.

Распределение обязанностей

Поскольку требования п. 29.3 Приказа №239 относятся к процессу разработки ПО, то выполнять требования должен разработчик, в том числе, и документально подтвердить их выполнение. Однако не редки случаи, когда субъект КИИ использует ПО, для которого закончилась поддержка разработчика и субъект КИИ осуществляет поддержку ПО самостоятельно или, когда субъектом КИИ используется свободно распространяемое ПО. В таком случае обязанность выполнения требований лежит на субъекте КИИ.

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

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

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

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

Государственный контроль выполнения требований по обеспечению безопасности значимых объектов КИИ (в т.ч. требований по безопасности разработки ПО) проводит ФСТЭК России.

Разделение обязанностей представлено на схеме:

Содержание требований

Требования по безопасности прикладного ПО включают:

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

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

Процесс безопасной разработки представлен на рисунке 1.

Рисунок 1 – Схема процесса безопасной разработки ПО

1. Руководство по безопасной разработке

На этапе планирования, когда определяются требования к разрабатываемому ПО, необходимо создать руководство по безопасной разработке ПО, где для каждого этапа разработки должны быть указаны меры по обеспечению безопасности ПО и процесса разработки в целом. В качестве методического документа можно использовать ГОСТ Р 56939-2016.

Схема подпроцессов безопасности разработки представлена на рисунке 2.

Рисунок 2 – Схема подпроцессов безопасности разработки

Рекомендуем регламентировать следующие процессы разработки ПО:

1. Процесс анализа требований к ПО

На данном этапе разработки должны быть определены требования по безопасности ПО. В качестве источника требований можно использовать, например, Приказ № 239, отраслевые стандарты и профили защиты ФСТЭК России.

2. Процесс проектирования архитектуры ПО

На данном этапе должны быть проведены следующие работы:

• анализ угроз безопасности и разработка модели угроз безопасности информации;
• оформление проекта архитектуры ПО;
• оценка рисков в отношении процесса разработки.

Подробнее о содержании модели угроз и проекте архитектуры разберем в разделах 2 и 3.

3. Процесс написания кода и сборки ПО

На данном этапе должны быть определены и утверждены:

• перечень инструментов разработки ПО;
• порядок оформления исходного кода ПО;
• инструменты и порядок проведения статического анализа исходного кода ПО.

Также рекомендуется после проведения статического анализа кода с помощью автоматических средств провести экспертизу кода «вручную».

4. Процесс квалификационного тестирования ПО

На данном этапе должны быть определены инструменты, порядок проведения и ответственные за проведение фаззинг-тестирования и динамического анализа кода ПО.

5. Процесс приемки и инсталляции ПО

На данном этапе должны быть определены и утверждены:

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

На данном этапе должны быть определены:

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

На данном этапе должны быть определены меры обеспечения безопасности среды разработки. Меры защиты определяются на основании модели угроз и оценки рисков. Например:

• меры защиты от несанкционированного доступа;
• резервное копирование;
• регистрация изменений и событий безопасности;
• реагирование на инциденты информационной безопасности;
• поиск уязвимостей;
• обновление заимствованных компонентов ПО.
8. Процесс обучения

На данном этапе должны быть определены порядок и периодичность обучения всего персонала, задействованного в процессе разработке ПО. Рекомендуется проводить обучение не реже одного раза в год.

2. Анализ угроз безопасности

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

Для анализа рекомендуется выполнить следующие шаги:

1. Построить схему информационных потоков (потоков данных) в ПО

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

2. Обозначить защищаемые ресурсы

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

3. Определить потенциальные угрозы, которые могут возникнуть с учетом информационных потоков и применяемых сервисов

В качестве источников информации об угрозах можно использовать:

• банк данных угроз безопасности информации ФСТЭК России (bdu.fstec.ru);
• публикации проекта Open Web Application Security Project (OWASP);
• MITRE Matrix;
• CWE top 25.

В качестве инструмента для оценки угроз можно использовать методику моделирования угроз ФСТЭК России от 05.02.2021, но она подходит для информационных систем, чем для ПО.

Еще одной методикой моделирования угроз является STRIDE, согласно которой для каждого компонента из схемы информационных потоков необходимо определить актуальность одной или нескольких угроз:

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

Для автоматизации процесса моделирования угроз по STRIDE существует инструмент, разработанный Microsoft, – Microsoft Threat Modeling Tool.

4. Определить меры нейтрализации угроз

Для каждой актуальной угрозы должны быть разработаны меры по их нейтрализации. В качестве мер нейтрализации угрозы могут быть:

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

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

3. Проект архитектуры ПО

Проект архитектуры ПО должен содержать:

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

4. Статический анализ кода

Статический анализ кода (SAST) позволяет проверить код на наличие ошибок и уязвимостей без его выполнения. Преимущество использования статических анализаторов в том, что они позволяют обнаруживать уязвимости и ошибки на ранних стадиях разработки ПО, а именно непосредственно при написании кода. Максимальная эффективность их применения достигается, если статический анализатор интегрирован в систему разработки и проводит автоматические проверки. Однако не стоит отказываться от проверок кода «вручную».

5. Динамический анализ кода

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

6. Фаззинг-тестирование

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

7. Отслеживание и исправление обнаруженных ошибок и уязвимостей

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

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

Государственный контроль

Государственный контроль по выполнению требований в отношении субъектов КИИ осуществляет ФСТЭК России на основе анализа материалов и документов на ПО. Поэтому все реализованные требования должны быть документированы. Контрольные мероприятия проводятся ФСТЭК России в рамках плановых и внеплановых проверок в соответствии с Постановлением Правительства РФ от 17.02.2018 №162 «Об утверждении Правил осуществления государственного контроля в области обеспечения безопасности значимых объектов критической информационной инфраструктуры Российской Федерации». Плановые проверки проводятся не реже, чем раз в три года после:

• внесения сведений о значимом объекте КИИ в реестр значимых объектов КИИ;
• окончания последней плановой проверки.

Внеплановые проверки проводятся после:

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

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

Компания УЦСБ помогает разработчикам ПО подготовить необходимые документы и провести тестирование ПО, а субъектам КИИ – провести оценку выполнения мер по безопасной разработке для ПО, применяемого на значимых объектах КИИ.

Компания УЦСБ обладает 15-летним опытом выполнения работ в области информационной безопасности. В штате УЦСБ работают высококвалифицированные специалисты, компетенции которых подтверждаются наличием:

• международных сертификатов в области анализа уязвимостей и этичного «хакинга» (CEH, CHFI, OSWE, OSCE, OSCP);
• международных сертификатов в области информационной безопасности (CISA, CISM, CISSP, CRISC);
• зарегистрированных бюллетеней по безопасности (CVE-2015-1010: Rockwell Automation RSView32; CVE-2017-7907: Schneider Electric Wonderware Historian Client; CVE-2017-9627, CVE-2017-9629, CVE-2017-9631: Schneider Electric Wonderware ArchestrA Logger; CVE-2018-18981: Rockwell Automation FactoryTalk Services Platform);
• опытом реализации различных проектов в области информационной безопасности и анализа защищенности.