Приказ ФСТЭК России N239: анализ защищенности ПО и контроль внедрения практик безопасной разработки для ОКИИ

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

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

Согласно Федеральному закону «О безопасности критической информационной инфраструктуры Российской Федерации» от 26.07.2017 N 187-ФЗ (далее – 187 ФЗ), организации, относящие себя к КИИ, должны выполнить ряд шагов по определению уровня критичности их информационных систем в масштабах РФ. Также им необходимо реализовать набор мер по обеспечению ИБ наиболее ключевых из информационных систем, которые в контексте данных требований получили название – ОКИИ.

Более подробно о том, как реализовывать те или иные меры по обеспечению ИБ описано в Приказе ФСТЭК России от 25.12.2017 N 239 (ред. от 20.02.2020) «Об утверждении Требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации» (далее – Приказ ФСТЭК N239).

При анализе данного документа важно учитывать его самую «свежую» редакцию. На текущий момент необходимо учитывать актуальные правки, опубликованные в Приказе ФСТЭК России от 20.02.2020 N 35 «О внесении изменений в Требования по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации, утвержденные приказом Федеральной службы по техническому и экспортному контролю от 25 декабря 2017 г. N 239» (далее – Приказ ФСТЭК N35).

Принципы построения подсистемы защиты информации для ОКИИ

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

Рис.1. Ключевые этапы построения подсистемы защиты информации в организации, согласно требованиям ФСТЭК России (общими словами)

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

На данном этапе выполняется сбор сведений о выстроенной в ИС схеме сети и ключевых ее элементах, также собираются сведения о процессах обработки, передачи и хранении данных в ИС и ответственных лицах, участвующих в проекте.

В рамках этого этапа проводится категорирование ОКИИ. В результате чего определяется, к какой категории значимости относится данная информационная система (ИС).

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

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

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

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

Анализ защищенности ИС и ПО: инструментальные средства контроля и методологии безопасной разработки

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

Рис.2. Общие подходы к реализации актуальных мер по обеспечению ИБ

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

Рис. 3.Примеры типов контролей, входящих в состав анализа защищенности ПО и ИС

В зависимости от типа проводимого анализа защищенности различным будет и набор применяемых методов.

Анализ защищенности информационной системы направлен на применение известных техник и тактик, цель которых скомпрометировать ИС в целом. К примеру, они представлены в базе MITRE ATT&CK, где собрано описание пошагового развития атаки. И если в данных типах работ и производят атаки на ПО, то, как правило, они направлены на известные уязвимости в широко распространенном ПО (к примеру, из такого банка данных уязвимостей как National Vulnerability Database). И если производится поиск уязвимостей нулевого дня, например, в веб-приложениях, то с весьма большими ограничениями по возможностям.

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

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

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

Каждое из перечисленных выше решений является эффективным средством в своей части и дополняет другие. При этом самым осмысленным первым шагом будет применение решений класса – SAST (статических анализаторов кода), но к этому вопросу вернемся чуть позже.

Компаниям-поставщикам ПО, которое будет подвергаться анализу защищенности, важно заранее быть готовыми к такого рода контролям. Контроли могут проводиться на этапе «приемки ПО в эксплуатацию». Чтобы процесс ввода в эксплуатацию прошел как можно более оперативно, требуется поставлять уже более безопасное ПО (не содержащее уязвимости). А самым лучшим способом этого добиться является внедрение у себя в организации практик безопасной разработки.

Рис. 4. Основные инструментальные контроли, выполняемые как при внедрении SDLC, так и DevSecOps

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

Сам термин безопасная разработка в мировом пространстве (в зависимости от источника информации) получил название SDLC (Security development lifecycle) или SSDLC (Security Software development lifecycle).

Сама по себе методология SSDLC (безопасной разработки) представляет из себя концептуальное описание того, какие меры должны быть реализованы в организации и на что следует обращать внимание при их выполнении. Это – скорее структурированный набор деклараций.

Что касается методологии DevSecOps, которая состоит в общем виде из тех же мер, то ее можно назвать набором практикоориентированных подходов, при реализации которых соблюдаются следующие принципы:

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

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

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

Ролевая модель выполнения требований Приказа N239 ФСТЭК России

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

