Информационная безопасность



страница1/7
Дата01.10.2018
Размер1.23 Mb.
  1   2   3   4   5   6   7



NIST Специальная публикация 800-64 Пересмотр 2

Рассмотрения безопасности в жизненном цикле разработки систем




Richard Kissel

Kevin Stine

Matthew Scholl

Hart Rossman

Jim Fahlsing

Jessica Gulick

ИНФОРМАЦИОННАЯ БЕЗОПАСНОСТЬ

Отдел компьютерной безопасности

Лаборатории информационных технологий

Национальный институт стандартов и технологий

Гейтерсбург, MD 20899-8930



Октябрь 2008




МИНИСТЕРСТВО ТОРГОВЛИ США

Carlos M.Gutierrez, Министр
НАЦИОНАЛЬНЫЙ ИНСТИТУТ СТАНДАРТОВ И ТЕХНОЛОГИЙ

Patrick D. Gallagher, Заместитель директора




Отчеты по технологиям компьютерных систем

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



Полномочия

Эта публикация была разработана NIST в соответствии с его обязанностями, установленными согласно Закону об управлении безопасностью федеральной информации (FISMA), Общественный закон (P.L). 107-347.

NIST ответственен за разработку стандартов информационной безопасности и руководств, включая минимальные требования для федеральных информационных систем, но такие стандарты и руководства не должны применяться к системам национальной безопасности. Это руководство непротиворечиво с требованиями Циркуляра A-130 Министерства управления и бюджета (OMB), Раздел 8b (3), Обеспечение безопасности информационных систем агентств, как указано в Циркуляре A-130, Приложение IV: Анализ ключевых разделов. Дополнительная информация предоставлена в Циркуляре A-130, Приложение III.

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

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


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


Благодарность

Авторы, Richard Kissel, Kevin Stine, и Matthew Scholl из NIST благодарят своих коллег, Hart Rossman, Jim Fahlsing и Jessica Gulick из Science Applications International Corporation (SAIC), которые помогали обновить этот документ, готовили предложения и рассматривали материалы. Кроме того, особая благодарность адресована авторам исходного документа, а так же нашим рецензентам Arnold Johnson, John Garguilo, Marianne Swanson и Elizabeth Lennonот из NIST, которые значительно способствовали разработке документа. NIST также с благодарностью подтверждает и ценит большое содействие людей из общественного и частного секторов, вдумчивые и конструктивные комментарии которых улучшили качество и полноценность этой публикации.



Оглавление

РЕЗЮМЕ ................................................. ....................................................................................1

ВВЕДЕНИЕ ......................................................... .........................................................................2

1.1 Назначение и область..............................................................................................................2

1.2 Аудитория ................................................................................................................................2

1.3 Значение для предназначения агентства, программ обеспечения безопасности и управления ИТ………………………………………………………….………………………………………………………………………………….2

1.4 Организация документа..........................................................................................................3

КРАТКИЙ ОБЗОР ОСНОВНЫХ ПРИНЦИПОВ ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ И ЖИЗНЕННОГО ЦИКЛА РАЗРАБОТКИ СИСТЕМ ….........................................................................4

2.1 Установление общего понимания..........................................................................................5

2.2 Рассмотрения унаследованной системы...............................................................................8

2.3 Ключевые роли и обязанности в SDLC....................................................................................8



ВКЛЮЧЕНИЕ БЕЗОПАСНОСТИ В SDLC........................................................................................11

3.1 ФАЗА SDLC: Инициирование.................................................................................................13

3.2 ФАЗА SDLC: Разработка/Приобретение...............................................................................21

3.3 ФАЗА SDLC: Реализация /Оценка..........................................................................................28

3.4 ФАЗА SDLC: Эксплуатация и поддержка...............................................................................32

3.5 ФАЗА SDLC: Ликвидация .......................................................................................................36



ДОПОЛНИТЕЛЬНЫЕ РАССМОТРЕНИЯ БЕЗОПАСНОСТИ ...........................................................40

4.1 Система приобретения и доверие к программному обеспечению..................................40

4.2 Сервис-ориентированная архитектура................................................................................41

4.3 Специальная аттестация модулей безопасности для повторного использования .........41

4.4 Меж-организационные решения .............................................................................................42

4.5 Продвижение технологий и основные миграции ..............................................................42

4.6 Разработка информационных центров или ИТ комплексов..............................................43

4.7 Виртуализация.......................................................................................................................44



ПРИЛОЖЕНИЕ A - ГЛОССАРИЙ................................................................................................ A-1

ПРИЛОЖЕНИЕ B - СОКРАЩЕНИЯ.............................................................................................B-1

