Гост р исо/мэк 15408-1-2008

Введение

Международный стандарт ИСО/МЭК 15408:2005 подготовлен Совместным техническим комитетом ИСО/МЭК СТК1 «Информационные технологии», Подкомитетом ПК27 «Методы и средства обеспечения безопасности ИТ». Идентичный стандарту ИСО/МЭК 15408:2005 текст опубликован организациями-спонсо-рами проекта «Общие критерии» как «Общие критерии оценки безопасности информационных технологий», версия 2.3 (ОК, версия 2.3).

Второе издание стандарта (ИСО/МЭК 15408:2005) отменяет и заменяет первое издание (ИСО/МЭК 15408:1999), которое подверглось технической переработке.

ИСО/МЭК 15408 под общим наименованием «Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий» состоит из следую-щихчастей:

—    часть 1. Введение и общая модель;

—    часть 2. Функциональные требования безопасности;

—    часть 3. Требования доверия к безопасности.

Если имеют в виду все три части стандарта, используют обозначение ИСО/МЭК 15408.

Компоненты доверия к безопасности, определенные в данной части ИСО/МЭК 15408, являются основой для выражения требований доверия к безопасности в профиле защиты (ПЗ) или задании по безопасности (ЗБ).

Данные требования устанавливают стандартный способ выражения требований доверия для объекта оценки (ОО). Данная часть ИСО/МЭК 15408 каталогизирует наборы компонентов, семейств и классов доверия. Данная часть ИСО/МЭК 15408 также определяет критерии для оценки ПЗ и ЗБ и представляет оценочные уровни доверия, которые определяют предопределенную ИСО/МЭК 15408 шкалу для рейтинга доверия к ОО, называемую «оценочными уровнями доверия» (ОУД).

Аудитория для этой части ИСО/МЭК 15408 включает в себя потребителей, разработчиков и оценщиков безопасных ИТ-систем и продуктов. Дополнительная информация о потенциальных пользователях ИСО/МЭК 15408 и использовании ИСО/МЭК 15408 группами, которые включают в себя потенциальных пользователей, представлена в ИСО/МЭК 15408-1, раздел 4. Эти группы могут использовать данную часть ИСО/МЭК 15408 следующим образом:

a)    потребители используют данную часть ИСО/МЭК 15408, выбирая компоненты, чтобы сформулировать требования доверия для удовлетворения целей безопасности, приведенных в ПЗ или ЗБ, определяя требуемые уровни доверия к безопасности ОО. Более подробная информация о взаимосвязях требований безопасности и целей безопасности приведена в ИСО/МЭК 15408-1, подраздел 5.3;

b)    разработчики, несущие ответственность за выполнение существующих или предполагаемых требований безопасности потребителя при разработке ОО, ссылаются на данную часть ИСО/МЭК 15408, интерпретируя утверждения требований доверия и определяя подходы доверия к ОО;

c)    оценщики используют требования доверия, определенные в данной части ИСО/МЭК 15408, как обязательное утверждение критериев оценки, которые определяют доверие к ОО и оценивание ПЗ и ЗБ.

V

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

Информационная технология

МЕТОДЫ И СРЕДСТВА ОБЕСПЕЧЕНИЯ БЕЗОПАСНОСТИ КРИТЕРИИ ОЦЕНКИ БЕЗОПАСНОСТИ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ

Часть 3

Требования доверия к безопасности

Information technology. Security techniques. Evaluation criteria for IT security. Part 3. Security assurance

requirements

Дата введения — 2009—10—01

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

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

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

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

История разработки

Разработке «Общих критериев» предшествовала разработка документа «Критерии оценки безопасности информационных технологий» (англ. Evaluation Criteria for IT Security, ECITS), начатая в 1990 году, и выполненная рабочей группой 3 подкомитета 27 первого совместного технического комитета (или JTC1/SC27/WG3) Международной организации по стандартизации (ISO).

