Суть материала.

Вторая статья цикла, посвященного ОУД, рассказывает о проблеме с позиции разработчика прикладного ПО (или заказчика, который должен получить гарантии безопасности конечного продукта). Материал подразумевает знакомство читателя с темой, поэтому если вы впервые столкнулись с этими страшными аббревиатурами и не понимаете контекста и терминологии, хотите понимать источники требований регуляторов, пожалуйста, изучите для начала первую статью и комментарии к ней https://habr.com/ru/company/swordfish_security/blog/543016/. Там подробно описывается контекст проблемы и приводится специальная терминология. Сегодня мы развиваем тему почти не оглядываясь назад. Термины “стандарт”, “фреймворк ОУД”, “семейство стандартов ГОСТ 15408” используются по тексту статьи как синонимы. В подготовке материала мне помогал независимый эксперт и специалист по информационной безопасности - Рустам Гусейнов.

Введение

Давайте ненадолго абстрагируемся от ОУД. Представьте, что вы разработчик и создаете приложение для финансовых или кредитных организаций, подшефных Банку России. Или вы работаете в одной из таких организаций - банке, страховой, брокере, и являйтесь заказчиком продукта. Вы очень хотите гарантировать определенный уровень качества, и даже если не хотите - существующие SLA, нормативы регуляторов и требования контрактов заставляют прорабатывать не только функциональные требования, но и вопросы информационной безопасности. С чего же следует начать?

С моделирования угроз (см. рис. 1), основанного на понимании архитектуры продукта, используемых технологий, функциональных возможностей и зависимостей продукта от ИТ-инфраструктуры и других автоматизированных систем, с которыми ему приходится взаимодействовать. В основе этой работы лежит понятие “актива” - чего-то ценного для человека или организации, чего-то что требует защиты от актуальных угроз, для уменьшения риска и снижения вероятности ущерба пользователям системы. В качестве пользователей можно рассматривать людей и организации, а риски и ущерб оценивать через вероятность и возможные потери, например финансовые. Логично, что владельцы “актива” стремятся управлять рисками и избегать ущерба. Для этого разработчики приложения вырабатывают меры защиты, которые снижают актуальные для данного продукта риски, позволяя защищаться от актуальных угроз. И пусть этот процесс, в отличии от средств личной гигиены, не дает гарантий 100% защиты, организация сознательно принимает решение о достаточности или недостаточности реализованных мер, опираясь на свои представления и оценки об актуальных угрозах и нарушителях.

Упрощенно можно считать, что организация пытается сделать реализацию угроз нерентабельной/маловероятной для всех сценариев, которые признаются актуальными (или, как было отмечено выше, проистекают из внешних требований - заказчиков, нормативных документов, лучших практик, которым организация стремится соответствовать). Это дает определенные гарантии сохранности базовых свойств всех активов, входящих в приложение, например обеспечивает конфиденциальность обрабатываемых приложением персональных данных за счет корректной ролевой модели или гарантирует доступность сервисов за счет отказоустойчивой архитектуры приложения, избыточности на уровне ИТ-инфраструктуры и реализованных процедур восстановления работоспособности.

Но как мы можем быть уверены в том, что предлагаемые решения и меры защиты действительно полезны и работают? Как проверить, что написанное в документации фактически выполняется нашим приложением? С помощью независимой оценки (см. рис. 2), результаты которой служат гарантией безопасности приложения и фиксируют его соответствие установленным требованиям. Безусловно, даже самая независимая и педантичная оценка не является абсолютной истиной. Люди могут ошибаться, в приложениях и зависимостях могут находиться 0-day уязвимости, в результате интеграций системы с другими приложениями может увеличиваться поверхность атаки… Но в заданных границах, с учетом выбранной методологии и выборки, хорошая оценка выявляет значительную часть проблем и существенно уменьшает вероятность несоответствия приложения требованиям или неадекватности самих требований, установленных разработчиком или заказчиком. А это снижает риски и вероятность реализации угроз, влекущих за собой болезненные инциденты и ущерб. Остаточные риски, которые не удалось или которые невозможно эффективно обработать, принимаются как данность и под них закладываются соответствующие резервы и сценарии. Например, если сильный искусственный интеллект подчинит себе инфраструктуру нашего облачного провайдера и остановит работу приложения, то мы перезапустим его в собственной серверной на допотопном оборудовании, с потерей доступности в 1 час и уменьшением производительности системы на 50%, что будет стоить нам 3 миллиона рублей в результате необработанных запросов клиента в первый час и примерно 12 миллионов рублей в сутки в течении всего времени эксплуатации допотопного ЦОДа, пока новоявленная Сара Конор не справится с ИИ.

