ГОСТ Р ИСО/МЭК 21827-2010 Информационная технология (ИТ). Методы и средства обеспечения безопасности. Проектирование систем безопасности. Модель зрелости процесса.
ГОСТ Р ИСО/МЭК 21827-2010
НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
Информационная технология
МЕТОДЫ И СРЕДСТВА ОБЕСПЕЧЕНИЯ БЕЗОПАСНОСТИ
Проектирование систем безопасности. Модель зрелости процесса
Information technology. Security techniques. Systems security engineering. Capability maturity model
ОКС 35.040
Дата введения 2011-09-01
Предисловие
1 ПОДГОТОВЛЕН Федеральным государственным учреждением "Государственный научно-исследовательский испытательный институт проблем технической защиты информации Федеральной службы по техническому и экспортному контролю" (ФГУ "ГНИИИ ПТЗИ ФСТЭК России")
2 ВНЕСЕН Техническим комитетом по стандартизации N 362 "Защита информации"
3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 30 сентября 2010 г. N 291-ст
4 ВВЕДЕН ВПЕРВЫЕ
5 Настоящий стандарт идентичен международному стандарту ИСО/МЭК 21827:2008* "Информационная технология. Методы и средства обеспечения безопасности. Проектирование систем защиты. Модель зрелости возможностей (SSE-CMM)" [ISO/IEC 21827:2008 "Information technology - Security techniques - Systems Security Engineering - Capability Maturity Model (SSE-CMM)"].
При применении настоящего стандарта рекомендуется использовать вместо ссылочных международных стандартов соответствующие им национальные стандарты Российской Федерации, сведения о которых приведены в дополнительном приложении ДА.
Правила применения настоящего стандарта установлены в ГОСТ Р 1.0-2012 (раздел 8). Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе "Национальные стандарты", а официальный текст изменений и поправок - в ежемесячном информационном указателе "Национальные стандарты". В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске информационного указателя "Национальные стандарты". Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования - на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (gost.ru)
0 Введение
0.1 Общие положения
Многие организации используют проектирование безопасности в разработке компьютерных программ, таких как операционные системы, а также функций обеспечения выполнения требований безопасности и управления безопасности, ПО, ПО для обмена данными или прикладных программ.
Следовательно, разработчики продукта, системные интеграторы и даже специалисты в области безопасности нуждаются в соответствующих методах и практических приемах. Некоторые из этих организаций имеют дело с высокоуровневыми задачами (например, функциональным использованием или системной архитектурой), другие сосредоточены на низкоуровневых задачах (например, проектировании или выборе механизма), третьи занимаются и тем, и другим. Организации могут специализироваться на определенной технологии или конкретной области деятельности (например, в области океанологии).
Модель SSE-CMM® предназначена для всех подобных организаций и случаев применения. Применение модели SSE-CMM® не подразумевает, что то или иное направление деятельности лучше другого или требуется какое-либо конкретное направление деятельности. Использование модели SSE-CMM® не должно отрицательно воздействовать на основное направление деловой деятельности конкретной организации.
Некоторые способы проектирования безопасности применяются на основе направления деловой деятельности организации. Кроме того, организации может потребоваться рассмотрение взаимосвязей между различными практическими приемами в границах модели с целью определения их применимости. Приведенные ниже примеры демонстрируют способы, какими многие организации могут применять модель SSE-CMM® для разработки программного обеспечения, систем, оборудования или эксплуатации.
Настоящий стандарт связан со стандартами серии ИСО/МЭК 15504, в частности с ИСО/МЭК 15504-2, поскольку они оба касаются технологического прогресса и оценки развития функциональных возможностей. Однако ИСО/МЭК 15504 сосредоточен конкретно на процессах создания и эксплуатации ПО, тогда как модель SSE-CMM предназначена для обеспечения безопасности.
Настоящий стандарт особенно тесно связан с новыми версиями ИСО/МЭК 15504, в частности с ИСО/МЭК 15504-2:2004, и согласуется с его принципами и требованиями.
Провайдеры услуг, связанных с безопасностью
Для определения возможностей технологического процесса (далее просто процесса) организации, проводящей оценки рисков, применяются несколько групп практических приемов. Для разработки или интеграции любой системы может потребоваться оценка способности организации определять и анализировать уязвимости системы безопасности, а также оценка эксплуатационных воздействий. Для эксплуатации любой системы может потребоваться оценка способности организации осуществлять мониторинг состояния безопасности системы, идентификацию, анализ уязвимостей и угроз безопасности, а также оценка воздействий, возникающих в процессе эксплуатации системы.
Разработчики мер противодействия
Когда группа разработчиков занимается разработкой мер противодействия угрозам безопасности, возможности технологического процесса организации характеризуются комбинацией практических приемов модели SSE-CMM®. Модель содержит практические приемы определения и анализа уязвимостей безопасности, оценки функциональных воздействий и предоставления входных данных и руководств другим задействованным группам специалистов (таким, как группа специалистов по программному обеспечению). Группа, предоставляющая услугу по разработке мер противодействия, должна знать взаимосвязи между этими практическими приемами.
Разработчики продукта
Модель SSE-CMM® содержит практические приемы, направленные на обеспечение понимания потребностей заказчика в области безопасности. Для их определения требуется взаимодействие с заказчиком. В случае с продуктом "заказчик" является общим понятием, поскольку продукт разрабатывается априори независимо от потребностей конкретного заказчика. Если потребуется, в качестве гипотетического заказчика может использоваться группа маркетинга продукции.
Специалисты - практики по проектированию безопасности признают, что методы ее разработки столь же разнообразны, как и сами продукты. Однако существуют несколько проблем, связанных с продукцией и проектами, о которых известно, что они оказывают воздействие на то, как продукты проектируются, изготавливаются, доставляются и обслуживаются. Особое значение для модели SSE-CMM® имеют:
- тип клиентской базы (продукты, системы или услуги);
- требования доверия (высокие в сравнении с низкими);
- поддержка как разрабатывающих, так и эксплуатационных организаций.
Ниже обсуждаются отличия между двумя разными клиентскими базами, различные степени требований доверия и воздействия каждого из этих различий в модели SSE-CMM®. Они представлены в качестве примера того, как организация или отрасль промышленности может определить, соответствует ли SSE-CMM® условиям конкретной окружающей среды.
Специфика отраслей промышленности
Каждая отрасль промышленности имеет свою особую культуру, терминологию и стиль общения. Минимизируя различия между должностями и последствия несовершенства структуры организации, ожидается, что концепции SSE-CMM® могут быть легко преобразованы любыми отраслями промышленности для своих нужд и внедрены в информационную систему.
0.2 Как следует использовать SSE-CMM®
Модель SSE-CMM® и метод ее применения (то есть оценочный метод) предназначены для использования в качестве:
- инструмента проектных организаций для оценки практических приемов проектирования безопасности и определения улучшений;
- метода, посредством которого организации, оценивающие проектирование безопасности, такие как органы сертификации и экспертные организации по оценке, могут упрочить доверие к ее потенциальным возможностям в качестве вклада в формирование доверия к безопасности продукта или системы;
- стандартного механизма оценки клиентами возможностей проектирования безопасности провайдером.
Область оценки должна определяться оценивающей организацией и, если это необходимо, обсуждаться с экспертом по оценке.
Методы оценки могут использоваться организацией при применении модели в целях самосовершенствования и выборе поставщиков, если пользователи модели и оценочных методов в достаточной мере осведомлены о надлежащем применении модели и присущих ей ограничениях. Дополнительная информация по использованию оценки технологических процессов содержится в ИСО/МЭК 15504-4:2004 "Информационная технология - Оценка технологических процессов - Часть 4: Руководство по применению для усовершенствования процессов и определения функциональных возможностей процессов".
0.3 Преимущества применения SSE-CMM®
Общей тенденцией обеспечения безопасности является переход от защиты правительственной информации к более широкому спектру задач, включая защиту финансовых операций, контрактов, персональных данных и Интернета. Эта тенденция привела к соответствующему распространению продукции, систем и услуг, сохраняющих и защищающих информацию. Продукция и системы обеспечения безопасности обычно поступают на рынок двумя путями: через длительное и дорогостоящее оценивание и без него. В первом случае надежная продукция часто попадает на рынок уже после снабжения ее системами безопасности, когда текущие угрозы для нее уже не страшны. Во втором случае приобретающая сторона и пользователи должны полагаться исключительно на утверждения разработчика или оператора о безопасности продукта или системы. Более того, услуги по проектированию безопасности по сложившейся традиции часто предоставлялись на основе принципа "пусть покупатель будет бдителен".
Данная ситуация требует от организации более продуманного проектирования безопасности. В частности, для производства и эксплуатации систем безопасности и надежной продукции необходимы следующие качества:
- непрерывность - знания, полученные в ходе предшествующей деятельности, используются в последующей деятельности;
- повторяемость - способ обеспечения повторения в проектах успешных работ;
- результативность - способ оказания помощи как разработчикам, так и оценщикам в повышении эффективности их труда;
- доверие - обеспечение уверенности в рассмотрении потребностей в безопасности.
Для выполнения этих требований необходим механизм, направляющий организации на понимание и усовершенствование своих действий по проектированию безопасности. Учитывая эти запросы, модель SSE-CMM® разработана с целью развития существующей практики проектирования безопасности для повышения качества и доступности защищенных систем, надежной продукции и услуг по проектированию безопасности, а также снижения затрат на их поставку.
В частности, предполагается получение следующих преимуществ.
Для проектных организаций.
Проектные организации включают в себя системных интеграторов, разработчиков прикладных программ, продавцов продукции и провайдеров услуг. Преимуществами применения модели SSE-CMM® в этих организациях являются:
- экономия средств вследствие уменьшения числа исправлений в ходе повторяющихся прогнозируемых процессов и практик;
- уверенность в надлежащем осуществлении функциональных возможностей, особенно при выборах источника;
- направленность на повышение компетентности (зрелости) организации.
Для приобретающих организаций.
Приобретающие стороны включают в себя организации, приобретающие системы, продукцию и услуги у внешних/внутренних источников, а также конечных пользователей. Для этих организаций преимущества от применения модели SSE-CMM® состоят в:
- снижении рисков (для функционирования, стоимости, плана) выбора неквалифицированного участника торгов;
- уменьшении числа претензий вследствие единообразия оценок, основанных на промышленном стандарте;
- прогнозируемости уровня доверия к продукту или услуге с высокой повторяемостью.
Для оценивающих организаций.
Оценивающие организации включают в себя органы сертификации и аккредитации систем, органы оценки и органы по аттестации. Для этих организаций преимущества от применения SSE-CMM® состоят в:
- возможности повторного использования результатов оценки процесса независимо от изменений системы или продукта;
- доверии к проектированию безопасности и его интеграции в другие дисциплины;
- доверии к доказательству, основанному на потенциальных возможностях и уменьшающему объем работ, связанных с оцениванием безопасности.
1 Область применения
Настоящий стандарт содержит подробное описание модели проектирования систем безопасности - зрелости функциональных возможностей (SSE-CMM®). SSE-CMM® является эталонной моделью процесса, сосредоточенной на требованиях по реализации безопасности в системе или серии взаимосвязанных систем, которые являются доменом безопасности информационных технологий (БИТ). В границах домена БИТ сосредоточена на процессах, используемых для обеспечения БИТ и, более конкретно, на зрелости этих процессов. Модель SSE-CMM® не предполагает навязывание конкретной организации заданного процесса, не говоря об определенной методологии. Скорее имеется в виду, что организации используют модель SSE-CMM®, если в них не применяются процессы, основанные на каком-либо другом руководстве по БИТ. Область применения настоящего стандарта охватывает:
- действия по проектированию безопасности для защищенного продукта или выверенной системы, включающие полный жизненный цикл, состоящий из определения понятия, анализа требований, проектирования, разработки, интеграции, установки, эксплуатации, обслуживания и вывода из эксплуатации;
- требования к разработчикам продукта, разработчикам и интеграторам безопасных систем, организациям, предоставляющим услуги по обеспечению компьютерной безопасности и проектированию безопасности;
- организации по проектированию безопасности всех типов и масштабов, от коммерческих до правительственных и академических.
Использование SSE-CMM® для оценки и улучшения возможностей проектирования безопасности не означает, что его следует осуществлять без применения других технических дисциплин. Наоборот, модель SSE-CMM® способствует интеграции с учетом того, что обеспечение безопасности распространяется на все технические дисциплины (например, системы, программное обеспечение и аппаратные средства), и определяет компоненты модели для решения таких задач. Общий признак "координация практических приемов" признает необходимость интегрирования безопасности во все дисциплины и группы, участвующие в проекте, или во всю организацию. Аналогично в области процесса "координация безопасности" приводится определение цели и описываются механизмы, предназначенные для использования при координировании действий по проектированию безопасности.
2 Нормативные ссылки
В настоящем стандарте использована ссылка на международный стандарт ИСО/МЭК 15504-2:2003 Информационная технология. Оценка процесса. Часть 2. Проведение оценки (ISO/IEC 15504-2, Information technology - Process assessment - Part 2: Performing an assessment).
3 Термины и определения
В настоящем стандарте применены следующие термины с соответствующими определениями:
3.1 учетность (подотчетность, отслеживаемость) (accountability): Свойство, обеспечивающее однозначное отслеживание собственных действий любого логического объекта.
[ИСО/МЭК 7498-2:1989]
3.2 аккредитация (accreditation): Формальное заявление назначенного утверждающего органа о принятии системы для эксплуатации в определенном режиме безопасности с использованием заданного набора мер безопасности.
Примечание - Данное определение в основном применяется в области безопасности в целом; в ИСО наиболее широко применяемым определением является следующее: процедура, посредством которой официальный орган формально признает компетентность организации или лица выполнять определенные задачи.
[ИСО/МЭК Руководство 2]
3.3 оценка (assessment): Верификация продукта, системы или услуги на соответствие требованиям стандарта, используя метод оценки, для установления соответствия и определения степени доверия.
Примечание - Адаптировано с ИСО/МЭК ТО 15443-1:2005.
3.4 актив (asset): Всё, что имеет ценность для организации.
[ИСО/МЭК ТО 13335-1:1996]
3.5 доверие (assurance): Основание для создания уверенности в том, что продукт отвечает своим целям безопасности.
Примечания
1 Адаптировано с ИСО/МЭК 15408-1:2005.
2 Данное определение в основном применяется в области безопасности в целом; в ИСО наиболее широко применяемым определением является следующее: "деятельность, приводящая в результате к утверждению, которое дает уверенность в том, что продукт, процесс или услуга соответствуют установленным требованиям".
[ИСО/МЭК Руководство 2].
3.6 аргумент доверия (assurance argument): Совокупность структурированных заявлений о доверии, подтвержденных доказательствами и аргументацией, четко демонстрирующих, каким образом были удовлетворены потребности в доверии.
3.7 заявление о доверии (assurance claim): Утверждение или поддержка утверждения того, что система удовлетворяет требованиям безопасности.
Примечание - В заявлениях учитываются как прямые угрозы (например, защищенность данных системы от атак посторонних лиц), так и косвенные (например, наличие у кода системы минимума дефектов).
3.8 свидетельство доверия (assurance evidence): Данные, на которых может базироваться обоснование заявления о доверии или заключение о нем.
Примечание - Свидетельство может состоять из наблюдений, результатов тестирования, результатов анализа и оценок.
3.9 аутентичность (authenticity): Свойство, гарантирующее, что субъект или ресурс идентичны заявленным.
Примечания
1 Аутентичность применяется к таким логическим объектам, как пользователи, процессы, системы и информация.
2 Адаптировано из ИСО/МЭК ТО 13335-1:1996.
3.10 доступность (availability): Свойство быть доступным и используемым по запросу со стороны уполномоченного логического объекта.
[ИСО/МЭК 7482-2:1989]
3.11 база (baseline): Спецификация или продукт, формально проанализированный, согласованный и впоследствии служащий в качестве основы для дальнейших разработок, который может быть изменен только посредством формальных процедур управления изменениями.
[IEEE-Std.610]
3.12 сертификация (certification): Изложенный в письменной форме процесс проведения всеобъемлющего оценивания функциональных возможностей обеспечения безопасности и других мер защиты системы для определения степени, в которой проект системы и его реализация удовлетворяют требованиям безопасности.
Примечание - Данное определение в основном применяется в области безопасности в целом; в ИСО наиболее широко применяемым определением является следующее: "процедура, посредством которой третья сторона дает письменные заверения, что продукт, процесс или услуга соответствуют установленным требованиям".
[ИСО/МЭК Руководство 2]
3.13 конфиденциальность (confidentiality): Свойство, позволяющее не давать право на доступ к информации или не раскрывать ее неполномочным лицам, логическим объектам или процессам.
[ИСО/МЭК 7498-2:1989]
3.14 последовательность (consistency): Степень единообразия, стандартизации и отсутствия противоречий в документах, частях системы или компонентах.
[IEEE-Std.610]
3.15 правильность (correctness): Состояние продукта или системы, демонстрирующее их соответствие установленным требованиям безопасности.
3.16 заказчик (customer): Получатель продукта, предоставленного поставщиком.
Примечания
1 В договорных ситуациях заказчик называется "покупателем".
2 Заказчик может быть, например, непосредственным потребителем, пользователем или покупателем.
3 Заказчик может быть ее сотрудником или сторонним для организации.
[ИСО 9000:2005] и [ИСО/МЭК 15504-1:2004].
3.17 эффективность (effectiveness): Свойство системы или продукта, показывающее, насколько хорошо оно обеспечивает безопасность в контексте их предполагаемой или фактической эксплуатации.
3.18 инженерная группа (engineering group): Совокупность лиц (как руководителей, так и инженерно-технического персонала), ответственных за действия по проекту или в организации, связанные определенной технической дисциплиной.
Примечание - Технические дисциплины включают в себя: аппаратные средства, программное обеспечение, управление конфигурированием программного обеспечения, доверие к качеству программного обеспечения, а также системы, их тестирование и безопасность.
3.19 свидетельство (evidence): Непосредственно измеряемые характеристики процесса и/или продукта, свидетельствующие, что конкретное действие удовлетворяет установленному требованию.
3.20 целостность (integrity): Свойство обеспечения безопасности достоверности и полноты информации и методов обработки.
3.21 техническое обслуживание (maintenance): Процесс модифицирования системы или компонента после доставки с целью исправления дефектов, улучшения рабочих и других характеристик или адаптации к изменившимся условиям.
[IEEE-Std.610]
3.22 методология (methodology): Совокупность стандартов, процедур и вспомогательных методов, определяющих детальный подход к разработке продукта или системы.
3.23 профиль преодоления защиты (penetration profile): Определение действий по преодолению защиты.
3.24 процедура (procedure): Письменное описание хода действия, осуществляемого для выполнения данной задачи.
[IEEE-Std.610]
3.25 процесс (process): Совокупность взаимосвязанных действий по преобразованию входных данных в выходные.
Примечание - Адаптировано с ИСО/МЭК 15288:2002.
3.26 надежность (reliability): Свойство поддержания постоянного режима и получения непротиворечивых результатов.
[ИСО/МЭК ТО 13335-1:1996]
3.27 остаточный риск (residual risk): Риск, сохраняющийся после внедрения мер безопасности.
[ИСО/МЭК ТО 13335-1:1996]
Примечание - Данное определение отличается от определения, применяемого в Руководстве 73 ИСО/МЭК.
3.28 риск (risk): Потенциальная опасность нанесения ущерба организации в результате реализации некоторой угрозы с использованием уязвимостей актива или группы активов.
[ИСО/МЭК ТО 13335-1:1996]
Примечание - Данное определение отличается от определения, применяемого в Руководстве 73 ИСО/МЭК.
3.29 анализ риска (risk analysis): Процесс идентификации рисков безопасности, определения их величины и областей, нуждающихся в применении мер безопасности.
[ИСО/МЭК ТО 13335-1:1996]
Примечание - Данное определение отличается от определения, применяемого в Руководстве 73 ИСО/МЭК.
3.30 менеджмент риска (risk management): Процесс оценки и определения величины риска, а также установления уровня риска, приемлемого для организации.
[ИСО/МЭК ТО 13335-1:1996]
Примечание - Данное определение отличается от определения, применяемого в Руководстве 73 ИСО/МЭК.
3.31 политика безопасности (security policy): Правила, указания и практические приемы, определяющие то, как активы, включая информацию ограниченного доступа, управляются, защищаются и распределяются внутри организации и ее систем, в особенности те, которые воздействуют на системы и связанные с ними элементы.
3.32 требования, связанные с безопасностью (security related requirements): Требования, оказывающие непосредственное влияние на безопасное функционирование системы и обязывающие соблюдать установленную политику безопасности.
3.33 система: Отдельный, различимый физически, существующий логический объект, имеющий определенное назначение, полностью состоящий из интегрированных взаимодействующих компонентов, каждый из которых в отдельности не соответствует указанному общему назначению.
Примечания
1 Адаптировано с ИСО/МЭК 15288:2002.
2 Толкование значения слова "система" часто упрощается использованием связанных с ним существительных или прилагательных (например "система продуктов", "авиационная система"). В качестве альтернативы слово "система" можно заменить зависящим от контекста синонимом (например "продукт", "самолет"), хотя в будущем это может исказить первоначальный смысл этой фразы.
3 Для удовлетворения различным требованиям во время ее жизненного цикла системе могут потребоваться другие системы. Например, автоматизированной системе может потребоваться система концептуализации, разработки, изготовления, эксплуатации, поддержки и удаления.
3.34 угроза (threat): Потенциальные возможности, намерения и методы атаки противника, другое обстоятельство или событие, возникнувшие внутри или вовне организации, которые могут нанести ущерб информации, программе или системе или заставить их причинить ущерб другой информации, программе или системе.
3.35 носитель угрозы (threat agent): Источник и/или инициатор преднамеренных или случайных исходящих от человека угроз.
3.36 проверка достоверности (validation): Подтверждение выполнения установленных требований к конкретному использованию по назначению посредством проверки и предоставление объективных доказательств.
Примечание - Адаптировано с ИСО/МЭК 15288:2002.
3.37 верификация (verification): Подтверждение путем проверки и предоставление объективных доказательств выполнения установленных требований.
Примечание - Адаптировано с ИСО/МЭК 15288:2002:2002*.
3.38 уязвимость (vulnerability): Слабое место актива или группы активов, которое может быть подвержено воздействию угрозы.
3.39 рабочий продукт (work product): Артефакт, связанный с выполнением процесса.
[ИСО/МЭК 15504-1:2004]
Примечание - Рабочий продукт может использоваться, производиться или изменяться процессом.
4 Вводная информация
В модели зрелости функциональных возможностей проектирования безопасности систем (SSE-CMM®) представлены необходимые характеристики процесса проектирования безопасности организации, которые должны обеспечивать высокое качество проектирования безопасности.
SSE-CMM® не предписывает каких-либо конкретных процессов или последовательности действий, а представляет собой совокупность практических приемов, в основном применяемых в промышленности. Эта модель является стандартной для практического проектирования систем безопасности, охватывающих:
- весь жизненный цикл системы безопасности, включающий в себя действия по разработке, эксплуатации, обслуживанию и выводу из эксплуатации;
- управленческую, организационную и конструкторскую деятельность организации;
- одновременные (параллельные) взаимодействия с другими дисциплинами, такими как система, программное обеспечение, человеческий фактор и испытательная техника, управление, эксплуатация и обслуживание системы;
- взаимодействие с другими организациями, включая приобретение, менеджмент систем, сертификацию, аттестацию и оценивание.
В описании SSE-CMM® представлено общее изложение принципов и архитектуры, на которых она основана, общий вид модели, предложения по ее надлежащему применению, практические приемы, включенные в модель, и описание атрибутов модели. В описании также содержатся требования, используемые для разработки модели. Оценочный метод SSE-CMM® описывает процесс и инструменты оценивания возможностей организации по проектированию системы безопасности и сопоставления с SSE-CMM®.
4.1 Основание для разработки
Как заказчики, так и поставщики заинтересованы в совершенствовании разработки продуктов, систем и услуг в области безопасности. В области проектирования безопасности содержатся несколько общепринятых принципов, но в настоящее время в ней отсутствует комплексная основа оценивания практических приемов проектирования безопасности. Определяя подобную основу, SSE-CMM® предоставляет способ измерения и улучшения эффективности применения принципов проектирования безопасности.
Необходимо подчеркнуть, что проектирование безопасности является уникальной дисциплиной, требующей уникальных знаний, навыков и процессов, гарантирующих разработку особой SSE-CMM® для проектирования безопасности. Это не противоречит исходному условию, что проектирование безопасности осуществляется в контексте системного проектирования. Фактически, четко определенная и общепринятая деятельность по системному проектированию позволит осуществлять на практике проектирование безопасности при всех обстоятельствах.
Современное статистическое управление процессом предлагает возможность производства более качественной продукции более рентабельным образом путем придания особого значения качеству процессов их производства и зрелости организационных практических приемов, присущих этим процессам. Большая эффективность процессов гарантируется при условии увеличения стоимости и времени, необходимых для разработки безопасных систем и высоконадежной продукции. Эксплуатация и обслуживание безопасных систем основаны на процессах, объединяющих людей и технологии.
Целью проекта является продвижение проектирования безопасности как определенной, зрелой и измеряемой дисциплины. SSE-CMM® и оценочные методы разрабатываются с целью обеспечения:
- направленных инвестиций в инструменты проектирования безопасности, обучение, определение процессов, практические приемы менеджмента и внесение усовершенствований инженерными группами;
- основанного на потенциальных возможностях доверия (то есть кредитоспособности, основанной на доверии к зрелости практических приемов и процессов обеспечения безопасности, применяемых инженерными группами);
- подбора квалифицированных проектировщиков систем безопасности посредством дифференциации претендентов по уровням их потенциальных возможностей и связанных с ними программируемых рисков.
4.2 Значимость проектирования безопасности
С усилением зависимости общества от информации защита этой информации становится все более значимой. Для сохранения и защиты информации требуются различные продукты, системы и услуги. Значимость проектирования безопасности расширилась от использования, связанного в первую очередь с защитой правительственной информации ограниченного доступа, до более широкого использования, включающего финансовые операции, контракты, персональную информацию и Интернет. Эта тенденция в существенной степени повысила значимость проектирования безопасности.
4.3 Согласованность
SSE-CMM® разрабатывалась более чем 50 организациями, многие из которых являются многонациональными корпорациями. В разработке проекта участвовали представители Австралии, Канады, Европы и США. Кроме того, проект SSE-CMM® всегда стремился к расширению круга участников путем использования различных мест проведения мероприятий, включая презентации, и применение выставочных стендов, а также веб-сайт www.sscmm.org.
Участники были организованы в руководящую группу и несколько рабочих групп. Большая часть разработки осуществлялась рабочими группами, в то время как руководящая группа отвечала за общий ход процесса и утверждение отдельных частей проекта.
Модель SSE-CMM® разрабатывалась посредством консенсуса. Все организации-участники могли посылать своих представителей на заседания рабочих групп и большинство из них именно так и поступали. Статьи рассылались электронной почтой другим членам рабочей группы в перерывах между заседаниями. Заседания проводились ежемесячно и на них обсуждались, пересматривались и согласовывались вносимые предложения. Результаты всех необходимых голосований фиксировались в протоколах заседаний рабочих групп на каждом заседании. Затем эти документы сохранялись.
Каждая версия модели SSE-CMM® вначале утверждалась рабочей группой, занимающейся разработкой. Затем она просматривалась и утверждалась руководящей группой. После этого версия модели отсылалась группе "главных рецензентов", собранной из представителей сообщества, связанного с безопасностью ИТ, для проведения анализа и критического разбора. Затем каждая версия публиковалась для общественного рассмотрения и получения замечаний и предложений. На основе замечаний и предложений главных рецензентов и сообщества в целом руководящая группа определяла последнюю редакцию этой версии модели SSE-CMM®.
Модель SSE-CMM® в первый раз утверждалась на уровне рабочей группы, второй раз на уровне руководящей группы, в третий раз на уровне главных рецензентов и, наконец, на уровне сообщества. Таким образом, по существу применялись три уровня утверждения.
Дополнительное утверждение и консенсус достигались в ходе проведения контрольных экспертиз результатов применения модели в различных заданных областях. Рабочая группа альтернативного гарантирования Проекта Общих Критериев провела анализ модели SSE-CMM® на ее применимость в качестве альтернативы получения доверия путем оценивания и представила в проект замечания и предложения, относящиеся к безопасности систем ИТ.
Каждая публикация модели анализировалась группой независимых рецензентов, которые не участвовали в ее разработке. Их замечания были собраны, проанализированы и включены в модель. Наконец, каждая версия этого документа подвергалась общественному изучению и критическому анализу на двух международных семинарах, а полученные замечания были рассмотрены и учтены.
5 Структура документа
Предпосылки создания документа и основания для его разработки обсуждаются в разделе 4. Архитектура модели SSE-CMM® и роль проектирования безопасности систем рассматриваются в разделе 6. Составные области процесса проектирования безопасности и базовые практики подробно рассматриваются в разделе 7. Уровни зрелости функциональных возможностей и общие практики изложены в приложении А, тогда как в приложении В описаны области организационного процесса и проекта и базовые практики. Концепции модели зрелости функциональных возможностей изложены в приложении С.
6 Архитектура модели
Модель SSE-CMM® представляет собой совокупность лучших практических приемов проектирования безопасности. Для понимания данной модели требуется исходная информация по этому проектированию. Данный раздел предлагает высокоуровневое описание проектирования безопасности, а также того, каким образом архитектура модели отражает это основное понятие.
6.1 Проектирование безопасности
6.1.1 Понятие проектирования безопасности
Стремление к всеобъемлющей взаимосвязи и совместимости сетей, компьютеров, прикладных программ и даже предприятий непрерывно повышает роль безопасности. Основное внимание к обеспечению безопасности сместилось с защиты правительственной информации ограниченного пользования к области более широкого применения, включая финансовые операции, контракты, персональные данные и Интернет. В результате необходимо, чтобы потенциальные области, нуждающиеся в защите, рассматривались и определялись для каждого направления использования. Примерами таких областей являются конфиденциальность, целостность, доступность, подотчетность, неприкосновенность частной жизни и доверие.
Смещение направленности задач обеспечения безопасности повышает значимость проектирования безопасности. Оно становится все более важной дисциплиной и должно превратиться в ключевой компонент согласованных действий инженерных групп, состоящих из специалистов в разных дисциплинах. Проектирование безопасности применимо к разработке, интеграции, эксплуатации, управлению и развитию систем и приложений, а также к разработке, доставке и модернизации продукции. Вопросы безопасности должны учитываться при определении, руководстве и модернизации безопасности предприятий и процессов деловой деятельности. Проектирование безопасности может осуществляться в системе, продукте или в виде услуги.
6.1.2 Описание проектирования безопасности
Проектирование безопасности является развивающейся дисциплиной. По существу согласие по точному определению понятия "проектирование" пока не достигнуто. Однако возможно несколько обобщений. Так, одними из целей проектирования безопасности являются:
- обеспечение понимания рисков безопасности предприятия;
- установление уравновешенной (сбалансированной) совокупности требований безопасности в соответствии с идентифицированными рисками;
- преобразование требований безопасности в руководство по безопасности с целью интеграции в деятельность, относящуюся к другим дисциплинам, участвующим в проекте, и в описание конфигурации или функционирования системы;
- создание уверенности или доверия к правильности и эффективности механизмов обеспечения безопасности;
- определение допустимости воздействий на эксплуатацию, обусловленных остаточными уязвимостями в системе или в процессе ее эксплуатации (то есть определение остаточных рисков);
- объединение усилий всех инженерных дисциплин с целью общего понимания надежности системы.
6.1.3 Организации, связанные с проектированием мер безопасности
Деятельность по проектированию безопасности практикуется различными типами организаций, такими как:
- разработчики;
- продавцы продукции;
- интеграторы;
- покупатели (приобретающая организация или конечный пользователь);
- организации, оценивающие безопасность (органы сертификации систем, оценки продукции и аккредитации эксплуатации);
- доверенные третьи стороны (орган сертификации);
- консультирующие организации/провайдеры услуг.
6.1.4 Жизненный цикл проектирования безопасности
Деятельность по проектированию безопасности осуществляется на всех этапах жизненного цикла, включая этапы:
- создания концепции;
- разработки;
- производства;
- эксплуатации;
- поддержки;
- изъятия из эксплуатации.
6.1.5 Проектирование безопасности и другие дисциплины
Деятельность по проектированию безопасности связана со многими другими дисциплинами, включая:
- проектирование предприятий;
- системное проектирование;
- проектирование программного обеспечения;
- инженерную психологию;
- технику связи;
- испытательную технику;
- администрирование системы.
Примечания
1 В отношении системного проектирования дополнительную информацию, рассматривающую задачи безопасности с точки зрения систем, можно найти в ИСО/МЭК 15288:2002.
2 В отношении проектирования программного обеспечения дополнительную информацию, рассматривающую задачи безопасности с точки зрения программного обеспечения, можно найти в ИСО/МЭК 12207:1995.
Деятельность по проектированию безопасности должна быть скоординирована со многими сторонними логическими объектами, поскольку доверие и приемлемость остаточных эксплуатационных воздействий устанавливаются совместно с разработчиком, интегратором, покупателем, пользователем, независимым оценщиком и другими группами. Именно эти необходимые взаимодействия между различными организациями делают проектирование безопасности особенно сложным.
6.1.6 Специализации в области проектирования безопасности
В то время как проектирование безопасности и безопасность ИТ очень часто являются ведущими дисциплинами в условиях обеспечения безопасности деловой деятельности, нельзя игнорировать другие более традиционные дисциплины обеспечения безопасности, такие как физическая защита и защита персонала. Если необходимо получить наиболее эффективные и действенные результаты при выполнении своей работы, к проектированию безопасности следует привлекать эти и многие другие специальные второстепенные дисциплины. В перечне, приведенном ниже, приведено несколько примеров специальных второстепенных дисциплин, связанных с безопасностью:
- эксплуатационная безопасность, связанная с безопасностью условий эксплуатации и поддержанием этой безопасности;
- информационная безопасность, относящаяся к информации и поддержанию безопасности информации во время ее обработки;
- сетевая безопасность, включающая в себя защиту аппаратных средств, программного обеспечения и протоколов, включая передаваемую по сетям информацию;
- физическая защита, подразумевающая защиту зданий и физических местоположений;
- защита персонала, связанная с людьми, их надежностью в работе и осведомленностью о задачах безопасности;
- административная безопасность, связанная с административными аспектами безопасности и безопасности в административных системах;
- коммуникационная безопасность (безопасность содержания и трафика информации), связанная с передачей информации между доменами безопасности, в частности защитой информации при ее передаче через средство сообщения;
- защита от побочных электромагнитных излучений и наводок, связанная с помехами, создаваемыми всеми ЭВМ, которые могут передавать информацию за пределы доменов безопасности;
- компьютерная безопасность, относящаяся конкретно к безопасности вычислительных устройств всех типов.
6.2 Общее понятие о процессе проектирования безопасности
Модель SSE-CMM® разделяет проектирование безопасности на три основные части: риск, проектирование и формирование доверия (см. рисунок 1). Поскольку эти части никак не зависят друга от друга, можно рассматривать их в отдельности. На самом простом уровне процесс обнаружения рисков идентифицирует угрозы, присущие разрабатываемому продукту или системе, и определяет их приоритеты. Процесс проектирования безопасности функционирует наряду с другими инженерными дисциплинами для определения задач, инициированных угрозами и реализации их решений. Наконец, процесс формирования доверия обеспечивает уверенность в решениях задач безопасности и передает эту уверенность заказчикам.
Вместе эти три части служат достижению цели получения надлежащих результатов в процессе проектирования безопасности.
6.2.1 Риск
Основной целью проектирования безопасности является снижение риска. Оценка риска является процессом выявления проблем, которые ранее не встречались. Риски оцениваются путем изучения вероятности реализации угрозы и уязвимости и рассмотрения потенциального воздействия непредусмотренного инцидента (см. рисунок 2). С этой вероятностью связан фактор неопределенности, который изменяется в зависимости от определенной ситуации. Это значит, что вероятность появления угрозы безопасности можно предсказать только в определенных пределах. Кроме того, воздействие, оцененное для конкретного риска, также имеет связанную с ним неопределенность, поскольку непредусмотренный инцидент может оказаться не таким, как предполагалось. Так как факторы могут иметь большую степень неопределенности, связанную с точностью их прогнозирования, планирование и обоснование обеспечения безопасности может быть сильно затруднено. Одним из путей рационального решения этой задачи является внедрение методов обнаружения непредусмотренного инцидента.
|
 |
