9. Спецификация раздела "Определение проблемы безопасности"

9 Спецификация раздела "Определение проблемы безопасности"

9.1 Введение

В данном разделе приведено руководство по спецификации раздела "Определение проблемы безопасности" (ОПБ) в ПЗ или ЗБ. В ГОСТ Р ИСО/МЭК 15408-1 (подразделы А.6 и В.6) описывается спецификация раздела "Определение проблемы безопасности" для ЗБ и ПЗ соответственно. При этом в подразделе В.6 просто приводится ссылка на подраздел А.6, что можно считать подтверждением того, что ожидаемое содержание раздела "Определение проблемы безопасности" одинаково для ПЗ и ЗБ. Действительно, формулировки соответствующих критериев оценки в ГОСТ Р ИСО/МЭК 15408-3 идентичны.

Целью определения проблемы безопасности является формализованное определение характера и масштаба проблемы безопасности, которую должен решать ОО (см. рисунок 1).

Рисунок 1 - Определение проблемы безопасности

В тех ПЗ и ЗБ, в структуре которых предусмотрен раздел "Определение проблемы безопасности", данный раздел является одним из наиболее важных разделов. Ниже приведен соответствующий фрагмент из ГОСТ Р ИСО/МЭК 15408-1 (пункт А.6.1):

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

Если проблема определена неправильно или описана нечетко, то остальные части ПЗ или ЗБ также будут являться неправильными. Что еще хуже, на основании технически правильной, но неподходящей спецификации может быть выбран или приобретен продукт не тот, который нужен. Поэтому в настоящем стандарте раздел 9 является одним из самых объемных и наиболее подробных, хотя описанным в нем критериям в ГОСТ Р ИСО/МЭК 15408 отведено только две или три страницы текста. Для разработчика и для заказчика независимо от того, будет ли ПЗ или ЗБ использоваться в процессе приобретения на основе спецификации или в процессе приобретения на основе выбора, правильное определение проблемы безопасности имеет первостепенное значение.

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

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

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

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

в) документирование применимых политик;

г) документирование применимых предположений;

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

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

В предложенном методическом подходе рассматриваются также два других аспекта, которые не требуются в обязательном порядке согласно ГОСТ Р ИСО/МЭК 15408, но которые, как показала практика, позволяют сэкономить время и избежать противоречий на последующих стадиях разработки ПЗ или ЗБ, а именно:

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

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

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

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

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

9.2 Определение неформализованных требований безопасности

9.2.1 Введение

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

9.2.2 Источники информации

9.2.2.1 Аннотация

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

9.2.2.2 Требуемые функциональные возможности

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

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

9.2.2.3 Оценка риска

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

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

9.2.2.4 Оценка угроз

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

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

9.2.2.5 Политика руководства

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

9.2.2.6 Презентационная политика

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

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

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

9.2.2.7 Политика оценки

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

9.2.3 Документирование неформализованных требований

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

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

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

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

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

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

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

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

б) атрибуты безопасности или характеристики безопасности, которыми должен обладать продукт ИТ;

в) атрибуты или характеристики безопасности, которые не являются необходимыми для продукта ИТ.

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

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

9.3 Идентификация и спецификация угроз

9.3.1 Введение

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

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

Для проведения анализа угроз необходимо:

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

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

в) применить методический подход.

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

9.3.2 Выбор методологии анализа угроз

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

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

Существуют различные методические подходы, которые могут быть использованы для проведения анализа угроз. Однако большинство разработчиков ПЗ и ЗБ используют один из трех методов:

а) анализ дерева угроз;

б) поиск по базе данных угроз;

в) специальная идентификация.

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

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

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

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

В настоящее время ФСТЭК России разработана и поддерживается национальная база данных угроз безопасности информации с помещением информации на общедоступном ресурсе.

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

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

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

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

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

9.3.3 Идентификация аспектов угроз

9.3.3.1 Введение

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

9.3.3.2 Источники угроз

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

а) нарушители;

б) уполномоченные пользователи;

в) привилегированные пользователи;

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

д) владельцы и разработчики системы.

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

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

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

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

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

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

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

9.3.3.3 Типы активов

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

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

Активы, связанные с системами ИТ, обычно относятся к одному из трех классов:

а) информационные активы;

б) процессы;

в) физические активы.

Информационные активы являются данными, представляющими ценность для организации - владельца активов (оператора). Примерами возможных типов информационных активов являются:

- данные общего характера;

- системные данные;

- специализированные базы данных;

- клиентские данные.

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

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

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

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

В некоторых случаях разные типы данных ФБО могут быть уязвимы в отношении разных атак или их компрометация может приводить к разным последствиям, поэтому их требуется рассматривать раздельно. Примерами разных типов данных ФБО могут быть:

- данные конфигурации ФБО;

- база аутентификационных данных;

- записи аудита.

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

- финансовые;

- коммуникационные;

- логистические;

- производственные;

- процессы автоматизации офисной работы.

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

Применительно к системе, как правило, есть возможность идентифицировать наименования и характеристики процессов, подлежащих защите.

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

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

- важные элементы сетевой инфраструктуры;

- портативные персональные компьютеры;

- центры обработки данных.

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

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

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

9.3.3.4 Негативные действия

В ГОСТ Р ИСО/МЭК 15408 отсутствует руководство по поводу того, каким образом следует описывать негативные действия. Что касается источников угроз, лучше всего, чтобы перечень описаний негативных действий был по возможности как можно более простым. Пример простого, но при этом достаточного по области охвата перечня:

- несанкционированный доступ;

- несанкционированная передача прав доступа;

- отказ в доступе субъекту, имеющему право доступа;

- отсутствие подотчетности.

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

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

9.3.4 Применение выбранного методического подхода к проведению анализа угроз

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

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

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

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

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

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

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

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

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

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

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

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

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

9.3.5 Практические рекомендации

Угрозы указывают на возможные способы совершить атаку на продукт ИТ. Поэтому их следует формулировать соответствующим образом. Целесообразнее использовать глагол "может". Например:

"Неуполномоченное лицо может попытаться получить доступ и использовать ресурсы ОО".

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

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

"Угроза-1

1. Аннотация угрозы - подключение к информационной системе внутренними и (или) внешними нарушителями незарегистрированных (неучтенных) съемных машинных носителей информации с последующей несанкционированной записью (передачей) на эти носители защищаемой информации из информационной системы.

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

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

4. Используемые уязвимости - отсутствие или недостаточность мер контроля за использованием съемных машинных носителей информации в информационной системе.

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

6. Нарушаемые свойства безопасности информационных ресурсов - конфиденциальность.

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

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

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

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

"Предполагается, что администраторы не относятся к злонамеренным пользователям, они являются доверенными и компетентными пользователями".

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

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

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

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

9.4 Идентификация и спецификация политик

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

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

"Администраторы должны пройти аутентификацию до предоставления им доступа к каким-либо функциям или данным ОО".

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

Ниже также приведены примеры изложения политик на базе профиля защиты ФСТЭК России для средств контроля подключения съемных машинных носителей информации:

"Политика безопасности-1

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

...

Политика безопасности-4

Должен обеспечиваться контроль использования интерфейсов ввода (вывода) в СВТ при подключении съемных машинных носителей информации.

Политика безопасности-5

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

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

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

Политики используются для спецификации:

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

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

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

- уверенность в существовании конкретной угрозы отсутствует, но, несмотря на это, было принято "политическое" решение обеспечить соответствующую защиту;

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

- было принято "политическое" решение о выборе конкретного подхода для противодействия ряду соответствующих угроз.

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

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

На практике большую часть политик легко идентифицировать и четко сформулировать. Однако следует отметить наличие некоторых общих проблем.

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

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

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

Не для всех определений проблем безопасности требуется наличие политик. Это вполне допустимо и не противоречит ГОСТ Р ИСО/МЭК 15408. В таких случаях раздел "Политика безопасности организации" следует оставить незаполненным с указанием, что политики не были идентифицированы.

9.5 Идентификация и спецификация предположений

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

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

"ОО будет размещен в месте, для которого обеспечивается физическая защита".

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

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

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

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

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

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

В ГОСТ Р ИСО/МЭК 15408 установлено, что предположения "могут быть по отношению к физическим аспектам, персоналу и аспектам связности среды функционирования" (ГОСТ Р ИСО/МЭК 15408-1, пункт А.6.4).

Ниже также приведены примеры предположений на базе профиля защиты ФСТЭК России для средств контроля подключения съемных машинных носителей информации:

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

Предположение-1

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

Предположения по отношению к аспектам связности среды функционирования

Предположение-2

Обеспечивается надежный источник меток времени для записи событий аудита безопасности СКН.

Предположение-3

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

Предположения, связанные с персоналом среды функционирования

Предположение-4

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

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

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

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

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

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

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

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

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

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

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

Не для всех проблем безопасности требуется наличие предположений. Это вполне допустимо и не противоречит ГОСТ Р ИСО/МЭК 15408. В таких случаях подраздел "Предположения безопасности" следует оставить незаполненным, указав, что предположения не были идентифицированы.

9.6 Оформление раздела "Определение проблемы безопасности"

Заключительный этап формирования раздела "Определения проблемы безопасности" состоит в его окончательном оформлении и включает в себя решение следующих двух задач:

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

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

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

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

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

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