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

ГОСТ Р ИСО/МЭК 27034-1-2014

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

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

МЕТОДЫ И СРЕДСТВА ОБЕСПЕЧЕНИЯ БЕЗОПАСНОСТИ

Безопасность приложений

Часть 1

Обзор и общие понятия

Information technology. Security techniques. Application security. Part 1. Overview and concepts

ОКС 35.040

Дата введения 2015-06-01

Предисловие

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

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 22 "Информационные технологии"

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

4 Настоящий стандарт идентичен международному стандарту ИСО/МЭК 27034-1:2011* "Информационная технология. Методы обеспечения безопасности. Безопасность приложений. Часть 1. Обзор и общие понятия" (ISO/IEC 27034-1:2011 "Information technology - Security techniques - Application security - Part 1: Overview and concepts").
________________
* Доступ к международным и зарубежным документам, упомянутым здесь и далее по тексту, можно получить, перейдя по ссылке на сайт . - .


Наименование настоящего стандарта изменено относительно наименования указанного международного стандарта для приведения в соответствие с ГОСТ 1.5 (пункт 3.5).

При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов соответствующие им национальные стандарты Российской Федерации, сведения о которых приведены в дополнительном приложении ДА

5 ВВЕДЕН ВПЕРВЫЕ


Правила применения настоящего стандарта установлены в ГОСТ Р 1.0-2012 (раздел 8). Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе "Национальные стандарты", а официальный текст изменений и поправок - в ежемесячном информационном указателе "Национальные стандарты". В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя "Национальные стандарты". Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

Введение

Введение

0.1 Общая информация

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

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

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

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

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

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

Примерами приложений являются кадровые системы, финансовые системы, системы обработки текстов, системы менеджмента взаимодействия с клиентами, межсетевые экраны, антивирусные системы и системы обнаружения вторжений.

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

Кроме того, безопасное приложение учитывает требования безопасности, вытекающие из типа данных, целевой среды (бизнес-контекст, нормативный и технологический контексты), действующих субъектов и спецификаций приложений. Должна существовать возможность получения свидетельств, доказывающих, что допустимый или приемлемый уровень остаточного риска достигнут и поддерживается.
_______________
Спецификация - документ, устанавливающий требования [ГОСТ ISO 9000-2011, пункт 3.7.3].

0.2 Назначение

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

a) предоставления общих понятий, принципов, структур, компонентов и процессов;

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

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

d) обеспечения процессно-ориентированных механизмов для определения, формирования и сбора свидетельств, необходимых для демонстрации того, что их приложения безопасны для использования в определенной среде;

e) поддержки общих концепций, определенных в ИСО/МЭК 27001, и содействия соответствующей реализации информационной безопасности, основанной на менеджменте риска;

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

ИСО/МЭК 27034:

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

b) применяется к организациям любого типа и величины (например, к коммерческим предприятиям, государственным учреждениям, некоммерческим организациям), подвергающимся рискам, связанным с приложениями.

ИСО/МЭК 27034 не предоставляет:

a) рекомендации по физической безопасности и безопасности сети;

b) типы измерения или меры и средства контроля и управления;

c) спецификации безопасного кодирования для любого языка программирования.

ИСО/МЭК 27034 не является:

a) стандартом по разработке прикладных программ;

b) стандартом по менеджменту проектов приложений;

c) стандартом, касающимся жизненного цикла развития программных средств.

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

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

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

0.3.1 Общие сведения

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

a) руководителей;

b) членов групп подготовки к работе и эксплуатации;

c) лиц, отвечающих за приобретение;

d) поставщиков;

e) аудиторов;

f) пользователей.

0.3.2 Руководители

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

a) ответственные за информационную безопасность;

b) руководители проектов;

c) администраторы;

d) ответственные за приобретение программных средств;

e) руководители разработки программных средств;

f) владельцы приложений;

g) руководители среднего звена, которые руководят сотрудниками.

В обязанности руководителей входит:

a) обеспечить баланс между стоимостью реализации и поддержанием безопасности приложений по отношению к рискам и представляемой ценностью приложений для организации;

b) проверять рекомендации аудиторских отчетов относительно принятия или отклонения достигаемого и поддерживаемого приложением целевого уровня доверия;

c) обеспечивать уверенность в соблюдении стандартов, законов и предписаний на основе регулятивного контекста приложения (см. 8.1.2.2);

d) осуществлять надзор за реализацией безопасного приложения;

e) санкционировать целевой уровень доверия в соответствии со специфическим контекстом организации;

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

g) сводить к минимуму расходы на верификацию безопасности приложений;

h) документально оформлять процедуры и политики безопасности для приложений;

i) обеспечивать информирование, обучение и надзор за обеспечением безопасности в отношении всех действующих субъектов;

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

k) курировать все планы, связанные с системами безопасности во всей структуре организации.

0.3.3 Члены групп подготовки к работе и эксплуатации

Члены групп подготовки к работе и эксплуатации (общеизвестные как группы проекта) - это лица, вовлеченные в проектирование, разработку и поддержку приложений на протяжении всего их жизненного цикла. К ним относятся:

a) разработчики архитектуры;

b) аналитики;

c) программисты;

d) специалисты по тестированию;

е) системные администраторы;

f) администраторы баз данных;

g) сетевые администраторы;

h) технический персонал.

Члены групп подготовки к работе и эксплуатации должны:

a) знать, какие меры и средства контроля и управления должны применяться на каждом этапе жизненного цикла приложений и по какой причине;

b) знать, какие меры и средства контроля и управления должны быть реализованы в самом приложении;

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

d) проверять соответствие введенных мер и средств контроля и управления безопасностью приложений требованиям соответствующих измерений;

е) иметь доступ к инструментальным средствам и лучшим практическим приемам для рациональной разработки, тестирования и документирования;

f) способствовать экспертной оценке;

g) принимать участие в планировании и разработке стратегии приобретения;

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

i) организовывать удаление элементов, оставшихся после завершения работы (например, управление имуществом/удаление).

0.3.4 Лица, отвечающие за приобретение

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

Лица, отвечающие за приобретение, должны:

a) подготавливать запрос предложений, включающий требования к мерам и средствам контроля и управления безопасностью;

b) выбирать поставщиков, соответствующих заданным требованиям;

c) проверять свидетельства применения мер и средств контроля и управления безопасностью услуг на основе аутсорсинга;

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