Рисунок 1 - Процесс проектирования безопасности, состоящий из трех основных частей
|
 |
Рисунок 2 - Процесс обнаружения риска, включающего в себя угрозы, уязвимости и воздействие
Непредусмотренный инцидент состоит из трех компонентов: угрозы, уязвимости и воздействия. Уязвимостями являются свойства актива, которые имеют слабые места и могут использоваться угрозой. При отсутствии угрозы или уязвимости непредусмотренного инцидента риска не будет. Менеджментом риска являются все действия, которые надо скоординировать для управления действиями по менеджменту риска в организациях и контроля за ними. Это подразумевает установление приемлемого уровня риска для организации и, соответственно, идентификацию, анализ, оценивание и обработку риска. Управление риском является важной частью управления безопасностью.
Риски обрабатывают посредством внедрения мер безопасности, которые могут учитывать угрозу, уязвимость, воздействие и сам риск. Однако обработка всех рисков или полная нейтрализация последствий реализации какого-либо определенного риска практически неосуществимо. Большей частью это является следствием высокой стоимости обработки рисков и связанными с ней неопределенностями. Следовательно, всегда должен приниматься во внимание некоторый остаточный риск. При высокой степени неопределенности принятие риска становится крайне проблематичным вследствие неточного характера риска. Одной из немногих областей, контролируемых лицом, принявшим риск, является неопределенность, связанная с системой. Области процесса SSE-CMM® включают в себя действия организации-провайдера, обеспечивающие анализ угроз, уязвимостей, воздействий и связанного с ними риска.
Примечание - Упорядоченность областей процесса является строго алфавитной, основанной на наименованиях областей процесса. Это делается с целью предотвращения возможности сделать вывод о какой-либо последовательности или приоритетах в упорядоченности областей процесса.
6.2.2 Проектирование
Проектирование безопасности, подобно другим дисциплинам проектирования, является процессом, который осуществляется посредством использования концепции, проекта, реализации, теста, ввода в эксплуатацию, обслуживания и вывода из эксплуатации. С помощью этого процесса специалисты в области безопасности должны тесно сотрудничать с другими подразделениями группы системного проектирования. В модели SSE-CMM® особое внимание придается тому, что специалисты в области безопасности являются частью большой группы и должны координировать свои действия со специалистами по другим дисциплинам. Это помогает обеспечивать неотъемлемость процесса обеспечения безопасности от большего процесса, а не рассматривать его как отдельный и обособленный вид деятельности.
Используя информацию по вышеизложенному процессу обнаружения риска и другую информацию о требованиях системы, соответствующих законов и политик, специалисты в области безопасности вместе с заказчиком определяют потребности в мерах безопасности (см. рисунок 3). После этого они определяют конкретные требования и отслеживают их выполнение.
Процесс принятия решений по проблемам безопасности в основном включает в себя установление возможных альтернатив и их последующую оценку с целью определения, какая из них является самой многообещающей. Трудность интегрирования этой деятельности в остальной процесс проектирования заключается в том, что решения невозможно принять на основе только соображений безопасности. Необходимо также учитывать широкий набор других соображений, включая стоимость, производительность, технический риск и удобство эксплуатации. Обычно эти решения надо обобщать для минимизации необходимости повторного обращения к этим проблемам. Проводимые анализы также формируют существенную основу для работы по обеспечению доверия.
Позднее, в ходе жизненного цикла систем безопасности, специалист в области безопасности вызывается для подтверждения правильности конфигурации продукции и систем в отношении осознанных рисков, обеспечивая защиту функционирования системы от новых рисков.
|
 |