Рис. 2 Роль оценки достаточности и корректности выбранных мер защиты

Задание по безопасности

Краеугольным камнем разработки приложения в рамках семейства стандартов является “задание по безопасности”. По существу это техническое задание, с учетом которого необходимо воплотить в жизнь функции безопасности приложения, которое в будущем станет “объектом оценки”. Здесь скрывается важный нюанс - для больших или модульных приложений допускается выводить все функции и интерфейсы, нуждающиеся в мерах защиты, в отдельный элемент или набор элементов, что позволяет делать “объект оценки” меньше целого продукта. Т.е. если вся ваша автоматизированная система состоит из 1000 модулей и 3 миллионов строк кода, вы можете избежать разработки бесконечно длинного задания и последующей оценки всей этой махины. Для этого достаточно вывести функционал клиентского интерфейса, работающего по https и доступного через интернет, в отдельный шлюзовой модуль, реализовать другие необходимые сервисы безопасности - например, авторизацию и журналирование - еще в паре модулей. В итоге может оказаться, что задание по безопасности охватывает лишь 3 модуля из 1000, и всего 10 тысяч строк кода. Согласитесь - это огромная разница и существенное уменьшение трудозатрат, особенно если в ядре приложения реализована сложная бизнес-логика, которая непрерывно изменяется. Естественно, что подобное выделение “объекта оценки” требует честного анализа рисков и угроз, что в свою очередь требует качественного описания системы, ее интерфейсов, взаимодействий и зависимостей. На бумаге вы можете написать, что камни падают вверх, но цена вопроса - безопасность пользователей системы и их данных, поэтому не стоит воспринимать описанную возможность слишком творчески. Цена некорректно составленного задания по безопасности - некачественное приложение в некачественной имплементации, что ведет к реализации угроз и инцидентам.

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

А. “Функциональные требования к безопасности” (требования к реализуемым мерам защиты, в соответствии с которыми необходимо проектировать систему) ;

Б. “Требования доверия к безопасности” (требования к оценке, в соответствии с которыми необходимо проводить внешний аудит).

На основании этих требований необходимо разработать, а затем и оценить само приложение.

Здесь у пытливого читателя наверняка возникнет практический вопрос - а как быть с уже разработанными системами? Увы, скорее всего начав разработку документации постфактум и сопоставив уже существующее приложение с семейством стандартов, вы обнаружите, что у вас накопился существенный бэклог - какие-то актуальные функции будут не реализованы вообще, какие-то реализованы криво, какие-то окажутся частью монолитного приложения с кучей дополнительного функционала, что приведет к удорожанию работ и увеличению их продолжительности, т.к. размеры объекта оценки вырастут. Тут нет легких и быстрых путей. ОУД существует в полном соответствии с заповедью создателя одной из версий структурного анализа - Тома де Марко - в идеальном мире которого проектирование и дизайн системы должны занимать больше времени, чем ее непосредственная разработка {ссылка на автора и книгу}. Отсюда встречающиеся на практике, особенно в Agile командах восторгающихся SCRUM, проблемы при попытки реализации предлагаемых ОУД подходов.

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

