5.2 SSOIS設計和實現

5.2.1 配置管理

5.2.1.1 配置管理能力

應確保SSOIS在提交用戶運行之前是正確和完備的，所有配置項不會缺少，并能防止對SSOIS配置項進行未授權的增加、刪除或修改。根據對配置管理的不同要求，配置管理（CM）能力分為：

a） 版本號：開發者所使用的版本號與所應表示的SSOIS樣本應完全對應，沒有歧義；

b） 配置項：配置項應有唯一的標識，從而對SSOIS的組成有更清楚的描述；

c） 授權控制：開發者用對SSOIS的唯一引用作為其標簽，從而使SSOIS的使用者明確自己使用的是哪一個樣本；使SSOIS不會受到未經授權的修改。為此，授權控制要求：

——CM計劃應描述系統是如何使用的，并說明運行中的CM系統與CM計劃的一致性；

——CM文檔應足以說明在CM系統下有效地維護了所有的配置項；

——CM系統應確保對配置項只進行授權修改；

d） 生成支持和驗收過程：確認對配置項的任何生成和修改都是由授權者進行的。為此，CM系統應支持SSOIS的生成，驗收計劃應描述用來驗收修改過的或新建的配置項的過程，并作為SSOIS的一部分；

e） 進一步的支持：集成過程應有助于確保由一組被管理的配置項生成SSOIS的過程是以授權的方式正確進行的，并要求CM系統有能力標識用于生成SSOIS的主拷貝的材料，這有助于通過適當的技術，以及物理的和過程的安全措施來保持這些材料的完整性。為此，CM的進一步支持要求：

——CM文檔除應包括配置清單、CM計劃外，還應包括一個驗收計劃和集成過程，集成過程應描述在SSOIS制作過程中如何使用CM系統；

——CM系統應要求將一個配置項接收到CM中的不是該配置項的開發者；

——CM系統應明確標識組成SSF的配置項；

——CM系統應支持所有對SSOIS修改的審計，至少應包括操縱者、日期、時間等信息；

——CM系統應有能力標明用于生成SSOIS主拷貝的所有材料；

——CM文檔應闡明CM系統與開發安全方法相聯系的使用，并只允許對SSOIS作授權的修改；

——CM文檔應闡明集成過程的使用能夠確保SSOIS的生成是以授權的方式正確進行的；

——CM文檔應闡明CM系統足以確保負責將某配置項接收到CM中的不是該配置項的開發者；

——CM文檔應能證明接收過程對所有配置項的修改都提供了充分而適當的復查。

5.2.1.2 配置管理自動化

應通過CM自動化增加CM系統的有效性，使所設計的SSOIS不易受人為錯誤或疏忽的影響。這里的SSOIS是就純軟件而言的，通過引進自動化的CM來協助SSOIS配置項的正確生成，并確定SSOIS與其以前版本之間的變化及將來版本的改變。根據對配置管理的不同要求，CM自動化分為：

a） 部分CM自動化：應確保SSOIS的實現表示是通過自動方式控制的，從而解決復雜實現或眾多合作者合作開發，以及在開發過程中多種變化情況所出現的人工難以解決的問題，并確保這些變化是已授權的行為所產生的。部分CM自動化要求：

——SSOIS的開發者所使用的CM系統應通過所提供的自動方式來確保SSOIS的實現表示只能進行已授權的變化，并能提供自動方式來支持SSOIS的生成；

——開發者所提供的CM計劃應描述CM系統中所使用的自動工具，并說明如何使用這些工具；

b） 完全CM自動化：除了與上述部分CM自動化有相同的內容外，還能自動確定SSOIS版本間的變化，并標識出哪個配置項會因其余配置項的修改而受到影響。

5.2.1.3 配置管理范圍

應通過確保CM系統跟蹤所有必須的SSOIS配置項來保證這些配置項的完整性。根據對配置管理的不同要求，CM范圍分為：

a） SSOIS配置管理范圍：將SSOIS的實現表示、設計文檔、測試文檔、用戶文檔、安全管理員文檔、CM文檔等置于CM之下，從而確保它們的修改是在一個正確授權的可控方式下進行的，為此要求開發者所提供的CM文檔應：

——展示CM系統能跟蹤被置于CM之下的內容；

