Необходимые требования по защите прикладных программ

Руслан Рахметов, Security VisionОдним из основных направлений требований по обеспечению информационной безопасности финансовых технологий,определяемых в нормативных документах Банка России, является обеспечение информационной безопасности прикладного программного обеспечения за счет анализа на уязвимости. В частности, данное требование сформулировано в следующих нормативных актах (в уже действующих и в тех, которые вступят в силу в ближайшее время) Банка России:

• Положение Банка России от 4 июня 2020 г. № 719-П «О требованиях к обеспечению защиты информации при осуществлении переводов денежных средств и о порядке осуществления Банком России контроля за соблюдением требований к обеспечению защиты информации при осуществлении переводов денежных средств». В пункте 1.2 данного акта для операторов по переводу денежных средств, банковских платежных агентов (субагентов), операторов услуг информационного обмена и операторов услуг платежной инфраструктуры выставляется требование по применению прикладного программного обеспечения автоматизированных систем и приложений, которые распространяются клиентам или взаимодействуют напрямую с сетью интернет (по сути, клиент-сервер), прошедшего сертификацию в системе сертификации Федеральной службы по техническому и экспортному контролю или оценку соответствия по требованиям к оценочному уровню доверия (далее — ОУД) не ниже чем ОУД 4 в соответствии с требованиями национального стандарта Российской Федерации ГОСТ Р ИСО/МЭК 15408-3-2013 «Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 3. Компоненты доверия к безопасности». Для проведения оценки соответствия организации (кроме банковских платежных агентов, субагентов) должны привлекать внешние проверяющие организации.
• Положение Банка России от 20 апреля 2021 г. № 757-П «Об установлении обязательных для некредитных финансовых организаций требований к обеспечению защиты информации при осуществлении деятельности в сфере финансовых рынков в целях противодействия осуществлению незаконных финансовых операций». В пункте 1.8 для некредитных финансовых организаций, реализующих усиленный и стандартный уровни защиты информации, указано аналогичное вышеуказанному требование по применению прикладного программного обеспечения, распространяемого клиентам или доступного к взаимодействию через сеть интернет, прошедшего сертификацию или оценку соответствия по ОУД 4. При этом, оценка соответствия прикладного ПО может проводиться как самостоятельно, так и с привлечением внешней проверяющей организации.
• Положение Банка России от 17 апреля 2019 г. № 683-П «Об установлении обязательных для кредитных организаций требований к обеспечению защиты информации при осуществлении банковской деятельности в целях противодействия осуществлению переводов денежных средств без согласия клиента» . В пункте 4.1 для кредитных организаций также указано аналогичное требование (но с некоторыми особенностями, которые будут, по всей вероятности, устранены через изменения), а в пункте 4.2 оговорено, что для проведения анализа кредитные организации должны привлекать организации, имеющие лицензию на осуществление деятельности по технической защите конфиденциальной информации.

Лекция 6. Приборные системы безопасности. Прикладная программа ПСБ | Противоаварийная защита

Требования к докладам по дисциплине «Защита программ и данных»

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

Очевидно, что в текущих реалиях программное обеспечение (особенно в части взаимодействия с клиентами) очень часто изменяется. Проведение сертификации весьма проблематично, увеличит сроки выхода новых версий ПО и, по сути, приведет к потере конкурентоспособности как за счет долгих сроков вывода новых продуктов, так и за счет стоимости сертификации. С этой точки зрения (экономической эффективности) интересен опубликованный в июне 2021 года на Федеральном портале проектов нормативных правовых актов проект Указания Банка России «О внесении изменений в Положение Банка России от 17 апреля 2019 года № 683-П…», в котором одно из изменений касается возможности проведения оценки соответствия самостоятельно. Вероятно, аналогичные изменения и подходы будут «стандартизированы» по всем актам Банка России и позволят организациям выстраивать безопасную разработку целиком внутри себя.

В актах указана оценка соответствия в соответствии с ГОСТ Р ИСО/МЭК 15408-3-2013 «Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 3. Компоненты доверия к безопасности», но общий характер ГОСТ и потребность в определении требований, учитывающих специфику финансовой сферы, сподвигло Банк России к разработке методического документа – профиля защиты (что и предусмотрено ГОСТ Р ИСО/МЭК 15408-3-2013, где в введении указано: «Компоненты доверия к безопасности, которые определены в ИСО/МЭК 15408-3, являются основой для требований доверия к безопасности, отражаемых в профиле защиты (ПЗ)»). Полное название методического документа – «ПРОФИЛЬ ЗАЩИТЫ прикладного программного обеспечения автоматизированных систем и приложений кредитных организаций и некредитных финансовых организаций» (далее – Профиль защиты) и, по всей видимости, он будет одним из основных методических документов для подразделений организаций финансово-кредитной сферы, обеспечивающих безопасную разработку.