0.3.5 Поставщики

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

Поставщики должны:

а) выполнять требования безопасности приложений, представленные в запросах предложений;

b) подбирать соответствующие заявленным требованиям меры и средства контроля и управления безопасностью приложений для предложений с указанием их стоимости;

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

0.3.6 Аудиторы

Аудиторы - лица, которые должны:

a) понимать объем и процедуры, вовлеченные в верификационные измерения в отношении соответствующих мер и средств контроля и управления;

b) обеспечивать уверенность в повторяемости результатов аудита;

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

d) применять стандартизированные процессы аудита, основанные на использовании свидетельств, поддающихся проверке.

0.3.7 Пользователи

Пользователи - лица, которые должны:

a) быть уверенными в том, что использование или развертывание приложения является безопасным;

b) быть уверенными в том, что приложения последовательно и своевременно создают надежные результаты;

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

0.4 Принципы

0.4.1 Безопасность является требованием

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

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

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

0.4.2 Безопасность приложений зависит от контекста

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

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

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

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

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

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

0.4.3 Соответствующие инвестиции в обеспечение безопасности приложений

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

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

0.4.4 Безопасность приложений должна демонстрироваться

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

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

0.5 Связь с другими международными стандартами

0.5.1 Общие сведения

На рисунке 1 показана взаимосвязь ИСО/МЭК 27034 с другими международными стандартами.

Рисунок 1 - Взаимосвязь ИСО/МЭК 27034 с другими международными стандартами

Рисунок 1 - Взаимосвязь ИСО/МЭК 27034 с другими международными стандартами

0.5.2 ИСО/МЭК 27001, Системы менеджмента информационной безопасности. Требования

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

a) систематический подход к менеджменту безопасности;

b) подход процесса "Планирование - Осуществление - Проверка - Действие";

c) реализация информационной безопасности на основе менеджмента риска.

0.5.3 ИСО/МЭК 27002, Свод норм и правил менеджмента информационной безопасности

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

a) раздел 10: Менеджмент коммуникаций и работ;

b) раздел 11: Управление доступом;

c) раздел 12: Приобретение, разработка и эксплуатация информационных систем.

0.5.4 ИСО/МЭК 27005, Менеджмент риска информационной безопасности

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

0.5.5 ИСО/МЭК 21827, Проектирование безопасности систем. Модель зрелости процесса® (SSE-CMM®)

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

0.5.6 ИСО/МЭК 15408-3, Критерии оценки безопасности информационных технологий. Часть 3: Требования доверия к безопасности

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

0.5.7 ИСО/МЭК ТО 15443-1, Основы доверия к безопасности информационных технологий. Часть 1: Обзор и основы, и ИСО/МЭК ТО 15443-3, Основы доверия к безопасности информационных технологий. Часть 3: Анализ методов обеспечения доверия

ИСО/МЭК 27034 помогает применять и отражать принципы доверия к безопасности из ИСО/МЭК ТО 15443-1 и содействовать сценариям обеспечения доверия из ИСО/МЭК ТО 15443-3.

0.5.8 ИСО/МЭК 15026-2, Разработка программного обеспечения и систем. Гарантирование систем и программного обеспечения. Часть 2: Сценарии обеспечения доверия

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

a) утверждения и их обоснования обеспечиваются процессом анализа риска безопасности приложений;

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

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

См. также 8.1.2.6.5.1.

0.5.9 ИСО/МЭК 15288, Разработка программного обеспечения и систем. Процессы жизненного цикла систем, и ИСО/МЭК 12207, Разработка программного обеспечения и систем. Процессы жизненного цикла программных средств

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

0.5.10 ИСО/МЭК ТО 29193 (в процессе разработки), Принципы и методы инжиниринга безопасных систем

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

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

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

Данная часть ИСО/МЭК 27034 содержит общий обзор безопасности приложений, а также определения, понятия, принципы и процессы, касающиеся обеспечения безопасности приложений.

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

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

В настоящем стандарте использованы нормативные ссылки на следующие международные стандарты*. Для датированных ссылок используют только указанное издание. Для недатированных ссылок используют самое последнее издание ссылочного документа (с учетом всех его изменений).
_______________
* Таблицу соответствия национальных стандартов международным см. по ссылке. - .


ИСО/МЭК 27000:2009 Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Обзор и терминология (ISO/IEC 27000:2009, Information technology - Security techniques - Information security management systems - Overview and vocabulary)
_______________
Отменен. Действует ИСО/МЭК 27000:2014. Однако для однозначного соблюдения требований настоящего стандарта, выраженных в датированных ссылках, рекомендуется использовать только данный ссылочный стандарт.


ИСО/МЭК 27001:2005 Информационная технология. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Требования (ISO/IEC 27001:2005, Information technology - Security techniques - Information security management systems - Requirements)
_______________
Отменен. Действует ИСО/МЭК 27001:2013. Однако для однозначного соблюдения требований настоящего стандарта, выраженных в датированных ссылках, рекомендуется использовать только данный ссылочный стандарт.


ИСО/МЭК 27002:2005 Информационная технология. Методы и средства обеспечения безопасности. Свод норм и правил менеджмента информационной безопасности (ISO/IEC 27002:2005, Information technology - Security techniques - Code of practice for information security management)
_______________
Отменен. Действует ИСО/МЭК 27002:2013. Однако для однозначного соблюдения требований настоящего стандарта, выраженных в датированных ссылках, рекомендуется использовать только данный ссылочный стандарт.


ИСО/МЭК 27005:2011 Информационная технология. Методы и средства обеспечения безопасности. Менеджмент риска информационной безопасности (ISO/IEC 27005:2011, Information technology - Security techniques - Information security risk management)

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

В настоящем стандарте применены термины по ИСО/МЭК 27000, ИСО/МЭК 27001, ИСО/МЭК 27002, ИСО/МЭК 27005, а также следующие термины с соответствующими определениями.

3.1 действующий субъект (actor): Лицо или процесс, осуществляющий деятельность во время жизненного цикла приложения или инициирующий взаимодействие с любым процессом, который обеспечивает или затрагивает приложение.

3.2 фактический уровень доверия (actual level of trust): Результат процесса аудита, обеспечивающий свидетельства, подтверждающие, что меры и средства контроля и управления безопасностью приложений, требуемые целевым уровнем доверия приложения, надлежащим образом реализованы, проверены и дают ожидаемые результаты.

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

