ГОСТ Р ИСО/МЭК 27034-6-2021. Национальный стандарт Российской Федерации. Информационные технологии. Методы и средства обеспечения безопасности. Безопасность приложений. Часть 6. Практические примеры

(утв. и введен в действие Приказом Росстандарта от 18.05.2021 № 369-ст)

Утвержден и введен в действие

ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ

Предисловие

1 ПОДГОТОВЛЕН Федеральным государственным учреждением «Федеральный исследовательский центр „Информатика и управление“ Российской академии наук» (ФИЦ ИУ РАН) и Обществом с ограниченной ответственностью «Информационно-аналитический вычислительный центр» (ООО ИАВЦ) на основе собственного перевода на русский язык англоязычной версии стандарта, указанного в пункте 4

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 18 мая 2021 г. № 369-ст

4 Настоящий стандарт идентичен международному стандарту ИСО/МЭК 27034-6:2016 «Информационные технологии. Методы и средства обеспечения безопасности. Безопасность приложений. Часть 6. Практические примеры» (ISO/IEC 27034-6:2016 «Information technology — Security techniques — Application security — Part 6: Case studies», IDT).

ИСО/МЭК 27034-6:2016 подготовлен подкомитетом 27 «Методы и средства обеспечения безопасности ИТ» Совместного технического комитета ИСО/МЭК СТК 1 «Информационные технологии»

Правила применения настоящего стандарта установлены в статье 26 Федерального закона от 29 июня 2015 г. № 162-ФЗ «О стандартизации в Российской Федерации». Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

Введение

0.1 Общие положения

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

ИСО/МЭК 27034, состоящий из нескольких частей, содержит описания понятий, принципов, структур, компонентов и процессов для оказания помощи организациям в планомерной интеграции мер обеспечения безопасности на протяжении жизненного цикла приложений.

Одним из ключевых компонентов настоящего стандарта являются меры обеспечения безопасности приложений (МОБП).

Чтобы облегчить внедрение мер обеспечения безопасности приложений, а также механизмов передачи и обмена данными МОБП, приведенных в ИСО/МЭК 27034 (все части), необходимо определить формальную структуру МОБП и других компонентов этой структуры.

0.2 Назначение

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

<1> Положения настоящего стандарта должны рассматриваться с учетом требований национальных нормативных актов и стандартов Российской Федерации в области защиты информации.

0.3 Целевая аудитория

0.3.1 Общие положения

Настоящий стандарт полезен для следующих групп лиц при осуществлении ими своих организационных ролей:

a) эксперты в предметной области.

0.3.2 Эксперты в предметной области

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

a) участвовать в разработке, валидации и верификации МОБП;

b) участвовать во внедрении и поддержке МОБП, предлагая стратегии, компоненты и процессы внедрения для адаптации МОБП к условиям организации;

c) подтверждать, что МОБП пригодны для применения и несут выгоду в рамках проектов приложений.

1 Область применения

В настоящем стандарте приведены примеры использования МОБП в определенных приложениях.

Примечание - Указанные МОБП приведены только в справочных целях, для обеспечения безопасности приложений рекомендуется разработать собственные МОБП.

2 Нормативные ссылки

В настоящем стандарте отсутствуют нормативные ссылки.

3 Термины и определения

В настоящем стандарте используются термины и определения по ИСО/МЭК 27034-1.

ИСО и МЭК поддерживают терминологические базы данных для использования в стандартизации в следующих адресах:

• ИСО, Онлайн просматривающий платформу: доступный в https://www.iso.org/obp;
• МЭК, Electropedia: доступный в http://www.electropedia.org/

4 Обозначения

МОБП — меры обеспечения безопасности приложений (ASC).

ЖЦБП — жизненный цикл безопасности приложений (ASLC).

ЭМБЖБП — эталонная модель жизненного цикла безопасности приложений (ASLCRM).

НСО — нормативная структура организации (ONF).

5 Руководство по обеспечению безопасности для конкретного приложения

5.1 Общие положения

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

Организации получат значительную пользу от применения этого руководства, поскольку в нем содержатся практические примеры формирования структуры МОБП для определенных приложений, использующих рекомендуемую структуру данных XML <1>, приведенную в ИСО/МЭК 27034-5-1, и реализации нормативной структуры организации (НСО).

<1> Расширяемый язык разметки (XML).

5.2 Пример меры обеспечения безопасности приложений: анализ исходного кода Java для мобильных приложений