Рисунок 3 - Безопасность, являющаяся неотъемлемой частью общего процесса проектирования
6.2.3 Доверие
Доверие определяется как степень уверенности в удовлетворении требований безопасности [1]. Оно является очень важным результатом проектирования безопасности. Существует много форм доверия. Модель SSE-CMM® содействует одному аспекту, а именно уверенности в повторяемости результатов процесса проектирования безопасности. Основанием для этой уверенности является наличие большей вероятности повторения результатов зрелой организацией, чем недостаточно зрелой (см. рисунок 4). Детальная взаимосвязь между различными формами доверия является целью проводимого анализа.
Доверие не добавляет каких-либо дополнительных мер безопасности для противодействия рискам, связанным с безопасностью, но обеспечивает уверенность в том, что уже внедренные меры безопасности снизят ожидаемые риски.
Доверие можно также рассматривать как уверенность в том, что меры безопасности функционируют должным образом. Эта уверенность основана на качествах правильности и эффективности. Правильность можно рассматривать как свойство выполнения мерами безопасности требований так, как это было запланировано. Эффективность можно рассматривать как свойство обеспечения мерами безопасности степени безопасности, адекватной потребностям заказчика. Интенсивность процесса также играет определенную роль, но она смягчается уровнем защиты и искомым доверием.
Доверие часто передается в виде аргумента. Аргумент включает в себя совокупность утверждений о свойствах системы. Эти утверждения поддерживаются доказательством. Доказательство часто имеет форму документации, разработанной во время стандартной деятельности по проектированию безопасности.
|
 |
Рисунок 4 - Процесс формирования доверия, производящий аргумент, который создает уверенность
Действия модели SSE-CMM® сами по себе включают получение относящегося к доверию свидетельства. Например, документация процесса может указывать на то, что разработка последовала за четко определенным и зрелым процессом проектирования, который постоянно совершенствуется. Проверка безопасности и подтверждение достоверности играют большую роль в формировании надежности продукта или системы.
Многие образцы продуктов, включенные в рамки области процесса, оказывают содействие свидетельству или образуют его часть. Современное статистическое управление процессом предлагает возможность получения продукции с большей степенью качества и доверия более рациональным и воспроизводимым образом, сосредоточивая внимание на процессе ее производства. На процесс также оказывает влияние и содействует ему зрелость (развитость) практических приемов организации.
6.3 Описание архитектуры модели SSE-CMM®
Архитектура модели SSE-CMM® спроектирована для определения зрелости процесса проектирования безопасности организации во всем объеме проектирования безопасности. Целью создания архитектуры является четкое отделение его основных характеристик от характеристик менеджмента и институционализации. Для обеспечения этого разделения модель имеет две величины, называемые "домен" и "возможности" и описанные ниже.
Важно, что SSE-CMM® не предполагает необходимости выполнения какого-либо процесса, описанного в модели какой-нибудь определенной группой в рамках организации. Модель также не требует применения новейшего метода или методологии проектирования безопасности. Однако она требует наличия в организации процесса, включающего в себя базовые практики обеспечения безопасности, изложенные в модели. Организация может создавать собственный процесс и организационную структуру, так или иначе отвечающие их бизнес-целям.
6.3.1 Базовая модель
SSE-CMM® имеет две величины, "домен" и "возможность". Из двух величин величина "домен", возможно, более легка для понимания. Эта величина состоит из всех практических приемов, которые в совокупности определяют проектирование безопасности. Эти практические приемы называются "базовыми практиками". Структура и содержание этих "базовых практик" обсуждаются ниже.
Величина "возможность" представляет собой практические приемы, демонстрирующие возможности менеджмента и институционализации процесса. Эти практические приемы называются "общими практиками", поскольку они применяются в широком диапазоне доменов. Общие практики представляют действия, которые должны осуществляться как часть базовых практик.
Взаимосвязь между базовыми и общими практиками показана на рисунке 5. Существенной частью проектирования безопасности является идентификация уязвимостей безопасности системы. Это действие представлено базовой практикой 05.02 "Идентификация уязвимостей безопасности системы".
Одним способом определения способности организации выполнять какие-либо действия является проверка наличия у нее процесса распределения ресурсов для действий, которые, по ее утверждению, она выполняет. Эта "характеристика" развитой (зрелой) организации отражена в общей практике 2.1.1 "Распределение ресурсов" модели SSE-CMM®.
Объединение общих и базовых практик обеспечивает способ проверки возможности организации выполнять определенную деятельность. Здесь заинтересованная сторона может задать вопрос: "Ваша организация выполняет распределение ресурсов для идентификации уязвимостей безопасности системы?". Если ответом является "Да", опрашивающий узнает немного о возможностях организации.
Ответы на все вопросы, возникающие при объединении всех общих практик со всеми базовыми, дают хорошую картину возможностей проектирования безопасности.
|
 |