Примечание - Процессы бизнеса включают как людей, так и технологии.

3.4 эталонная модель жизненного цикла безопасности приложений (application security life cycle reference model): Модель жизненного цикла, используемая в качестве эталона для введения мероприятий по обеспечению безопасности в процессы, связанные с менеджментом приложений, подготовкой к работе и эксплуатацией приложений, менеджментом инфраструктуры и аудитом приложений.

3.5 нормативная структура приложений; ANF (application normative framework - ANF): Совокупность нормативных элементов, выбранных из нормативной структуры организации и значимых для конкретного проекта приложения.

3.6 владелец приложения (application owner): Организационная роль, отвечающая за менеджмент, использование и обеспечение защиты приложения и его данных.

Примечания

1 Владелец приложения принимает все решения, касающиеся безопасности приложения.

2 Используемый в настоящем стандарте термин "владелец" является синонимом термина "владелец приложения".

3.7 проект приложения (application project): Попытка действий с определенными критериями начала и завершения, направленных на создание приложения в соответствии с заданными ресурсами и требованиями.

[ИСО/МЭК 12207:2008, определение 4.29, модифицированное специально для сферы действия приложений]

Примечание - Для целей ИСО/МЭК 27034 критерии начала и завершения таковы, что весь жизненный цикл приложения включен в проект приложения.

3.8 мера и средство контроля и управления безопасностью приложения; ASC (application security control - ASC): Структура данных, содержащая четкое перечисление и описание видов деятельности по обеспечению безопасности и их соответствующего верификационного измерения, подлежащего выполнению в конкретный момент жизненного цикла приложения.

3.9 процесс менеджмента безопасности приложений; ASMP (application security management process - ASMP): Используемый организацией общий процесс менеджмента в отношении видов деятельности по обеспечению безопасности, действующих субъектов, артефактов и аудита каждого приложения.

3.10 прикладное программное средство (application software): Программное средство, предназначенное для содействия пользователям в осуществлении определенных задач или обработке конкретных видов задач, в отличие от программного средства, управляющего компьютером.

[ИСО/МЭК/ИИЭР 24765:2010, определение 3.130-1]

3.11 аудит (audit): Систематический, независимый и документированный процесс получения свидетельств аудита и объективного их оценивания с целью установления степени выполнении согласованных критериев аудита.

[ИСО 9000:2005, определение 3.9.1, обобщенно модифицированное]

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

3.13 жизненный цикл (life cycle): Развитие системы, продукта, услуги, проекта или других изготовленных человеком объектов, начиная со стадии разработки концепции и заканчивая прекращением применения.

[ИСО/МЭК 12207:2008, определение 4.16]

3.14 модель жизненного цикла (life cycle model): Структура процессов и действий, связанных с жизненным циклом, организуемых на стадиях, которые также служат в качестве общей ссылки для установления связей и взаимопонимания сторон.

[ИСО/МЭК 12207:2008, определение 4.17]

3.15 сопровождение (maintenance): Любое изменение приложения, осуществленное после его выпуска.

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

3.16 нормативная структура организации; ONF (organization normative framework - ONF): Внутренняя структура всей организации, включающая совокупность нормативных процессов и элементов безопасности приложений.

3.17 группа нормативной структуры организации; группа ONF (ONF Committee): Организационная роль в нормативной структуре организации, отвечающая за сопровождение и санкционирование компонентов, связанных с безопасностью приложений.

3.18 операционная среда (operating environment): Внешнее окружение программы, которое существует или предполагается во время ее выполнения.

[ИСО/МЭК 2382-7:2000, определение 07.11.07]

3.19 продукция (product): Результат процесса.

[ИСО 9000:2005, определение 3.4.2]

3.20 безопасное приложение (secure application): Приложение, фактический уровень доверия которого равен целевому уровню доверия, который определяется организацией, использующей приложение.

3.21 целевой уровень доверия (targeted level of trust): Обозначение или метка совокупности мер и средств контроля и управления безопасностью приложений, сочтенных необходимыми владельцем приложения для снижения связанного с конкретным приложением риска до допустимого (или приемлемого) уровня после анализа риска безопасности приложения.

3.22 пользователь (user): Лицо, использующее или эксплуатирующее что-то.

[Краткий оксфордский словарь английского языка]

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

3.23 валидация (validation): Подтверждение посредством представления объективных свидетельств того, что требования, предназначенные для конкретного использования или применения, выполнены.

Примечания

1 Термин "валидирован" используется для обозначения соответствующего статуса.

2 Условия применения могут быть реальными или смоделированными.

[ИСО 9000:2005, определение 3.8.5]

3 На языке неспециалиста "валидация" означает "Правильно ли построено приложение?"

3.24 верификация (verification): Подтверждение посредством представления объективных свидетельств того, что установленные требования были выполнены.

Примечания

1 Термин "верифицирован" используют для обозначения соответствующего статуса.

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

[ИСО 9000:2005, определение 3.8.4]

3 На языке неспециалиста "верификация" означает "Корректно ли построено приложение?"

4 Сокращения

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

5 Структура ИСО/МЭК 27034

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

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

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

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

Содержание шести частей ИСО/МЭК 27034:

Часть 1 - Обзор и общие понятия

В части 1 представлен обзор безопасности приложений. Она знакомит с определениями, общими понятиями, принципами и процессами, касающимися обеспечения безопасности приложений.

Часть 2 - Нормативная структура организации

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

Часть 3 - Процесс менеджмента безопасности приложений

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

Часть 4 - Валидация безопасности приложений

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

Часть 5 - Структура данных управления безопасностью протоколов и приложений

В части 5 представлены протоколы и XML-схема для мер и средств контроля и управления безопасностью приложений (ASC) на основе ИСО/МЭК ТУ 15000 "Расширяемый язык разметки для электронного бизнеса (ebXML)". Данная часть может быть использована для содействия организациям в валидации структуры данных ASC и других компонентов ИСО/МЭК 27034, а также для поддержки распространения, обновления и использования ASC.

Часть 6 - Руководство по безопасности для конкретных приложений

В части 6 представлены примеры ASC, приспособленных к конкретным требованиям безопасности приложений.

6 Введение в безопасность приложений

6.1 Общая информация

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

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

6.2 Безопасность приложений в сравнении с безопасностью программных средств

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