Профиль защиты — достаточно объемный документ (155 страниц). Рассмотрим его основные разделы.

Из общих положений явно следует применение данного документа для сертификации и оценки соответствия как самими организациями кредитно-финансовой сферы, так и привлекаемыми внешними организациями. Указывается на то, что документ учитывает положения национальных стандартов Российской Федерации (хотелось бы отдельно отметить указанные в документе ГОСТ Р 57580.1-2017 и ГОСТ 34.603-92), отраслевых рекомендаций (РС БР ИББС-2.6-2014) и нормативных актов Банка России – в общем, разработчики документа постарались передать всю специфику требований мегарегулятора к своим поднадзорным.

Из введения следует, что документ разработан для оценочного уровня доверия 4 (ОУД4), усиленного рядом компонент. Хотелось бы отметить, что в 719-П и в проекте изменений 683-П для организаций поменьше (например, для не являющихся системно значимыми) предусмотрен ОУД5 – возможно, скоро данный документ получит обновление. Также в данном разделе указаны термины и определения, соглашения (операции «уточнение», «выбор», «назначение» и «итерация» над компонентами требований безопасности) и аннотация объекта оценки.

Аннотация объекта оценки (ОО) содержит подробное описание и, в принципе, её можно использовать как разъяснение объекта, к которому предъявляются требования из нормативных актов Банка России по проведению оценки соответствия или сертификации. Для ОО разъяснено что это такое, на каких технологических участках применяется и какие функциональные требования безопасности (ФТБ) предъявляются. Правильно реализованные (и в последующем периодически проверяемые) ФТБ обеспечат исключение возникновения типовых недостатков прикладного ПО:

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

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

В следующем разделе «Определение проблемы безопасности» идет разбор угроз, которые обязательно нужно рассмотреть:

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

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

Рис. 1. Матрица соответствия целей угрозам и политикам

В следующем разделе приведены «Цели безопасности» для ОО и среды функционирования, а также матрица (см. рис. 1), демонстрирующая достижение каких целей безопасности ОО необходимо для противостояния ранее обозначенным угрозам и для реализации политик безопасности. Рассмотрены только цели безопасности для ОО, так как, в основном, требования сфокусированы на самом прикладном программном обеспечении, что указано в пункте 2.3.3 Профиля защиты. Приводятся следующие цели безопасности ОО (можно сказать, весь документ направлен на достижение этих целей):

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

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

Рис. 2. Матрица соответствия функциональных требований безопасности и достигаемых целей безопасности

Перечислим направления (классы), которым посвящены функциональные требования безопасности:

• Аудит безопасности
• Защита данных пользователя
• Идентификация и аутентификация
• Управление безопасностью
• Приватность
• Защита ФБО
• Доступ к ОО
• Доверенный маршрут/канал

Классы доверия к безопасности ОО (взяты из ГОСТ Р ИСО/МЭК 15408-3-2013):

• Оценка задания по безопасности
• Разработка
• Руководства
• Поддержка жизненного цикла
• Тестирование
• Оценка уязвимостей
• Поддержка доверия

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

Источник: www.securityvision.ru

Решает ли покупка сертифицированной программы проблему защиты ПДн?

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

В данном материале разберем теоретическую сторону проблемы. В дальнейшем рассмотрим практические шаги по выполнению требований по защите ПДн без использования сертифицированной программы.

Разберемся с понятиями

Обработку и защиту персональных данных в информационных системах регламентирует Федеральный закон от 27.07.2006 № 152-ФЗ «О персональных данных». Конкретные меры защиты описывает Приказ ФСТЭК РФ от 18.02.2013 № 21 «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных».

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

Проблема во многом связана с тем, что пользователи объединяют понятия «программа» и «информационная система», из-за чего складывается мнение, что, защитив «программу», можно выполнить требования Закона № 152-ФЗ.

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

Чего же хочет закон?

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

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

Программа — данные, предназначенные для управления конкретными компонентами системы обработки информации в целях реализации определенного алгоритма («Обеспечение систем обработки информации программное. Термины и определения. ГОСТ 19781-90»).

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

Федеральный закон № 152-ФЗ предъявляет требования в первую очередь к защите информационной системы, обрабатывающей персональные данные, а не конкретно к программе.