——描述CM系統是如何跟蹤這些配置項的；

——提供足夠的信息證明達到所有要求；

b） 問題跟蹤配置管理范圍：除SSOIS配置管理范圍描述的內容外，特別強調對安全缺陷的跟蹤；

c） 開發工具配置管理范圍：除問題跟蹤配置管理范圍所描述的內容外，特別強調對開發工具和相關信息的跟蹤。

5.2.2 分發和操作

5.2.2.1 分發

應通過系統控制、分發工具和分發過程確保接收方所收到的SSOIS產品正是發送者所發送的，且沒有任何修改，主要目標是在分發過程中能夠檢測和防止對SSOIS的任何修改。根據對分發和操作的不同要求，分發分為：

a） 分發過程：應將SSOIS或其部分的分發以文檔形式提供給用戶，分發文檔應描述給用戶分發SSOIS的各版本時用以維護安全所必須的所有過程，并按該過程進行分發；

b） 修改檢測：除按分發過程的要求進行SSOIS的分發外，分發文檔還應：

——描述檢測修改的方法和技術，并描述開發者的主拷貝與用戶收到的版本之間的差異；

——描述用來檢測試圖偽裝成開發者向用戶發送產品的方法；

c） 修改防止：在修改檢測的基礎上，分發文檔還應描述如何防止修改的方法和技術。

5.2.2.2 操作（安裝、生成和啟動）

應確保在開發者所期望的安全方式下進行安裝、生成和啟動，將處于配置控制下的SSOIS的實現表示安全地轉換為用戶環境下的初始操作。安裝、生成和啟動過程可以以獨立的文檔進行描述，也可以與其它管理員文檔一起描述。根據對分發和操作的不同要求，操作分為：

a） 安裝、生成和啟動過程：要求開發者以文檔形式提供對SSOIS安全地進行安裝、生成和啟動的過程進行說明，并確保最終生成了安全的配置；

b） 日志生成：要求文檔應描述建立日志的過程，該日志包含了用以生成SSOIS的生成選項，從而能夠明確決定SSOIS是何時及如何產生的。

5.2.3 開發

5.2.3.1 功能設計

根據要求的形式化程度和所提供的SSF外部接口的詳細程度，根據對開發的不同要求，功能設計分為：

a） 非形式化功能設計：應使用非形式化風格來完備地描述SSF及其外部接口，功能設計應當是內部一致的，并且應描述所有外部SSF接口的使用目的與方法，適當的時候，還要提供結果例外情況和錯誤信息的細節；

b） 完全定義的外部接口：除上述非形式化功能設計的要求外，功能設計還應完備地表示SSF的基本原理；

c） 半形式化功能設計：應使用半形式化風格來完備地描述SSF及其外部接口，必要時可由非形式化、解釋性的文字來支持。其余要求與上述相同；

d） 形式化功能設計：應使用形式化風格來描述SSF及其外部接口，必要時由非形式化、解釋性的文字來支持。其余要求與上述相同。

5.2.3.2 安全策略模型化

通過開發基于SSP策略的安全策略模型，并建立功能設計、安全策略模型和SSP策略之間的對應性的方法，確保功能設計中的安全功能實施SSF中的策略。根據對開發的不同要求，安全策略模型化分為：

a) 非形式化SSOIS安全策略模型：SSP模型應闡明功能設計與SSP模型之間的對應性，并滿足：

——SSP模型應是非形式化的，并描述所有可以模型化的SSP策略的規則與特征；

——SSP模型應包括一個基本原理，闡明該模型與所有可模型化的SSP策略是一致的、完備的；

——SSP模型和功能設計之間的對應性闡明應說明功能設計中的安全功能與SSP模型是一致的、完備的；

b) 半形式化SSOIS安全策略模型：除上述非形式化SSOIS安全策略模型的要求外，要求所提供的SSP模型應是半形式化的；

c) 形式化SSOIS安全策略模型：除上述半形式化SSOIS安全策略模型的要求外，要求所提供的SSP模型應是形式化的。

5.2.3.3 高層設計

應通過對SSF的每個子系統的功能及其相互關系的描述，實現SSOIS的安全功能要求。根據對開發的不同要求，高層設計分為：

a） 描述性高層設計要求：