6.3 Сфера действия безопасности приложений

6.3.1 Общие сведения

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

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

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

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

Рисунок 2 - Сфера действия безопасности приложений

Рисунок 2 - Сфера действия безопасности приложений

Таблица 1 - Сфера действия приложений в сравнении со сферой действия безопасности приложений

Приведенные ниже данные и процессы находятся в сфере действия безопасности приложений и должны быть защищены.

6.3.2 Бизнес-контекст

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

6.3.3 Регулятивный контекст

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

6.3.4 Процессы жизненного цикла приложений

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

a) процессы обучения, аудита и аттестации;

b) процессы реализации (разработка, менеджмент проектов, сопровождение, контроль версий, тестирование и т.д.);

c) операционные процессы.

6.3.5 Процессы, связанные с приложениями

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

a) процессы использования и менеджмента;

b) процессы сопровождения и резервного копирования;

c) процессы распространения и развертывания;

d) процессы, на которые влияют приложения или которые требуются приложениям.

6.3.6 Технологический контекст

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

a) терминалы, сети и иные разрешенные периферийные устройства;

b) операционная система, конфигурация и сервисы;

c) разрешенные каналы связи и порты;

d) COTS и иные продукты, такие как системы управления базами данных (СУБД), используемые приложениями, и их технологическая инфраструктура;

e) модификация и иные процессы, связанные с технологическим контекстом;

f) продукты, на которые оказывают влияние приложения или которые используются приложениями.

6.3.7 Спецификации приложений

Должна обеспечиваться защита от несанкционированной модификации всех спецификаций приложений, таких как:

a) спецификации аппаратных средств;

b) спецификации безопасности;

c) функциональные возможности приложений;

d) спецификации терминала клиента;

e) спецификации операционного отдела.

6.3.8 Прикладные данные

Должна обеспечиваться защита всей критической информации приложений, такой как:

a) конфигурационные данные приложений;

b) двоичный код приложений;

c) исходный код приложений;

d) компоненты приложений и библиотек;

e) документация важнейших компонентов и функциональных возможностей приложений.

6.3.9 Данные организации и пользователей

Должна обеспечиваться защита всей критической информации, касающейся организации и пользователей, такой как:

a) сертификаты;

b) секретные ключи;

c) необходимые для целевой задачи данные;

d) персональные данные;

e) пользовательские данные конфигурации.

6.3.10 Роли и полномочия

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

a) данные по управлению идентификацией;

b) идентификационные и аутентификационные данные;

c) данные авторизации.

6.4 Требования безопасности приложений

6.4.1 Источники требований безопасности приложений

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

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

6.4.2 Разработка требований безопасности приложений

Разработка требований приложений - это процесс, охватывающий сбор, анализ и определение требований для приложений. Он должен быть дополнен оценкой риска с целью включения требований безопасности.

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

6.4.3 Система менеджмента информационной безопасности

6.4.3.1 СМИБ организации

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

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

6.4.3.2 Безопасность приложений в контексте СМИБ

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

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

6.5 Риск

6.5.1 Риск безопасности приложений

Риск безопасности приложений - это риск, которому подвергаются организации при использовании конкретного приложения.

Риск безопасности приложений возникает при наличии:

a) угроз, направленных на информацию, которая доступна приложениям;

b) уязвимостей;

c) влияния успешного использования уязвимостей угрозами.

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

6.5.2 Уязвимости приложений

Уязвимости являются результатом наличия неадекватных мер и средств контроля и управления или их отсутствия. Неадекватно контролируемые уязвимости в результате приводят к неприемлемому риску приложений.

Уязвимости проистекают от:

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

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

c) технологического контекста, такого как плохо выбранная технологическая инфраструктура или продукты;

d) особенностей, таких как неадекватное проектирование, уязвимости, обусловленные взаимодействиями в системе или ошибками в интерфейсах компонентов.

6.5.3 Угрозы приложениям

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

a) среды приложений: регулятивного контекста, бизнес-контекста и технологического контекста;

b) действующих субъектов.

6.5.4 Влияние приложений

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

6.5.5 Менеджмент риска

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

Менеджмент риска представляет собой ключевую концепцию в информационной безопасности. Согласно ИСО/МЭК 27005, "процесс менеджмента риска информационной безопасности может применяться к организации в целом, любой отдельной части организации (например, отделу, физической площадке, услуге), любой информационной системе, существующим, планируемым или конкретным аспектам мер и средств контроля и управления (например, планированию непрерывности бизнеса)".

Представленный в ИСО/МЭК 27005 процесс менеджмента риска информационной безопасности состоит из установления контекста, оценки риска, обработки риска, принятия риска, коммуникации риска, мониторинга и пересмотра риска.

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

6.6 Расходы на безопасность

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

6.7 Целевая среда

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

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

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

6.8 Меры и средства контроля и управления и их цели

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

7 Общие процессы ИСО/МЭК 27034

7.1 Компоненты, процессы и структуры

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

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

a) процесса менеджмента ONF;

b) процесса менеджмента безопасности приложений (ASMP).

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

7.2 Процесс менеджмента ONF

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

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


Процессы, связанные с безопасностью приложений, должны быть частью ONF.

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

Примечание 2 - Процесс менеджмента ONF и его компоненты и подпроцессы более детально представлены в 8.1.3.2, а также в ИСО/МЭК 27034-2.

7.3 Процесс менеджмента безопасности приложений

7.3.1 Общие сведения

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

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

a) определение требований и среды приложений;

b) оценка рисков безопасности приложений;

c) создание и поддержка нормативной структуры приложений;

d) подготовка к работе и эксплуатация приложений;

e) аудит безопасности приложений.

Примечание - ASMP более детально представлен в разделе 8, а также в ИСО/МЭК 27034-3.

Рисунок 3 - Процессы менеджмента

Рисунок 3 - Процессы менеджмента

7.3.2 Определение требований и среды приложений

Первым шагом ASMP является определение всех требований приложений, включая:

a) действующих субъектов;

b) спецификации;

c) информацию;

d) среду.

Среда приложений состоит из:

a) технологического контекста;

b) бизнес-контекста;

c) регулятивного контекста.

Примечание - Контекст более детально представлен в 8.1.2.1-8.1.2.2.


Этот шаг соответствует шагу "определение контекста" в устанавливаемом ИСО/МЭК 27005 процессе менеджмента риска. Он предоставляет необходимую информацию для последующего шага оценки риска.