5.2.1 Общие положения

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

В данном примере представлена структура МОБП, разработанная вымышленной организацией под названием ORGANIsation Inc. Эта МОБП выполняет защитную функцию анализа исходного кода.

5.2.2 Назначение

Целью этого подраздела является предоставление простого описания примера МОБП под названием «Анализ исходного кода» для организации, разрабатывающей мобильные приложения Java. Для обеспечения краткости и удобочитаемости информации упрощенное подмножество МОБП представлено на русском языке, но требования к МОБП, установленные в ИСО/МЭК 27034-5, позволяют описывать любой объект МОБП, используя набор символов, как приведено в приложении A (таблица A.1).

5.2.3 Контекст

ORGANIsation Inc. — это международная организация, разрабатывающая мобильные приложения на языке Java для внутреннего использования и по запросу своих клиентов. Офисы ORGANIsation Inc. по разработке программного обеспечения расположены в Монреале, Ванкувере и Москве. Поэтому вся документация по разработке, инструкции и справочные материалы в ORGANIsation должны быть доступны на английском, французском и русском языках.

В ходе внедрения ИСО/МЭК 27034 (все части) в ORGANIsation приоритет отдается разработке МОБП с целью уменьшения уязвимостей в мобильном коде на языке Java. Комитет НСО в ORGANIsation поручает Службе безопасности приложений (Application Security Department, ASD) разработать и представить МОБП для анализа исходного кода Java.

5.2.4 Правила классификации информации в ORGANIsation

В ORGANIsation используются утвержденные внутренние правила классификации информации на четыре уровня:

a) с ограниченным доступом;

b) конфиденциальная;

c) строго конфиденциальная;

d) коммерческая.

5.2.5 Уровни доверия приложений, указанные в библиотеке мер обеспечения безопасности приложений ORGANIsation

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

Таблица 1

Уровни доверия приложений ORGANIsation

5.2.6 Результат

Службе безопасности приложений было поручено выбрать и приобрести инструментальное средство автоматического анализа исходного кода на языке Java с настраиваемыми правилами. После анализа предложений, поступивших от поставщиков, служба выбрала инструментальное средство под названием Efficient-Reviewer, версия 2.2.

В результате проекта были разработаны и внедрены пять МОБП версии 1.0.

МОБП ORGANIsation для анализа исходного кода

5.2.7 Заинтересованные стороны ORGANIsation, использующие выбранные меры обеспечения безопасности приложений

Для каждой из МОБП определены соответствующие обязанности.

Примечание - В данном пункте приводятся описания элементов выбранных МОБП в произвольной форме и формальные описания тех же элементов с использованием терминологии XML.

Имена и обязанности заинтересованных сторон, использующих МОБП для анализа исходного кода Java

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

Структура МОБП позволяет добавлять электронную подпись для каждой из версий МОБП с целью обеспечения целостности данных. Директивы ORGANIsation, приведенные в таблице 3, указывают, какие электронные подписи являются обязательными. Это позволяет убедиться, что критические этапы жизненного цикла МОБП выполнены и соответствуют политике ORGANIsation.

Часть МОБП, защищенная электронными подписями, представлена на рисунке 1 в форме облака.

Рисунок 1 — Целостность электронных подписей заинтересованных сторон

Также см. приложение A (таблица A.2).

«МОБП organisation-ASD-042 — анализ исходного кода» является «главной МОБП» и не содержит мероприятий по обеспечению безопасности или проверок и измерений. Она связана с четырьмя дочерними МОБП, которые необходимы для внедрения процедуры анализа исходного кода в процесс разработки приложений Java в организации. Этот принцип иерархии МОБП приведен на рисунке 2. Следует отметить, что в «главной МОБП» пропущены некоторые обязательные атрибуты МОБП, определенные в ИСО/МЭК 27034-1:2011 (рисунок 6). Они содержатся в дочерних МОБП.

5.2.8 Описание примеров мер обеспечения безопасности приложений

5.2.8.1 Общие положения

5.2.8.2 МОБП ORGANIsation-ASD-042: анализ исходного кода

Также см. приложение A (таблица A.4).

Также см. приложение A (таблица A.5).

5.2.8.3 МОБП ORGANIsation-ASD-043: классификация кода

Также см. приложение A (таблица A.6).

<1> Сертифицированный специалист по безопасному жизненному циклу программного обеспечения (CSSLP).

<2> Формат электронных документов (формат PDF).

