ГОСТ 1*ИСО/МЭК 15408-1-2002
противостояние угрозе или проведение политики безопасности частично возлагается на 0 0 . а частично на его
среду, соответствующая цель безопасности должна повторяться в каждой категории.
а) Цели безопасности дня ОО должны быть четко изложены и сопоставлены с аспектами установленных
угроз, которым необходимо противостоять средствами ОО. и/илн с политикой безопасности организации,
которой должен отвечать ОО.
б) Цели бетопаспости для среды ОО должны быть четко изложены и сопоставлены с аспектами установ
ленных угроз, которым не полностью противостоит ОО. и/илн с политикой безопасности организации и
предположениями, нс полностью удовлетворяемыми ОО.
Необходимо отмстить, что цели безопасности для среды могут повторять, частично или полностью,
некоторые предположения, сделанные при изложении среды безопасности ОО.
Б.2.6 Т р с б о в а н и я б е з о п а с н о с т и ИТ
В этой части ПЗ подробно определяются требования безопасности ИТ, которые должны удовлетворяться
ОО или сто средой. Требования безопасности ОО должны быть ипожены следующим образом.
а) При изложении требовании безопасности ОО должны быть определены функциональные требования
и требования доверия, которым должны удовлетворять ОО и свидетельства поддержки сто оценки для дости
жении целей безопасности ОО. Требования безопасности ОО должны излагаться следующим образом.
1) При изложении функциональных требований безопасности ОО следует определять функциональные
требования к ОО, где это возможно, как функционатьные компоненты, выбираемые из части 2 ОК.
Беги требуется охватить различные аспекты одного и того же требования (например, при идентификации
пользователей нескольких типов), то возможно повторение использования одного и тот же компонента из
части 2 ОК (т. с. применение к нему операции итерации), чтобы охватить каждый аспект.
Если требования доверия к (X) включают компонент AVA_SOF.l (например, ОУД2 и выше), то при
изложении функциональных требований безопасности ОО должен устанавливаться минимальный уровень
стойкости атя функций безопасности, реализуемых с помощью вероятностного или перестановочного меха
низма (например, пароля или хэш-функции). Все подобные функции должны удовлетворять этому минимать-
ному уровню. Уровень должен быть одним из следующих: базовая СФБ. средняя СФБ и высокая СФБ. Уровень
должен выбираться в соответствии с устаноаленными целями безопасности ОО. Для достижения некоторых
целей безопасности ОО могут быть определены специальные метрики стойкости функций для выбранных
функциональных требований.
Каксоставная частьоценки стойкости функций безопасности ОО (AVA_SOF.I) будут оценены и утверждения
стойкости, сделанные
ДЛЯ
отдельных функции безопасности ОО. и мшшматьный уровень стойкости для ОО в целом.
2) При изложении требований доверия к безопасности ОО следует определить их как один из ОУД,
возможно, усиленный другими компонентами доверия из част 3 ОК. Расширение ОУД в ПЗ может осущест
вляться за счет явною включения дополнительных компонентов доверия, нс содержащихся в этой части.
б) Необязательное наложение требований безопасности атя среды ИТ должно определять требования
безопасности ИТ. которым должна отвечать среда ИТ этою ОО. Если безопасность ОО не зависит от среды
ИТ. то эта часть ЗБ может быть опущена.
Отмстим, что хотя требования безопасности среды, нс относящиеся к ИТ. часто бывают полезны на
практике, истребуется, чтобы они яатялисьформальной частью ПЗ. посколькуони несвязаны непосредственно с
реализацией ОО.
в) Перечисленные ниже общие условия в равной степени относятся к выражению функциональных
требований и требований доверия как для ОО, так и для сто среды ИТ.
1) Когда это применимо, все требования безопасности ИТ следует вводить ссылкой на компоненты
требований безопасности из частей 2 и 3 ОК. Если при формировании всех либо части требований ire
применимы компоненты из частей 2 или 3, то в ПЗ допускается сформулировать необходимые требования
безопасности явным образом, без ссылки на содержание ОК.
2) Все функциональные требовании и требования доверия к ОО. сформулированные явным образом,
должны быть четко и однозначно выражены, чтобы были возможны оценка и демонстрация соответствия им.
Уровень детализации и способ выражения функциональных требований и требований доверия, принятый в ОК.
должны использоваться как образен.
3) Если выбраны компоненты требований, в которых специфицированы требуемые операции (назначе
ние, выбор), то эти операции должны использоваться в ПЗ для конкретизации требований до уровня детали
зации, необходимого ятя демонстрации достижения целей безопасности. Все разрешенные операции, которые
не исполнены в ПЗ. должны быть отмечены как незавершенные.
4) При изложении требований безопасности ОО допускается дополнительно разрешать или запрещать,
при необходимости, использование определенных механизмов безопасности, применяя разрешенные операции
нал компонентами требований.
5) Следует удовлетворить все зависимости между требованиями безопасности ИТ. Зависимости могут
быть удовлетворены включением необходимых требований в состав требований безопасности ОО или требо
ваний к среде.
Б.2.? З а м е ч а н и я по п р и м е н е н и ю
Эта часть ПЗ не является обязательной и может содержать дополнительную информацию, которая
считается уместной или полезной ятя создания, оценки и использования ОО.
27