Рисунок 5 - Модель, оценивающая каждую область процесса в сопоставлении с каждым общим признаком
6.3.2 Базовые практики
Модель SSE-CMM® состоит из 129 базовых практик, организованных в 22 областях процесса. Из них 61 базовая практика, организованные в 11 областях процесса, охватывает все главные области проектирования безопасности. Остальные 68 практик, организованных в 11 областях процесса, относятся к доменам проекта и организации. Эти практики были выведены из модели зрелости функциональных возможностей модели СММ® средств программирования и системного проектирования и требуются для обеспечения условий и поддержки областей процесса проектирования безопасности систем. Общие практические приемы обеспечения безопасности были собраны из большого количества существующих материалов, результатов практической деятельности и практического опыта. Выбранные практические приемы протестированы и отражают имеющийся передовой опыт организаций, занимающихся проектированием безопасности.
Определение базовых практик проектирования безопасности осложняется наличием многих различных названий действий, которые по существу одинаковы. Некоторые из этих действий применяются позднее в жизненном цикле на разном уровне абстракции или обычно выполняются лицами на различных должностях. Однако нельзя считать, что организация получила базовую практику, если она применяется только на этапе проектирования или на одном уровне абстракции. Следовательно, модель SSE-CMM® игнорирует эти различия и определяет основной набор практических приемов, которые необходимы в деятельности по качественному проектированию безопасности.
Базовая практика:
- применяется в течение жизненного цикла предприятия;
- не накладывается на другие базовые практики;
- представляет собой "передовой опыт" по обеспечению безопасности;
- не является простым отражением самой современной технологии;
- применяется множественными методами в многочисленных, связанных с деятельностью ситуациях;
- не обозначает конкретный метод или инструмент.
Базовые практики были организованы в области процесса таким образом, чтобы они соответствовали широкому спектру организаций, занимающихся проектированием безопасности. Существует много способов разделить домен проектирования безопасности на области процесса. Кто-то может попытаться смоделировать реальную обстановку, создавая области процесса, согласующиеся с услугами по проектированию безопасности. В других стратегиях делается попытка идентифицировать концептуальные зоны, образующие стандартные блоки проектирования безопасности. Модель SSE-CMM® создает компромисс между этими разными целями в текущей совокупности областей процесса.
Каждая область процесса имеет ряд целей, которые представляют собой предполагаемое состояние организации, успешно выполняющей базовые практики области процесса. Организация, выполняющая базовые практики области процесса, также должна добиваться этих целей.
Область процесса:
- объединяет родственные действия в одной части для удобства использования;
- связана с важными услугами по проектированию безопасности;
- может реализовываться во многих контекстах организаций и продуктов;
- может усовершенствоваться как отдельный процесс;
- может усовершенствоваться группой с аналогичной заинтересованностью в процессе;
- включает в себя все базовые практики, которые требуются для выполнения целей данной области процесса.
Ниже приведены одиннадцать частей процессов модели SSE-CMM® проектирования безопасности систем. Следует отметить, что они перечислены в алфавитном порядке во избежание представления о том, что области процесса упорядочены по этапам или областям жизненного цикла. Эти области процесса (РА) и определяющие их базовые практики (BP) изложены в разделе 7 и перечислены ниже:
- РА01 управляет средствами защиты;
- РА02 оценивает воздействие;
- РА03 оценивает риск безопасности;
- РА04 оценивает угрозу;
- РА05 оценивает уязвимость;
- РА06 формирует аргумент доверия;
- РА07 координирует задачи безопасности;
- РА08 проводит мониторинг состояния безопасности;
- РА09 предоставляет входные данные по безопасности;
- РА10 обозначает потребности в безопасности;
- РА11 проверяет и подтверждает состояние безопасности.
Модель SSE-CMM® также включает в себя одиннадцать областей процесса, связанных с проектными и организационными приемами. Эти области процесса были адаптированы к модели SSE-CMM®. Эти области процесса и определяющие их базовые практики изложены в приложении В и перечислены ниже:
- РА12 обеспечивает качество;
- РА13 управляет конфигурацией;
- РА14 управляет проектным риском;
- РА15 осуществляет мониторинг и управляет технической деятельностью;
- РА16 планирует техническую деятельность;
- РА17 определяет процесс системного проектирования организации;
- РА18 совершенствует процесс системного проектирования организации;
- РА19 управляет развитием производственных линий;
- РА20 управляет средой поддержки системного проектирования;
- РА21 постоянно обеспечивает практические навыки и знания;
- РА22 осуществляет сотрудничество с поставщиками.
Примечание - Изложение этих областей процесса помещено в приложение с целью способствования синхронизации с ИСО/МЭК 15288:2002 в будущем.
6.3.3 Общие практики
Общие практики представляют собой действия, применимые ко всем процессам. Эти практики связаны с процессами менеджмента, измерения и институционализации. В общем, общие практики применяются во время оценки возможностей организации осуществлять процесс.
Общие практики сгруппированы в логические области, называемые "Общие признаки", которые организованы в пять "Уровней возможностей", представляющих возрастающие функциональные возможности организации. В отличие от базовых практик величины "домен" общие практики измерения возможностей упорядочены в соответствии с их зрелостью. Следовательно, общие практики, указывающие на более высокие уровни функциональных возможностей процесса, расположены в верхней части величины "возможность".
Общие признаки предназначены для описания основных изменений в типичном способе выполнения организацией технологических процессов (в данном случае домен проектирования безопасности). Каждый общий признак имеет один или несколько практических приемов. Самым низким общим признаком является уровень "1.1 Базовые практики выполнены". Этот общий признак просто проверяет, выполняет ли организация все базовые практики в той или иной области процесса.
Следующие общие признаки имеют общие практики, помогающие определить, насколько качественно проект управляет и улучшает каждую область процесса в целом. Общие практики, изложенные в приложении А, сгруппированы для выявления основных изменений процесса выполнения проектирования безопасности. Несколько принципов применения общих практик указаны в таблице 1.
Таблица 1 - Принципы измерения возможностей
|
|
Принцип | Способ выражения в SSE-CMM® |
Вам следует сделать "это" перед тем, как вы сможете управлять "этим" | Уровень "Выполненный Неформально" относится к тому, осуществляет ли организация процесс, объединяющий базовые практики |
Следует знать, что происходит с проектом (где находится продукция!) перед определением процессов в объеме организации | Уровень "Запланированный и Отслеженный" относится к задачам определения, планирования и выполнения на уровне проекта |
Используйте лучшее из того, что вы узнали из ваших проектов, для создания проектов в масштабе организации | Уровень "Четко Определенный" относится к упорядоченной подгонке определенных процессов на уровне организации |
Вы не сможете измерить "это", пока не узнаете, что "это" значит | Хотя важно начать сбор и использование основных мер измерения проекта заранее (то есть на уровне "Запланированный и Отслеженный"), измерение и использование данных не ожидается в масштабе организации до тех пор, пока не будут достигнуты уровни "Четко Определенный и Управляемый" |
Управление с измерением значимо только тогда, когда вы измеряете правильные вещи | Уровень "Управляемый Количественно" относится к измерениям, связанным с целями деловой деятельности организации |
Культура постоянного улучшения требует основания надежной практики менеджмента, определенных процессов и измеримых целей | Уровень "Постоянное улучшение" использует все улучшения практики менеджмента с предыдущих уровней, затем выделяет культурные сдвиги, которые поддержат полученные достижения |
Приведенные ниже общие признаки представляют собой характеристики зрелого проектирования безопасности, необходимые для достижения каждого уровня. Эти общие признаки и определяющие их общие практики изложены в приложении А.
Уровень 1:
1.1 Базовые практики выполнены.
Уровень 2:
2.1 Планирование выполнения.
2.2 Упорядоченное выполнение.
2.3 Проверка выполнения.
2.4 Отслеживание выполнения.
Уровень 3:
3.1 Определение стандартного процесса.
3.2 Выполнение заданного процесса.
3.3 Координация практических приемов.
Уровень 4:
4.1 Определение измеримых целей обеспечения качества.
4.2 Объективное управление выполнением.
Уровень 5:
5.1 Улучшение организационных возможностей;
5.2 Улучшение эффективности процесса.
Модель SSE-CMM® не подразумевает наличие конкретных требований по выполнению общих практик. В основном организация может по своему усмотрению планировать, отслеживать, определять свои процессы и управлять ими в любом виде и в любой последовательности. Однако, поскольку некоторые общие практики более высокого уровня зависят от общих практик более низкого уровня, организациям рекомендуется поработать с общими практиками более низкого уровня перед тем, как пытаться достичь более высоких уровней.
6.3.4 Уровни возможностей
Существует несколько путей группирования практических приемов в общие признаки, а общих признаков - в уровни возможностей. Нижеследующее обсуждение касается этих общих признаков.
Упорядочивание общих признаков исходит из того, что реализация и институционализация некоторых практических приемов выигрывают от присутствия других приемов. Это особенно справедливо, если практические приемы являются общепризнанными. До того, как организация сможет определить, адаптировать и эффективно использовать конкретный процесс, отдельные проекты должны иметь некоторый опыт управления функционированием этого процесса. Например, организация должна вначале попробовать применить процесс оценки на проекте перед институционализацией специфического процесса оценки всей организации. Однако некоторые аспекты реализации и институционализации должны рассматриваться в совокупности (не по очереди), поскольку они работают вместе в направлении усиления возможностей.
Общие признаки и уровни возможностей имеют значение как при проведении оценки, так и при усилении возможностей процесса организации. В случае оценки, когда организация имеет несколько общих признаков, реализованных на определенном уровне возможностей заданного процесса, организация обычно функционирует на самом низком уровне этого процесса. Например, организация, выполняющая все, кроме одной, общие практики Уровня 2 некоторой области процесса должна получить категорию Уровня 1. Организация не может получить все преимущества от внедрения общего признака на какой-либо данный уровень возможностей, если не были внедрены общие признаки на более низких уровнях возможностей. Группа по оценке должна учитывать это при оценке отдельных процессов организации.
В случае с улучшением возможностей объединение практических приемов в уровни возможностей обеспечивает для организации план действий по улучшению, если она захочет усилить свои возможности в отношении какого-либо конкретного процесса. По этим причинам практические приемы модели SSE-CMM® сгруппированы в общие признаки, которые упорядочены уровнями возможностей.
Каждая область процесса должна оцениваться на предмет определения ее уровней возможностей. Это указывает на то, что различные области процесса могут и возможно будут находиться на различных уровнях возможностей. Тогда организация сможет использовать эту специфическую для процесса информацию как средство его улучшения. При установлении приоритетов и последовательности действий по улучшению процессов организации необходимо учитывать свои бизнес-цели.
Бизнес-цели являются основной мотивацией интерпретации такой модели, как SSE-CMM®. Но существует основной порядок действий и основные принципы, которые приводят в действие логическую последовательность типичных действий по улучшению. Этот порядок выражен в общих признаках и общих практиках аспекта уровней возможностей архитектуры SSE-CMM®.
Модель SSE-CMM® состоит из пяти уровней, представленных на рисунке 6 и подробно изложенных в приложении А.
|
 |
процесса (РА). В приведенной ниже таблице приводится соответствие уровней возможностей модели SSE-CMM® уровням по ИСО/МЭК 15504-2:2003.*
Таблица 2 - Соответствие величины "возможность" структуре измерений
|
|
Величина "возможность" модели SSE-CMM® | Структура измерений ИСО/МЭК 15504-2:2003 |
[В SSE-CMM® не определен однозначно, а подразумевается] | Уровень 0: незавершенный процесс |
Уровень возможностей 1 Выполнен неформально | Уровень 1: выполненный процесс |
Общий признак 1.1 Базовые практики выполнены | РА 1.1 Характеристика выполнения процесса |
Уровень возможностей 2 Запланированный и отслеженный | Уровень 2: управляемый процесс |
Общий признак 2.1 Планирование выполнения
Общий признак 2.4 Отслеживание выполнения | РА 2.1 Характеристика управления выполнением |
Общий признак 2.2 Упорядоченное выполнение
Общий признак 2.3 Проверка выполнения | РА 2.2 Характеристика управления рабочим изделием |
Уровень возможностей 3 Вполне определенный | Уровень 3: установленный процесс |
Общий признак 3.1 Определение стандартного процесса
Общий признак 3.2 Выполнение заданного процесса | РА 3.2 Характеристика ресурса процесса |
[Специально здесь не рассматриваются, но рассматриваются в последующих общих практиках]
ОПП 2.1.1 Распределяет ресурсы
ОПП 2.1.2 распределяет обязанности
ОПП 2.1.5 Обеспечивает обучение | РА 3.2 Характеристика ресурса процесса |
Общий признак 3.3 Координирует практические приемы | [Прямой эквивалент отсутствует] |
Уровень возможностей 4 Количественно контролируется | Уровень 4: прогнозируемый процесс |
Общий признак 4.1 Определение измеримых целей обеспечения качества | РА 4.1 Характеристика измерений |
Общий признак 4.2 Объективное управление выполнением | РА 4.2 Характеристика управления процессом |
Уровень возможностей 5 Постоянно улучшает | Уровень 5: оптимизация процесса |
Общий признак 5.1 Улучшение возможностей организации | РА 5.2 Характеристика постоянного улучшения |
Общий признак 5.2 Повышение эффективности процесса | РА 5.1 Характеристика изменения процесса |
6.3.6* Взаимосвязь с ИСО/МЭК 15288:2002
В настоящем стандарте модель SSE-CMM® была разработана за рамками обычной среды ИСО/МЭК. Это означает существование отличий в использовании терминологии и построении между ИСО/МЭК 21827 и ИСО/МЭК 15288:2002. Кроме того, ИСО/МЭК 21827 нацелен на разработку другой области и дисциплины, а именно проектирования безопасности, что неизбежно ведет к появлению некоторых различий, являющихся второстепенными и упоминаемых только при необходимости. Однако основные концепции и подходы, используемые ИСО/МЭК 21827 и ИСО/МЭК 15288:2002, очень похожи.
Некоторые примеры взаимосвязи этих стандартов:
- области процесса ИСО/МЭК 21827 непосредственно связаны с процессами ИСО/МЭК 15288:2002;
- практические приемы ИСО/МЭК 21827 непосредственно связаны с действиями ИСО/МЭК 15288:2002;
- рабочие документы ИСО/МЭК 21827 имеют непосредственное отношение к результатам применения ИСО/МЭК 15288:2002;
- описания процесса ИСО/МЭК 21827 идентичны описаниям процесса ИСО/МЭК 15288:2002.
Основные взаимосвязи областей процесса ИСО/МЭК 21827 с процессами ИСО/МЭК 15288:2002 приведены в таблице 3.
Примечания
1 Строка с многочисленными "X" указывает на то, что заданный процесс ИСО/МЭК 15288:2002 перекрывается более чем одной областью процессов ИСО/МЭК 21827.
2 Столбец с многочисленными "X" указывает, что определенная область процесса ИСО/МЭК 21827 перекрывается более чем одним процессом ИСО/МЭК 15288:2002.
Таблица 3 - Взаимосвязь областей процесса ИСО/МЭК 21827 с процессами ИСО/МЭК 15288:2002
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
15288 Процессы | 21827 Части процесса | ||||||||||||||||||||||
Приобретение | РА 01 | РА 02 | РА 03 | РА 04 | РА 05 | РА 06 | РА 07 | РА 08 | РА 09 | РА 10 | РА 11 | РА 12 | РА 13 | РА 14 | РА 15 | РА 16 | РА 17 | РА 18 | РА 19 | РА 20 | РА 21 | РА 22
Х | При- меча- ние |
Поставка |
|
|
|
|
|
|
|
|
| Х |
|
|
|
|
|
|
|
|
|
|
|
|
|
Управление средой | Х |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Х | Х |
|
|
|
Управление инвестициями |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| ЭО |
Управление системой |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Х | Х |
|
|
|
|
|
Управление ресурсами |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Х |
|
|
| Х | Х |
|
Планирование проекта |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Х |
|
|
|
|
|
|
|
Оценка проекта |
|
|
|
|
|
|
|
|
|
|
|
|
|
| Х |
|
|
|
|
|
|
|
|
Управление проектом |
|
|
|
|
|
|
|
|
|
|
| Х |
|
| Х |
|
|
|
|
|
|
|
|
Принятие решений |
|
|
|
|
|
|
|
|
| Х |
|
|
|
|
|
|
|
|
|
|
|
|
|
Менеджмент риска |
|
|
|
|
|
|
|
|
|
|
|
|
| Х |
|
|
|
|
|
|
|
|
|
Управление конфигурацией |
|
|
|
|
|
|
|
|
|
|
|
| Х |
|
|
|
|
|
|
|
|
|
|
Управление информацией |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Определение запроса акционера |
|
|
|
|
|
|
|
|
| Х |
|
|
|
|
|
|
|
|
|
|
|
|
|
Анализ требований |
|
| Х |
|
|
|
|
| Х | Х | Х |
|
|
|
|
|
|
|
|
|
|
|
|
Проектирование архитектуры |
|
|
|
|
|
|
|
| Х |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Реализация |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| ЭО |
Проверка интеграции |
|
|
|
|
|
|
|
|
|
| Х |
|
|
|
|
|
|
|
|
|
|
| ЭО |
Переход |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| ЭО |
Подтверждение |
|
|
|
|
|
|
|
|
|
| Х |
|
|
|
|
|
|
|
|
|
|
|
|
Функционирование |
|
|
|
|
|
|
| Х |
|
|
|
|
|
|
|
|
|
| Х |
|
|
|
|
Обслуживание | Х |
|
|
|
|
|
|
| Х |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Удаление | Х |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Примечания |
| ЭО |
| ЭО | ЭО |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Условные обозначения | Х - Есть взаимосвязь между частью процесса и процессом | ЭО - Эквивалент отсутствует | |||||||||||||||||||||
|
 |