Обеспечьте защиту персональных данных в вашей компании

Что такое сертифицированная программа и какие требования по защите ПДн она выполняет?

Сертифицированная по требованиям безопасности программа — это программа, прошедшая процедуру проверки соответствия требованиям государственных стандартов и нормативных документов по защите информации ФСТЭК России или ФСБ России, что подтверждается сертификатом соответствия.

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

Немаловажным является тот факт, что, согласно 21-му Приказу ФСТЭК России, использование сертифицированных программ является лишь одной из мер по обеспечению безопасности персональных данных и реализуется лишь в случаях, когда применение таких средств необходимо для нейтрализации актуальных угроз безопасности персональных данных.

На практике сертифицированные программы имеют ряд ограничений:

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

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

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

Как выполнить требования и не парализовать работу предприятия

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

Алгоритм действий по приведению информационной системы в соответствие ФЗ № 152

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

1. Обследование организации на предмет соответствия процессов обработки и защиты персональных данных требованиям Федерального закона от 27.07.2006 № 152-ФЗ «О персональных данных».
2. Разработка комплекта внутренней организационно-распорядительной документации, регламентирующей процессы обработки и защиты персональных данных.
3. Определение угроз безопасности и потенциальных нарушителей безопасности персональных данных.
4. Определение требуемого уровня защищенности персональных данных обрабатываемых в информационной системе персональных данных.
5. Разработка технического проекта на создание системы защиты персональных данных.
6. Приобретение средств защиты персональных данных.
7. Внедрение системы защиты персональных данных.
8. Организация и проведение аттестации соответствия системы защиты персональных данных требованиям безопасности информации.

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

Безопасность

Комплекс услуг по обеспечению информационной безопасности предприятия. Подключение к ГИС: АИСТ ГБД, ЕГИСМ и др.

Источник: kontur.ru

Требования к безопасной разработке ПО согласно приказу ФСТЭК №31

В приказе ФСТЭК №31 есть «особенная» подсистема мер — «обеспечение безопасной разработки ПО». Что мы знаем об ОБР?

Например, что в этом направлении ведется нормотворческая работа, примером тому служит проект ГОСТ Р «Обеспечение безопасной разработки ПО» (далее – проект ГОСТ). Посвящен он созданию системы управления безопасной разработкой ПО (далее – СУБР ПО) организацией-разработчиком ПО и учитывает, например, такие практики как Microsoft SDL, Cisco CDL, OWASP CLASP и положения ГОСТ Р ИСО/МЭК 15408-3, ГОСТ Р ИСО/МЭК 27001. Одной из причин создания данного ГОСТ является тот факт, что «виновниками»инцидентов ИБ чаще всего становятся дефекты безопасности и уязвимости программ. Актуальность защиты самого ПО (в том числе применяемого в промышленных системах автоматизации) от угроз, связанных с наличием в нем уязвимостей, не вызывает сомнения (Рисунок 1).

Рисунок 1 – Распределение уязвимостей кода программных средств АСУ ТП и ПО программно-аппаратных средств АСУ ТП согласно сведениям банка данных угроз безопасности информации ФСТЭК

Проект ГОСТ устанавливает требования к процессу разработки программного обеспечения и определяет следующие группы мер, направленные на обеспечение безопасной разработки ПО:

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

Сравним положения проекта ГОСТ с мерами защиты информации подсистемы ОБР Приказа №31 (Таблица 1).

Таблица 1 – Соответствие положений проекта ГОСТ и требований подсистемы ОБР Приказа №31.

Меры защиты информации подсистемы ОБР Приказа №31

Положения проекта ГОСТ (требования к организации-разработчику ПО)

ОБР.0:Разработка правил и процедур (политик) обеспечения безопасной разработки программного обеспечения

Определить и задокументировать политику обеспечения безопасности разработки ПО

ОБР.1:Анализ уязвимостей и угроз безопасности информации в ходе разработки программного обеспечения

Выполнять моделирование угроз с целью выявления потенциальных дефектов безопасности и уязвимостей разрабатываемой программы

ОБР.2:Статический анализ кода программного обеспечения в ходе разработки программного обеспечения

Проводить статический анализ программы с целью выявления дефектов безопасности и уязвимостей программы

ОБР.3:Ручной анализ кода программного обеспечения в ходе разработки программного обеспечения

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

ОБР.4:Тестирование на проникновение в ходе разработки программного обеспечения