<3> Формат электронных документов (формат RTF).

Также см. приложение A (таблица A.7).

Также см. приложение A (таблица A.8).

5.2.8.4 МОБП ORGANIsation-ASD-044: базовый автоматический анализ исходного кода

5.2.8.5 МОБП ORGANIsation-ASD-045: расширенный автоматический анализ исходного кода

5.2.8.6 МОБП ORGANIsation-ASD-046: экспертиза исходного кода

5.3 Пример использования: разработка мер обеспечения безопасности приложений для решения вопросов конфиденциальности в двух странах

5.3.1 Общие положения

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

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

5.3.2 Назначение

Назначение этого подраздела — предоставить пример разработки МОБП для решения вопросов конфиденциальности для двух стран.

5.3.3 Контекст

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

ORGANIsation нашла новых клиентов в странах A и B.

На первом этапе процесса менеджмента безопасности приложений (ПМБП) юристы ORGANIsation выделили и проанализировали соответствующие законы и правила обеих стран и сформировали регулятивный контекст для приложения. Был обнаружен конфликт между некоторыми требованиями законов о конфиденциальности в странах A и B.

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

С учетом риска нарушения существующих законов для клиентов ORGANIsation возникает два требования:

a) обеспечить, чтобы в стране A персональные данные субъекта хранились не менее десяти лет после последнего использования;

b) обеспечить, чтобы в стране B персональные данные субъекта надежно удалялись в течение одного года после последнего использования.

ORGANIsation должна продемонстрировать клиентам, что приложение отвечает этим требованиям.

ORGANIsation принимает решение удовлетворить эти требования путем внедрения следующих МОБП.

a) МОБП 1: внедрить процедуру безопасного удаления медицинских карт и связанной с ними информации. Это «головная МОБП», которая служит материнской для двух указанных ниже дочерних МОБП.

1. МОБП 1.1: разработать, внедрить и верифицировать процедуры безопасного удаления.

i) Когда: ВО ВРЕМЯ подробного анализа архитектуры (уровень доставки приложения, внедрение/разработка/уточнение).

ii) Мероприятие по обеспечению безопасности: в МОБП должны входить, помимо прочего, следующие мероприятия по обеспечению безопасности:

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

iii) Процедура верификации: в МОБП должны быть описаны процедуры проверки правильности реализации каждого из указанных выше мероприятий.

2. МОБП 1.2: выполнить процедуры безопасного удаления, реализованные в МОБП 1.1, и проверить правильность их работы.

i) Когда: ВО ВРЕМЯ использования приложения (уровень поставки приложения, эксплуатация и сопровождение/вывод из эксплуатации).

ii) Мероприятие по обеспечению безопасности: в МОБП должны входить, помимо прочего, следующие мероприятия по обеспечению безопасности:

• выполнение безопасной процедуры удаления данных при необходимости.

iii) Процедура верификации: в МОБП должны быть описаны процедуры проверки правильности удаления данных приложением.

b) МОБП 2: внедрить процедуру правильного выбора медицинских карт для удаления согласно соответствующим правилам. Это «главная» МОБП, которая служит материнской для двух указанных ниже дочерних МОБП.

1. МОБП 2.1: разработать, внедрить и верифицировать процедуру правильного выбора медицинских карт для удаления согласно соответствующим правилам.

i) Когда: ВО ВРЕМЯ подробного анализа архитектуры (уровень поставки приложения, реализация/проектирование/уточнение).

ii) Мероприятие по обеспечению безопасности: в МОБП должны входить, помимо прочего, следующие мероприятия по обеспечению безопасности:

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

iii) Процедура верификации: в МОБП должны быть описаны процедуры проверки правильности реализации каждого из указанных выше мероприятий.

• В частности, юристы должны подтвердить правила удаления для каждой из стран.

2. МОБП 2.2: выполнить процедуры безопасного удаления, реализованные в МОБП 2.1, и проверить правильность их работы.

i) Когда: ВО ВРЕМЯ использования приложения (уровень поставки приложения, эксплуатация и сопровождение/вывод из эксплуатации).

ii) Мероприятие по обеспечению безопасности: в МОБП должны входить, помимо прочего, следующие мероприятия по обеспечению безопасности:

• выполнение процедуры выбора данных при необходимости.

iii) Процедура верификации: в МОБП должны быть описаны процедуры проверки правильности выбора данных приложением.