Рисунок 7 - Итоговая схема взаимосвязей областей процесса с общими признаками
6.4 Итоговая схема
Данная схема представляет собой модель на высоком уровне абстракции. Специалист-практик предупреждается, что каждая область процесса состоит из нескольких базовых практик, которые подробно изложены в разделе 7 и приложении В. Каждый общий признак состоит из нескольких общих практик, которые подробно изложены в приложении В. Каждой отдельной организации предоставляется выбор комбинации областей процесса. Итоговая схема взаимосвязей областей процесса с общими признаками представлена на рисунке 7.
7 Базовые практики обеспечения безопасности
Настоящий раздел содержит практические приемы, считающиеся необходимыми при проведении основного проектирования безопасности (то есть базовые практики). При этом области процесса не пронумерованы в каком-то особом порядке, поскольку модель не предписывает какой-либо конкретный процесс или последовательность процессов.
Организацию можно оценить по любой отдельной области процесса или комбинации областей процесса. Однако вместе области процесса предназначены для охвата всех базовых практик проектирования безопасности, а между областями процессов имеется много взаимосвязей. В настоящее время модель SSE-CMM® включает в себя 11 областей процесса, связанных с безопасностью, каждая из которых содержит несколько базовых практик. Каждая область процесса определена в последующих подразделах.
Общий формат областей процесса показан на рисунке 8. В кратком описании содержится беглый обзор их назначения. Каждая область процесса разделяется на несколько базовых практик. Базовые практики считаются обязательными элементами (то есть они должны успешно реализовываться для выполнения назначения области процесса, который они поддерживают). Каждая базовая практика подробно описана в соответствии с кратким изложением области процесса. Цели определяют желательный конечный результат реализации области процесса.
7.1 РА01 - Управляет мерами безопасности
7.1.1 Область процесса
7.1.1.1 Краткое описание
Назначением области процесса "Управление мерами безопасности" является обеспечение того, что заданный уровень безопасности, интегрированный в проект системы, фактически достигнут разработанной в результате системой, находящейся в рабочем состоянии.
|
 |