——以子系統的觀點、以非形式化的方法來一致性地描述SSOIS的體系結構；

——描述每一個子系統所提供的安全功能及其相互關系；

——標識SSF要求的任何基礎性的硬件、固件和/或軟件，并且通過這些硬件、固件和/或軟件所實現的保護機制，來提供SSF功能；

——標識SSF子系統的所有接口，并標明SSF子系統的哪些接口是外部可見的；

b） 安全加強的高層設計：除描述性高層設計要求外，還應當描述SSF子系統所有接口的使用目的與方法，并提供例外情況和錯誤信息的細節，以及描述如何將SSOIS分離成SSP加強單元和其它子系統；

c） 半形式化高層設計：除安全加強的高層設計要求外，高層設計的表示應是半形式化的，并對SSF子系統提供所有結果的完整細節；

d） 形式化高層設計：除半形式化高層設計要求外，高層設計的表示應是形式化的。

5.2.3.4 低層設計

應對SSF的每一個模塊描述它的目的、功能、接口、依賴性和所有SSP加強功能的實現。根據對開發的不同要求，低層設計分為：

a) 描述性低層設計，要求：

——低層設計的表示應是非形式化的，內在一致的，并以模塊術語描述；

——描述每一個模塊的目的；

——以所提供的安全功能和對其它模塊的依賴性術語定義模塊間的相互關系；

——描述如何提供每一個SSP功能的實施；

——標識SSF 模塊的所有接口，標識SSF 模塊的哪些接口是外部可見的，以及描述SSF 模塊所有接口的目的與方法，必要時，應提供影響、例外情況和錯誤信息的細節；

——描述如何將SSOIS分離成SSP實施模塊和其它模塊；

b) 半形式化低層設計：除描述性低層設計要求外，低層設計應當是半形式化的，并在必要時提供所有結果的完備細節、例外情況和錯誤信息；

c) 形式化低層設計：除半形式化低層設計要求外，低層設計的表示應當是形式化的。

5.2.3.5 SSF內部結構

應采用模塊化、層次化、復雜度最小化進行SSF的內部結構設計，從而簡化SSF的設計，達到可分析的程度。根據對開發的不同要求，SSF內部結構分為：

a） 模塊化：應以模塊化方法設計和構建SSF，并避免設計模塊之間出現不必要的交互，為此要求：

——標識SSF模塊，并應描述每一個SSF模塊的目的、接口、參數和影響；

——描述SSF設計是如何使獨立的模塊間避免不必要的交互作用；

b） 層次化：除模塊化的要求外，還應以分層的方式設計和構建SSF，使設計層次之間的交互作用最小化，為此要求：

——在設計和構建SSF時，應使SSF局部的復雜度最小化，以加強訪問控制策略；

——標識SSF模塊，并應指明SSF的哪些部分是加強安全策略的；

——描述分層結構，并說明如何使交互作用最小化；

——描述加安全策略的SSF部分是如何被構建的，從而使其復雜性降低；

c） 復雜度最小化：除層次化要求外，還應使SSF的設計和構建使整個SSF的復雜度最小化，為此要求：

——在設計和構建SSF時，應使實施任何安全策略的SSF部分“簡單到足以進行分析”；

——應確認那些與SSF無關的功能都已從SSF中排斥出去。

5.2.3.6 實現表示

應以源代碼、固件或硬件等來表述SSF的具體符號表示，從而可以獲得SSF內部的詳細工作情況。根據對開發的不同要求，實現表示分為：

a） SSF子集實現：應無歧義地為選定的SSF子集定義一個詳細級別的SSF實現表示，并且實現表示應當是內在一致的；

b） SSF完全實現：應為整個SSF提供實現表示，并應描述各部分之間的關系。其余要求與SSF子集實現相同；

c） SSF的結構化實現：實現表示應是構造較小的，且易于理解。其余要求與SSF完全實現相同。

5.2.3.7 表示的對應性

各種SSF表示，如功能設計、高層設計、低層設計、實現表示等相鄰表示之間在相應嚴格程度上應具有對應性。根據對開發的不同要求，表示的對應性分為：

