Привет, Хабр!

На связи Антон Башарин, технический директор Swordfish Security. После некоторого перерыва мы продолжаем наш цикл статей, рассказывающий о процессах безопасной разработки в контексте стандартов серии ГОСТ Р ИСО/МЭК 15408. В этом, финальном, материале данной серии мы посмотрим на обозначенный вопрос с точки зрения оценщика, который проводит сертификацию, проверки на наличие уязвимостей и соответствие стандартам безопасности, а также наметим будущие изменения в практиках и подходах. По традиции, в подготовке статьи нам помогал независимый эксперт и специалист по информационной безопасности Рустам Гусейнов.

Напомним, в вводной статье цикла мы познакомились с историей ОУД, ключевыми терминами, положениями и концепцией фреймворка, сформировали общее представление о проблеме. Во втором материале – рассмотрели фреймворк с позиции задач и обязанностей разработчика ПО. Если вы впервые или совсем недавно столкнулись с этими не всем привычными аббревиатурами (ОУД4, ГОСТ Р ИСО/МЭК 15408-3-2013) и пока еще не слишком разбираетесь в теме, прочитайте наши первые статьи – они помогут вам разобраться.

А теперь приступим к делу!

Оглавление

1. Введение

2. Оценка по чек-листу

3. ТОП-3 популярных вопросов

4. Задачи оценщика и будущее ОУД4

5. Возможности автоматизации

6. Заключение

Введение 

С момента публикации второго материала (июль 2021 года) кое-что успело измениться. А если говорить конкретно:

• Вышел уточненный профиль защиты Банка России с разделом 7.4. Он посвящен «гибкой разработке» и нацелен на гармонизацию подходов ОУД с современными продуктовыми реалиями.

• Стартовала новая волна импортозамещения в области средств защиты, вызванная специальной военной операцией и указом Президента Российской Федерации от 1 мая 2022 года № 250.

• В 2022 году технический комитет по стандартизации «Защита информации» (ТК 362) подготовил и направил на утверждение в Росстандарт новые версии нормативных документов 15408 (они еще не приняты и не вступили в силу).

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

Но есть и то, что осталось без изменений. В частности, по-прежнему отсутствует четкая обратная связь от регулятора в лице Банка России по степени детализации работ, совершаемых как на стороне разработчика, так и на стороне оценщика. Также всё еще актуально Информационное письмо Банка России от 8 июля 2020 г. N ИН-014-56/110 «Об анализе уязвимостей ПО по требованиям к оценочному уровню доверия (ОУД)». Оно гласит, что работы проводятся «в соответствии с требованиями национального стандарта Российской Федерации ГОСТ Р ИСО/МЭК 15408-3-2013». Еще в нем рекомендуется применять методический документ «Профиль защиты прикладного программного обеспечения автоматизированных систем и приложений кредитных организаций и некредитных финансовых организаций».

Таким образом, подходы регулятора остаются стабильными со времен вступления в силу Положения № 382-П и семейства стандартов ГОСТ 57580. Иными словами, специалисты получают обратную связь о качестве, корректности и полноте проведенных ими работ только во время визитов аудиторов Банка России. Шаблонов и примеров документов по-прежнему нет, потому что «необходимое уже содержится в стандартах и нормативно-правовых актах». И лучшее, что остается делать разработчикам и оценщикам в этой ситуации – внимательно изучать стандарты и сопутствующие документы, по возможности сверяться с экспертизой специалистов испытательных лабораторий ФСТЭК России. Они много лет работают в системе ОУД, а в последние годы развивают собственные подходы к уровням доверия и стандартизации требований к типовым средствам защиты. 

Напомним, что сертификация ОО в испытательной лаборатории является вторым легитимным способом выполнения требований Банка России к ОУД4. Эта позиция зафиксирована во всех сопутствующих нормативно-правовых актах ЦБ по защите информации (683-П, 719-П, 757-П и ряде других). Значит, консультации с испытательными лабораториями, даже если вы выбрали путь самооценки, помогут получить полезную обратную связь от практиков, которые выполняют аналогичные задачи более десяти лет. 

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

Оценка по чек-листу

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