Данный документ послужил основой для начала работы над документом Общие критерии оценки безопасности информационных технологий (англ. Common Criteria for IT Security Evaluation), начатой в 1993 году. В этой работе принимали участие правительственные организации шести стран (США, Канада, Германия, Великобритания, Франция, Нидерланды). В работе над проектом принимали участие следующие институты:

  1. Национальный институт стандартов и технологии и Агентство национальной безопасности (США);
  2. Учреждение безопасности коммуникаций (Канада);
  3. Агентство информационной безопасности (Германия);
  4. Органы исполнения программы безопасности и сертификации ИТ (Англия);
  5. Центр обеспечения безопасности систем (Франция);
  6. Агентство национальной безопасности коммуникаций (Нидерланды).

Стандарт был принят в 2005 году комитетом ISO и имеет статус международного стандарта, идентификационный номер ISO/IEC 15408.
В профессиональных кругах за этим документом впоследствии закрепилось короткое название — англ. Common Criteria, CC; рус. «Общие критерии», ОК.

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

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

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

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

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

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

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

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

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

Применение методологии ISO 20022

Конечной целью применения методологии ISO 20022 в той или иной предметной области (например, безналичные расчеты) является обеспечение информационного обмена с помощью сообщений, соответствующих данному стандарту.

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

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

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

  • Проверка наличия в составе ISO 20022 БизнесОбласти, совпадающей или сходной с предметной областью, для которой планируется применение ISO 20022 (Например: безналичные расчеты и БизнесОбласть ISO 20022 «Платежи»).
  • Сопоставление состава и свойств операций в рассматриваемой предметной области с составом и свойствами БизнесПроцессов в соответствующей БизнесОбласти ISO 20022.
  • Документирование совпадений и отличий (анализ разрывов в БизнесОбласти).
  • Сопоставление состава и свойств сообщений в рассматриваемой предметной области с составом и свойствами МножестваСообщений для соответствующей БизнесОбласти ISO 20022 с последующим документированием (анализ разрывов в ОпределенииСообщений).
  • По результатам анализа разрывов: создание новых и/или модифицированных БизнесПроцессов и/или ОпределенийСообщений, соответствующих ISO 20022
  • Регистрация в Репозитории ISO 20022 изменений и дополнений в БизнесПроцессах и/или ОпределенияхСообщений11
  • Планирование и осуществление миграции к МножествуСообщений ISO 20022.

Ниже на Рисунке 4 приведено схематическое представление данного процесса.

Россия и ISO 20022

Применение методологии ISO 20022 в России возможно для:

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

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

Полезные ссылки и материалы по теме:

  1. https://malotavr.blogspot.com/ – блог Дмитрия Кузнецова, эксперта Positive Technologies, одного из немногих специалистов, систематически рассматривающих вопросы сертификации ПО и анализа уязвимостей по ОУД4. Написал несколько материалов про требования ЦБ и ОУД4, см. статьи за 2019 год.

  2. https://www.youtube.com/watch?v=0ZoNdaoAeyc&t=658s – обзорный вебинар компании RTM Group, посвященный особенностям фреймворка, с участием компании Safe Tech, описывающий реализацию фреймворка в отношении своего продукта.

  3. Переведенные стандарты:

    a. ГОСТ 15408-1-2012;

    b. ГОСТ 15408-2-2013;

    c. ГОСТ 15408-3-2013;

    d. ГОСТ 18045-2013;

    e. ГОСТ 57628-2017;

    f. ГОСТ Р 58143-2018.

  4. https://en.wikipedia.org/wiki/Common_Criteria – Обзор лучших практик по безопасной разработке – статья в вики для желающих самостоятельно углубиться в исторические предпосылки.

  5. Лучшие практики безопасной разработки:

    a. https://doi.org/10.6028/NIST.CSWP.04232020 – обзор актуальных практик SDLC от американского института NIST – «Mitigating the Risk of Software Vulnerabilities by Adopting a Secure Software Development Framework (SSDF)» от 23.04.2020;

    b. https://www.iso.org/standard/55583.html – стандарт ISO/IEC 27034-3:2018 «Information technology — Application security — Part 3: Application security management process»;

    c. https://www.pcisecuritystandards.org/document_library – стандарты PCI SSC линейки «Software Security Framework»:

    i. «Secure Software Requirements and Assessment Procedures»;

    ii. «Secure Software Lifecycle (Secure SLC) Requirements and Assessment Procedures».

  6. https://www.cbr.ru/information_security/acts/ – Методический документ Банка России «ПРОФИЛЬ ЗАЩИТЫ прикладного программного обеспечения автоматизированных систем и приложений кредитных организаций и некредитных финансовых организаций».