7.3.3 Оценка рисков безопасности приложений

Второй шаг ASMP представляет собой процесс, соответствующий шагу "оценка риска" и частично шагу "обработка риска" в устанавливаемом ИСО/МЭК 27005 процессе менеджмента риска, с более точным уровнем детальности и сферой действия, ограниченной одним проектом приложения.

Оценка риска состоит из идентификации риска, анализа риска и оценивания риска.

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

Данный шаг также соответствует "выбору вариантов обработки риска", относящемуся к шагу "обработка риска" в устанавливаемом ИСО/МЭК 27005 процессе менеджмента риска.

7.3.4 Создание и поддержка нормативной структуры приложений

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

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

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

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

Примечание - Этот шаг ASMP и его компоненты и процессы более детально представлены в 8.3.

7.3.5 Подготовка к работе и эксплуатация приложений

Четвертым шагом ASMP является фактическое использование мер и средств контроля и управления безопасностью приложений, как предусмотрено ANF в жизненном цикле приложений. Группа проекта реализует меры и средства контроля и управления безопасностью приложений согласно ANF, используя:

a) часть действий по безопасности каждой ASC, осуществляемых соответствующим действующим субъектом, определенным в ASC;

b) часть измерений безопасности каждой ASC, осуществляемых соответствующим действующим субъектом, определенным в ASC.

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

Примечание - Этот шаг ASMP и его компоненты и процессы более детально представлены в 8.4.

7.3.6 Проведение аудита безопасности приложений

Пятым и завершающим шагом ASMP является аудит безопасности приложений.

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

Данный шаг соответствует шагу "мониторинг и проверка" в устанавливаемом ИСО/МЭК 27005 процессе менеджмента риска.

Примечание - Этот шаг ASMP и его компоненты и процессы более детально представлены в 8.5.

8 Общие понятия

8.1 Нормативная структура организации

8.1.1 Общая информация

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

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

Как показано на рисунке 3, ONF предоставляет основную входную информацию для ASMP, осуществляемого для каждого проекта приложения в организации.

На рисунке 4 показано высокоуровневое представление контента ONF

Рисунок 4 - Нормативная структура организации (упрощенная)

Рисунок 4 - Нормативная структура организации (упрощенная)

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

a) бизнес-контекст;

b) регулятивный контекст;

c) технологический контекст;

d) репозиторий спецификаций приложений;

e) роли, обязанности, квалификация;

f) библиотека ASC организации;

g) процессы, связанные с безопасностью приложений;

h) эталонная модель жизненного цикла безопасности приложений.

Формальная ONF должна также содержать:

a) процесс менеджмента ONF;

b) подпроцессы менеджмента ONF

8.1.2 Компоненты

8.1.2.1 Бизнес-контекст

Бизнес-контекст перечисляет и документирует все принятые организацией стандарты и лучшие практические приемы, которые могут оказывать влияние на проекты приложений.

Бизнес-контекст включает:

a) процессы менеджмента проекта, разработки, анализа риска, операционные процессы, процессы аудита и контроля;

b) политику безопасности организации;

c) практические приемы в сфере бизнеса;

d) используемую организацией методику разработки;

e) лучшие практические приемы для всех языков программирования, используемых организацией и перечисленных в технологическом контексте;

f) формальный процесс менеджмента проекта организации;

g) применение организацией других необходимых международных стандартов, таких как ИСО/МЭК 27001, ИСО/МЭК 27002 и ИСО/МЭК 15288.

8.1.2.2 Регулятивный контекст

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

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

8.1.2.3 Репозиторий спецификаций приложений

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

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

b) обычные параметры приложений, функциональные возможности, услуги и требования;

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

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

a) другими системами;

b) рабочей инфраструктурой, от которой они зависят;

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

8.1.2.4 Технологический контекст

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

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

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

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

Пример 2 - Если технологический контекст не включает механизм аутентификации TLS 1.0 для поддержки функциональности "двусторонняя аутентификация", то ASC на основе TLS 1.0 не могут быть включены в приложение. Группе проекта придется выбирать альтернативные ASC для получения функциональной возможности двусторонней аутентификации, если эта функциональная возможность требуется на целевом уровне доверия приложения.

_______________
TLS (Transport Layer Security) - Протокол безопасности транспортного уровня.


Технологический контекст должен включать:

а) технологии, доступные для проектов приложений организации.

Инвентарная опись таких технологий должна постоянно обновляться группой ONF через обратную связь от предыдущих проектов приложений;

b) технологии, требуемые приложением.

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

c) доступные технологии.

Данные технологии выявляются в результате исследований, анализа тенденций и мониторинга технологий.

8.1.2.5 Роли, обязанности и квалификация

ONF должна содержать:

a) перечни и описания всех ролей, обязанностей и необходимой профессиональной квалификации всех действующих субъектов, участвующих в создании и поддержке ONF, и/или ролей по созданию и поддержке ASC;

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

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

8.1.2.6 Библиотека ASC организации

8.1.2.6.1 Общие сведения

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

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

Из библиотеки ASC организации выбираются точные и подробные ASC для каждого конкретного проекта приложения.

8.1.2.6.2 Пример библиотеки ASC организации

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

В этом примере организация определила две спецификации приложений: безопасное протоколирование и онлайновые платежи. Бизнес-контекстом для данной организации является авиационная сфера, и организация реализует стандарт безопасности данных индустрии платежных карт (PCI-DSS). Регулятивный контекст налагает необходимость соответствия определенным законам обеспечения приватности. Технологический контекст показывает, что данная организация определила меры и средства контроля и управления для SSL-соединений и беспроводной сети.

Рисунок 5 - Графическое представление библиотеки ASC организации

Рисунок 5 - Графическое представление библиотеки ASC организации

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

8.1.2.6.3 Процесс создания библиотеки ASC организации

Процесс создания библиотеки ASC прост и легко может быть выполнен даже очень небольшими организациями.

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

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

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

Эта совокупность ASC может быть согласована с существующей библиотекой ASC тремя возможными способами:

а) полная совокупность ASC в библиотеке уже обеспечивает требуемый уровень доверия, в таком случае в библиотеку ничего не добавляется;

b) полной совокупности мер и средств контроля и управления безопасностью приложений в библиотеке недостаточно для требуемого уровня доверия, в таком случае библиотека может быть пополнена из новой совокупности ASC;

