Приложение А (справочное). Пример сопоставления существующего процесса разработки с ИСО/МЭК 27034

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

Пример
сопоставления существующего процесса разработки с ИСО/МЭК 27034

А.1 Общая информация

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

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

В данном приложении в поддержку ИСО/МЭК 27034 приведены:

a) краткий обзор жизненного цикла разработки безопасного программного обеспечения;

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

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

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

3) в общих чертах описываются роли и обязанности различных лиц, вовлеченных в процесс разработки приложения;

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

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

6) дается наглядная иллюстрация эталонной модели жизненного цикла безопасности приложений;

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

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

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

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

Использование жизненного цикла разработки безопасного программного средства (Security Development Lifecycle - SDL) в этом поясняющем контексте не означает одобрение SDL Международной организацией по стандартизации (ИСО).

А.2 О жизненном цикле разработки безопасного программного средства

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

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

Рисунок А.1 - Жизненный цикл разработки безопасного программного средства

А.3 Сопоставление SDL с нормативной структурой организации

Сопоставление SDL с нормативной структурой организации показано на рисунке А.2. Последующее обсуждение SDL будет придерживаться этого формата.

Рисунок А.2 - Сопоставление SDL с нормативной структурой организации

Список сокращений:
PG	product group (группа продуктов);
LCA	legal and corporate affairs (правовые и корпоративные вопросы);
LOB Арр	proprietary line of applications used in support of business and technological contexts (характерные особенности приложений, используемые в поддержку бизнес-контекста и технологического контекста);
SDL	security development lifecycle (жизненный цикл разработки безопасного программного средства);
HR	human resources (кадровый отдел);
FSR	final security review (окончательная проверка безопасности).

А.4 Бизнес-контекст

8.1.2.1 Бизнес-контекст перечисляет и документирует все принятые организацией стандарты и лучшие практические приемы, которые могут оказывать влияние на проекты приложений. Бизнес-контекст включает: a) процессы менеджмента проекта, разработки, анализа риска, операционные процессы, процессы аудита и контроля; b) политику безопасности организации; c) практические приемы в сфере бизнеса; d) используемую организацией методику разработки; e) лучшие практические приемы для всех языков программирования, используемых организацией и перечисленных в технологическом контексте; f) формальный процесс менеджмента проекта организации; g) применение организацией других необходимых международных стандартов ИСО/МЭК, таких как ИСО/МЭК 27001, ИСО/МЭК 27002 и ИСО/МЭК 15288.

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

Приватность и безопасность при разработке программных продуктов является общекорпоративным предписанием согласно жизненному циклу разработки безопасного программного средства (SDL). ^i 1) SDL также требует определения лиц (руководящих обеспечением безопасности и приватности), процессов и мер и средств контроля и управления безопасностью приложения, которые будут использоваться для отслеживания продвижения к целям обеспечения безопасности и приватности".

------------------------------

¹⁾_{Таким образом, (здесь и далее по тексту приложения А) нумеруется ссылка, приведенная в конце приложения А.}

------------------------------

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

А.5 Регулятивный контекст

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

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

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

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

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

8.1.2.3 Репозиторий спецификаций приложений перечисляет и документирует общие функциональные требования ИТ организации и соответствующие, заранее утвержденные решения. Спецификации приложений должны включать: a) спецификации о том, каким образом приложения будут вычислять, хранить и передавать информацию; b) обычные параметры приложений, функциональные возможности, услуги и требования; c) исходный код, двоичный код, библиотеки и продукты или услуги, которые используются приложениями или на которых основаны приложения. Дополнительные спецификации могут включать подробное описание взаимодействия приложений с: a) другими системами; b) рабочей инфраструктурой, от которой они зависят; c) перечнем мер и средств контроля и управления безопасностью приложений в рабочей среде.

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

А.7 Технологический контекст

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

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

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

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

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

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

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

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

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

ii) эксперта, т.е. обладать поддающейся проверке компетентностью в вопросах безопасности;

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

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

ii) эксперта, т.е. обладать поддающейся проверке компетентностью в вопросах приватности.

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

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

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

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

А.9 Библиотека ASC организации

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

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

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

Рисунок А.3 - Пример древовидной схемы ASC

А.9.1 Обучение