ПРИЛОЖЕНИЕ C - ССЫЛКИ...................................................................................................... C-1

ПРИЛОЖЕНИЕ D - МАТРИЦА ССЫЛОК И ВЕБСАЙТЫ NIST...................................................... D-1

ПРИЛОЖЕНИЕ E - ДРУГИЕ МЕТОДОЛОГИИ SDLC ....................................................................E-1

ПРИЛОЖЕНИЕ F - РАССМОТРЕНИЯ ПЛАНИРОВАНИЯ ДОПОЛНИТЕЛЬНОГО ПРИОБРЕТЕНИЯ …………………………………………………………………………………………………………………………………………….….F-1

ПРИЛОЖЕНИЕ G - ДОПОЛНИТЕЛЬНЫЕ ГРАФИЧЕСКИЕ ПРЕДСТАВЛЕНИЯ БЕЗОПАСНОСТИ В SDLC………………………………………………………………………………………………………………………………………. G-1

ТАБЛИЦА РИСУНКОВ

Рисунок 2-1. Рассмотрения позиционирования безопасности .....................................................4

Рисунок 3-1. SDLC – Концептуальное представление....................................................................11

Рисунок 3-2. Связь рассмотрений безопасности в фазе инициирования ...................................13

Рисунок 3-3. Связь рассмотрений безопасности в фазе разработки/приобретения................. 21

Рисунок 3-4. Связь рассмотрений безопасности в фазе реализации/оценки............................ 28

Рисунок 3-5. Связь рассмотрений безопасности в фазе эксплуатации/поддержки.................. 32

Рисунок 3-6. Связь рассмотрений безопасности в фазе ликвидации..........................................36





РЕЗЮМЕ

Специальная Публикация (SP) 800-64, Рассмотрения Безопасности в Жизненном цикле разработки систем Национального института стандартов и технологий (NIST), была разработана, чтобы помочь агентствам федерального правительства в интегрировании важных этапов обеспечения безопасности информационных технологий (ИТ) в их установленный жизненный цикл разработки систем ИТ (SDLC). Это руководство применяется ко всем федеральным системам ИТ кроме систем национальной безопасности. Документ предназначен как ссылочный ресурс, а не как учебное руководство и должен использоваться совместно с другими публикациями NIST как обязательный в течение разработки систем.

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

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

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

Осознание потенциальных технических проблем вызванных обязательными мерами безопасности;

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

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

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

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

Наконец, SP 800-64 обеспечивает понимание проектов и инициатив в сфере ИТ, которые не очень ясно определены как основанные на SDLC разработки, такие как сервис-ориентированные архитектуры, межведомственные проекты и разработки ИТ комплексов.
ГЛАВА ОДИН

ВВЕДЕНИЕ

Рассмотрение безопасности в жизненном цикле разработки систем важно для реализации и интегрирования всеобъемлющей стратегии управления риском для всех активов информационных технологий в организации. Специальная Публикация (SP) 800-64 Национального института стандартов и технологий (NIST) предназначена, чтобы помочь агентствам федерального правительства интегрировать существенные работы по безопасности в свои установленные руководства по жизненному циклу разработки систем.



1.1 Назначение и область

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

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

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



1.2 Аудитория

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



1.3 Значение для предназначения агентства, программ обеспечения безопасности и управления ИТ

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

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

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

Осознание потенциальных технических проблем вызванных обязательными мерами безопасности;

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

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

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

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

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



1.4 Организация документа

Последующие главы этого руководства обсуждают следующее:

Глава 2, Краткий обзор информационной безопасности и жизненного цикла разработки систем, резюмирование отношений между SDLC и другими дисциплинами ИТ, установление общего понимания SDLC и обсуждение ролей и обязанностей вовлечённых в интегрирование информационной безопасности в SDLC.

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

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

Это руководство содержит семь приложений. Приложение A приводит глоссарий терминов. Приложение B приводит всесторонний список акронимов. Приложение C перечисляет ссылки, процитированные в этой публикации. Приложение D обеспечивает отображение соответствующих публикаций NIST к соответствующим работам по безопасности SDLC. Приложение E дает краткий обзор других методологий SDLC. Приложение F дополнительно обсуждает рассмотрения планирования для фазы разработки/приобретения SDLC. Приложение G обеспечивает дополнительное графическое представление интеграции безопасности в SDLC.



ГЛАВА ДВА

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