Второе, что нужно сделать оценщикам – выпить как минимум три чашки кофе, приготовиться к хардкору и открыть ГОСТ Р ИСО/МЭК 18045-2013. В нем есть исчерпывающее описание всех действий с подробными разъяснениями, что и как нужно реализовать на каждом шаге работы, в привязке к индексам требований, установленным в семействе 15408, которые мы разобрали ранее. 

Для примера рассмотрим случайное место стандарта: 

Нам четко говорят, что, если требование ASE_REQ.1-2 актуально для данного кейса (таблички, по которым это определяется, приведены в предыдущих статьях), нужно проверить ряд документов и убедиться, что они содержат соответствующие положения. Дополнительно стандарт предлагает общие замечания и комментарии к каждому классу, а также приложения-справочники, разъясняющие подходы к действиям оценщика. 

Тем не менее при кажущейся избыточности проверок и шагов действия оценщика описываются достаточно верхнеуровнево. И получается не такая уж страшная задача, если исходить из того, что по букве закона оценщик не должен заниматься созданием документации и другими вопросами разработчика ОО (например, тестированием приложения в рамках класса ATE), и что из всего объема шагов, содержащихся в стандарте, необходимо выполнить лишь минимум, свойственный ОУД4. Более того, в стандарте 18045 в Приложении А прямо говорится о возможности использования выборок и отсутствии жестких требований к отчетности. В целом принятие решений о полноте и достаточности работ в документе делегируется на систему оценки/орган по сертификации. Это создает некоторую рекурсию с упомянутым во введении письмом ЦБ, где дается ссылка на стандарты как на источник всех необходимых требований к работе оценщика.  

Таким образом, всё, что вам нужно – это просто взять и сделать всю работу, согласно стандарту 18045. 

Но есть ли здесь какие-нибудь прикладные нюансы, которые помогут новичкам на тернистом пути оценки соответствия и раскроют старожилам возможности оптимизации процесса? – Разбираемся. 

ТОП-3 популярных вопросов 

Для начала ответим на часто встречающиеся вопросы, которые касаются ОУД. 

1. Относительно периодичности работ по оценке соответствия.
   В нормативно-правовых актах Банка России этот показатель не установлен в явном виде. При этом стоит руководствоваться правовой аналогией с оценками соответствия по ГОСТ 57580.1-2017, а также риск-ориентированным подходом и выбирать такую периодичность, которая бьется с ГОСТ 57580. То есть, если у компании стандартный уровень защиты и/или ее приложение не претерпевает значительных изменений, таких как переписывание ядра, замена стека технологий, формирующих среду функционирования ОС, СУБД, веб-серверов и прочего, то уместно говорить об оценке соответствия 1 раз в 2 года. Если у организации усиленный уровень защиты и/или ее приложение значительно модернизируется, то можно проводить ежегодную оценку в процессе апгрейда до вывода новой версии в промышленную эксплуатацию.

2. Относительно профиля защиты и «сертификации» жизненного цикла.
   В рамках Профиля защиты Банка России, который, как мы увидели во введении, носит рекомендательный характер, с 2022 года появилась опция «построения безопасного жизненного цикла ОО». Она зафиксирована в разделе 7.4 данного документа. Процитируем фрагмент: 

   «В связи с этим требования настоящего раздела могут использоваться в целях реализации требования доверия к безопасности (ТДБ) ОО (п. 7.2. настоящего документа) в случаях, когда финансовая организация либо разработчик ОО (далее при совместном упоминании – Разработчик) реализует документированный безопасный жизненный цикл ОО, основанный на современных гибких практиках разработки, тестирования и внедрения ОО, в основе которых лежат различные методологии безопасного жизненного цикла программных продуктов (например, такие международные и общепринятые в рамках соответствующих сообществ методологии, как SDLC, DevSecOps, BSIMM, OWASP и др.)».

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

   В качестве примеров рассмотрим две таблицы. Первая иллюстрирует то, как стандарт предлагает «оптимизировать» нагрузку и адаптироваться под современные agile‑методологии — выглядит очень удобно и правильно.

