Оценочный уровень доверия (оуд4) и гост р исо/мэк 15408-3-2013. введение

Введение

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

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

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

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

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

Введение и цели цикла

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

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

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

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

Обозначение: ГОСТ Р ИСО/МЭК 15408-2-2002
Статус: заменён
Название рус.: Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 2. Функциональные требования безопасности
Название англ.: Information technology. Security techniques. Evaluation criteria for IT security. Part 2. Security functional requirements
Дата актуализации текста: 07.11.2012
Дата актуализации описания: 07.11.2012
Дата введения в действие: 01.01.2004
Область и условия применения: Настоящий стандарт распространяется на функциональные компоненты безопасности, являющиеся основой для функциональных требований безопасности информационных технологий (ИТ) объекта оценки (ОО), излагаемых в профиле защиты (ПЗ) или в задании по безопасности (ЗБ). Требования описывают желательный безопасный режим функционирования ОО и предназначены для достижения целей безопасности, установленных в ПЗ или ЗБ. Требования описывают также свойства безопасности, которые пользователи могут обнаружить при непосредственном взаимодействии с ОО (т.е. при входе и выходе) или при реакции ОО на запросы
Заменяющий: ГОСТ Р ИСО/МЭК 15408-2-2008
Расположен в:
  • ОКС Общероссийский классификатор стандартов
    • 35 ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ. МАШИНЫ КОНТОРСКИЕ

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

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

        П85 Виды представления информации и математическое обеспечение машин

  • Тематические сборники

    ИТ.ВОС Информационные технологии. Взаимосвязь открытых систем.

  • ОКП
    • 400000 ВЫЧИСЛИТЕЛЬНАЯ ТЕХНИКА
    • 500000 ПРОГРАММНЫЕ СРЕДСТВА И ИНФОРМАЦИОННЫЕ ПРОДУКТЫ ВЫЧИСЛИТЕЛЬНОЙ ТЕХНИКИ
      • 501000 Системные программные средства

        501400 Программные средства защиты и восстановления информации

Наши события

5 октября 2021, 12:50
RusCable Insider #241 — Оборудование Xinming. Genesis кабельных полимеров. Новый проект «По следам Герды»: Великокняжеский кабельный завод

1 октября 2021, 11:13
RusCable Live — Pink Electric, Сарансккабель, Москабель. Эфир 1.10.2021

28 сентября 2021, 13:08
Премьера спецвыпуска RusCable Review: Сарансккабель. Павел Цветков. Новое поколение кабельщиков. Шлангокабель

27 сентября 2021, 12:58
RusCable Insider #240 — Цифровой Москабельмет. Интервью с Павлом Цветковым, Сарансккабель. «АЧП-терроризм» побежден?

27 сентября 2021, 12:40
Какой он, кабельный завод будущего?

23 сентября 2021, 11:47
“АЧП-терроризм” побежден? Счет 3:0 в пользу кабельщиков. СЗМТУ Росстандарта может дорого заплатить за действия “псевдорегулятора”

ПАРТНЁРЫ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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