c) из новой совокупности ASC в библиотеке создается новый уровень доверия.

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

Библиотека ASC организации расширяется в ответ на замечания и предложения от каждого нового проекта приложения, как описано в 8.1.3.2.

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

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

Пример 1 - На рисунке 5 организация определила шесть уровней доверия, представленных крайними правыми графами, пронумерованными от 0 до 5.

Пример 2 - На рисунке 5 уровень доверия 1 определяет совокупность из трех ASC, относящихся к онлайновым платежам, законам об обеспечении приватности и SSL-соединениям. Кроме того, на уровне 1 также применяются ASC, относящиеся к безопасному протоколированию и беспроводной сети (показаны стрелками с точкой).

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

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

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

Пример 3 - Организация может использовать цифровые уровни от 0 до 5, как в примере на рисунке 5, а может использовать область определенных значений, например [низкий, средний, высокий] или [зеленый, желтый, красный]. Также организация может использовать критерии, основанные на критериях принятия риска.

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

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

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

8.1.2.6.5 Меры и средства контроля и управления безопасностью приложений

8.1.2.6.5.1 Общие сведения

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

Понятие мер и средств контроля и управления безопасностью широко используется в сфере информационной безопасности. В ИСО/МЭК 15408-3 и NIST SP 800-53 опубликовано множество соответствующих мер и средств контроля и управления безопасностью, являющихся широкодоступными.

ASC - это используемые в проектах приложений меры и средства контроля и управления безопасностью, определенные с использованием структуры, которая представлена в последующих подпунктах. В приложении В представлен пример, иллюстрирующий, как, используя структуру ASC, можно описать меры и средства контроля и управления безопасностью из NIST SP 800-53.

Для организаций, реализующих концепцию сценариев обеспечения доверия в соответствии с ИСО/МЭК ТО 15026-2, ASC полезны для упрощения менеджмента и своевременного предоставления свидетельств, необходимых для поддержки заявлений и доводов о безопасности приложений. Дальнейшая поддержка доводов обеспечивается последовательным использованием организацией предлагаемых настоящим стандартом процессов по созданию, утверждению и использованию каждой ASC. Поскольку полная совокупность ASC, выбранных для проекта приложения, проистекает из анализа риска безопасности приложений, то она напрямую поддерживает высокоуровневые заявления, обоснования и доводы о безопасности приложений.

ASC могут использоваться для:

a) обеспечения безопасности компонентов приложений, включая программные средства, данные, COTS и инфраструктуру;

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

c) проверки ролей, обязанностей и квалификации всех действующих субъектов, вовлеченных в проект;

d) определения критериев для оценивания/приемки компонентов;

e) содействия в определении фактического уровня доверия приложений.

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

Рисунок 6 - Компоненты ASC

Рисунок 6 - Компоненты ASC

Относящаяся к мероприятиям обеспечения безопасности часть ASC определяет, как решаются вопросы безопасности для проекта приложения.

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

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

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

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

b) облегчения взаимодействия путем группирования соответствующих ASC под определенными заголовками, используя соответствующий словарь, например, используя язык бизнеса при взаимодействии с руководством;

c) содействия распределению ASC путем группирования их во взаимосвязанные совокупности;

d) обеспечения уверенности в том, что все мероприятия по обеспечению доверия в связанных ASC выполнены и ни одно из них не обойдено.

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

Рисунок 7 - Схема ASC организации

Рисунок 7 - Схема ASC организации

ASC - это сложная структура данных, которая будет детально рассмотрена в ИСО/МЭК 27034-5: "Структура данных управления безопасностью протоколов и приложений". Ниже следует краткий общий обзор ASC.

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

8.1.2.6.5.2 Идентификация ASC

Элемент идентификации ASC содержит следующее:

a) информацию об ASC: название, идентификатор, автор, дата, описание ASC и т.д.;

b) указатели на материнскую и дочерние ASC (ASC могут быть представлены как схематическая структура);

c) указатели на соответствующий бизнес-контекст, регулятивный и технологический контексты, а также на спецификации приложений, обеспечивающие требования безопасности для данной ASC (см. рисунок 5).

8.1.2.6.5.3 Цель ASC

Цель ASC определяет, "зачем" существует данная ASC, а именно требования безопасности, для реализации которых была разработана данная ASC.

Цель ASC определяет:

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

b) для каких уровней доверия эта ASC является обязательной;

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

d) угрозы безопасности и предположения об операционной среде приложения.

ASC может быть связана с несколькими уровнями доверия.

Пример - На рисунке 5 ASC определена на уровне доверия 1 для любых приложений, включающих онлайновые платежи. Эта ASC обязательна для любых проектов разработки приложений, включающих онлайновые платежи, где владельцем приложения присвоен целевой уровень доверия от 1 до 2. Если владелец приложения хочет присвоить третий целевой уровень доверия, то нужна ASC с более строгим мероприятием по обеспечению безопасности и/или измерением.

8.1.2.6.5.4 Мероприятие по обеспечению безопасности ASC

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

a) что:

1) полное описание мероприятия по обеспечению безопасности;

2) сложность мероприятия;

3) артефакты, создаваемые в результате мероприятия. Эти артефакты предоставляют свидетельства, подтверждающие наличие процессов или процедур введенной меры и средства контроля и управления безопасностью приложений (т. е. мероприятия по обеспечению безопасности ASC);

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

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

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

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

e) когда: указание на определенную деятельность на этапе эталонной модели жизненного цикла безопасности приложений (см. 8.1.2.7), когда должно осуществляться данное мероприятие;

f) сколько: расчетная стоимость реализации ASC.

8.1.2.6.5.5 Верификационное измерение ASC

Здесь представлено верификационное измерение, проводимое для проверки реализации соответствующей ASC. Верификационное измерение по меньшей мере должно определять:

a) что:

1) полное описание измерения безопасности. Это описание определяет, как верифицируется существование и правильность артефакта, создаваемого в результате реализации ASC;

2) сложность измерения;

3) артефакт, создаваемый при измерении. Этот артефакт предоставляет свидетельства, необходимые для демонстрации верификации ASC;

4) ожидаемые результаты (описание ситуации, состояния или точного значения артефакта);

b) как: метод выполнения данного измерения и получения артефакта, такой как инструментальные средства и установки проверки кода или документ, предоставляющий руководство по выполнению измерения;