В июне 2020 года Банк России разработал собственный профиль защиты для финансового ПО (различных вариаций программ дистанционного банковского обслуживания клиентов), и хотя, согласно письмам Банка России, профиль носит рекомендательный характер, в р. 3.5 самого Профиля есть прямое указание на его обязательность при разработке заданий по безопасности на его основе. По факту разработчикам и заказчикам рекомендуется опираться на Профиль Банка России, как на каталог необходимых требований и по возможности соответствовать ему, либо строго обосновывать неприменимость его положений, чтобы ваше задание по безопасности не отклонялось от магистрального пути, заданного Банком России. Изучение Профиля несет еще одну, не очевидную пользу - он позволяет относительно безболезненно погрузиться в контекст ОУД на конкретном примере, по нашему опыту. Поэтому если после первой статьи цикла вы не знаете с чего начать погружение, попробуйте сначала проработать ГОСТ 15408-1-2012, а затем читайте профиль, подключая остальные документы по необходимости.

Фреймворк вводит еще несколько концептуальных понятий, актуальных для разработчика, но для простоты изложения мы оставим их за скобками материала (эта статья лишь одна из ступеней на пути к чтению оригинала, которое, поверьте, неизбежно). Самое важное осознать, что разработчик в своей деятельности руководствуется риск-ориентированным подходом и выстраивает наборы требований, исходя из актуальных для конкретного приложения угроз, которые в свою очередь зависят не только от приложения, но и от среды функционирования - от всех тех операционных систем, баз данных, сетевого окружения и прочего, что может влиять на безопасность активов (подробнее см. р. 4 и 5 Профиля защиты Банка России). Само задание по безопасности не содержит функциональных требований к безопасности среды и фокусируется исключительно на самом приложении. При этом, в эксплуатационной документации для клиента, внутренних политиках организации, а также при анализе уязвимостей конечного, введенного в промышленную эксплуатацию приложения, проверяющими выполняется оценка корректности настроек среды функционирования и ее безопасности, что является неотъемлемой частью работ (в следующей статье, полностью посвященной оценке, мы остановимся на этом вопросе). Мало утешения в том, что приложение в итоге взломали и нанесли ущерб не из-за уязвимой реализации разработчиком клиентского интерфейса, а из-за пароля qwerty на учетку local admin на хосте с Windows с проброшенным в интернет непропатченным RDP.

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

Рис. 3 Связь концептуальных понятий

Структура задания по безопасности жестко регламентирована в Приложении А к ГОСТ 15408-1 и отдельном стандарте. Ее можно представить следующим образом:

Рис. 4 Структура задания по безопасности

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

Другие документы для безопасности разработки

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

Упрощенно можно говорить о двух категориях документов:

А. Документации для релиза (т.е. конкретной версии приложения, в отношении которой проводится анализ уязвимостей);

Б. Документации для безопасности разработки (т.е. для построения пресловутого Secure SDLC).

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

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

Здесь важно сделать отступление - с момента публикации первой статьи кое-что изменилось. Банк России в новом Положении № 757-П от 20.04.2021 (замена Положению № 684-П для не кредитных финансовых организаций) и в проекте изменений в Положение № 683-П (для кредитных организаций) явно указывает, что подшефные ЦБ организации должны соответствовать ОУД. А это значит, что со следующего года в организациях, ответственных за безопасность продукта, должны присутствовать оба пакета документов. Любимая всеми опция сертификации приложения в системе ФСТЭК осталась, но уже не по НДВ, а в соответствии с Приказом ФСТЭК № 76 от 02.06.2020 и уровнями доверия, как их понимает этот регулятор (не имеет ничего общего с семейством 15408, по которому предлагается проводить оценку соответствия). Добавлены явно опции самостоятельной оценки соответствия, что является дополнительным аргументом в пользу построения у себя DevSecOps. Точные сроки достижения соответствия ОУД разнятся для организаций разных типов, но вы наверняка знаете свой дедлайн, а если нет - самое время исследовать этот вопрос. Помним - процесс качественной и повторяемой реализации ОУД не только дорогостоящий, но и требовательный ко времени.