Рис.5. Ключевые роли при выполнении требований ФСТЭК России к контролю безопасности ПО для ОКИИ

Как видно из рисунка выше, ответственный за ОКИИ, руководствуясь требованиями Приказов ФСТЭК России, формирует требования к конкурсной документации. В данной документации, ответственность за исполнение которой лежит на поставщике ПО\ПАК\СЗИ.

Таким образом, на этапе приемки проекта владелец ОКИИ – обязан выполнить проверку соответствия требованиям регуляторов, а производитель ПО\ПАК\СЗИ должен подготовиться к тому, чтобы выполнить данную проверку успешно.

Согласно вступающим в действие с 1 января 2023 года правкам:

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

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

Согласно обязательным для выполнения проверкам в подобных случаях, изложенных в «Приказе ФСТЭК N76» и «Методике по выявлению уязвимостей и недекларированных возможностей в программном обеспечении» (Документ под грифом ДСП), чтобы СЗИ можно было бы считать доверенным, необходимо провести ряд серьезных инструментальных и экспертно-аналитических контролей. В состав обязательных контролей также входит и необходимость проведения анализа защищенности ПО (включая и анализ кода).

Вторым важным изменением, вступающим в силу с 1 января 2023 года, является необходимость проверки вводимого в эксплуатацию системообразующего ПО (АСУТП, АБС, ERP – систем и пр.) на предмет соответствия требованиям безопасной разработки. А именно:

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

29.3.1. Требования по безопасной разработке программного обеспечения:

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

29.3.2. Требования к испытаниям по выявлению уязвимостей в программном обеспечении:

• проведение статического анализа исходного кода программы;
• проведение фаззинг-тестирования программы, направленного на выявление в ней уязвимостей;
• проведение динамического анализа кода программы (для программного обеспечения, планируемого к применению в значимых объектах 1 категории значимости).

29.3.3. Требования к поддержке безопасности программного обеспечения:

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

29.4. Выполнение требований по безопасности, указанных в подпунктах 29.3.1-29.3.3 пункта

29.3 настоящих Требований, оценивается лицом, выполняющим работы по созданию (модернизации, реконструкции или ремонту) значимого объекта и (или) обеспечению его безопасности, на этапе проектирования значимого объекта на основе результатов анализа материалов и документов, представляемых разработчиком (производителем) программного обеспечения в соответствии с техническим заданием (частным техническим заданием), разрабатываемым в соответствии с пунктом 10 настоящих Требований.

Результаты оценки включаются в проектную документацию на значимый объект (подсистему безопасности значимого объекта) и представляются субъекту критической информационной инфраструктуры».

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

Также стоит отметить, что для выполнения требований государственного регулятора разработчикам необходимо ориентироваться на отраслевой стандарт «ГОСТ Р 56939-2016. Защита информации. Разработка безопасного программного обеспечения. Общие требования».

С чего начать подготовку ОКИИ

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

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

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

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

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

Рис.6. Описание выявленных уязвимостей, представленное в интерфейсе статического анализатора кода Solar appScreener

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

Данное инструментальное средство обнаруживает все проблемы автоматически. Решение имеет возможность интеграции со сборочной инфраструктурой в рамках процессов безопасной разработки\SDLC\DevSecOps «без танцев с бубном» и «из коробки».

Иными словами, Solar appScreener содержит возможность интеграции с большим перечнем решений сборочной инфраструктуры, применяемых разработчиками по всему миру (таких как CI\CD, VCS -хостинги,IDE и сборщики, таск трекеры и пр.). Анализатор полностью соответствует всем требованиям регуляторов, а отчет, формируемый по итогу его работы, содержит подробное описание уязвимостей с точным указанием, где в коде возникли проблемы, и, конечно, рекомендации по их устранению. Работать с данным инструментальным средством может любой эксперт в области разработки ПО и ИБ.

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

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

Разумеется, что по мере роста экспертизы внутри компании все меньшую роль могут играть подрядчики, и верным шагом будет поэтапно к этому стремиться.

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

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

Реклама. Рекламодатель ООО "СОЛАР СЕКЬЮРИТИ", ОГРН 1157746204230.