Рисунок 8 - Формат области процесса
7.1.1.2 Цели:
- правильные конфигурация и использование мер безопасности.
7.1.1.3 Перечень базовых практик
ВР.01.01 - Определяет обязанности и подотчетность по мерам безопасности и обеспечивает информирование о них каждого сотрудника организации.
BP.01.02 - Управляет конфигурацией мер безопасности системы.
ВР.01.03 - Управляет программами обеспечения осведомленности, подготовки и обучения для всех пользователей и администраторов.
ВР.01.04 - Управляет периодическим обслуживанием и администрированием служб безопасности и механизмов контроля.
7.1.1.4 Примечания к данной области процесса
В данной области процесса применяются действия, требуемые для управления и обслуживания механизмов контроля безопасности среды проектирования и автоматизированной системы. Далее эта область процесса способствует тому, чтобы уровень безопасности со временем не понизился. Управление мерами безопасности какого-либо нового устройства должно интегрироваться с уже имеющимися мерами безопасности.
7.1.2 Базовая практика 01.01 (ВР.01.01) - Определяет обязанности в области безопасности
Данная базовая практика определяет обязанности и подотчетность для мер безопасности и информирует о них каждого сотрудника организации.
7.1.2.1 Описание
Некоторые аспекты безопасности могут управляться в рамках обычной структуры менеджмента, в то время как для других требуется более специализированный менеджмент.
Процедуры должны обеспечивать подотчетность лиц с возложенными на них обязанностями и их полномочия на проведение каких-либо действий. Необходимо также обеспечить, чтобы любые принятые меры безопасности были понятны и применялись последовательно. Кроме того, они должны обеспечивать передачу информации о любой принятой структуре не только лицам в рамках самой структуры, но и всей организации.
7.1.2.2 Примеры результатов деятельности:
- схема структуры безопасности организации - определяет сотрудников организации, связанных с безопасностью, и их должность;
- документация с описанием функций, связанных с обеспечением безопасности - описывает каждую из должностей в организации, связанных с безопасностью, и связанные с ней обязанности;
- документация с описанием обязанностей по безопасности - подробно описывает каждую из обязанностей по безопасности, включая ожидаемые выходные данные и способ их анализа и использования;
- документация с подробным описанием подотчетности по безопасности - определяет лицо, подотчетное за связанные с безопасностью вопросы, гарантируя его ответственность за все риски;
- документация с подробным описанием полномочий в области безопасности - определяет, что разрешено делать каждому сотруднику организации.
7.1.2.3 Примечания
Некоторые организации создают рабочую группу по проектированию безопасности, ответственную за решение связанных с ней вопросов. Другие организации определяют руководителя рабочей группы, ответственного за обеспечение достижения целей, связанных с безопасностью.
7.1.3 ВР.01.02 - Управляет конфигурацией безопасности
Управляет конфигурацией средств обеспечения безопасности системы.
7.1.3.1 Описание
Конфигурация всех технических средств, связанных с обеспечением безопасности, нуждается в управлении. Эта базовая практика признает, что безопасность системы в огромной степени зависит от многих взаимосвязанных компонентов (аппаратных средств, программного обеспечения и процедур) и что обычные практические приемы управления конфигурацией не могут охватить взаимосвязанные зависимости, необходимые для обеспечения безопасности систем.
7.1.3.2 Примеры результатов деятельности:
- записи обо всех обновлениях программного обеспечения - отслеживают лицензии, серийные номера и информацию по всему программному обеспечению и обновлениях программного обеспечения системы, включая дату обновления, ответственное лицо и описание изменения;
- записи обо всех задачах распределения - содержат описание любой проблемы, встретившейся во время распределения программного обеспечения, и способ ее решения;
- конфигурация безопасности системы - база данных, описывающая текущее состояние аппаратного и программного обеспечения и средств связи системы, включая их местоположение, назначенных для работы с ними лиц и связанную с ними информацию;
- изменения конфигурации безопасности системы - база данных, описывающая все изменения конфигурации безопасности системы, включая имя лица, внесшего изменение, описание изменения, причину изменения и время внесения изменения;
- периодическое документирование распространения программного обеспечения, гарантирующего отсутствия скрытых модулей с неизвестными функциями, - приводят описание последнюю деятельность по распределению выверенного программного обеспечения, отмечая любые встреченные трудности и все элементы деятельности;
- изменения в требованиях, связанные с безопасностью, - отслеживает любые изменения в требованиях к системе, внесенные по причинам, связанным с безопасностью, или влияющим на безопасность, чтобы убедиться в преднамеренности этих изменений и их воздействий;
- изменения в проектной документации, связанные с безопасностью, - отслеживает любые изменения в проектировании системы, внесенные по причинам, связанным с безопасностью или влияющим на безопасность, чтобы убедиться в преднамеренности этих изменений и их воздействий;
- внедрение средств обеспечения безопасности - описывает внедрение средств обеспечения безопасности в систему, включая детали конфигурации внедрения;
- анализ безопасности - описывает текущее состояние средств обеспечения безопасности системы относительно намеченного внедрения контроля;
- удаление контроля - описывает процедуру удаления или блокирования средств защиты, включая планы перехода.
7.1.3.3 Примечания
Данная базовая практика включает в себя создание при необходимости конфигураций средств обеспечения безопасности. Однако фактическая задача по выбору конфигурации средства обеспечения безопасности, по-видимому, должна выполняться при внедрении этого средства. Сохранение приемлемой конфигурации средств обеспечения безопасности в любой системе является сложной задачей, особенно в большой распределенной системе. Некоторые аспекты самой конфигурации имеют жизненно важное значение для поддержания безопасности. Эффективная безопасность требует регистрации определенной информации, связанной с механизмами управления безопасностью, которые являются частью системы и обычно не используются другими дисциплинами. Аналогично, предлагаемые изменения в существующей системе должны подвергаться оценке с целью определения их воздействия на общее состояние безопасности системы.
Требуются процедуры обеспечения идентичности всех копий определенного модуля программного обеспечения или приложения и того, что они являются соответствующей версией, особенно в распределенной среде. Кроме того, особенно в случае распределения программного обеспечения по всей сети, важно убедиться в том, что программное обеспечение не было нарушено во время распределения. Эти требования применяются ко всему программному обеспечению.
Данная базовая практика должна обеспечивать выполнение программным обеспечением только намеченных функций, сохранение эталонной версии программного обеспечения; идентичность всех копий программного обеспечения, подтверждение обновлений, известность и сохранение конфигурации средств обеспечения безопасности.
7.1.4 ВР.01.03 - Управляет программами по обеспечению осведомленности, подготовке и обучению
Управляет программами по обеспечению осведомленности, подготовке и обучению всех пользователей.
7.1.4.2 Описание
Осведомленность, подготовка и обучение в области безопасности всего персонала нуждается в управлении так же, как осведомленность, подготовка и обучение в других областях.
7.1.4.2 Примеры результатов деятельности:
- анализ пользователем учебного материала в области безопасности - описывает эффективность, применимость и важность осведомленности и учебного материала в области обеспечения безопасности;
- журналы регистрации проведения подготовки, обучения и повышения квалификации и их результатов - отслеживает обеспечение осведомленности пользователя в области безопасности организации и системы;
- периодические повторные оценки уровня знаний, компетентности и подготовки пользователей в отношении безопасности - анализирует осознание сотрудниками организации задач безопасности и определяет возможные области, на которых следует сосредоточиться в будущем;
- каталоги учебных и образовательных материалов - набор учебных материалов в области безопасности, который может использоваться повторно во всей организации. Может быть объединен с другими учебными материалами организации.
7.1.4.3 Примечания
В данном контексте термин "пользователи" применяется в отношении не только тех лиц, которые непосредственно работают с системой, но и всех лиц, прямо или косвенно получающих информацию от системы, плюс все руководство.
Крайне важно, чтобы пользователи знали цели и задачи обеспечения безопасности и определенного механизма или средства обеспечения безопасности. Кроме того, важно, чтобы пользователи знали, как правильно пользоваться тем или иным механизмом или средством обеспечения безопасности. Таким образом, для пользователей требуется начальная подготовка и периодическая переподготовка в случае внедрения новых механизмов и средств обеспечения безопасности. От всех пользователей требуется осведомленность о безопасности, для обеспечения которой необходимо обучение по использованию механизмов обеспечения безопасности, а для небольшого количества пользователей требуются более глубокие знания в области безопасности и таким образом, эти пользователи являются кандидатами на получение образования в этой области.
7.1.5 ВР.01.04 - Управляет услугами по обеспечению безопасности и механизмами управления
Осуществляет периодическое обслуживание и администрирование услуг по обеспечению безопасности и механизмов управления.
7.1.5.1 Описание
Общее управление услугами по обеспечению безопасности и механизмами обеспечения безопасности идентично управлению другими услугами и механизмами. Оно включает в себя защиту услуг и механизмов от повреждений, случайных или преднамеренных, в соответствии с юридическими требованиями и требованиями политики.
7.1.5.2 Примеры результатов деятельности:
- журналы учета состояния оборудования и административные журналы - фиксирование обслуживания, проверок целостности и регламентных проверок, выполненных на механизмах защиты системы;
- периодический анализ с целью обслуживания и административные осмотры - содержит анализ последних действий по администрированию и обслуживанию системы безопасности;
- неисправности, внесенные в процессе администрирования и обслуживания - отслеживает проблемы администрирования и обслуживания с целью определения мест, где требуются дополнительные усилия;
- исключения из администрирования и обслуживания - содержит описания исключений, сделанных в процедурах администрирования и обслуживания, включая основание для исключения и его срок действия;
- перечень информации ограниченного доступа - приводит различные типы информации в системе и способ ее защиты;
- перечень носителей ограниченного доступа - описывает различные типы носителей, используемых для хранения информации, и способ защиты каждого из них;
- удаление секретной информации, перевод в более низкую категорию секретности и ликвидация - описывает процедуры предупреждения появления ненужных рисков в случае понижения степени секретности информации, при удалении секретной информации с носителей или их ликвидации.
7.1.5.3 Примечания
Примерами этих услуг являются идентификация и аутентификация (И/А); посредничество при осуществлении доступа и управление доступом; распределение ключей.
Каждая услуга по обеспечению безопасности должна включать в себя установление соответствующих параметров безопасности, их соблюдение, мониторинг и анализ соблюдения, а также корректировку параметров.
Эти требования особенно применимы к таким услугам по обеспечению безопасности, как идентификация и аутентификация, для поддержания пользователей и данных аутентификации и управления доступом для поддержания прав доступа.
Программное обеспечение и данные, принадлежащие организации, определены как информационные активы, представляющие подгруппу активов. Для некоторых активов требуется удаление их частей ограниченного доступа для обеспечения возможности использования остальной части активов в менее секретных целях. Удаление секретной информации обеспечивает выдачу информации лицам по принципу обеспечения необходимого знания. Этого можно достичь посредством понижения категории секретности информации или выборочного удаления специальной информации ограниченного доступа.
Электронные носители могут сохранять остаточные следы информации даже после наложения на нее другой информации. Может потребоваться удаление секретной информации с некоторых носителей перед использованием их для менее секретных целей. После завершения полезного времени жизни носителя его можно ликвидировать способом, наиболее соответствующим степени секретности остаточной информации, которая может обуславливать необходимость ликвидации этого носителя. Некоторые организации не разрешают использовать носители повторно для менее секретной информации. Специфические детали требований удаления, перевода на более низкую категорию и ликвидации секретной информации зависят от конкретной организации и применяемых ею инструкций.
7.2 РА02 - Оценивает воздействия
7.2.1 Область процесса
7.2.1.1 Краткое описание
Назначением области является идентификация воздействий, вызывающих опасения по отношению к системе, и оценки вероятности возникновения воздействий. Воздействия могут быть материальными, например, такими как потеря доходов или финансовые санкции, и нематериальными, такими как потеря репутации и доброго имени.
7.2.1.2 Цели:
- определение и характеризация воздействия рисков на безопасность системы.
7.2.1.3 Перечень базовых практик
BP.02.01 Определение, анализ и назначение приоритетов функциональных и деловых возможностей или возможностей выполнения целевых задач, используемых системой.
BP.02.02 Определение и составление спецификации активов системы, поддерживающих ключевые функциональные возможности или цели безопасности системы.
BP.02.03 Выбор показателя воздействия, используемого для этой оценки.
BP.02.04 При необходимости определения взаимосвязи между выбранной системой мер этой оценки и коэффициентами преобразования показателей.
BP.02.05 Определение и снятие характеристик воздействий.
BP.02.06 Мониторинг текущих изменений в воздействиях.
7.2.1.4 Примечания к области процесса
Воздействие является результатом (следствием) нежелательного инцидента, созданного намеренно или случайно и оказывающего негативное влияние на активы. Последствиями могут быть уничтожение определенных аспектов, нанесение ущерба системам ИТ и потеря конфиденциальности, целостности, доступности, подотчетности, аутентичности или надежности. Возможные косвенные последствия включают в себя финансовые убытки и потерю доли рынка или имиджа компании. Измерение воздействий позволяет установить соответствие между результатами нежелательного инцидента и стоимостью мер безопасности для защиты от него. Следует принимать во внимание частоту возникновения нежелательных инцидентов. Это имеет особое значение, когда объем ущерба, наносимого при каждом возникновении инцидента, невелик, но совокупное воздействие многочисленных инцидентов может привести к нанесению значительного ущерба. Оценка результатов воздействий является важным элементом оценки рисков и выбора мер безопасности.
Информация о воздействиях, получаемая в этой области процесса, предназначена для использования базовой практики РА03 наряду с информацией об угрозах от РА04 и информацией об уязвимостях от РА05. Несмотря на то, что действия по сбору информации об угрозах, уязвимостях и воздействиях были объединены в отдельные области процесса, они являются взаимозависимыми. Целью сбора информации о воздействиях является обнаружение комбинаций угрозы, уязвимости и воздействия, которые считаются достаточно рискованными для обоснования применения определенного действия. Следовательно, поиск воздействий должен в определенной степени определяться наличием соответствующих угроз и уязвимостей.
7.2.2 ВР.02.01 - Назначает приоритеты функциональным возможностям
Определение, анализ и назначение приоритетов функциональных и деловых возможностей или возможностей выполнения целевых задач, используемых системой.
7.2.2.1 Описание
Определение, анализ и назначение приоритетов руководящих указаний по эксплуатации, деловой деятельности или выполнению целевых задач. Следует принимать во внимание стратегии бизнеса, которые влияют на воздействия, которым может подвергаться организация, и смягчают их. Это в свою очередь может повлиять на последовательность рассмотрения рисков при других практических приемах и в других частях процесса. Следовательно, необходимо учитывать эти влияния при изучении потенциальных воздействий. Эта практика связана с действиями РА10.
7.2.2.2 Примеры результатов деятельности:
- указатели приоритетов системы и модификаторы воздействий
- краткая характеристика возможностей системы - описывает функциональные возможности системы и их значимость для выполнения назначения системы.
7.2.2.3 Примечания
Функциональные и информационные активы могут интерпретироваться по их ценности и критичности в определенной среде. Ценностью могут быть: функциональная значимость, засекречивание, уровень конфиденциальности и другие средства обозначения воспринимаемой ценности актива для намеченного функционирования и использования системы. Критичность может интерпретироваться как воздействие на функционирование системы, человеческую жизнь, эксплуатационные расходы и другие критические факторы, когда используемая функция компрометируется, модифицируется или недоступна в условиях эксплуатации. Ценность актива может быть также определена относительно его требованиям безопасности. Например, ценность может быть определена как конфиденциальность списка клиентов, доступность межофисной связи или целостность информации о списочном составе. Многие активы являются нематериальными или неявными в противоположность явным. Выбранный метод оценки рисков должен учитывать то, как определяется ценность функциональных возможностей и активов, и назначаются их приоритеты.
7.2.3 ВР.02.02 - Идентифицирует активы системы
Идентификация и характеристика активов системы, которые поддерживают ключевые функциональные возможности или цели обеспечения безопасности системы.
7.2.3.1 Описание
Идентифицирует ресурсы системы и данные, необходимые для поддержки целей обеспечения безопасности или ключевых возможностей (функциональные, деловые функции или функции по выполнению целевых задач) системы. Определяет каждый из этих активов путем оценки его значимости при предоставлении такой поддержки в рамках установленной среды.
7.2.3.2 Примеры результатов деятельности:
- анализ произведенных активов - содержит идентификацию произведенных активов и их значимости для функционирования системы;
- анализ активов системы - содержит идентификацию активов системы и их значимости для функционирования системы.
7.2.3.3 Примечания
Активы толкуются расширительно для включения в систему людей, среду, технические средства и инфраструктуру. Активы также включают в себя данные и ресурсы. Под этим подразумевается не только информация, но также системы (например, связь, поиск данных, приложения и печатные ресурсы). Важность этих активов можно определить как их значимость для ценности и критичности возможностей, которые они поддерживают в определенной среде. В некоторых случаях этой практикой является анализ работы областей процесса от РА09 и РА11.
7.2.4 ВР.02.03 - Выбирает способы измерения воздействия
Выбор способов меры измерения при оценке степени воздействия.
7.2.4.1 Описание
Для определения степени воздействия можно использовать различные способы измерения. Полезно заранее определять способы измерения для использования в конкретной рассматриваемой системе.
7.2.4.2 Примеры результатов деятельности:
- выбранные способы измерения степени воздействия.
7.2.4.3 Примечания
Ограниченный набор согласованных способов измерения минимизирует трудности работы с расходящимися измерениями. Количественные и качественные измерения степени воздействия можно осуществлять различными способами, такими как:
- определение финансовых расходов;
- установление эмпирической шкалы строгости (например, от 1 до 10);
- использование прилагательных из стандартного списка (например, низкая, средняя, высокая).
7.2.5 ВР.02.04 - Определяет взаимодействия способов измерения
При необходимости определяет взаимосвязь между способами измерения, выбранными для этой оценки, и коэффициентами преобразования способов измерения.
7.2.5.1 Описание
Некоторые воздействия требуют оценки посредством различных измерений. Для обеспечения согласованного подхода ко всем случаям подвергания воздействию во время его оценки необходимо установить взаимосвязь между различными измерениями. "Подверганием" считается комбинация угрозы, уязвимости и воздействия, которая может причинить значительный вред. В некоторых случаях измерения необходимо объединить для получения единого обобщенного результата. Следовательно, надо установить подход к требованиям обобщения. При использовании качественных измерений следует также установить правила руководства комбинацией качественных факторов на этапе объединения.
7.2.5.2 Примеры результатов деятельности:
- перечни взаимодействий измерений воздействий - описывают взаимосвязи между измерениями;
- правила объединения измерений воздействий - описывают правила объединения измерений воздействий.
7.2.5.3 Примечания
В качестве примера может служить воздействие метеора, разрушившего здание, где одним потенциальным воздействием могут быть расходы на восстановление здания - 100000 долларов. Другим воздействием может быть лишение крова до восстановления здания - шесть месяцев. Эти два воздействия можно объединить, если установлена стоимость предоставления приюта в месяц - 250 долларов в месяц. Тогда общее воздействие в этом случае будет оценено в 101500 долларов.
7.2.6 ВР.02.05 - Определяет и характеризует воздействия
Определение и характеристика воздействия нежелательных инцидентов посредством или нескольких измерений, или объединенного измерения по выбору.
7.2.6.1 Описание
Начав с активов и возможностей, идентифицированных в BP.02.01 и BP.02.02, определяет наносящие ущерб последствия. Для каждого актива они могут включать в себя несанкционированное раскрытие, модификацию, потерю и/или уничтожение. Воздействия на возможности могут включать в себя прерывание, задержку или понижение устойчивости к внешним факторам.
После создания относительно полного перечня воздействий их можно характеризовать с помощью измерений, определенных в BP.02.03 и BP.02.04. Для этого шага может потребоваться изучение актуарных таблиц, сборников и других источников. Для каждого актива следует учитывать связанную с ним неопределенность измерений.
7.2.6.2 Примеры результатов деятельности:
- перечни подверганий воздействиям - перечень потенциальных воздействий и соответствующих им измерений.
7.2.6.3 Примечания
Оценку воздействий проводят на основе их измерений, определенных в BP.02.03, а воздействия объединены на основе правил, установленных в BP.02.04. В большинстве случаев существует некая неопределенность, связанная с измерениями, и вероятность появления специфического воздействия на них в определенной среде. В целом, полезнее держать факторы неопределенности отдельно, чтобы в случае принятия мер по уточнению рабочих данных можно было увидеть, уточняются ли сами данные или связанная с ними неопределенность.
7.2.7 ВР.02.06 - Осуществляет мониторинг воздействий
Осуществление мониторинга текущих изменений в воздействиях.
7.2.7.1 Описание
Воздействия на любую позицию или ситуацию имеют динамичный характер. Новые воздействия могут стать действующими, а характеристики существующих воздействий могут измениться. Следовательно, важно постоянно контролировать как новые, так и уже существующие воздействия и регулярно корректировать возможность появления новых воздействий. Эта базовая практика тесно связана с обобщенной деятельностью по мониторингу в BP.08.02.
7.2.7.2 Примеры результатов деятельности:
- отчеты по мониторингу воздействий - описывают результаты мониторинга воздействий;
- отчеты об изменениях в воздействиях - описывают изменения в воздействиях.
7.2.7.3 Примечания
Из-за возможности изменения в воздействиях деятельность по оценке воздействий должна быть повторяющейся и проводиться несколько раз для различных условий. Однако повторение оценки воздействий не должно подменять мониторинг воздействий.
7.3 РА03 - Оценивает риск безопасности
7.3.1 Область процесса
7.3.1.1 Краткое описание
Назначением области процесса по оценке риска безопасности является идентификация, анализ и оценивание рисков безопасности системы в определенных условиях (среде). Данная область процесса сосредоточена на выявлении этих рисков, основанном на общепринятом знании того, каким образом возможности и активы уязвимы для угроз. Конкретно эта деятельность включает в себя определение и оценку вероятности появления подверганий. Данный комплекс действий выполняется в любое время в ходе жизненного цикла системы для поддержки решений, связанных с разработкой, обслуживанием и эксплуатацией системы в известной среде.
7.3.1.2 Цели:
- достижение понимания риска безопасности, связанного с эксплуатацией системы в определенной среде;
- назначение приоритетов рискам в соответствии с установленной методологией.
7.3.1.3 Перечень базовых практик
BP.03.01 Выбор методов, технологии и критериев, по которым идентифицируются, анализируются, оцениваются и сравниваются риски безопасности для системы в определенной среде.
BP.03.02 Идентификация угроз/уязвимостей/подвергания воздействиям.
BP.03.03 Оценка рисков, связанных с возникновением факта незащищенности.
BP.03.04 Оценка общей неопределенности, связанной с риском незащищенности.
BP.03.05 Упорядочивание рисков по приоритетам.
BP.03.06 Постоянный контроль текущих изменений в диапазоне рисков и изменений их характеристик.
7.3.1.4 Примечания к области процесса
Риском безопасности является вероятность реализации воздействия нежелательного инцидента. Будучи связанным с проектными рисками, касающимися расходов и графика, риск безопасности имеет дело конкретно с защитой активов и возможностей системы от воздействий.
Оценивание риска всегда включает в себя фактор неопределенности, который изменяется в зависимости от конкретной ситуации. Это означает, что вероятность можно предсказать только в определенных пределах. Кроме того, воздействие, оцененное для определенного риска, также имеет некую неопределенность, поскольку нежелательный инцидент может оказаться ожидаемым. Таким образом, большинство факторов имеют неопределенность в отношении точности связанных с ними прогнозов. Во многих случаях эти неопределенности могут быть значительными. Это в огромной мере затрудняет планирование и обеспечение безопасности.
Все, что может уменьшить связанную с конкретной ситуацией неопределенность, очень важно. Поэтому так важно доверие, которое косвенно снижает риски системы.
Информация о риске, предоставляемая этой областью процессов, зависит от информации об угрозе от РА04, информации об уязвимости от РА05 и информации о воздействии от РА02. Несмотря на то, что действия по сбору информации об угрозах, уязвимостях и воздействиях были сгруппированы в различных частях процесса, они взаимосвязаны. Цель заключается в нахождении комбинаций угрозы, уязвимости и воздействия, которые считаются достаточно рискованными для обоснования принятия мер. Информация о риске формирует основу определения потребности в безопасности в РА10 и входных данных по безопасности, предоставляемых РА09.
Поскольку условия риска подвержены изменениям, они должны периодически контролироваться с тем, чтобы убедиться в поддержании постоянной осведомленности о риске, создаваемом этой областью процессов.
7.3.2 ВР.03.01 - Выбирает метод анализа риска
Выбор методов, технологий и критериев, по которым идентифицируют, анализируют, оценивают и сравнивают риски безопасности для системы в определенной среде и назначают их приоритеты.
7.3.2.1 Описание
Данная практика определяет метод идентификации рисков безопасности для системы в определенной среде способом, который позволяет анализировать, оценивать и сравнивать их. Эта практика должна включать в себя схему категорирования и назначения приоритетов рискам на основе существующих угроз, эксплуатационных функций, установленных уязвимостей системы, потенциальных потерь, требований безопасности или задачных областей процесса.
7.3.2.2 Примеры результатов деятельности:
- метод идентификации риска описывает подход к идентификации риска;
- метод оценки риска описывает подход к анализу и оцениванию рисков;
- форматы оценки риска - описывает формат документирования и отслеживания рисков, включающего их описание, значимость и зависимости.
7.3.2.3 Примечания
Можно использовать уже существующий метод, адаптированный метод или метод, специфический для функциональных аспектов и определенной среды системы. Методология, применяемая для оценки риска, должна согласовываться с методологиями, выбранными для оценки угроз, уязвимостей и воздействий.
7.3.3 ВР.03.02 - Идентифицирует подвергания
Идентификация трех факторов подвергания: угрозам/уязвимостям/воздействиям.
7.3.3.1 Описание
Целью выявления незащищенности является распознавание того, какая из угроз и уязвимостей вызывает опасение, и определение воздействия появления угрозы и уязвимости. Эту незащищенность следует учитывать при выборе мер безопасности для защиты системы.
7.3.3.2 Примеры результатов деятельности:
- перечни видов незащищенности системы - описывает незащищенность системы.
7.3.3.3 Примечания
Эта базовая практика зависит от выходных данных об угрозах, уязвимостях и областей процесса, связанного с рисками.
7.3.4 ВР.03.03 - Оценивает риск подвергания
Оценка рисков, связанных с каждым подверганием.
7.3.4.1 Описание
Определяет последствия и вероятность появления каждого подвергания, объединяет эти значения для получения оценки риска и оценивает риск в сопоставлении с заранее определенными критериями.
7.3.4.2 Примеры результатов деятельности:
- перечень рисков подвергания - перечень расчетных рисков.
7.3.4.3 Примечание
Вероятность подвергания является комбинацией вероятности угрозы и вероятности уязвимости. Во многих случаях необходимо также учитывать вероятность определенной или обобщенной величины или силы воздействия. Во всех случаях будет присутствовать связанная с измерениями неопределенность. Полезнее хранить факторы неопределенности раздельно, чтобы в случае принятия мер по уточнению рабочих данных можно было увидеть, уточнятся ли сами данные или связанная с ними неопределенность. Это часто может воздействовать на стратегии, принятые для рассмотрения рисков. Эта базовая практика использует данные о вероятности, собранные в BP.04.05, BP.05.03 и BP.02.05, для оценки воздействия реализации подвергания или с помощью множественных или обобщенных измерений по выбору.
7.3.5 ВР.03.04 - Оценивает общую неопределенность
Оценивание общей неопределенности, связанной с подверженностью рискам.
7.3.5.1 Описание
Каждый риск обладает неопределенностью. Общая неопределенность риска является накоплением неопределенностей, идентифицированных для угроз, уязвимостей и воздействий и их характеристик в BP.04.05, BP.05.03 и BP.02.05. Эта базовая практика тесно связана с действиями РА06, поскольку доверие может использоваться для изменения неопределенности и в некоторых случаях уменьшать ее.
7.3.5.2 Примеры результатов деятельности:
- подверженность риску с соответствующей неопределенностью - перечень рисков, демонстрирующий меру риска наряду с мерой неопределенности.
7.3.5.3 Примечания
Если неопределенность не сохраняется отдельно от вероятности появления подвергания, то применение мер безопасности может не принести ожидаемых результатов или привести к смягчению последствий реализации риска, когда фактически в этом нет необходимости.
7.3.6 ВР.03.05 - Назначает приоритеты рискам
Упорядочивает риски посредством назначения приоритетов.
7.3.6.1 Описание
Идентифицированные риски следует упорядочивать на основе приоритетов организации, вероятности их появления, неопределенности, связанной с ними, и имеющихся денежных средств. Можно также использовать их комбинации. Риск может снижаться, передаваться, приниматься или его можно избегать. Снижение может касаться угрозы, уязвимости и воздействия или самого риска. Действия должны выбираться с учетом потребностей заинтересованных сторон, как показано в РА10, приоритетов деловой деятельности и общей архитектуры системы.
7.3.6.2 Примеры результатов деятельности:
- перечень приоритетов рисков - перечень, назначающий приоритеты рискам;
- перечень требований к мерам безопасности - перечни возможных мер безопасности, которые могут смягчить риски;
- обоснование назначения приоритетов - описание схемы назначения приоритетов.
7.3.6.3 Примечания
Этот этап может быть очень сложным и часто требует многократного повтора. Меры безопасности могут относиться к многократным рискам или многократным угрозам, уязвимостям и воздействиям. Этот аспект может изменять эффективное упорядочение рассматриваемых рисков. Следовательно, эта область процесса тесно связана с РА10 и РА09.
7.3.7 ВР.03.06 - Осуществляет мониторинг рисков и их характеристик
Осуществление мониторинга изменений в диапазоне рисков и их характеристиках.
7.3.7.1 Описание
Диапазон рисков, применимый к любой позиции и ситуации, имеет динамичный характер. Новые риски могут стать действующими, а характеристики существующих рисков могут измениться. Следовательно, важно осуществлять мониторинг как существующих рисков, так и их характеристик, а также проверять новые риски на постоянной основе. Эта базовая практика тесно связана с обобщенной деятельностью по мониторингу в BP.08.02.
7.3.7.2 Примеры результатов деятельности:
- отчеты о мониторинге рисков - отчеты, описывающие диапазон действующих рисков;
- отчеты об изменениях рисков - описывают функциональные возможности системы и их значимость для выполнения целей системы.
7.3.7.3 Примечания:
Действия по оценке риска в определенных средах из-за возможности изменения рисков должны выполняться несколько раз. Однако повторение оценки рисков не должно подменять их мониторинг. Следует отметить, что термин "диапазон" используется для обозначения новых рисков, а термин "характеристики" относится к свойствам существующих идентифицированных рисков.
7.4 РА04 - Оценивает угрозы
7.4.1 Область процесса
7.4.1.1 Краткое описание
Назначением области процесса "Оценка угроз" является идентификация угроз безопасности и их характеристик.
7.4.1.2 Цели:
- идентификация и определение характеристик угроз безопасности.
7.4.1.3 Перечень базовых практик
BP.04.01 Идентификация соответствующих угроз, исходящих от естественного источника.
BP.04.02 Идентификация соответствующих угроз, исходящих от искусственных источников, случайных или преднамеренных.
BP.04.03 Определение соответствующих единиц измерения и диапазонов в определенной среде.
BP.04.04 Оценка возможностей и мотивации агента (носителя) угрозы в отношении угроз, исходящих от искусственных источников.
BP.04.05 Оценка вероятности появления события, связанного с угрозой.
BP.04.06 Мониторинг текущих изменений диапазона угроз и изменений их характеристик.
7.4.1.4 Примечания к области процесса
Для выполнения оценки угрозы можно использовать различные методы и технологии. Важным фактором определения методологии для использования является то, как она будет согласовываться и работать с методологиями, применяемыми на других участках выбранного процесса оценки риска.
Информация об угрозах, полученная от этой области процесса, предназначена для использования в РА03 наряду с информацией об уязвимостях от РА05 и воздействиях от РА02. Несмотря на то, что действия по сбору информации об угрозах, уязвимостях и воздействиях были объединены в отдельные области процесса, они являются взаимозависимыми. Целью сбора информации является обнаружение комбинаций угрозы, уязвимости и воздействия, которые считаются достаточно рискованными для обоснования действия. Следовательно, поиск угроз должен в определенной степени руководствоваться наличием соответствующих уязвимостей и воздействий.
Вследствие подверженности изменениям воздействий должны периодически подвергаться мониторингу с целью обеспечения постоянного поддержания осведомленности о них, полученной с помощью этой области процесса.
При отслеживании функционирования этой области процесса анализ тенденций, существующий среди различных общих практических приемов, может указать на удовлетворение аргументу доверия (см. РА06).
7.4.2 ВР.04.01 - Идентифицирует естественные угрозы
Идентифицирование угроз, происходящих от естественных источников.
7.4.2.1 Описание
Естественные угрозы исходят от землетрясений, цунами и торнадо. Однако не все угрозы природного происхождения могут возникать повсеместно. Например, цунами не может появиться в центре большого континента. Следовательно, важно определить, какие угрозы естественного происхождения могут возникнуть в конкретном месте.
7.4.2.2 Примеры результатов деятельности:
- применимые таблицы естественных угроз - таблицы, документирующие характер и вероятность естественных угроз.
7.4.2.3 Примечания:
Большую часть информации, требуемую для этой оценки, можно получить из статистических таблиц и баз данных возникновения природных явлений. Из-за ценности этой информации ею надо пользоваться с осторожностью, поскольку она может быть в значительной степени обобщенной, и, следовательно, для применения в конкретной среде может потребоваться ее интерпретация.
7.4.3 ВР.04.02 - Идентифицирует искусственные угрозы
Идентифицирование угроз, исходящих от искусственных источников, как случайных, так и преднамеренных.
7.4.3.1 Описание
Для угроз, исходящих от искусственных источников, требуется несколько иной подход. Существуют два основных типа искусственных угроз: исходящие от случайных источников и угрозы, являющиеся результатом преднамеренного воздействия. Некоторые искусственные угрозы не могут применяться в определенных средах. Они не должны рассматриваться в дальнейшем анализе.
7.4.3.2 Примеры результатов деятельности:
- описания сценариев угроз - описания действий угроз;
- оценки серьезности угроз - измерения вероятности, связанной с какой-либо угрозой.
7.4.3.3 Примечания
В некоторых случаях распознаванию преднамеренной угрозы может помочь разработка сценария, описывающего возможность появления угрозы. Общие базы данных искусственных угроз должны подвергаться оценке на предмет завершенности и уместности.
7.4.4 ВР.04.03 - Определяет единицы измерения угроз
Определение подходящих единиц и диапазонов измерения в определенной среде.
7.4.4.1 Описание
Для большинства естественных и многих искусственных угроз имеются связанные с ними единицы измерения. Примером является шкала Рихтера для землетрясений. В большинстве случаев полный диапазон единиц измерения не применим в каком-либо конкретном месте. Следовательно, уместно установить максимум, а в некоторых случаях минимум, масштабность или частоту возникновения события, которое может возникнуть в определенном месте.
7.4.4.2 Примеры результатов деятельности:
- таблица угроз с соответствующими единицами и диапазонами измерения.
7.4.4.3 Примечания:
При отсутствии единицы измерения для определенной угрозы следует создать единицу измерения, приемлемую для того или иного места. Если это применимо, соответствующий диапазон и единица измерения должны быть описаны в проверяемых терминах.
7.4.5 ВР.04.04 - Оценивает возможности носителя угрозы
Оценка возможностей и мотивации носителя угроз, исходящих от искусственного источника.
7.4.5.1 Описание
Данная область процесса связана с определением потенциальной способности и возможности потенциального противника осуществлять успешную атаку против системы. Данная способность подразумевает осведомленность противников об атаках (например, имеют ли они подготовку/знания). Возможностью является степень вероятности того, что компетентный противник может действительно осуществить атаку (например, имеет ли он достаточно ресурсов).
7.4.5.2 Примеры результатов деятельности:
- описания носителей угрозы - описания и оценки возможностей.
7.4.5.3 Примечания
Преднамеренные искусственные угрозы в значительной степени зависят от возможностей носителя угрозы и ресурсов, находящихся в его распоряжении. Таким образом, сравнительно неопытный хакер, имеющий доступ к инструментарию гораздо более опытных и квалифицированных хакеров, представляет собой довольно опасную угрозу, но не настолько опасную, как опытные хакеры. Однако совсем неопытный хакер также может нанести непреднамеренный ущерб, что вряд ли сделает опытный хакер. Кроме возможностей носителя угрозы, необходимо учитывать оценку ресурсов, имеющихся у носителя, наряду с его мотивацией к выполнению действий, на которую может повлиять вероятная оценка носителем угрозы привлекательности объекта (актива).
Для достижения желаемой цели носитель угрозы может наносить множественные атаки последовательно или параллельно. Необходимо рассмотреть результат множественных атак, проводимых последовательно или параллельно. Выполнению этой задачи может содействовать разработка сценариев угроз.
7.4.6 ВР.04.05 - Оценивает вероятность угроз
Оценка вероятности появления события угрозы.
7.4.6.1 Описание
Оценивает степень вероятности возникновения события, связанного с угрозой. При проведении этой оценки надо учитывать многие факторы от случайного возникновения природного явления до случайных действий отдельного лица. Многие из этих факторов не поддаются оценке или измерению. В целях отчетности желательно иметь согласованную систему показателей по этому вопросу.
7.4.6.2 Примеры результатов деятельности:
- оценка вероятности события, связанного с угрозой - отчет о вероятности возникновения события, связанного с угрозой.
7.4.6. Примечания
Данная оценка представляет собой сложное вычисление, поскольку многие факторы содержат изменяющиеся вероятности. С любой оценкой вероятности связан фактор неопределенности, связанный с ее точностью и достоверностью. О неопределенности оцененной вероятности следует сообщать отдельно с целью избежания возможной путаницы. Во всех случаях будет существовать неопределенность, связанная с измерениями и вероятностью. Обычно предпочтительно сохранять факторы неопределенности, которые являются составными выражениями, отдельно для того, чтобы при принятии мер по уточнению рабочих данных можно было увидеть, уточняются ли сами данные или неопределенность, связанная с этими данными.
7.4.7 ВР.04.06 - Осуществляет мониторинг угроз и их характеристик
Осуществление мониторинга текущих изменений в диапазоне угроз и изменений их характеристик.
7.4.7.1 Описание
Диапазон угроз, применимый к любому месту и ситуации, имеет динамический характер. Новые угрозы могут стать действующими, а характеристики существующих угроз - измениться. Таким образом, важно постоянно контролировать как существующие угрозы, так и их характеристики и регулярно корректировать новые угрозы. Эта базовая практика тесно связана с общей деятельностью по мониторингу в BP.08.02.
7.4.7.2 Примеры результатов деятельности:
- отчеты о мониторинге угроз - документы, описывающие результаты мониторинга угроз;
- отчеты об изменениях угроз - документы, описывающие изменения в спектре угроз.
7.4.7.3 Примечания
Поскольку угрозы в определенных средах могут изменяться, действия по оценке угроз следует проводить многократно. Однако повторение оценки угроз не заменяет мониторинга угроз.
7.5 РА05 - Оценивает уязвимости
7.5.1 Область процесса
7.5.1.1 Краткое описание
Назначением области процесса "Оценка уязвимостей" является идентификация и определение уязвимостей безопасности системы. Эта область процесса включает в себя анализ активов системы, определение специфических характеристик и обеспечение оценки общей уязвимости системы. Термины, связанные с риском безопасности и оценкой уязвимости, используются во многих контекстах по разному. Для данной модели термин "уязвимость" относится к аспекту системы, который можно использовать в целях, отличных от намеченных первоначально, а именно: слабые места, пробелы в безопасности или ошибки при реализации в рамках системы, которые могут быть использованы угрозой. Эти уязвимости не зависят от какой-либо определенной угрозы или атаки. Эта совокупность видов деятельности осуществляется в любое время жизненного цикла системы для поддержки решения о разработке, обслуживании и эксплуатации системы в пределах известной среды.
7.5.1.2 Цели:
- осведомленность об уязвимостях безопасности системы в пределах определенной среды.
7.5.1.3 Перечень базовых практик
BP.05.01 Выбирает методы, технологии и критерии, по которым идентифицируются уязвимости безопасности системы в определенной среде и определяются их характеристики.
BP.05.02 Идентификация уязвимостей безопасности системы.
BP.05.03 Сбор данных, связанных со свойствами уязвимостей.
BP.05.04 Оценка уязвимостей системы и обобщение уязвимостей, являющихся результатом конкретных уязвимостей и их комбинаций.
ВР.05.05 Проведение мониторинга текущих изменений соответствующих уязвимостей и их характеристик.
7.5.1.4 Примечания к данной области процесса
Анализ и практические приемы, связанные с данной областью процессов, часто являются "бумажной работой". Обнаружение уязвимостей системы активными средствами и способами является еще одним методом, который дополняет другие методы анализа уязвимостей, но не подменяет их. Эти активные методы можно рассматривать как специализированный вид анализа уязвимостей. Этот вид анализа может быть полезен при подтверждении уязвимости безопасности системы после ее значительного обновления или идентификации уязвимости системы в случае соединения двух систем. В некоторых случаях активный анализ уязвимости требуется для подтверждения правильности состояния безопасности системы и улучшения осознания и понимания имеющихся уязвимостей безопасности. Активный анализ, иногда называемый испытанием на проникновение, является процессом, посредством которого специалисты по безопасности пытаются обмануть средства защиты системы. Обычно они работают при тех же ограничениях, которые налагаются на обычных пользователей, но имеют всю проектную документацию и документацию по внедрению. Процесс атаки на безопасность не истощает ресурсы, а сдерживается их ограниченностью (время, деньги, персонал и т.д.).
Информация об уязвимостях, полученная от этой области процесса, предназначена для использования в РА03 наряду с информацией об угрозах из РА04 и воздействиях из РА02. Несмотря на то, что действия по сбору информации об угрозах уязвимостях и воздействиях были объединены в отдельные области процесса, они являются взаимозависимыми. Целью является обнаружение комбинаций угрозы, уязвимости и воздействия, которые считаются достаточно рискованными для обоснования действия. Следовательно, поиск уязвимостей должен в определенной степени руководствоваться наличием соответствующих угроз и воздействий.
Вследствие подверженности уязвимостей изменениям они должны периодически контролироваться с целью обеспечения постоянного поддержания осведомленности о них, полученной с помощью этой области процесса.
При отслеживании функционирования этой области процесса анализ тенденций, существующих среди различных общих практических приемов, может указать на удовлетворение аргументу доверия (см. РА06).
7.5.2 ВР.05.01 - Выбирает метод анализа уязвимости
Выбираются методы, технологии и критерии, по которым идентифицируются уязвимости безопасности системы в определенной среде и определяются их характеристики.
7.5.2.1 Описание
Эта базовая практика определяет метод установления уязвимостей безопасности способом, позволяющим их идентифицировать и характеризовать. Это может включать в себя схему категорирования уязвимостей и назначения им приоритетов на основе угроз и их вероятностей, эксплуатационных функций требований безопасности и других проблемных зон (при их наличии). Определение глубины анализа позволяет специалистам по безопасности и заказчику определять целевые системы, предназначенные для использования, и их полноту. Анализ должен проводиться по известной и зафиксированной конфигурации в течение заранее согласованного и заданного периода времени. Методология анализа должна включать в себя ожидаемые результаты. Следует четко формулировать конкретные цели анализа.
7.5.2.2 Примеры результатов деятельности:
- метод анализа уязвимостей - определяет метод обнаружения и изучения уязвимостей безопасности системы, включая анализ, отчетность и процесс отслеживания;
- форматы анализа уязвимостей - описывает формат результатов анализа уязвимостей для обеспечения стандартизированного подхода;
- методология и методика атак - включает цели и метод проведения тестирования атак;
- процедуры атак - подробные этапы проведения тестирования атак;
- планы атак - включает ресурсы атак, график и описание их методологии;
- изучение проникновения - анализ и реализация сценариев атак, направленные на идентификацию неизвестных уязвимостей;
- сценарии атак - описание конкретных атак, которые будут предприниматься.
7.5.2.3 Примечания
Метод анализа уязвимостей может быть действующим, адаптированным или специфическим для эксплуатационных аспектов и определенной среды системы. Он часто основывается на методологии анализа риска, выбранной из РА03, или дополняет ее. Следует отметить, что разъяснение угроз, возможностей и значений может быть не предусмотрено, и в этом случае необходимо сузить область применения методологии или принять набор подходящих допущений.
Метод анализа уязвимостей может быть качественным или количественным. Он часто включает в себя отражение вероятности существования уязвимости. Результаты атак могут передаваться в письменном отчете, но сами атаки могут быть продемонстрированы.
Для идентификации уязвимостей существует, по крайней мере, два принципиально различных метода. Один из них основан на анализе, другой - на тестировании. Основанный на тестировании метод удобен для идентификации существующих уязвимостей, для которых есть известная угроза, включенная в набор тестов. Основанный на анализе метод является лучшим для идентификации новых уязвимостей и уязвимостей, недоступных для использования непосредственно, но которые могут стать доступными после разрешения какой-то другой проблемы. Другими вариантами, которые следует учитывать при выборе методологии идентификации уязвимостей, являются качественный и количественный методы. Следует также учитывать возможность осуществления контроля полноты анализа и тестирования.
7.5.3 ВР.05.02 - Идентифицирует уязвимости
Идентификация уязвимостей безопасности системы.
7.5.3.1 Описание
Уязвимости системы можно обнаружить как в связанных с обеспечением безопасности частях системы, так и в частях, не связанных с ней. Во многих случаях оказывается, что не связанные с безопасностью механизмы, поддерживающие функции безопасности или работающие во взаимодействии с механизмами безопасности, имеют используемые уязвимости. Методологии сценариев атак, разработанной в BP.05.01, надо следовать до тех пор, пока уязвимости не подтвердятся. Все обнаруженные уязвимости системы должны фиксироваться.
7.5.3.2 Примеры результатов деятельности:
- перечень уязвимостей - описывает уязвимость системы для различных атак;
- профиль проникновения - включает в себя результаты тестирования атак (например, уязвимости).
7.5.3.3 Примечания
В данном практическом приеме уязвимости рассматриваются как внутренне присущие системе без учета вероятности каких-либо угроз. Приоритеты упорядочения таких уязвимостей могут быть назначены в соответствии с результатами анализа угрозы. Невоспроизводимые атаки усложняют задачу разработки контрмер.
Уязвимости идентифицируются частично на основе рисков с назначенными приоритетами из РА03, и приоритетов деловой деятельности и целей, обозначенных в РА10. Кроме того, надо учитывать активы, упоминаемые в РА02.
7.5.4 ВР.05.03 - Собирает данные об уязвимостях
Сбор данных, связанных со свойствами уязвимостей. Назначением этой базовой практики является сбор данных, связанных с указанными свойствами. В некоторых случаях уязвимость может иметь единицы измерения аналогичные единицам, связанным с угрозами (см. BP.04.03). Легкость использования уязвимости и вероятность существования уязвимости следует определять и фиксировать.
7.5.4.2 Примеры результатов деятельности:
- таблицы свойств уязвимости - таблицы, документирующие характеристики продукта или системы.
7.5.4.3 Примечания
Большая часть данных, собранных во время этой деятельности, будет использоваться позднее для выполнения РА03. Поэтому важно, чтобы данные собирались и хранились в формате, пригодном для использования РА03. Во всех случаях будет существовать неопределенность, связанная с измерениями и вероятностями. Обычно удобнее хранить неопределенность отдельно, так, чтобы при принятии мер по уточнению данных можно было видеть, уточняются ли сами данные или связанная с ними неопределенность.
7.5.5 ВР.05.04 - Синтезирует уязвимость системы
Оценка уязвимости системы и объединение уязвимостей, вытекающих из конкретных уязвимостей и их комбинаций.
7.5.5.1 Описание
Анализирует, какие уязвимости или комбинации уязвимостей создают проблемы для системы. Анализ должен определять дополнительные характеристики уязвимости, такие как вероятность использования уязвимости и возможность ее успешного использования. В результаты анализа можно также включить рекомендации по рассмотрению синтезированных уязвимостей.
7.5.5.2 Примеры результатов деятельности:
- отчет об оценке уязвимостей - включает в себя количественное или качественное описание уязвимостей, которые создают проблемы для системы, включая вероятность атаки, вероятность ее успеха и ее воздействие;
- отчеты об атаках - документируют результаты и их анализ, включая обнаруженные уязвимости, возможность их использования и любые рекомендации.
7.5.5.3 Примечания
Результаты анализа и осуществления атаки должны регистрироваться. Любые обнаруженные уязвимости и возможность их использования должны идентифицироваться и документироваться достаточно подробно, чтобы заказчик мог принять решение о принятии контрмер.
7.5.6 ВР.05.05 - Осуществляет мониторинг уязвимостей и их характеристик
Проведение мониторинга текущих изменений в соответствующих уязвимостях и их характеристиках.
7.5.6.1 Описание
Диапазон уязвимостей применим повсеместно, а ситуация является динамичной. Новые уязвимости могут стать действующими, а характеристики существующих уязвимостей могут изменяться. Поэтому важно проводить мониторинг существующих уязвимостей и их характеристик, а также постоянно проверять новые уязвимости. Эта практика тесно связана с общей деятельностью по мониторингу в BP.08.02.
7.5.6.2 Примеры результатов деятельности:
- отчеты о мониторинге уязвимостей - документы, описывающие результаты действий по мониторингу уязвимостей;
- отчеты об изменениях уязвимостей - документы, описывающие новые или изменившиеся уязвимости.
7.5.6.3 Примечания
Из-за возможности изменения уязвимостей действия по их оценке должны проводиться несколько раз в определенных средах. Однако они не должны заменять мониторинг уязвимостей.
7.6 РА06 - Создает аргумент доверия
7.6.1 Область процесса
7.6.1.1 Краткое описание
Назначением области процесса является однозначное сообщение о том, что требования безопасности заказчика удовлетворены. Аргументом доверия является набор установленных целей доверия, поддерживаемых свидетельством, которое можно получить от различных источников и уровней абстракции.
Этот процесс включает в себя идентификацию и определение связанных с доверием требований, получение свидетельства и деятельность по проведению анализа и дополнительных связанных со свидетельством действий, необходимых для поддержки требований к доверию. Кроме того, свидетельства, полученные в результате этих действий, собираются, объединяются в пакеты и готовятся к презентации.
7.6.1.2 Цели:
- рабочая продукция и процессы представляют собой четкое доказательство удовлетворения требованиям безопасности заказчика.
7.6.1.3 Перечень базовых практик
BP.06.01 Определяет цели обеспечения доверия к безопасности.
BP.06.02 Определяет стратегию обеспечения доверия для работы со всеми целями обеспечения доверия.
BP.06.03 Определяет меры измерения для мониторинга целей обеспечения доверия к безопасности.
BP.06.04 Идентифицирует и контролирует свидетельства доверия к безопасности.
BP.06.05 Проводит анализ свидетельства доверия к безопасности.
BP.06.06 Предоставляет аргумент доверия к безопасности, демонстрирующий удовлетворение требованиям безопасности заказчика.
7.6.1.4 Примечания к данной области процесса
Действия по созданию аргумента доверия включают в себя управление идентификацией, планированием, пакетированием и представлением свидетельства доверия к безопасности.
При отслеживании функционирования этой области процесса анализ тенденций между различными базовыми практиками может указать на удовлетворение аргумента доверия.
7.6.2 ВР.06.01 - Определяет цели обеспечения доверия
Определение целей обеспечения доверия к безопасности.
7.6.2.1 Описание
Для угроз, исходящих от искусственных источников, требуется несколько иной подход. Существуют два основных типа искусственных угроз: те, которые исходят от случайных источников и те, которые являются результатом преднамеренного воздействия. Некоторые искусственные угрозы не могут применяться в определенных средах. Они не должны рассматриваться в дальнейшем анализе.
Определение новых и модификация существующих целей обеспечения доверия к безопасности координируются со всеми связанными с безопасностью группами проектных организаций и группами, являющимися сторонними для этой организации (например, заказчиком, органом сертификации систем, пользователем).
Цели обеспечения доверия к безопасности обновляются для отражения происходящих изменений. Примеры изменений, требующих модификации целей обеспечения доверия к безопасности, включают в себя изменения степени приемлемости риска заказчиком, органом сертификации систем или пользователем и изменения в требованиях или их трактовках.
О целях обеспечения доверия к безопасности должно быть сообщено для избежания двусмысленности. Включается или (при необходимости) разрабатывается приемлемое объяснение этих целей.
7.6.2.2 Примеры результатов деятельности:
- формулировка целей обеспечения доверия к безопасности - определяет требования заказчика к степени уверенности в характеристиках безопасности системы.
7.6.2.3 Примечания
В случаях, когда конкретное утверждение необязательно, полезно цели обеспечения доверия сформулировать или связать с конкретным утверждением о доверии, которое должно быть получено или удовлетворено. Это помогает устранить неверные толкования и неясности.
7.6.3 BP.06.02 - Определяет стратегию обеспечения доверия
Определение стратегии обеспечения доверия к безопасности для выполнения ее целей.
7.6.3.1 Описание
Целью стратегии обеспечения доверия к безопасности является планирование и обеспечение правильной реализации целей безопасности. Свидетельство, полученное посредством реализации этой стратегии, должно обеспечить приемлемую степень уверенности в адекватности мер защиты системы менеджмента риска безопасности. Эффективное управление связанными с обеспечением доверия действиями достигается посредством разработки и установления в обязательном порядке стратегии обеспечения доверия к безопасности. Ранняя идентификация и определение связанных с обеспечением доверия требований крайне важны для получения необходимого подтверждающего свидетельства. Знание требований заказчика к доверию и мониторинг их выполнения посредством постоянной внешней координации обеспечивает удовлетворение высоких требований доверия к качеству обеспечения безопасности.
7.6.3.2 Примеры результатов деятельности:
- стратегия обеспечения доверия к безопасности - описывает план выполнения целей обеспечения доверия к безопасности заказчика и определяет ответственные стороны.
7.6.3.3 Примечания
Стратегия обеспечения доверия к безопасности координируется со всеми группами проектирования безопасности в организации и сторонними группами (например, заказчиком, органом сертификации систем, пользователем), как определено в РА07.
7.6.4 ВР.06.03 - Определяет измерения безопасности
Определение измерений для мониторинга целей обеспечения доверия к безопасности.
7.6.4.1 Описание
Измерения используются для облегчения принятия решений, улучшения функционирования и подотчетности посредством сбора, анализа соответствующих связанных с функционированием данных и путем сообщения о них. Целью измерения рабочих характеристик является мониторинг состояния процессов обеспечения безопасности и способствование усовершенствованию этих процессов с применением корректирующих действий, основанных на полученных измерениях. Применение измерений упрощает мониторинг осуществления стратегии обеспечения доверия и, следовательно, поддерживает аргумент доверия.
7.6.4.2 Примеры результатов деятельности:
- перечень измерений, согласующихся с целями и стратегиями обеспечения доверия.
7.6.4.3 Примечания
Измерения должны быть количественными по своему характеру и выражаться числами и практическими данными. Они должны быть финансово разумными и соответствовать стоимости проекта (например, расходы на сбор данных не должнысм. превышать ценности собранных данных). Измерения должны проверяться представителями третьей стороны на предмет согласованности результатов. Некоторые измерения могут применяться для анализа тенденций изменения и сообщать об изменениях воздействий за период времени. Результирующие измерения должны быть полезными для принятия решений о месте сосредоточения усилий по реализации проекта. Они должны собираться на самом низком уровне и не делиться по другому формату. Наконец, измерения должны быть хорошо определены с помощью таких характеристик, как частота, формулы, доказательство и показатели. Для данной базовой практики рекомендуется знать измерения, требуемые для оценки других влияний (например, на правительство, на промышленность и т.д.).
7.6.5 ВР.06.04 - Управляет свидетельствами доверия
Идентификация свидетельства доверия к безопасности и управление им.
7.6.5.1 Описание
Свидетельства доверия к безопасности собираются согласно определению в стратегии обеспечения безопасности посредством взаимодействия со всеми областями процессов проектирования безопасности для идентификации свидетельств на различных уровнях абстракции. Эти свидетельства контролируются для обеспечения широкого применения рабочей продукции и ее соответствия целям обеспечения безопасности.
7.6.5.2 Примеры результатов деятельности:
- архив информации свидетельства доверия к безопасности - хранит все доказательства, полученные в процессе разработки, тестирования и использования. Может существовать в виде базы данных, справочника по инжинирингу, тестовых результатов или журнала доказательств.
7.6.5.3 Примечания
Рабочую документацию по доверию можно получить из информации о системе, архитектуре, проекте, реализации, процессе разработки, физической среде разработки и физической среде эксплуатации. Идентификация свидетельств доверия и управление ими способствует сбору данных более высокого качества и повышению эффективности передачи результатов анализа более широкой аудитории, обеспечивая объективный механизм постоянного измерения и улучшения функционирования и результатов общих процессов обеспечения безопасности.
7.6.6 ВР.06.05 - Анализирует свидетельства
Проведение анализа свидетельства доверия к безопасности.
7.6.6.1 Описание
Анализ свидетельств доверия к безопасности проводится для обеспечения уверенности в том, что собранные доказательства отвечают целям обеспечения безопасности, таким образом, удовлетворяя требованиям безопасности заказчика. Анализ свидетельства доверия определяет достаточную степень адекватности и полноты процессов проектирования и верификации безопасности для принятия решения об удовлетворительности реализации характеристик и механизмов обеспечения безопасности. Кроме того, свидетельства подвергаются анализу для гарантирования полноты и правильности артефактов проектирования по отношению к основной системе. В случае недостаточности или неадекватности свидетельства доверия этот анализ может обусловить исправления в системе результатов деятельности по обеспечению безопасности и в процессах, поддерживающих цели обеспечения безопасности.
7.6.6.2 Примеры результатов деятельности:
- результаты анализа свидетельства доверия - идентифицируют и обобщают сильные и слабые места доказательств в архиве информации.
7.6.6.3 Примечания
Некоторые свидетельства доверия можно получить только из объединения других объектов системного проектирования или вывести из обобщения других видов доверия.
7.6.7 ВР.06.06 - Предоставляет аргумент доверия
Предоставление аргумента доверия к безопасности, демонстрирующего удовлетворение требований заказчика.
7.6.7.1 Описание
Общий аргумент доверия разрабатывается для демонстрации соответствия целям обеспечения доверия к безопасности и представляется заказчику. Аргументом доверия является совокупность установленных целей обеспечения доверия, поддерживаемых комбинацией свидетельств доверия, которые можно вывести из многих уровней абстракции. Аргумент доверия должен анализироваться на предмет наличия недостатков в изложении свидетельства, а также недостатков в выполнении целей обеспечения доверия к безопасности.
7.6.7.2 Примеры результатов деятельности:
- аргумент доверия с поддерживающим доказательством - структурированная совокупность целей обеспечения доверия, поддерживаемая различными компонентами свидетельства доверия.
7.6.7.3 Примечания
Высокоуровневый аргумент доверия может заключаться в том, что были выполнены цели соответствующих критериев. Другие вероятные части аргумента доверия могут касаться того, как были рассмотрены угрозы активам системы. Каждая из целей обеспечения доверия поддерживается соответствующим достаточным доказательством для соответствия критерию доказанности. Аргумент доверия может использоваться заказчиком, органом сертификации безопасности систем и пользователями.
Для получения доступа к полной версии без ограничений вы можете выбрать подходящий тариф или активировать демо-доступ.