c) где: цель верификации, а именно точные характеристики артефакта, создаваемого соответствующей верифицируемой ASC;

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

e) когда: указание на определенную деятельность на этапе эталонной модели жизненного цикла безопасности приложений (см. 8.1.2.7), когда должно осуществляться данное измерение. При необходимости это измерение может осуществляться периодически;

f) сколько: расчетная стоимость выполнения одного верификационного измерения.

8.1.2.7 Эталонная модель жизненного цикла безопасности приложений

8.1.2.7.1 Общая информация

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

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

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

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

Мероприятия, осуществляемые на различных этапах жизненного цикла программных средств или систем, являются частью процессов в масштабах организации, которые должны соответствовать нормативным требованиям, представленным в ИСО/МЭК 12207 и ИСО/МЭК 15288. Кроме того, в ИСО/МЭК ТО 24748 представлено дополнительное руководство и описаны модели жизненного цикла разработки систем и программных средств, этапы жизненного цикла и их связь с процессами жизненного цикла.

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

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

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

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

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

Цель эталонной модели жизненного цикла безопасности приложений состоит в:

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

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

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

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

e) предоставлении организации стандартной модели для коллективного использования ASC вместе с другими организациями, независимо от различных моделей жизненного цикла приложений.

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

Рисунок 8 - Высокоуровневая эталонная модель жизненного цикла безопасности приложений

Рисунок 8 - Высокоуровневая эталонная модель жизненного цикла безопасности приложений

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

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

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

Этапы подготовки к работе и эксплуатации далее делятся на следующие стадии:

a) этап подготовки к работе состоит из трех стадий: подготовка, реализация и ввод в действие;

b) этап эксплуатации состоит из трех стадий: использование и поддержка, архивирование, уничтожение.

Данная эталонная модель по вертикали разделяется на четыре основных уровня:

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

b) подготовка к работе и эксплуатация приложений: этот уровень составляют мероприятия, связанные с подготовкой к работе и использованием самого приложения. Такие мероприятия обычно осуществляются в рамках процессов, рекомендуемых ИСО/МЭК 15026, ИСО/МЭК 15288, ИСО/МЭК 12207 и ИСО/МЭК 21827;

c) менеджмент инфраструктуры: этот уровень составляют мероприятия, связанные с менеджментом поддерживающей приложение инфраструктуры услуг ИТ организации. Такие мероприятия обычно осуществляются в рамках процессов, рекомендуемых такими стандартами, как ИСО/МЭК ТО 20000-4, и руководствами, такими как ITIL;
_______________
ITIL (Information Technology Infrastructure Library) - библиотека передового опыта в области информационных технологий.

d) аудит приложений: этот уровень составляют мероприятия, связанные с контролем и верификацией. Такие мероприятия обычно осуществляются в рамках процессов, рекомендуемых такими стандартами, как ИСО/МЭК 15288, ИСО/МЭК 12207, и документами по отраслевой практике, такими как стандарт CobiT.

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

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

8.1.2.7.2 Менеджмент подготовки приложений к работе

Мероприятия по менеджменту подготовки приложений к работе осуществляются руководителями проектов и руководителями организации на этапе подготовки к работе жизненного цикла приложений.

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

8.1.2.7.3 Менеджмент эксплуатации приложений

Мероприятия по менеджменту эксплуатации приложений связаны с менеджментом и использованием приложений на этапе эксплуатации.

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

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

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

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

8.1.2.7.4 Подготовка

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

8.1.2.7.5 Подготовительные процессы

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

Примечание - Подготовительные процессы включают процессы проектирования программных средств из ИСО/МЭК 12207, такие как процесс определения требований причастных сторон, анализ требований системы и менеджмент риска (см. ИСО/МЭК 12207, 6.4.1).

8.1.2.7.6 Аутсорсинг

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

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

8.1.2.7.7 Разработка

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

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

8.1.2.7.8 Приобретение

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

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

8.1.2.7.9 Ввод в действие

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

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

8.1.2.7.10 Использование

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

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

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

8.1.2.7.11 Архивирование

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

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

8.1.2.7.12 Уничтожение

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

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

8.1.2.7.13 Менеджмент обеспечения инфраструктуры приложений

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

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

8.1.2.7.14 Менеджмент инфраструктуры эксплуатации приложений

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

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

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

8.1.2.7.15 Снятие с эксплуатации

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

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

8.1.2.7.16 Аудит подготовки приложений к работе

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

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

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

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

8.1.2.7.17 Аудит эксплуатации приложений

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

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

8.1.2.8 Процессы, связанные с безопасностью приложений

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

a) все процессы, описанные в разделе 8 настоящего стандарта;

b) все процессы, описанные в последующих частях ИСО/МЭК 27034;

c) все процессы, упоминаемые в ASC, такие как планы реагирования на инциденты, планы обеспечения непрерывности бизнеса, процедуры проверки кода и процедуры тестирования уязвимостей.

8.1.3 Процессы, связанные с нормативной структурой организации

8.1.3.1 Общая информация

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

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

Эти процессы упоминаются в настоящем стандарте и будут более детально обсуждаться в ИСО/МЭК 27034-2.

8.1.3.2 Процесс менеджмента ONF

Рисунок 9 - Процесс менеджмента ONF

Рисунок 9 - Процесс менеджмента ONF

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

Цели процесса менеджмента ONF:

a) обеспечение уверенности в том, что потребности безопасности приложений, а также утверждение библиотеки ASC и уровней доверия, особенно нулевого уровня доверия, по-прежнему урегулированы с потребностями бизнеса организации;

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

c) утверждение высшим руководством политик безопасности в масштабах организации и признание высшим руководством значимости компонентов ONF;

d) обеспечение уверенности в адекватном и единообразном применении ASC в масштабах организации;

e) информирование о компонентах ONF всех групп в организации;

f) обеспечение обратной связи для ONF с целью включения новых знаний, предложений о совершенствовании ASC и новых практических приемов, приобретенных в ходе осуществления проекта приложения.

8.1.3.3 Подпроцессы менеджмента ONF

Все связанные с безопасностью приложений процессы должны быть частью ONF. Они также должны соответствовать СМИБ организации. В таблице 2 показано, как связанные с безопасностью приложений подпроцессы менеджмента ONF соответствуют четырем этапам процесса СМИБ.