a） 非形式化對應性說明：應在所提供的SSF表示的所有相鄰對之間提供其對應性分析，對每個相鄰對，應當闡明較為抽象的SSF表示的所有相關安全功能在較不抽象的SSF表示中得到正確而完備地細化；

b） 半形式化對應性說明：除非形式化對應性要求外，當SSF表示的兩個相鄰對的各部分至少都是以半形式化來描述時，其對應性說明也應是半形式化的；

c） 形式化對應性說明：除半形式化對應性要求外，還要求：

——對那些形式化規定的表示的相應部分，應證明其對應性；

——對所提供的SSF表示的每個相鄰對，當其中一個表示是半形式化規定，而另一個表示至少是半形式化規定時，表示部分之間的對應性說明也應是半形式化的；

——對于所提供的SSF表示的每個相鄰對，如果兩者的各部分都是形式化規定的，表示部分之間的對應性的說明也應是形式化的。

5.2.4 文檔要求

5.2.4.1 安全管理員指南

應描述設置、維護和管理SSOIS的正確方式和方法，最大限度地保證SSOIS安全運行。安全管理員指南應幫助安全管理員理解SSOIS所提供的安全功能，包括要求安全管理員應采取的緊急安全措施和應提供的緊急安全信息。安全管理員指南應包括以下內容：

a) 描述安全管理員可使用的管理功能和接口；

b) 描述如何以安全的方式管理SSOIS；

c) 說明在安全處理環境中安全管理員可獲取的功能和權限的警告；

d) 描述所有與安全操作有關的用戶行為的假設；

e) 描述所有受安全管理員控制的安全參數；

f) 描述每一種與管理功能有關的安全相關事件，包括改變安全功能所控制的實體的安全特性；

g) 描述與安全管理員有關的系統環境的所有安全要求。

5.2.4.2 用戶指南

應描述SSF提供的安全功能，安全功能使用的命令和指導方針，包括警報信息說明等。用戶指南提供關于SSOIS的使用和可信度的測量的假設基礎，使非惡意的用戶、應用提供者和其他使用SSOIS外部接口的人員都能理解SSOIS安全操作并自覺執行。用戶指南可對兩類不同用戶提供單獨的文檔：一類是一般的操作員用戶，另一類是使用軟硬件接口的應用程序員和/或硬件設計員。用戶指南應包含以下內容：

a) 描述非安全管理員用戶可用的功能和接口；

b) 描述用戶可獲取的安全功能和接口的用法；

c) 說明在安全處理環境中用戶可獲取的功能和權限的警告；

d) 闡明安全操作中用戶應負的責任，包括在安全環境中能找到的用戶行為的假設；

e) 描述與用戶有關的系統環境的所有安全要求。

5.2.5 生存周期支持

5.2.5.1 開發安全

應采用物理上、程序上、人員上以及其它方面的安全措施，保護SSOIS開發環境的安全，包括開發場地的物理安全和對開發人員的選擇；應采取適當的防護措施來消除或降低SSOIS開發所面臨的安全威脅。根據對生存周期支持的不同要求，開發安全分為：

a） 安全措施的說明：提供的開發安全文件應包括以下內容：

——描述在SSOIS的開發環境中，為保護SSOIS設計和實現的安全性，在物理上、程序上、人員上以及其它方面必要的安全措施；

——提供在SSOIS的開發和維護過程中執行安全措施的證據；

b） 安全措施的充分性：除安全措施說明的要求外，開發安全文件中所提供的安全措施的證據應能證明安全措施對維護SSOIS的安全性提供了必要的保護。

5.2.5.2 缺陷糾正

應跟蹤和糾正SSOIS的缺陷，并提供缺陷信息和糾正缺陷所采取的策略和過程。根據對生存周期支持的不同要求，缺陷糾正分為：

a） 基本缺陷糾正：要求缺陷糾正程序文檔中應：

——描述用以跟蹤所有SSOIS版本里已被報告的安全缺陷的過程；

——描述所提供的每個安全缺陷的性質和效果，以及缺陷糾正的情況；

——標識每個安全缺陷所采取的糾正措施；

——描述為SSOIS用戶的糾正行為所提供的信息，糾正和指導的方法。

b) 缺陷報告：除基本缺陷糾正外，還應提供缺陷報告。缺陷報告應：