РИСУНОК 2-1. ПОЗИЦИОНИРОВАНИЕ РАССМОТРЕНИЙ БЕЗОПАСНОСТИ
Процессы и работы по безопасности информационных систем обеспечивают ценный вклад в управление IT-системами и их разработкой, позволяя выявлять, планировать и уменьшать риски. Подход к управлению рисками1 включает постоянно балансировать защиту информации и активов агентства со стоимостью мер безопасности и стратегий уменьшения всюду по полному жизненному циклу разработки информационных систем (см. рисунок 2-1). Самый эффективный способ реализовать управление рисками состоит в том, чтобы идентифицировать критические активы и деятельность, а так же уязвимости систем в агентстве. Риски являются общими и не связаны с организацией, источником дохода или топологией. Идентификация и проверка критических активов и операций и их взаимосвязи могут быть достигнуты посредством процесса планирования безопасности систем, атак же посредством компиляции информации от процессов Планирование капиталовложений и управление инвестициями (CPIC) и Архитектуры предприятия (EA), чтобы установить понимание жизненно важных операций для деятельности агентств, поддерживающих их активов и существующих взаимозависимостей и отношений. С идентифицированными критическими активами и операциями, организация может и должна выполнить анализ влияния на бизнес (BIA). Назначение BIA состоит в том, чтобы связать системы и активы с обеспечивающими их критическими сервисами и оценить последствия их нарушения. Идентифицируя эти системы, агентство может эффективно управлять безопасностью, устанавливая приоритеты. Это позиционирует службу безопасности на то, чтобы облегчить рентабельное выполнение программы ИТ, а так же ясно сформулировать ее влияние на деятельность и значение для агентства.

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

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

Есть много методологий SDLC, которые могут использоваться организацией, чтобы эффективно разработать информационную систему. Традиционный SDLC, линейная последовательная модель (также известная как метод водопада), предполагает, что система будет поставлена на заключительных этапах жизненного цикла её разработки. Другой метод SDLC использует модель прототипирования, которая часто используется, чтобы разработать понимание системных требований, фактически не разрабатывая полноценную автоматизированную систему. Более сложные системы могут потребовать нескольких моделей итерационной разработки. Более сложные модели были разработаны и успешно использовались, чтобы учесть развивающуюся сложность перспективных и иногда больших проектов информационных систем. Примерами таких более сложных моделей является модель быстрой разработки приложений (RAD), модель совместной разработки приложений (JAD), модель прототипирования и спиральная модель. Ожидаемый размер и сложность системы, график разработки и длина жизни системы будут влиять на выбор того, какую модель SDLC использовать. Во многих случаях, выбор модели SDLC будет определен политикой приобретения организации. Приложение E содержит краткий обзор других методологий SDLC.

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

2.1 Установление общего понимания

2.1.1 Политика и руководство SDLC агентства

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

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

Инициирование. Во время фазы инициирования выражается потребность в системе и документируется назначение системы.

Разработка/Приобретение. Во время этой фазы система проектируется, закупается, программируется, разрабатывается или иначе создаётся.

Реализация/Оценка. После системного приемного тестирования система устанавливается или развёртывается.

Эксплуатация/Поддержка. Во время этой фазы система выполняет свою работу. Система почти всегда модифицируется путем добавления аппаратного и программного обеспечения и многочисленными другими событиями.

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

Руководство SDLC обеспечивает полезность, документируя:

понимание главных работ и вех;

моменты принятия решений или контрольные результаты;

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

проектные достижения; и

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

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

2.1.2 Введение в интеграцию безопасности

Выполнение основанного на управлении рисками подхода для систем и проектов означает интегрировать безопасность в установленную агентством разработку систем и жизненные циклы CPIC. Интегрированный компонент безопасности (составленный из вех, поставок, контрольных результатов и взаимозависимостей), который конкретно определяет управление рисками (обсуждаемое в следующем разделе), даёт возможность планировать, приобретать, встраивать и развертывать безопасность, как неотъемлемую часть проекта или системы. Это также играет существенную роль в оценке и определении требований безопасности всюду по жизненному циклу. Полная и эффективная интеграция в SDLC облегчает профессионалам информационной безопасности быть партнерами CPIC, ИТ и EA представителей, чтобы способствовать эффективному управлению и надзору за рассмотрениями безопасности в жизненном цикле.

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


Совет по реализации

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



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

2.1.3 Процессы планирования капиталовложений и управления инвестициями

У каждого агентства есть установленный и задокументированный процесс CPIC в соответствии с Циркуляром OMB A-11. NIST SP 800-65, Интегрирование безопасность IT в процесс планирования капиталовложений и управления инвестициями, ясно формулирует интеграцию и значение безопасности. Это руководство стремится продолжать это обсуждение с фокусом на интеграцию безопасности в SDLC.