5.4 Пример использования: интеграция сторонних мер обеспечения безопасности приложений

5.4.1 Общие положения

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

Необходимым условием для интеграции и адаптации сторонних МОБП является открытый и переносимый язык обмена данными для МОБП (в соответствии с рекомендациями ИСО/МЭК 27034-5-1).

5.4.2 Назначение

Назначение данного примера использования — показать, как сторонние МОБП можно адаптировать и интегрировать в программу обеспечения безопасности приложений организации. Кроме того, данный пример подчеркивает важность включения диапазона уровней доверия приложений в определение МОБП.

Для упрощения описания некоторые пункты в примере определены как «[опущено]», однако в соответствии с рекомендованной XML-структурой из ИСО/МЭК 27034-5-1 их необходимо вносить в каждую МОБП.

5.4.3 Контекст

ORGANIsation Inc. («организация») — это компания, занимающаяся онлайн-торговлей биржевых ценных бумаг, например фьючерсов, облигаций и акций. В настоящее время ORGANIsation использует 80 приложений, 25 из которых подключаются к Интернету. 12 мес назад ORGANIsation запустила программу обеспечения безопасности приложений. В настоящее время НСО состоит из 13 МОБП с четырьмя уровнями доверия приложений (см. таблицу 4).

Таблица 4

Уровни доверия приложений ORGANIsation

В соответствии с недавними изменениями в регулятивном контексте ORGANIsation необходимо обновить свою НСО, чтобы обеспечить применение различных видов тестирования безопасности своих приложений. Чтобы ускорить процесс обновления НСО, организация решает приобрести две МОБП у стороннего поставщика, а также нанять специалиста по проведению тестирования на проникновение из Hackus Inc. («Hackus»).

На рисунке 3, иллюстрирующем пример использования «интеграции сторонней МОБП», показана процедура передачи двух МОБП (МОБП1 и МОБП2) от двух разных субпоставщиков приобретающей стороне («ORGANIsation»).

Рисунок 3 — Пример цепочки поставки МОБП

У каждой вовлеченной в процесс организации имеется своя собственная НСО, как показано на рисунке 3. В рамках «Проекта приложения» поставщик предоставляет адаптированную версию своего «Универсального приложения». МОБП «Общего приложения» действуют в своих (отдельных) нормативных структурах приложений (НСП). Эти МОБП входят в НСО поставщика. НСО поставщика получает МОБП1 от специализированной охранной компании («Поставщик МОБП»), а МОБП2 — от одного из субпоставщиков (программных) компонентов («Субпоставщик компонентов»). Хотя МОБП1 и МОБП2 предназначены для использования с «Универсальным приложением» в составе НСП, сначала необходимо интегрировать их в НСО поставщика. Состав и характер средств управления НСП* клиента могут отличаться от общей НСП. НСП* передается приобретающей стороне вместе с «Проектом приложения» в целом. Приобретающая сторона может обновить ее конфигурацию безопасности, создав НСП**. Новые МОБП1 и МОБП2, попавшие в НСП**, также регистрируются в НСО приобретающей стороны. Стрелка на рисунке между НСО приобретающей стороны и НСП проекта приложения направлена в обе стороны, поскольку в новом проекте могут использоваться дополнительные МОБП (например, созданные для определенного сайта).

Путь передачи МОБП1, представленный на рисунке 3, можно описать в виде последовательности: НСО Поставщика МОБП \rightarrow НСО Поставщика \rightarrow НСП Поставщика \rightarrow НСП* Поставщика \rightarrow НСП** приобретающей стороны \rightarrow НСО приобретающей стороны. Приобретающая сторона может получить МОБП3 напрямую от поставщика МОБП, который явно не указан на рисунке 3. В соответствии с соглашением о покупке и согласно схеме, приведенной в ИСО/МЭК 27034-5-1, Hackus экспортирует обе МОБП в виде «пакета МОБП» в формате XML. Фрагменты обеих МОБП приведены ниже. Поскольку 5.4 содержит только процедуру интеграции сторонних МОБП в НСО организации, мероприятия по обеспечению безопасности, а также по верификации МОБП опущены.

МОБП 1.1: автоматический поиск уязвимостей.

Когда:

• ВО ВРЕМЯ [12-месячный период] (уровень поставки приложений/эксплуатации/использования и сопровождения).

Рекомендуемые уровни доверия приложений:

• «Синий» уровень.

Шкала уровней доверия приложения <1>:

<1> На шкале уровней доверия приложений Hackus в данном примере синий цвет обозначает меньший риск, а красный — больший.

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

Мероприятие по обеспечению безопасности: [опущено]

Мероприятие по верификации: [опущено]

МОБП 1.2: Тестирование на проникновение

Когда:

• ВО ВРЕМЯ [12-месячный период] (уровень поставки приложений/эксплуатации/использования и сопровождение).

Рекомендуемые уровни доверия:

• «Красный» уровень.

Шкала уровней доверия приложений:

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

Мероприятие по обеспечению безопасности: [опущено]

Мероприятие по верификации: [опущено]

Согласно шкале уровней доверия приложений, включенной в обе МОБП, Hackus использует два уровня доверия приложения («красный» и «синий»), а ORGANIsation — четыре уровня доверия (i, ii, iii, iv). Для интеграции МОБП в НСО ORGANIsation важно сопоставить уровни доверия приложений Hackus и ORGANIsation. В таблице 5 представлено такое сопоставление.

Таблица 5

Сопоставление уровней доверия приложений Hackus и ORGANIsation

Сопоставление выполнено после рассмотрения определений уровней доверия приложений ORGANIsation и Hackus (в МОБП). При этом становится очевидным, что в структуре НСО ORGANIsation необходимо присвоить МОБП для автоматического поиска уязвимостей уровни доверия приложений (ii) и (iv), а МОБП для проведения тестирования на проникновение - уровни (i) и (III).

5.5 Пример использования: использование эталонной модели жизненного цикла безопасности приложений для упрощения процедуры внедрения мер обеспечения безопасности приложений различными группами разработки внутри организации

5.5.1 Общие положения

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

5.5.2 Назначение

Назначение данного примера использования — показать важность и полезность ЭМЖЦБП. Данный пример демонстрирует, что МОБП можно использовать в различных контекстах разработки с учетом мероприятий по разработке ЭМЖЦБП.

5.5.3 Контекст

ORGANIsation Inc. («ORGANIsation») — это банковская и страховая корпорация национального масштаба. В ней работают более 40 000 сотрудников и несколько внутренних команд разработчиков, которые используют различные методологии разработки, например Agile и Heavyweight. Цель недавно внедренной инициативы по защите приложений: систематическая интеграция функций безопасности во все проекты с разными методологиями разработки.

С этой целью ORGANIsation разработала 18 МОБП, охватывающих различные аспекты безопасности приложений, например обучение, анализ исходного кода, тестирование и сертификацию. Пример МОБП (тестирование на проникновение) приведен в таблице 6. Для краткости изложения МОБП показана в сокращенной и упрощенной форме.

Таблица 6

МОБП ORGANIsation для проведения тестирования на проникновение

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

Данная форма косвенной адресации позволяет (повторно) использовать МОБП в различных методологиях разработки с разными мероприятиями и ролями. Для этого необходимо сопоставить конкретные роли и мероприятия (определенной методологии разработки) с их аналогами в ЭМЖЦБП. Примеры сопоставления для методологий разработки ORGANIsation Agile и ORGANIsation Heavyweight приведены в таблицах 7 и 8.

Сопоставление жизненного цикла мероприятий.

Таблица 7

Сопоставление мероприятий ЭМЖЦБП с существующими мероприятиями ORGANIsation

Сопоставление ролей.

Таблица 8

Сопоставление ролей ЭМЖЦБП с существующими ролями ORGANIsation

Благодаря этим сопоставлениям команде разработчиков и экспертам в предметной области МОБП не требуются сведения о мероприятиях и ролях в ORGANIsation Agile, ORGANIsation Heavyweight или любой другой методологии. Им нужны только данные об ЭМЖЦБП.

Отделам разработки приложений, использующим методологию ORGANIsation Agile, не требуется изучать новую методологию, им достаточно изучить соответствие их методологии с ЭМЖЦБП. Им не требуются сведения о мероприятиях и ролях в ORGANIsation Heavyweight или любой другой методологии. То же самое касается других отделов разработки.

5.6 Пример использования: внедрение сторонних мер обеспечения безопасности приложений в процесс безопасного жизненного цикла разработки

5.6.1 Общие положения

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

5.6.2 Назначение

Назначение данного примера — показать, как сторонние средства управления безопасностью разработки можно адаптировать и интегрировать во внутреннюю программу обеспечения безопасности приложений в качестве прямого ответа на атаку.