——記錄缺陷糾正的過程，并制定用戶接受安全缺陷報告和糾正這些缺陷的要求的措施；

——描述用以跟蹤所有SSOIS版本里已報告的安全缺陷的過程；

——確保已報告的安全缺陷處理過程的所有已知缺陷都已被糾正，并將糾正辦法告知用戶；

——確保已報告的安全缺陷處理過程所提供的防范機制為糾正這些安全缺陷所引進的糾正方法不會帶來新的缺陷；

c) 有組織缺陷糾正：除缺陷報告外，還應為用戶有關SSOIS的安全問題的報告和查詢指明一個或多個特別聯系點，負責及時將安全缺陷報告及其相應的糾正方法自動分發給可能受到這種安全缺陷影響的注冊用戶。

5.2.5.3 生存周期定義

應在SSOIS的生存周期內建立SSOIS開發和維護的模型。生存周期模型應包括用于開發和維護SSOIS的過程、工具和技術。這個模型所涉及的內容包括設計方法、復查過程、項目管理控制、轉換控制過程、測試方法和接收過程。根據對生存周期支持的不同要求，生存周期定義分為：

a） 開發者定義的生存周期模型：開發者應建立用于開發和維護SSOIS的生存周期模型，對SSOIS開發和維護提供必要的控制，并以文檔形式描述用于開發和維護SSOIS的模型；

b） 標準生存周期模型：開發者應建立標準化的、用于開發和維護SSOIS的生存周期模型。標準化的生存周期模型應是為某些專家組(例如學科專家、標準化實體等)所認可的模型。該模型應對SSOIS開發和維護提供必要的控制。開發者所提供的生存周期定義文檔應描述用于開發和維護SSOIS的模型，解釋選擇該模型的原因，解釋如何用該模型來開發和維護SSOIS，以及闡明與標準化的生存周期模型的相符性；

c） 可測量的生存周期模型：開發者應建立標準化的、可測量的、用于開發和維護SSOIS的生存周期模型。可測量的生存周期模型應帶有算術參數和/或測量SSOIS開發特性的度量(例如源碼復雜性度量)。該模型應對SSOIS開發和維護提供必要的控制。開發者所提供的生存周期定義文檔應描述用于開發和維護SSOIS的模型，并解釋選擇該模型的原因，解釋如何用該模型來開發和維護SSOIS，闡明與標準化的可測量的生存周期模型的相符性，以及提供利用標準化的可測量的生存周期模型來進行SSOIS開發的測量結果。

5.2.5.4 工具和技術

應明確定義用于開發、分析和實現SSOIS的工具，如編程語言、文檔、實現標準和其它支持SSOIS 運行的程序庫等，無需進一步檢驗就可以使用。根據對生存周期支持的不同要求，工具和技術分為：

a） 明確定義的開發工具：開發者應標識用于開發SSOIS的工具，并且所有用于實現的開發工具都應有明確定義。開發者應文檔化已選擇的依賴實現的開發工具的選項，開發工具文檔應明確定義實現中每個語句的含義，以及明確定義所有基于實現的選項的含義；

b） 遵照實現標準-應用部分：除明確定義的開發工具的要求外，開發者應對所應用部分的實現標準進行描述；

c） 遵照實現標準-所有部分：除明確定義的開發工具的要求外，開發者應對SSOIS所有部分的實現標準進行描述。

5.2.6 測試

5.2.6.1 測試范圍

應表明所標識的測試范圍如何像功能設計中描述的那樣與SSF 相一致。這里不需要開發者覆蓋SSF 的各個方面，但有必要考慮其不足之處。根據對測試的不同要求，測試范圍分為：

a） 范圍的證據：開發者應通過提供相應的證據表明SSF已按功能要求進行了測試。開發者所提供的測試范圍的證據應表明測試文檔中所標識的測試與功能設計所描述的SSF之間的對應性；

b） 范圍分析：開發者應通過提供對應性分析表明SSF已經以系統的方法針對功能設計進行了測試。為此要求：

——開發者所闡明的已標識的測試應包括在功能設計描述的所有安全功能的測試；

——開發者所提供的范圍分析應表明測試文檔所標識的測試與功能設計所描述的SSF之間的對應性；

——測試范圍的分析應闡明功能設計所描述的SSF和測試文檔所標識的測試之間的對應性是完備的；