1) Требования обучения: Все члены групп разработки программных средств должны пройти соответствующее обучение, чтобы быть в курсе основ обеспечения безопасности и последних тенденций в сфере безопасности и приватности. Лица с техническими рабочими ролями (разработчики, специалисты по тестированию, руководители программ), непосредственно участвующие в разработке программ, должны ежегодно проходить, по крайней мере, один курс обучения по безопасности. Базовое обучение по безопасности программных средств должно охватывать основополагающие концепции, такие как безопасное проектирование, моделирование угроз, определение видов атак, безопасное кодирование, тестирование безопасности и приватности. ^iv

А.9.2 Требования

2) Требования безопасности: Необходимость рассмотрения вопросов безопасности и приватности на базовом уровне является основополагающим аспектом разработки систем. Оптимальным моментом определения требований надежного проектирования программного средства является начальная стадия планирования его версии. Это дает возможность занимающимся разработкой группам идентифицировать ключевые этапы и результаты, а также позволяет осуществлять интеграцию безопасности и приватности таким образом, чтобы она сводила к минимуму любые нарушения планов и временных графиков. Анализ требований безопасности и приватности осуществляется в начале проекта и состоит из различных обязательных действий, включая (как минимум): определение применимости SDL; определение лиц, отвечающих за надзор за безопасностью и приватностью (см. 8.1.2.5 - Роли, обязанности и квалификация); определение минимальных требований безопасности; специфицирование и развертывание системы отслеживания уязвимостей/рабочих вопросов; ^v

3) Границы качества/порог ошибок: Границы качества/пороги ошибок используются для установления минимально допустимых уровней качества обеспечения безопасности и приватности. ^vi vii Определение этих критериев в самом начале проекта способствует пониманию рисков, связанных с проблемами безопасности, и дает возможность группам проекта идентифицировать и исправлять ошибки во время разработки. Группа проекта должна обсуждать границы качества для каждого этапа разработки, они должны быть утверждены куратором по безопасности с разъяснениями, соответствующими проекту, и более строгими требованиями безопасности, определенными куратором по обеспечению безопасности (в соответствующих случаях). Группа проекта должна также продемонстрировать соответствие согласованным границам качества для соблюдения требований проверки при окончательной проверке безопасности. Порог ошибок - это границы качества, относящиеся ко всему проекту разработки программных средств. Он используется для определения границ серьезности ошибок, влияющих на безопасность (например, нет известных ошибок в приложении с "критическим" показателем во время выпуска). Порог ошибок никогда не должен снижаться, даже если приближается дата выпуска проекта.

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

4) Оценка риска безопасности и приватности: Оценка риска безопасности и приватности (Security and privacy risk assessments - SRA) - это обязательные процессы идентификации функциональных аспектов программных средств, которые могут требовать углубленной проверки. Учитывая, что характеристики программы и намеченные функциональные возможности могут отличаться в разных проектах, разумно начинать с простых оценок риска и расширять их по мере необходимости для соответствия масштабу проекта. Такие оценки должны включать следующую информацию:

a) (безопасность) какие части проекта потребуют модели угроз (см. ASC 7) ¹⁾, ниже) перед выпуском?

------------------------------

¹⁾_{См. перечисление 7) в А.9.3.}

------------------------------

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

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

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

e) (безопасность) разъяснение конкретной сферы требований "случайное тестирование" ²⁾ (см. ASC 12) ³⁾, ниже);

------------------------------

²⁾ " _{Случайное тестирование" (fuzz testing) - тестирование, использующее случайный набор входных данных.}

³⁾_{См. перечисление 12) в А.9.5.}

------------------------------

f) (приватность) определение показателя влияния на приватность: ^viii ix

i) Р1 - высокий риск приватности: Функция, продукт или услуга хранят или передают PII ⁴⁾, меняют установки или ассоциации типа файла или инсталлируют программные средства;

------------------------------

⁴⁾_{PII (Personally Identifiable Information) - персональная идентификационная информация.}

------------------------------

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

iii) Р3 - низкий риск приватности: В функции, продукте или услуге отсутствует вид действия, оказывающий влияние на приватность. Не передаются анонимные или персональные данные, не хранится в машине персональная идентификационная информация, не меняются никакие установки от имени пользователя, не инсталлируются программные средства.

А.9.3 Проектирование

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

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

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

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

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

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

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

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

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

А.9.4 Реализация