Таблица 2 - Соответствие СМИБ подпроцессам менеджмента ONF, связанным с безопасностью приложений

Как показано в таблице 2, процесс менеджмента ONF можно разделить на следующие подпроцессы:

а) проектирование ONF: установление связанных с безопасностью приложений компонентов ONF, включая ASMP, библиотеку ASC и все связанные с ними процессы:

1) определение и документирование возможного контекста (регулятивного, технологического и бизнес-контекста), в котором будет использоваться приложение;

2) создание, документирование и поддержка репозитория спецификаций приложений:

a) анализ спецификаций для каждого нового приложения на этапе поставки;

b) анализ спецификаций существующих в организации приложений;

3) определение действующих субъектов и процессов:

a) анализ и документирование лиц и процессов, вовлеченных в полный жизненный цикл приложений;

b) определение (или разработка) и утверждение формальной методологии анализа риска на уровне приложений, основанной на ИСО/МЭК 27005;

4) анализ лучших практических приемов и стандартов, таких как ИСО/МЭК 12207, ИСО/МЭК 15288 и ИСО/МЭК 15026, и определение на основе этого анализа ASC;

a) создание и обновление ASC.

Создание или обновление ASC для учета конкретных требований безопасности происходит, когда это необходимо организации.

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

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

Пример 2 - ASC, необходимые для соблюдения процесса менеджмента идентификаторов приложений, должны создаваться или обновляться специалистом в сфере менеджмента идентификаторов;

b) валидация и интеграция ASC.

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

Ответственность за утверждение всех АSС несет группа ONF;

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

6) определение и реализация библиотеки ASC организации;

7) приобретение (или разработка), обновление и валидация необходимых организации ASC, интеграция их в библиотеку ASC;

8) анализ, адаптация и валидация обратной связи от проектов приложений;

b) реализация ONF: реализация ONF и информирование о ней;

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

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

2) требование проведения периодической оценки риска для всех используемых организацией приложений;

d) постоянное совершенствование ONF: поддержка и совершенствование всех компонентов ONF путем периодической проверки контекста, процессов, лиц и технологии в масштабах организации, обнаружение всех изменений с возможным влиянием на ASMP и интеграции их в ONF.

8.2 Оценка риска безопасности приложений

8.2.1 Оценка риска в сравнении с менеджментом риска

Оценка риска - это второй шаг описанного в ИСО/МЭК 27005 процесса менеджмента риска. Кроме того, оценка риска безопасности приложений является вторым шагом ASMP, применяющего процесс оценки риска на уровне приложений. Другие шаги менеджмента риска осуществляются посредством других шагов ASMP.

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

Оценка риска включает три действия: идентификацию риска, анализ риска и оценивание риска.

8.2.2 Анализ риска приложений

8.2.2.1 Высокоуровневый анализ риска приложений

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

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

8.2.2.2 Детальный анализ риска приложений

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

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

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

8.2.3 Оценивание риска

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

a) следует ли предпринимать действие;

b) приоритеты обработки риска, учитывающие оцененные уровни риска".

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

8.2.4 Целевой уровень доверия приложений

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

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

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

Целевой уровень доверия приложения должен быть одним из уровней доверия (или находиться в диапазоне), определенных в библиотеке ASC организации (см. 8.1.2.6), являющейся частью ONF.

Библиотека ASC (см. рисунок 5) может быть представлена в виде таблицы, а целевой уровень доверия приложения - в виде графы в этой таблице. Таким образом, выбор уровня доверия приводит к выбору всех ASC в этой графе.

8.2.5 Принятие риска владельцем приложений

Владелец приложения несет ответственность за принятие остаточных рисков, связанных с конкретным приложением.

Владелец приложения выполняет эту обязанность двумя способами:

a) утверждая целевой уровень доверия приложения на втором шаге ASMP;

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

После принятия риска владельцем приложения за достижение целевого уровня доверия приложения отвечает группа проекта посредством реализации соответствующих ASC на соответствующих этапах жизненного цикла приложения.

8.3 Нормативная структура приложений

8.3.1 Общая информация

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

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

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

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

Изменения ANF влияют на безопасность приложений. Эти изменения должны соответствующим образом утверждаться владельцем приложения.

ANF для конкретного проекта приложения содержит компоненты, рассмотренные ниже. На рисунке 10 показано графическое представление ANF.

Рисунок 10 - Нормативная структура приложений

Рисунок 10 - Нормативная структура приложений

8.3.2 Компоненты

8.3.2.1 Бизнес-контекст, связанный со средой приложения

Все процессы бизнеса, методики, стандарты и действующие субъекты, вовлеченные в проект приложения, включая внешние процессы бизнеса, необходимые для обеспечения адекватной целостности бизнеса в операционной среде, выводятся для приложения из бизнес-контекста ONF (см. 8.1.2.1) или детализируются в ней.

8.3.2.2 Регулятивный контекст, связанный со средой приложения

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

8.3.2.3 Технологический контекст, связанный со средой приложения

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

8.3.2.4 Спецификации приложения

Спецификации приложений принимают форму функциональных и нефункциональных требований и требований безопасности.

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

8.3.2.5 Действующие субъекты приложения: роли, обязанности и квалификация

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

8.3.2.6 Выбранные ASC для жизненного цикла приложения

Согласно 8.1.2.6, точные и подробные ASC для конкретного проекта приложения выбираются из библиотеки ASC организации в соответствии с приведенными ниже критериями:

a) целевой уровень доверия приложения;

b) требования организации к приложению;

c) определенный контекст и спецификации приложения.

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

ASC определяет и утверждает организация до разработки. Разработчикам больше не нужно проектировать их для каждого нового проекта приложения. Это обеспечивает уверенность в унифицированном подходе организации к рассмотрению вопроса требований безопасности приложений.

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

8.3.3 Процессы, связанные с безопасностью приложения

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

8.3.4 Жизненный цикл приложения

Компонент жизненного цикла приложения обозначает этапы и мероприятия, выбранные из ONF для определенного проекта приложения. Более конкретно, жизненный цикл приложений - это подмножество эталонной модели жизненного цикла безопасности приложений (см. 8.1.2.7), содержащейся в ONF.

Жизненный цикл приложений и стандартное содержание эталонной модели жизненного цикла безопасности приложений обсуждались в 8.1.2.7.

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

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