Чтобы ОУД не остался для вас “бумажной” утопией, вероятно, придется создавать или расширять application security team, нанимать штатного техписа, внедрять средства защиты и оркестрации безопасной разработки. Такой путь, вероятно, будет опробован только довольно крупными организациями с большим объемом собственной разработки, подпадающей под требования к ОУД, либо реализован в массовом сегменте, аутсорсерсами, замыкающими на себя выполнения требований своих заказчиков. Для совсем маленьких организаций с собственными приложениями, небольшими бюджетами и маленькими командами реализация ОУД может быть обременительна, хотя справедливости ради необходимо понимать - что согласно упоминаемым выше положениям Банка России ОУД обязателен только для организаций, относимых к усиленному и стандартному уровням защиты, что соответствует большим оборотам денег и операций. Поэтому как разработчики или заказчики не делайте далеко идущих выводов без совещания с юристами и бизнес-аналитиками, возможно требования к ОУД неактуальны для вас в обозримой перспективе. Но даже если ОУД актуален, экономические и технологические факторы при анализе и оценке рисков никто не отменял, стоимость мер защиты должна быть адекватна ценности защищаемого актива, а сами меры должны закрывать актуальные, реализуемые угрозы. Поэтому, как и с любыми комплексными проектами, фактическая реализация ОУД может оказаться не такой страшной и тяжеловесной, какой она кажется при отдаленном рассмотрении.

Требования к функциям безопасности. Структура 15408-2-2013

В ГОСТ 15408 наименьший набор требований называется “компонентом”. Компоненты образуют “семейства” - множество компонент, которые направлены на достижения сходных целей, но отличаются акцентами и строгостью. В свою очередь семейства образуют “классы” - множество семейств, объединенных общим назначением. Декомпозиция класса представлена ниже:

Рис. 5 Декомпозиция класса

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

Рис. 6. Декомпозиция элементов, формирующих функциональные требования безопасности

В ГОСТе выделяются следующие классы:

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

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

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

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

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

• FMT Управление безопасностью. Класс содержит семейства, определяющие требования по управлению атрибутами и данными функциями безопасности, а также по управлению ролями безопасности;

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

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

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

• FTA Контроль доступа к системе. Класс определяет функциональные требования по идентификации и аутентификации для контроля над установленным сеансом пользователя;

• FTP Доверенный путь/ канал. Класс обеспечивает требования:

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

  • для доверенного канала связи между функциями безопасности системы.

Жаждующих подробностей отсылаем к оригиналу, в теле и приложениях которого подробно описываются отдельные компоненты и их атрибуты. Здесь же отметим, что разработчику не требуется включать в задание по безопасности и иную документацию на приложение все семейства всех классов. Может быть выбрано количество, существенно меньшее половины всех имеющихся семейств функциональных классов (помним, что источником вдохновения нам служит Профиль защиты ЦБ).

Например, в классе «FAU Аудит безопасности», в задании по безопасности может быть не включено семейство “FAU.ARP”. Далее, получившееся небольшое количество требований к семействам можно декомпозировать на более низкий уровень, аналогичным образом выбрав лишь часть компонент входящих в семейство.

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

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

Первая - это “зависимости”, вторая - это “пакеты”.

“Зависимости” - это компоненты, связанные с данным и обязательно необходимые для выполнения указанных требований. Т.е. если компонент А зависит от компонента Б, то мы должны заложить в наш набор требований и А, и Б, в противном случае мы не будем выполнять требования фреймворка.

Чтобы стало понятнее, рассмотрим цитату из Приложения J к ГОСТ 15408-2, которое описывает требования к классу FPT, связанному с целостностью и управлением функциями безопасности:

“J.6.2 FPT_PHP.1 Пассивное обнаружение физического нападения
J.6.2.1 Замечания по применению для пользователя
Компонент FPT_PHP.1 «Пассивное обнаружение физической атаки» следует применять, когда угрозам несанкционированного физического воздействия на части ОО не противопоставлены процедурные методы. В этом компоненте рассматривается угроза, что физическое воздействие на ФБО может и не быть выявлено. Обычно задача верификации того, что нападение имело место, возлагается на уполномоченного пользователя. Как было изложено выше, этот компонент всего лишь представляет способность ФБО обнаруживать физическое воздействие, поэтому требуется зависимость от FMT_MOF.1 «Управление режимом выполнения функций безопасности», чтобы специфицировать, кто и каким образом может воспользоваться этой способностью. Если это выполняется с помощью механизма, не связанного с ИТ (например, путем физической проверки), то может быть указано, что зависимость от FMT_MOF.1 не удовлетворяется.”

Более того, с учетом ориентации фреймворка на реальную безопасность, попытка игнорировать существование компонентов, нейтрализующих актуальные для вашего приложения угрозы, является заведомо плохим вариантом. При таком раскладе независимый оценщик совершенно закономерно возмутится отсутствию необходимых защитных мер и укажет на небезопасность приложения, его несоответствие требованиям фреймворка и неспособность противостоять реальному злоумышленнику. А это в свою очередь может привести вас к вопросам со стороны Банка России, новые подходы к риск-профилированию которого учитывают влияние информационной безопасности на операционные риски подшефных организаций (см. Положение Банка России № 716 от 08.04.2020).

“Пакеты требований” - это установленные наборы мер, которые необходимо выполнять. Об этом поговорим в следующем разделе.

Требования к уровням доверия. ГОСТ 15408-3-2013

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

Вспомним иллюстрацию из первой статьи цикла:

Рис. 7 Состав уровней доверия

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

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

• ASE Оценка задания по безопасности. Требуется для демонстрации того, что ЗБ является правильным и внутренне непротиворечивым, и если ЗБ основано на одном или более ПЗ или пакетах доверия, что ЗБ является корректной реализацией этих ПЗ и пакетов. Эти свойства необходимы для того, чтобы можно было использовать ЗБ в качестве основы при оценке ОО.

• ADV Разработка. Требования этого класса предоставляют информацию об объекте оценки. Сведения, полученные путем изучения этой информации, служат основой для проведения анализа уязвимостей и тестирования ОО в соответствии с описанием, представленным в классах AVA «Анализ уязвимостей» и АТЕ «Тестирование».

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

• ALC Поддержка жизненного цикла. Является аспектом установления организационного порядка и управления в процессе совершенствования ОО во время его разработки и сопровождения. Уверенность в соответствии ОО требованиям безопасности к ОО будет больше, если анализ безопасности и формирование свидетельств выполняются на регулярной основе как неотъемлемая часть деятельности по разработке и сопровождению.

• ATE Тестирование. Тестирование позволяет получить доверие к тому, что ФБО функционирует в описанном (в функциональной спецификации, проекте ОО, представлении реализации) режиме.

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

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

Требования Стандарта привязываются к ролям - явно указано, какие требования находятся на стороне разработчика или заказчика (если последний самостоятельно разрабатывает или курирует разработку продукта), а какие относятся к оценщику (о специфических задачах оценщика мы поговорим в следующей статье цикла):

Рис. 8 Пример требования к разработчику 

Рис. 9 Пример требований к оценщику

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

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

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

Заключение

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

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

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

Термины и сокращения

ЗБ - задание по безопасности

ИСО/МЭК - Международная организация по стандартизации / Международная электротехническая комиссия

НДВ - не декларированные возможности

ОО - объект оценки

ПЗ - профиль защиты

ФБО - функциональные возможности безопасности ОО (реализация ФТБ)

ФТБ - функциональные требования безопасности (каталог содержится в ГОСТ Р ИСО/МЭК 15408-2-2013)

ЦБ - Банк России, центральный банк

Соавтор: (Рустам Гусейнов, специалист по информационной безопасности).