Перечень мероприятий для обеспечения полного соответствия требованиям ИСО/МЭК 27034 (все части) может включать в себя:

a) обновление сторонних средств управления безопасностью разработки с учетом структуры МОБП:

1. обновление средств управления для обеспечения безопасности МОБП,

2. обновление средств управления безопасностью в соответствии с процедурой верификации МОБП;

b) сопоставление процедур разработки программного обеспечения с ЭМЖЦБП.

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

5.6.3 Контекст

В 2008 году сайты крупной компании из Соединенных Штатов подверглись атакам, что привело к небольшому повреждению внутренней базы данных. Что еще более важно, в результате взлома ботнет получил платформу для распространения вредоносных программ среди ничего не подозревающих пользователей сети Интернет.

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

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

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

Разработанный процесс используется компанией практически без изменений даже спустя пять лет.

5.6.4 Этап подготовки (1.00)

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

Таблица 9

Мероприятия по внедрению МОБП и результаты этапа подготовки

<1> Жизненный цикл безопасной разработки (SDL).

5.6.5 Этап составления требований (2.00)

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

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

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

Таблица 10

Мероприятия по внедрению МОБП и результаты этапа составления требований

На этапе проектирования определяются общие требования к программному обеспечению и его структура. Этап проектирования является наиболее важным этапом всего процесса безопасной разработки, поскольку именно на нем определяется уровень безопасности разработки ПО <1>. С точки зрения безопасности ключевыми элементами этапа проектирования являются: определение архитектуры безопасности и руководящих принципов проектирования; документирование поверхности атаки программного обеспечения; моделирование угроз. Все мероприятия на этапе проектирования вносятся в постоянную документацию компьютерной системы.

<1> Программное обеспечение.

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

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

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

Таблица 11

Мероприятия по внедрению МОБП и результаты этапа проектирования

5.6.7 Этап реализации (4.00)

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

Элементы SDL, которые используются на этапе реализации:

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

2. Применение инструментальных средств для выполнения фаззинг-тестирования. В ходе фаззинга в программные интерфейсы приложений (API) и сетевые интерфейсы вводятся структурированные, но недействительные входные данные, которые позволяют максимизировать вероятность обнаружения ошибок, открывающих уязвимости ПО.

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

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

Таблица 12

Мероприятия по внедрению МОБП и результаты этапа реализации

5.6.8 Этап верификации (5.00)

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

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

В этом примере МОБП предназначена только для наиболее приоритетного исходного кода.

Мероприятия по внедрению МОБП и результаты этапа верификации

5.6.9 Этап выпуска (6.00)

На этапе выпуска приложение должно пройти окончательную проверку безопасности (final security review, FSR). Цель FSR — ответить на вопрос: готово ли это приложение для отправки клиентам с точки зрения безопасности? FSR проводится до завершения работы над приложением и с учетом сферы его применения. FSR проходит стабильную версию приложения, а перед выпуском допускается внесение только минимальных изменений, не связанных с безопасностью.

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

Таблица 14

Мероприятия по внедрению МОБП и результаты этапа выпуска

5.6.10 Этап технического обеспечения, поддержки и обслуживания (7.00)

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

Таблица 15

Мероприятия по внедрению МОБП и результаты этапа поддержки и обслуживания

Приложение A (справочное)

ПРИМЕРЫ ИСПОЛЬЗОВАНИЯ ИЗ 5.2 НА ЯЗЫКЕ XML

Примеры приведены с целью упрощения разработки и передачи данных МОБП внутри организации или между разными организациями с учетом требований ИСО/МЭК 27034-5-1.

Таблица A.1

XML-пример названия МОБП, написанного на трех языках

Таблица A.2

XML-пример процедуры утверждения МОБП и соответствующих подписей

Таблица A.3

XML-пример определения дочерней МОБП

Таблица A.4

XML-пример МОБП ORGANIsation-ASD-042: анализ исходного кода, идентификация

Таблица A.5

XML-пример МОБП ORGANIsation-ASD-042: анализ исходного кода, назначение

Таблица A.6

XML-пример МОБП ORGANIsation-ASD-043: классификация кода, назначение

Таблица A.7

XML-пример МОБП ORGANIsation-ASD-043: классификация кода, мероприятия по обеспечению безопасности

Таблица A.8

XML-пример МОБП ORGANIsation-ASD-043: классификация кода, проверочные измерения

БИБЛИОГРАФИЯ