История

Во второй половине 20-го века, в период активного развития электронных расчетов, в Европе и США не было единой государственной расчетной системы, массово доступной для банков, зато существовала и активно развивалась инфраструктура электронных коммуникаций. Как следствие, появилось большое количество частных электронных платежных систем со своими особыми форматами сообщений и бизнес-правилами работы. Банки и корпоративные клиенты этих платежных систем были вынуждены тратить значительные средства на поддержку различных форматов. Неоднократно предпринимавшиеся попытки стандартизации по инициативе «снизу» привели к параллельному существованию значительного количества разных, часто пересекающихся и не всегда согласованных региональных или отраслевых стандартов. Стала очевидной потребность в более глобальном стандарте. В работе над ним активно участвовали представители частных компаний, финансовых институтов и эксперты финансовых рынков, с 2002 года эта работа проводилась в Техническом Комитете 68 «Финансовые операции» (TC 68) Международной организации по стандартизации (ISO, International Organisation for Standardisation). В результате в 2004 году был официально принят стандарт ISO 20022. В настоящее время идет его практическое применение, например, единое европейское платежное пространство (SEPA, Single Europe Payment Area) построено по методологии ISO 20022. Инициатива Федеральной резервной системы (США) по глобальному стандарту для трансграничных платежей IPF (International Payment Framework) также базируется на ISO 20022. География применения ISO 20022 очень широка и включает в себя, например, Японию, Бразилию, Южную Африку. Международные системы, такие как CLS и Euroclear, поддерживают обмен сообщениями, спроектированными в соответствии с ISO 20022, и стимулируют своих участников к переходу на них.

Система межбанковских сообщений SWIFT планирует постепенный переход от применяемых в настоящее время сообщений формата SWIFT MT к сообщениям формата SWIFT MX, которые спроектированы по методологии ISO 20022.

Крупные банки, такие как JP Morgan, HSBC, Deutche Bank и другие, предоставляют своим клиентам по всему миру возможность передавать платежи в формате, спроектированном и размещенном в центральном хранилище ISO 20022.

Модель угроз при сертификации

Прохождение сертификации неким продуктом в соответствии со стандартом Common Criteria может подтверждать или не подтверждать определенный уровень защищённости продукта, в зависимости от модели угроз и окружения.

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

Операционная система Microsoft Windows XP (Professional SP2 и Embedded SP2), а также Windows Server 2003 были сертифицированы на уровень Common Criteria EAL4+ по профилю CAPP в 2005-2007 годах, после чего для них были выпущены пакеты обновлений (service pack) и регулярно выпускались новые критические обновления безопасности. Тем не менее, Windows XP в проверявшейся версии по-прежнему обладал сертификатом EAL4+,. Это факт свидетельствует в пользу того, что условия сертификации (окружение и модель злоумышленника) были подобраны весьма консервативно, в результате чего ни одна из обнаруженных уязвимостей не применима к протестированной конфигурации.

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

Наши события

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 в пользу кабельщиков. СЗМТУ Росстандарта может дорого заплатить за действия “псевдорегулятора”

ПАРТНЁРЫ

Хранилище

Единое централизованное хранилище (репозитарий) является центром знаний по ISO 20022 и открыто для просмотра с целью исключения различий в использовании одних и тех же элементов и согласования порядка работы.