Проводить тестирование программы на проникновение с целью выявления дефектов безопасности и уязвимостей программы

ОБР.5:Динамический анализ кода программного обеспечения в ходе разработки программного обеспечения

Проводить динамический анализ программы с целью выявления дефектов безопасности и уязвимостей программы

ОБР.6:Документирование процедур обеспечения безопасной разработки программного обеспечения разработчиком и представление их заказчику (оператору)

Документация системы управления безопасной разработкой ПО должна включать в себя:

-политику обеспечения безопасности разработки ПО;

-описание области функционирования (логические и физические границы) системы управления безопасной разработкой ПО;

-подход к оценке рисков, связанных с обеспечением безопасной разработки ПО;

-документированные свидетельства реализации мер по обеспечению безопасности разработки ПО

Отдельный пункт в проекте ГОСТ посвящен описанию необходимого комплекта документации и требований к управлению документацией СУБР ПО.

Что касается моделирования угроз и выявления уязвимостей в проекте ГОСТ выделена необходимость:

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

Все бы ничего, но, в силу особенностей процесса разработки прикладного ПО АСУ ТП и его специфичности, возникают вопросы к реализации некоторых требований, которые в условиях отсутствия соответствующих методических документов к Приказу №31, воспринимаются через призму субъективного мнения.

Чтобы не заблудиться в своих рассуждениях, мы решили обратиться непосредственно к разработчику Приказа №31, и делимся с вами результатами (Таблица 2). К слову, спасибо представителям ФСТЭК, которые очень подробно ответили на все вопросы в течение месяца, и даже позвонили, чтобы пояснить ответы)).

Таблица 2 – Комментарии ФСТЭК к подсистеме ОБР Приказа №31

Вопрос, касающийся подсистемы ОБР Приказа №31

Выдержка из ответа представителей ФСТЭК

Являются ли инженеры-программисты (представители оператора АСУ), разрабатывающие/дорабатывающие прикладное программное обеспечение для функционирования АСУ ТП (мнемосхемы, алгоритмы ПЛК и т.д.) разработчиками согласно терминологии приказа №31

К разработчикам системы защиты информации АСУ относятся в том числе инженеры-программисты, привлекаемые к разработке/доработке прикладного ПО для обеспечения безопасности информации в АСУ

В случае самостоятельной разработки прикладного программного обеспечения операторами АСУ и необходимости выполнения ими требований к ОБР, какие из анализаторов кода можно использовать? Ведь на данный момент известные анализаторы кода (Safe ERP, Infowatch APPERCUT, SolarinCode, PVS-Studio и т.п.) не ориентированы на SCADA-пакеты и АСУ в целом (не поддерживают языки программирования ПЛК, к примеру)

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

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

Может ли оператор АСУ использовать ПО стороннего разработчика, который не выполняет требования ОБР.0-ОБР.6 при разработке ПО? Если да, то при каких условиях?

В соответствии с пунктом 13.4 Требований требования к мерам и средствам защиты информации, применяемым в АСУ, устанавливаются заказчиком на этапе формирования требований к защите информации в автоматизированной системе управления.

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

В случае отсутствия возможности использования указанного ПО разработчиком системы защиты АСУ должны быть реализованы компенсирующие меры, связанные с применением недоверенного ПО, в соответствии с пунктом 22 Требований

Согласно п.18.14 Приказа №31 контроль принимаемых мер по выявлению, анализу и устранению уязвимостей программного обеспечения осуществляется Заказчиком и (или) Оператором АСУ. Каким образом, выполняется данное требование, в случае, когда Заказчиком или Оператором АСУ не осуществляется разработка прикладного ПО, а используется прикладное ПО (SCADA-пакеты, СУБД, исполнительные системы ПЛК и т.д.) сторонних разработчиков?

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

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

Что мы получаем в итоге?

Требования подсистемы ОБР предъявляются к ПО, разрабатываемому в том числе представителями оператора АСУ ТП, таким образом необходима реализация определенного для конкретной АСУ ТП набора мер данной подсистемы. Плюс в том, что механизм адаптации и уточнения Приказа №31 позволяет обосновать, например, использование ручного анализа кода вместо статистического или динамического. Т.е. возможность использования компенсирующих мер позволяет для каждого специфичного случая обеспечить требуемый уровень защищенности АСУ ТП.

Белых пятен в Приказе №31 становится все меньше. А какие белые пятна для вас были/есть в Приказе №31? С полной версией ответа ФСТЭК России можно ознакомиться здесь.

Источник: www.ec-rs.ru