c） 嚴格的范圍分析：除范圍分析外，還要求測試范圍的分析應嚴格地闡明功能設計所標識的SSF的所有外部接口已經被完備測試過了。

5.2.6.2 測試深度

應根據所要求的安全保護等級確定測試需要達到的深度。根據對測試的不同要求，測試的深度分為：

a） 高層設計測試：應以“單元”描述對SSF高層設計的測試。SSF單元提供SSF內部工作的一個高層描述。以闡明缺陷為目的的單元級別的測試保證了該單元已正確實現。開發者所提供的測試深度分析應闡明測試文檔中所標識的測試足以表明該SSF的行為是與高層設計一致的；

b） 低層設計測試：應以“模塊”描述對SSF低層設計的測試。SSF模塊提供SSF內部工作的低層描述。以闡明缺陷為目的的模塊級別的測試，確保SSF的模塊已經正確實現。開發者所提供的測試深度分析應闡明測試文檔中所標識的測試足以表明該SSF的行為是與高層設計和低層設計一致的；

c） 實現表示測試：應確保該SSF的設計要求已正確實現。開發者所提供的測試深度分析應闡明測試文檔中所標識的測試足以表明該SSF是根據高層設計、低層設計和實現表示而運作的。

5.2.6.3 功能測試

應展示SSF滿足安全保護輪廓（PP）所要求的安全功能，并提供測試程序和測試工具的使用說明書，包括測試環境，測試條件，測試數據參數和值，還應顯示如何從輸入中得到測試結果。根據對測試的不同要求，功能測試分為：

a） 一般功能測試：開發者應闡明所有安全功能按規定運作。為此要求：

——開發者所提供的測試文檔應包括測試計劃、測試過程描述，預期的測試結果和實際測試結果；

——測試計劃應標識要測試的安全功能，描述要達到的測試目標；

——測試過程應標識要執行的測試，并描述每個安全功能的測試概況，包括測試的順序；

——預期的測試結果應當表明成功的測試運行后的預期輸出；

b） 順序的功能測試：除一般功能測試外，測試文檔還應包含測試過程中對順序依賴性的分析。

5.2.6.4 獨立性測試

應由一個有專業知識的團體支持的獨立實驗室或消費者組織實施獨立的測試。這種測試需要對SSOIS的一致理解。獨立性測試可以采用全部或部分重復開發者功能測試的形式，也可采用增加開發者功能測試的方式。對于每個SSOIS功能都可制定一個適當的組合計劃。這個組合計劃應考慮測試結果的可用性和適用范圍，以及SSF的功能復雜度。測試計劃應考慮與安全保護等級要求的一致性，對更高的安全保護等級應包括更多樣本的重復測試。根據對測試的不同要求，獨立性測試分為：

a） 相符性獨立測試：應表明安全功能是按規定運作的。開發者應提供與測試相適應的SSOIS；

b） 抽樣獨立性測試：應通過選擇和重復測試開發者測試的一個抽樣，表明安全功能是按規定運作的，并提供能有效重現開發者測試的必需資料，包括可聯機閱讀的測試文檔、測試程序等。評估者應擁有開發者提供的有用的測試結果以補充測試過程。要求開發者所提供的用于測試的SSOIS應與測試相適應，并提供一個與開發者的SSF功能測試中使用的資源相等的集合；

c） 完全獨立性測試：應通過重復所有開發者的測試來表明安全功能是按規定運作的。除要求執行測試文檔內的所有測試，以驗證開發者的測試結果外，其余要求與抽樣獨立性測試。

5.2.7 脆弱性評定

5.2.7.1 隱蔽信道分析

根據對脆弱性評定的不同要求，隱蔽信道分析分為：

a) 一般性隱蔽信道分析

應通過對隱蔽存儲信道的非形式化搜索，標識出可識別的隱蔽存儲信道，并以文檔形式描述：

——標識的隱蔽存儲信道，并估算它們的帶寬；

——用于確定隱蔽存儲信道存在的過程，以及進行隱蔽存儲信道分析所需要的信息；

——隱蔽存儲信道分析期間所作的全部假設；

——最壞情況下對隱蔽存儲信道帶寬進行估算的方法；