Хранилище логически делится на словарь данных и каталог бизнес-процессов. Словарь данных включает в себя описание базовых сфер бизнеса (например, Forex, операции с акциями), определение сообщений, их базовых элементов (например, электронно-цифровая подпись (ЭЦП) и типов данных (например, код валюты, банковский идентификационный код (BIC – стандарт ISO 9362). Каталог бизнес-процессов содержит модели финансовых бизнес-процессов, описания конкретных бизнес-операций со ссылками на используемые сообщения.

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

Рабочая группа по взаимодействию банков и корпораций (СMPG)

Во многих ведущих странах мира существуют национальные группы по анализу и поддержке практики взаимодействия банков и корпораций на финансовом рынке (Corporate-to-Bank Market Practice Group), деятельность которых координирует международный форум Common Global Implementation (CGI). Целью таких групп является выработка единых требований и конкретных рекомендаций по формированию и использованию сообщений SWIFT на основе стандарта ISO 20022 с учетом национальной специфики.

Национальная рабочая группа по стандартизации практик взаимодействия нефинансовых организаций с банками и другими контрагентами в Российской Федерации (Russian Corporate-to-Bank Market Practice Group), краткое наименование — Рабочая группа по взаимодействию банков и корпораций (СMPG) была создана в ноябре 2012 года. В процессе работы группы были разработаны Рекомендации по использованию стандартов ISO 20022 для передачи финансовых сообщений между банком и корпорацией с учетом требований национальной платежной системы (ISO-RUB), в которых нашли отражение основные особенности заполнения платежных сообщений и сообщений управления денежными средствами при проведении расчетов корпораций на российском финансовом рынке. В дальнейшем указанный документ будет актуализироваться в соответствии с изменениями форматов ISO 20022, изменениями законодательства РФ, пожеланиями и замечаниями пользователей на ежегодной основе.

Деятельность Рабочей группы регулируется Положением, утвержденным Комитетом РОССВИФТ. Председателем Рабочей группы является Якунина Татьяна Анатольевна, Первый вице-президент Газпромбанка, Заместителями — Чирков Георгий Валентинович, Руководитель Отдела по разработке и администрированию продуктов Управления корпоративной ликвидности Юникредитбанка и Мельников Алексей Валерьевич, Генеральный директор ЕвразХолдинг Финанс.

В состав Рабочей группы входят 91 представителей 19-ти банков, 18-ти корпораций и регулирующих организаций, в частности, Банк России, Сбербанк России, ВТБ, Газпромбанк, ЮниКредитБанк, Ситибанк, ЕвразХолдинг, Роснефть, Лукойл, Интер РАО ЕЭС, SWIFT и др.

В Рамках деятельности Рабочей группы была проведена большая работа в области обоснования легитимности использования электронной подписи SWIFT. Был направлен запрос и получено официальное разъяснение ряда положений нормативных актов Банка России.

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

Деятельность Рабочей группы ведется в тесном взаимодействии с различными российскими и международными структурами, занимающимися стандартизацией в области электронного документооборота на финансовом рынке, такими как Технический комитет № 122 «Стандарты финансовых операций» Банка России, CGI, SWIFT и др.

2015: «Синимекс» вошла в состав Рабочей группы РОССВИФТ по локализации стандарта ISO 20022

Компания «Синимекс», один из разработчиков интеграционных решений для финансового сектора, вступила в Российскую Национальную Ассоциацию SWIFT (РОССВИФТ), объединяющую около 600 крупнейших банков и организаций-пользователей SWIFT на территории РФ. В SWIFT представлены более половины российских кредитных организаций, которые являются крупнейшими финансовыми институтами страны и осуществляют более 80% расчетов.

«Синимекс» стала второй по счету российской ИТ-компанией, получившей статус официального члена РОССВИФТ и вошедшей в состав Рабочей группы Ассоциации по локализации международного стандарта ISO 20022 для взаимодействия банков и корпораций. В состав Рабочих групп РОССВИФТ входят представители Банка России, Национального Расчетного Депозитария, крупнейших коммерческих банков и корпораций, а также SWIFT.

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

История и эволюция фреймворка

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

  • архитектурой (дизайном);

  • разработкой (кодированием архитектуры в конечный продукт);

  • внедрением (настройкой);

  • эксплуатацией (обслуживанием).

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

Рисунок 1. Иллюстрация вектора атаки

Корни фреймворка уходят в становление индустрии ИБ в США в семидесятых и восьмидесятых годах прошлого века. По мере автоматизации и развития системного подхода силовые ведомства стремились гарантировать надежность системных компонентов, используемых государственными структурами для защиты информации. В течение какого-то времени несколько подобных стандартов существовали в различных юрисдикциях параллельно, пока не были объединены международными организациями ISO/IEC в новый, единый фреймворк ISO/IEC 15408 «Common Criteria for Information Technology Security Evaluation» (или просто Common Criteria – то есть Общие Критерии). Любопытные до истории и фактов могут изучить подробности хроники по ссылкам внизу статьи, нас же интересует тот факт, что отечественные стандартизаторы с 2012 года начали анализировать и перерабатывать указанное семейство стандартов, чтобы издать их официально на русском под эгидой Стандартинформа.

Здесь стоит сделать небольшое отступление про статус подобных стандартов. На фоне вступления России в ВТО и либерализации законодательства национальные стандарты перестали быть обязательными на территории Российской Федерации. Сегодня, в соответствии со ст. 27 Федерального закона № 162-ФЗ «О стандартизации», ГОСТы на территории России являются обязательными тогда, когда на них явно ссылаются какие-то нормативно-правовые акты уполномоченных органов государственной власти. Здесь на сцену выходит Центральный Банк России.

Рисунок 2. Титульный лист ГОСТ Р 15408-1-2012

Основные понятия

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

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

Функциональные требования

Функциональные требования сгруппированы на основе выполняемой ими роли или обслуживаемой цели безопасности, всего 11 функциональных классов (в трёх группах), 66 семейств, 135 компонентов.

  1. Первая группа определяет элементарные сервисы безопасности:
    1. FAU — аудит, безопасность (требования к сервису, протоколирование и аудит);
    2. FIA — идентификация и аутентификация;
    3. FRU — использование ресурсов (для обеспечения отказоустойчивости).
  2. Вторая группа описывает производные сервисы, реализованные на базе элементарных:
    1. FCO — связь (безопасность коммуникаций отправитель-получатель);
    2. FPR — приватность;
    3. FDP — защита данных пользователя;
    4. FPT — защита функций безопасности объекта оценки.
  3. Третья группа классов связана с инфраструктурой объекта оценки:
    1. FCS — криптографическая поддержка (обеспечивает управление криптоключами и крипто-операциями);
    2. FMT — управление безопасностью;
    3. FTA — доступ к объекту оценки (управление сеансами работы пользователей);
    4. FTP — доверенный маршрут/канал;

Классы функциональных требований к элементарным сервисам безопасности

К элементарным сервисам безопасности относятся следующие классы FAU, FIA и FRU.

Класс FAU включает шесть семейств (FAU_GEN, FAU_SEL, FAU_STG, FAU_SAR, FAU_SAA и FAU_ARP), причём каждое семейство может содержать разное число компонентов.

Назначение компонентов данного класса следующее.

FAU_GEN — генерация данных аудита безопасности. Содержит два компонента FAU_GEN.1 (генерация данных аудита) и FAU_GEN.2 (ассоциация идентификатора пользователя).

Требования доверия

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

  1. Первая группа содержит классы требований, предшествующих разработке и оценке объекта:
    1. APE — оценка профиля защиты;
    2. ASE — оценка задания по безопасности.
  2. Вторая группа связана с этапами жизненного цикла объекта аттестации:
    1. ADV — разработка, проектирование объекта;
    2. ALC — поддержка жизненного цикла;
    3. ACM — управление конфигурацией;
    4. AGD — руководство администратора и пользователя;
    5. ATE — тестирование;
    6. AVA — оценка уязвимостей;
    7. ADO — требования к поставке и эксплуатации;
    8. АMA — поддержка доверия-требования, применяется после сертификации объекта на соответствие общим критериям.