8) Использование утвержденных инструментальных средств: Все группы разработки должны определять и публиковать список утвержденных инструментальных средств (и конкретные функциональные возможности безопасности, такие как опции компилятора/компоновщика, предупреждающие сообщения и т.д.) для использования в программных проектах. ^xii xiii Этот список должен согласовываться и утверждаться куратором по обеспечению безопасности группы проекта. Как правило, группы разработки должны стараться использовать новейшую версию утвержденных инструментальных средств, чтобы можно было использовать новые функциональные возможности безопасности;

9) Исключение ненадежных функций из числа используемых: Многие обычно используемые функции и интерфейсы прикладного программирования (Application Programming Interface - API) не являются безопасными в отношении существующей среды угроз. Группы проекта должны анализировать все функции и API, которые будут использоваться совместно с проектом разработки программных средств, и запрещать те из них, которые определены как ненадежные. ^xiv После определения списка запрещенных элементов группы проекта должны использовать заголовочные файлы, обновленные компиляторы или инструментальные средства сканирования кода программы для осуществления проверки кода (включая унаследованный код в соответствующих случаях) на предмет существования запрещенных функций и замены их более надежными альтернативными вариантами;

10) Статический анализ: Группы проекта должны осуществлять статический анализ исходного кода программы. Статический анализ исходного кода программы обеспечивает масштабируемое решение для проверки безопасности кода и может использоваться для обеспечения уверенности в соблюдении политик безопасного программирования, устанавливаемых руководителем группы по вопросам безопасности и куратором по обеспечению безопасности. Для проведения тщательной проверки безопасности одного статического анализа кода обычно недостаточно, отвечающая за безопасность группа и кураторы по обеспечению безопасности должны осознавать сильные и слабые стороны инструментальных средств статического анализа и быть готовыми к дополнительным задачам проверки кода другими инструментальными средствами или ручными проверками при необходимости. Облегченный статический анализ происходит во время SDL в момент регистрации кода путем использования функции/analyze Visual Studio. ^xv Другие задачи статического анализа осуществляются по мере необходимости.

А.9.5 Верификация

11) Динамический анализ программы: Верификация программ во время прогона необходима для обеспечения уверенности в том, что функциональные возможности программы действуют, как было спроектировано. Динамический анализ программы должен специфицировать инструментальные средства для мониторинга поведения приложения при повреждении памяти, проблемах с привилегиями пользователей и других критических вопросах безопасности. Процесс SDL использует специальные инструментальные средства, такие как AppVerifier, а также такие методы, как "случайное" тестирование, для достижения желаемых уровней охвата тестирования безопасности; ^xvi

12) "Случайное" тестирование: "Случайное" тестирование используется, чтобы вызвать сбой программы путем преднамеренного введения в приложение неправильных или случайных данных. SDL определяет, что "случайное" тестирование должно проводиться на различных интерфейсах программы. Выполнение "случайных" тестов основано на намеченном использовании приложения, а также на функциональных и технических спецификациях приложения. Куратор по обеспечению безопасности может требовать дополнительного "случайного" тестирования или увеличения охвата и длительности тестирования на основе намеченного поведения приложения; ^xvii

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

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

А.9.6 Выпуск

15) План реагирования на инциденты: Каждая версия программного продукта с учетом требований SDL должна быть охвачена планом реагирования на инциденты. ^xviii Программы, не содержащие известные уязвимости на момент выпуска, также могут подвергаться новым угрозам, возникающим с течением времени. План реагирования на инциденты должен как минимум включать следующее:

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

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

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

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

16) Окончательная проверка безопасности: Окончательная проверка безопасности (Final Security Review - FSR) - это продуманное изучение всех мероприятий по обеспечению безопасности, реализованных для прикладных программных средств до их выпуска. FSR проводится куратором по обеспечению безопасности при поддержке штатного коллектива разработчиков и руководящими лицами групп по вопросам приватности. FSR - это не проведение "проникновения и установления патчей" и не возможность проведения мероприятий по обеспечению безопасности, которые ранее игнорировались или были забыты. FSR обычно включает изучение моделей угроз, запросы исключительных ситуаций, выходные данные инструментальных средств и функционирования относительно ранее определенных границ качества/порога ошибок. ^xix FSR может приводить к одному из следующих трех результатов:

a) FSR пройдена - все проблемы безопасности и приватности, идентифицированные в ходе FSR, решены или уменьшены;

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

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

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