——每個可標識的隱蔽存儲信道的最大可利用情形；

——用封鎖和/或限制帶寬和/或審計等，對所標識的隱蔽存儲信道進行處理的措施。

b) 嚴格的隱蔽信道分析

應通過對隱蔽信道的嚴格搜索，標識出可識別的隱蔽信道，以結構化、可重復的方式標識出隱蔽信道，并以文檔形式描述：

——標識的隱蔽信道，并估算它們的帶寬；

——用于確定隱蔽信道存在的過程，以及進行隱蔽信道分析所需要的信息；

——隱蔽信道分析期間所作的全部假設；

——最壞情況下對隱蔽信道帶寬進行估算的方法；

——每個可標識的隱蔽信道的最大可利用情形；

——用封鎖和/或限制帶寬和/或審計等，對所標識的隱蔽信道進行處理的措施。

5.2.7.2 防止誤用

應防止對SSOIS以不安全的方式進行使用或配置而不為人們所察覺。為此，應使對SSOIS 的無法檢測的不安全配置和安裝，操作中人為的或其它錯誤造成的安全功能解除、無效或者無法激活，以及導致進入無法檢測的不安全狀態的風險達到最小。應按要求提供必要的文檔，以防止提供沖突、誤導、不完備或不合理的指南。根據對脆弱性評定的不同要求，防止誤用分為：

a） 文檔檢查：文檔應：

——提供安裝、生成和啟動過程及非形式化功能設計說明，安全管理員指南和用戶指南等，確保用戶能進行安全配置和使用；

——明確說明對SSOIS的所有可能的操作方式（包括失敗和操作失誤后的操作）、它們的后果，以及對于保持安全操作的意義；

——是完備的、清晰的、一致的、合理的，列出所有目標環境的假設，并列出所有外部安全措施（包括外部過程的、物理的或人員的控制）的要求；

b） 分析確認：在文檔檢查的基礎上，應對文檔實施文檔化管理，并要求分析文檔是完備的；

c） 對安全狀態的檢測和分析：在分析確認的基礎上，應進行獨立驗證，以確定安全管理員或用戶在正確理解文檔的情況下能基本判斷SSOIS 是否在不安全狀態下配置或運行。

5.2.7.3 SSOIS安全功能強度評估

應通過對安全機制的安全行為的合格性或統計結果的分析，以及對克服脆弱性所付出努力的分析，得到SSOIS安全功能強度的說明。

應對安全目標中標識的每個具有SSOIS安全功能強度聲明的安全機制進行SSOIS安全功能強度的分析，證明該機制達到或超過安全目標要求所定義的最低強度，并證明該機制達到或超過安全目標要求所定義的特定功能強度。

5.2.7.4 脆弱性分析

應能夠發現由于缺陷所帶來的威脅。這些缺陷會導致對資源的非授權訪問、對安全功能的影響或改變，或者干擾其它授權用戶的權限。根據對脆弱性評定的不同要求，脆弱性分析分為：

a） 開發者脆弱性分析：應確定明顯的安全脆弱性的存在，并確認在所期望的環境中所存在的脆弱性不會被利用。為此，應通過搜索用戶可能違反SSP的明顯途徑，文檔化明顯的脆弱性分布。對所有已標識的脆弱性，分析文檔應說明在所期望的環境中無法利用這些脆弱性；

b） 獨立脆弱性分析：應通過獨立穿透測試，確定SSOIS可以抵御的低攻擊能力攻擊者發起的攻擊。為此，除開發者脆弱性分析外，分析文檔應表明具有已標識脆弱性的SSOIS可以抵御明顯的攻擊，并通過進一步實施獨立的脆弱性分析，實施獨立的穿透性測試，以確定在所期望環境中額外標識的脆弱性的可利用性；

c） 中級抵抗力：在獨立脆弱性分析的基礎上，分析文檔應說明對脆弱性的搜索是系統化的，并確定可以抵御中攻擊能力攻擊者發起的對SSOIS的穿透性攻擊；

d） 高級抵抗力：在中級抵抗力的基礎上，分析文檔應表明該分析完備地表述了SSOIS的脆弱性，并確定可以抵御高攻擊能力攻擊者發起的對SSOIS的穿透性攻擊。