Кажется, что можно очень здорово оптимизировать трудозатраты и не мучиться с адаптацией под ОУД4. Но нам стоит держать в уме то, что Профиль защиты – рекомендация, и нормативно-правовые акты ссылаются на ГОСТ Р ИСО/МЭК 15408-3-2013 – в нем ничего нет о Профиле, а его реализацию необходимо оценивать по ГОСТ Р ИСО/МЭК 18045-2013. Так, если мы пройдемся дальше по Профилю защиты, то обнаружим, что в разъяснениях нам предлагают довольно консервативную практику, которая не очень-то снижает трудозатраты. 

Например, в рамках класса ATE по-прежнему необходимо проводить тестирование функций безопасности, то есть натурально проверять, как все заложенные в ОО возможности (парольная политика, безопасная аутентификация, журналирование событий и тому подобное) отрабатывают себя. 

Фактически нам предстоит выполнить всё тот же ОУД, просто здесь (см. табл. 2) есть словарик, сопоставляющий его практики с некоторыми терминами DevSecOps и Agile.

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

Задачи оценщика и будущее ОУД4

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

1. Оценщик приходит в организацию и принимает от нее весь набор свидетельств, включающий в себя пакеты документов на ОО и его ЖЦ; 

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

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

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

1. Собрать рабочую группу с координатором со стороны разработчика, чтобы обеспечить своевременное предоставление всех документов, доступов, исходников и не тормозить работу; 

2. Осуществлять грамотное ресурсное планирование и проектное управление, чтобы минимизировать количество ошибок и избежать нехватки рабочих рук;

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

4. Провести внутреннюю проверку соблюдения всех требований стандарта 18045 перед сдачей документации заказчику. 

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

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

Возможности автоматизации

В 2022 году на конференции Coop-Days в выступлении, посвященном проблематике ОУД4, прозвучала идея шаблонизировать соответствующие документы, в том числе отчетности по итогам выполненных проверок. Сегодня, когда на свет вышел GitHub Copilot, ChatGPT 4 автоматизирует работу программистов, а Stable Diffusion «радует» дизайнеров, всё чаще звучит вопрос: «А нельзя ли доверить оценку роботам?» Ведь там, где есть четкие и понятные шаги, где существуют прозрачные критерии, где все сводимо к набору типовых элементов, сам бог велел освободить людей от ручной работы с помощью AI. Но так ли всё просто на самом деле?

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

Теперь представим, что специалисты придумали конструкции, позволяющие безболезненно и этично переносить подобные задачи на плечи виртуальных помощников. И здесь мы сталкиваемся со второй проблемой – современные AI основаны на использовании нейронных сетей, которые учатся на определенных выборках данных и таким образом формируют свои модели мира. Но эти модели и результаты, которые выдает конкретная сеть в ответ на отправленную ей информацию, являются для пользователей черным ящиком. Да, современные нейросети способны корректно дополнять поисковые системы или выступать в роли джунов-помощников, выполняющих какие-то отдельные, хорошо описанные операции. Но если работать в области, далекой от «массового пользователя», или поручать подобным инструментам слишком большой объем задач без пояснений и ограничений, то вероятность столкнуться с «галлюцинациями», поверхностными решениями, грубыми ошибками и даже фальсификатом будет стремиться к 100%.   

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

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

Заключение

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

Тем не менее опыт ОУД не пройдет бесследно. Несмотря на различия, в основе всех практик лежат универсальные принципы. Подобно тому как положение 382-П готовило финансовые организации к более изощренным и детализированным инфраструктурным требованиям ГОСТ 57580.1-2017, так и практики ОУД4 стали для финсектора первым шагом на пути к бесконечному развитию безопасности приложений. 

Можно сказать, что благодаря инициативе Банка России финансовая отрасль на наших глазах за пять лет практически прошла тот путь, который система оценки ФСТЭК России преодолевала с начала нулевых годов, когда стандарты серии 15408 только вступили в силу на территории РФ. – Уже тогда эксперты подчеркивали неясность вопроса и пророчили ему «непростую судьбу».

На этом всё. До новых встреч, друзья!

P. S. Будем рады ответить на ваши вопросы и получить обратную связь в комментариях)