17) Выпуск/Архив: Выпуск программного средства в производство (RTM - Read The Manual) или в веб-сеть (RTW - Ready-To-Wear) обуславливает завершение процесса SDL. Назначенный куратор по обеспечению безопасности должен подтвердить, что группа проекта удовлетворила требования безопасности в отношении выпускаемого средства. Аналогичным образом для всех продуктов, имеющих, по крайней мере, один компонент с высоким риском приватности Р1, куратор по обеспечению приватности должен подтвердить до отправки программного продукта, что группа проекта удовлетворила требования приватности.

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

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

8.5.1 Цель пятого шага ASMP состоит в верификации и формальном фиксировании подтверждающих свидетельств достижения и поддержания конкретным приложением целевого уровня доверия приложения. Данный шаг ASMP может выполняться в любое время в течение жизненного цикла приложения. В зависимости от целевого уровня доверия приложения этот шаг может быть однократным, периодическим или обуславливаемым событиями. Пример 1 - Организация может периодически выполнять этот шаг для мониторинга степени обеспечения безопасности на этапе реализации приложения. Пример 2 - Организация может выполнять этот шаг для демонстрации фактического уровня доверия приложения, прежде чем будет утверждено его развертывание. Пример 3 - Организация может выполнять этот шаг на этапе эксплуатации жизненного цикла приложения как часть ежегодно проводимого организацией аудита безопасности. В рамках этого шага внутренняя или внешняя группа, занимающаяся верификацией (в зависимости от политик организации, содержащихся в ONF), проверяет, чтобы все верификационные измерения, представленные всеми ASC в ANF для конкретного приложения, были выполнены и результаты верифицированы. Целью данного шага является демонстрация в определенное время фактического уровня доверия приложения. Организация может объявить приложение "безопасным", когда его фактический уровень доверия равен его целевому уровню доверия.

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

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

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

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

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

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

Рисунок A.4 - Пример применения бизнес-приложения для аудита безопасности приложений

А.11 Модель жизненного цикла приложений

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

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

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

Рисунок А.5 - Иллюстрация процесса SDL

А.12 Сопоставление SDL с эталонной моделью жизненного цикла безопасности приложений

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

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

На рисунке А.7 показано более детальное сопоставление этапов SDL с этапами эталонной модели жизненного цикла безопасности приложений.

Рисунок А.7 - Детальное сопоставление этапов SDL с этапами эталонной модели жизненного цикла безопасности приложений

Ссылки в Приложении А

------------------------------

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

ⁱ_{http://msdn.microsoft.com/en-us/library/cc307748.aspx}

ⁱⁱ_{http://msdn.microsoft.com/en-us/library/cc307412.aspx}

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

ⁱⁱⁱ_{http://msdn.microsoft.com/en-us/library/cc307407.aspx}

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

Обучение

^iv_{http://msdn.microsoft.com/en-us/library/cc307407.aspx}

Требования

^v_{http://msdn.microsoft.com/en-us/library/cc307412.aspx}

^vi_{http://msdn.microsoft.com/en-us/library/cc307404.aspx (Безопасность)}

^vii_{http://msdn.microsoft.com/en-us/library/cc307403.aspx (Приватность)}

^viii_{http://msdn.microsoft.com/en-us/library/cc307393.aspx}

^ix_{http://www.microsoft.com/downloads/details.aspx?FamilyID=c48cf80f-6e87-48f5-83ec-a18d1ad2fc1f&displaylang=en}

Проектирование

^x_{http://msdn.microsoft.com/en-us/library/cc307414.aspx}

^xi_{http://msdn.microsoft.com/en-us/library/cc307415.aspx}

Реализация

^xii_{http://msdn.microsoft.com/en-us/library/cc307417.aspx}

^xiii_{http://msdn.microsoft.com/en-us/library/cc307395.aspx}

^xiv_{http://msdn.microsoft.com/en-us/library/bb288454.aspx}

^xv_{http://msdn.microsoft.com/en-us/library/cc307395.aspx}

^xvi_{http://msdn.microsoft.com/en-us/library/cc307418.aspx}

^xvii_{http://msdn.microsoft.com/en-us/library/cc307418.aspx}

^xviii_{http://msdn.microsoft.com/en-us/library/cc307408.aspx}

^xix_{http://msdn.microsoft.com/en-us/library/cc307409.aspx}

------------------------------