Ключевые концепции NIST SP 800-65, которые нужно рассмотреть, читая это руководство, включают:

Процесс CPIC определен Циркуляром OMB A-130 как " процесс управления постоянной идентификацией, выбором, контролем и оценкой инвестиций в информационные ресурсы. Процесс связывает формирование и выполнение бюджета, и фокусируется на предназначении агентства и достижении конкретных программных результатов." Интегрирование безопасности в этот процесс гарантирует, что информационные ресурсы спланированы и обеспечены в полном, упорядоченном способе, дающим возможность улучшения безопасности за счёт инвестиций в IT.

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

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

В соответствии с планированием капиталовложений OMB и руководствами NIST, агентства обязаны придерживаться лучших практик Управления государственной отчётности (GAO), трехфазной инвестиционной модели жизненного цикла для федеральных инвестиций в IT.

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



2.1.4 Архитектуры безопасности

Архитектуры безопасности должны соответствовать руководствам NIST, состоять из семейств мер безопасности, выделенных в NIST SP 800-53 в отношении защиты конфиденциальности, целостности и доступности федеральной информации и информационных систем. Всесторонняя архитектура безопасности фиксирует текущие сервисы безопасности, инструменты и опыт, очерчивает прогнозируемые потребности деятельности и требования, и ясно формулирует план реализации, согласованный со спецификой агентства и стратегическими планами. Обычно, архитектура безопасности увязана с интегрированным календарным планом задач, который идентифицирует ожидаемые результаты (индицирует и запускает для дальнейшего пересмотра/выравнивания), устанавливает проектные временные шкалы, обеспечивает оценки требований по ресурсам и идентифицирует ключевые проектные зависимости.



2.1.5 Роль в основах управления рисками NIST

NIST SP 800-64 дополняет Основы управления рисками, предоставляя типовой путеводитель по интеграции функциональности и доверия к безопасности в SDLC. Кроме того, эта публикация предоставляет большую детализацию по дополнительным работам, которые ценны для рассмотрения изменений, которые даёт специфика каждой системы и агентства. Эти дополнительные работы дополняют основы управления рисками. Более детализированное описание Основ управления рисками NIST представлено в Проекте NIST SP 800-39, Управление риском информационных систем: Организационная перспектива.



2.2 Рассмотрения унаследованных систем

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



Совет по реализации

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



2.3 Ключевые роли и обязанности в SDLC

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



ТАБЛИЦА 2-1. КЛЮЧЕВЫЕ РОЛИ И ОБЯЗАННОСТИ БЕЗОПАСНОСТИ В SDLC

Роль

Обязанности

Санкционирующее должностное лицо

Authorizing Official (AO)

AO - высшее должностное лицо или руководитель с полномочием по формальному принятию на себя ответственности за эксплуатацию информационной системы на допустимом уровне риска в отношении деятельности организации и активов, людей, других организаций и Нации. Чтобы сделать это, AO полагается прежде всего на: (i) завершенный план обеспечения безопасности; (ii) отчёт по оценке безопасности; и (iii) план действий и вех по сокращению или устранению уязвимостей информационной системы.

Директор по информации

Chief Information Officer (CIO)

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

Менеджер по управлению конфигурацией (УК)

Configuration Management (CM) Manager

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

Контрактный специалист

Contracting Officer

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

Технический представитель контрактного специалиста

Contracting Officer’s Technical Representative

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

Сотрудник безопасности информационной системы

Information System Security Officer

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

Совет по инвестициям в информационные технологии (или подобный)

Information Technology Investment Board

Совет по инвестициям в информационные технологии (ИТ), или его эквивалент, ответственнен за управление процессом CPIC, определенным законом Клингер-Коэна 1996 (Раздел 5).

Юристконсульт/Контрактный поверенный

Legal Advisor/Contract Attorney

Юрисконсульт ответственен за консультирование команды по юридическим вопросам во время процесса приобретения.

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

Privacy Officer

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

Диспетчер программ / Чиновник (Владелец информации)

Program Manager / Official (Information Owner)



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

Директор по испытаниям

QA/Test Director

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

Высший сотрудник по информационной безопасности агентства

Senior Agency Information Security Officer (SAISO)

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

Разработчик программного обеспечения

Software Developer

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

Системный архитектор

System Architect

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

Владелец системы

System Owner

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

Другие участники

Other Participants

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





Поделитесь с Вашими друзьями:
  1   2   3   4   5   6   7


База данных защищена авторским правом ©vossta.ru 2019
обратиться к администрации

    Главная страница