CNS 15408-3-2004 Information technolgoy – Security techniques – Evaluation criteria for ITSecurity – Part 3 Security assurance requirements《信息技术－安全技术－信息技术安全评估准则－第3部：安全保证需求》.pdf

1、 1 印行年月 94 年 10 月 本標準非經本局同意不得翻印 中華民國國家標準 CNS 總號 類號 ICS 35.040.00 X5068-315408-3經濟部標準檢驗局印行 公布日期 修訂公布日期 93 年 4 月 12 日 年月日 (共 154 頁 )資訊技術安全技術資訊技術安全 評估準則第 3 部：安全保證需求 Information technolgoy Security techniques Evaluation criteria for IT Security Part 3: Security assurance requirements 目錄 前言 . 7 1. 適用範圍 8

2、 1.1 本標準之組織 . 8 1.2 本系列標準保證典範 . 8 1.2.1 本系列標準理念 . 8 1.2.2 保證方式 8 1.2.3 本系列標準評估保證尺度 10 2. 安全保證需求 11 2.1 結構 11 2.1.1 類別結構 .11 2.1.2 保證屬別結構 . 13 2.1.3 保證組件結構 . 14 2.1.4 保證元件 15 2.1.5 EAL 結構 . 16 2.1.6 在保證需求和保證等級之間的關係 19 2.2 組件分類法 19 2.3 保護剖繪和安全標的評估準則類別結構 . 19 2.4 用語釋義 19 2.5 保證歸類 21 2.6 保證類別和屬別概論 . 21

3、2.6.1 類別 ACM：組態管理 . 22 2.6.2 類別 ADO：交付和運作 23 2.6.3 類別 ADV：發展 23 2.6.4 類別 AGD：指引文件 . 24 2.6.5 類別 ALC：生命週期支援 . 24 2.6.6 類別 AT E：測試 . 25 2.6.7 類別 AVA：脆弱性評鑑 . 25 2.7 維護歸類 26 2.8 維護保證類別和屬別概論 26 2 CNS 15408-3, X 5068-3 2.8.1 類別 AMA：維護保證 . 26 3. 保護剖繪和安全標的評估準則 . 27 3.1 概論 . 27 3.2 保護剖繪準則概論 27 3.2.1 保護剖繪評估 .

4、 27 3.2.2 與安全標的評估準則的關係 27 3.2.3 評估員任務 27 3.3 安全標的準則概論 28 3.3.1 安全標的評估 . 28 3.3.2 與本標準裡的另一評估準則的關係 28 3.3.3 評估員任務 28 4. 類別 APE：保護剖繪評估 30 4.1 TOE 描述 (APE_DES) . 30 4.2 安全環境 (APE_ENV) . 31 4.3 PP 簡介 (APE_INT) 31 4.4 安全目的 (APE_OBJ) 32 4.5 IT 安全需求 (APE_REQ) . 33 4.6 明確陳述的 IT 安全需求 (APE_SRE) . 34 5. 類別 ASE：

5、安全標的評估 36 5.1 TOE 描述 (ASE_DES) . 36 5.2 安全環境 (ASE_ENV) . 37 5.3 ST 簡介 (ASE_INT) 37 5.4 安全目的 (ASE_OBJ) 38 5.5 PP 聲明 (ASE_PPC) 39 5.6 IT 安全需求 (ASE_REQ) . 40 5.7 明確陳述的 IT 安全需求 (ASE_SRE) . 41 5.8 TOE 彙總規格 (ASE_TSS). 42 6. 評估保證等級 . 44 6.1 評估保證等級 (EAL)概論 44 6.2 評估保證等級細節 44 6.2.1 評估保證等級 1 (EAL1)功能測試 46 6.2

6、.2 評估保證等級 2 (EAL2)結構性測試 46 6.2.3 評估保證等級 3 (EAL3)系統化測試和檢查 48 6.2.4 評估保證等級 4 (EAL4)系統化設計、測試和審查 . 49 6.2.5 評估保證等級 5 (EAL5)半正規地設計和測試 51 6.2.6 評估保證等級 6 (EAL6)半正規地查證設計和測試 . 53 6.2.7 評估保證等級 7 (EAL7)正規地查證設計和測試 . 55 7. 保證類別、屬別和組件 . 57 3 CNS 15408-3, X 5068-3 8. 類別 ACM：組態管理 . 58 8.1 CM 自動化 (ACM_AUT) . 58 8.2

7、CM 能力 (ACM_CAP) . 60 8.3 CM 範圍 (ACM_SCP) 65 9. 類別 ADO：交付和運作 68 9.1 交付 (ADO_DEL) . 68 9.2 安裝、產生和啟動 (ADO_IGS) . 69 10. 類別 ADV：發展 . 72 10.1 功能規格 (ADV_FSP) . 75 10.2 高階設計 (ADV_HLD) 78 10.3 實作表示 (ADV_IMP). 82 10.4 TSF 內部事宜 (ADV_INT) 85 10.5 低階設計 (ADV_LLD) 87 10.6 表示之對應性 (ADV_RCR) . 90 10.7 安全政策模型化 (ADV_S

8、PM) 92 11. 類別 AGD：指引文件 95 11.1 管理者指引 (AGD_ADM) 95 11.2 使用者指引 (AGD_USR) . 96 12. 類別 ALC：生命週期支援 98 12.1 發展安全 (ALC_DVS). 98 12.2 缺點修補 (ALC_FLR) . 99 12.3 生命週期定義 (ALC_LCD).101 12.4 工具和技術 (ALC_TAT) .104 13. 類別 ATE：測試 .106 13.1 涵蓋 (ATE_COV).107 13.2 深度 (ATE_DPT) .109 13.3 功能測試 (ATE_FUN) 111 13.4 獨立測試 (ATE

9、_IND).116 14. 類別 AVA：脆弱性評鑑 117 14.1 隱密通道分析 (AVA_CCA) .117 14.2 誤用 (AVA_MSU) 120 14.3 TOE 安全功能強度 (AVA_SOF) 123 14.4 脆弱性分析 (AVA_VLA) 125 15. 保證維護典範 129 15.1 簡介 129 15.2 保證維護週期 131 15.2.1 TOE 接受驗收 .132 15.2.2 TOE 監視 133 4 CNS 15408-3, X 5068-3 15.2.3 重新評估 .134 15.3 保證維護類別和屬別 135 15.3.1 保證維護計畫 135 15.3.

10、2 TOE 組件歸類報告 .136 15.3.3 保證維護的證據 .137 15.3.4 安全衝擊的分析 .137 16. 類別 AMA：保證維護 .139 16.1 保證維護計畫 (AMA_AMP)139 16.2 TOE 組件歸類報告 (AMA_CAT) .141 16.3 保證維護的證據 (AMA_EVD) 142 16.4 安全衝擊分析 (AMA_SIA) .143 附錄 A 保證組件相依性之交互參考 (參考 ) 147 附錄 B EAL 和保證組件之交互參考 (參考 ) 150 英中名詞對照表 151 5 CNS 15408-3, X 5068-3 附圖表列 圖 2.1 - 保證類別

11、 /屬別 /組件 /元件階層 . 12 圖 2.2 - 保證組件結構 . 14 圖 2.3 - EAL 結構 . 17 圖 2.4 - 保證和保證等級關聯 18 圖 2.5 - 樣本類別之圖解 . 19 圖 4.1 - 保護剖繪評估類別之圖解 . 30 圖 5.1 - 安全標的評估類別之圖解 . 36 圖 8.1 - 組態管理類別之圖解 58 圖 9.1 - 交付和運作類別之圖解 . 68 圖 10.1 - 發展類別之圖解 . 72 圖 10.2 - 在 TOE 表示和需求之間的關係 . 73 圖 11.1 - 指引文件類別之圖解 95 圖 12.1 - 生命週期支援類別之圖解 . 98 圖

12、13.1 - 測試類別之圖解 106 圖 14.1 - 脆弱性評鑑類別之圖解 117 圖 15.1 - 保證維護週期之範例 .132 圖 15.2 - TOE 驗收方式之範例 .133 圖 15.3 - TOE 監視方式之範例 .134 圖 16.1 - 保證之維護類別的圖解 139 6 CNS 15408-3, X 5068-3 表之表列 表 2.1 - 保證屬別拆解和對映 22 表 2.2 - 維護保證類別圖解 26 表 3.1 - 保護剖繪屬別僅本系列標準需求 27 表 3.2 - 保護剖繪屬別本系列標準擴充需求 28 表 3.3 - 安全標的屬別僅本系列標準需求 28 表 3.4 -

13、安全標的屬別本系列標準擴充需求 29 表 6.1 - 評估保證等級彙總 45 表 6.2 - EAL1 . 46 表 6.3 - EAL2 . 47 表 6.4 - EAL3 . 48 表 6.5 - EAL4 . 50 表 6.6 - EAL5 . 52 表 6.7 - EAL6 . 54 表 6.8 - EAL7 . 56 表 15.1 - 維護保證屬別拆解和對映 135 表 A.1 - 保證組件相依性 148 表 A.2 - AMA 內部相依性 .149 表 B.1 - 評估保證等級彙總 .150 7 CNS 15408-3, X 5068-3 前言 本系列標準，包含下列三部： (1)

14、第 1 部：簡介及一般模型 (2) 第 2 部：安全功能需求 (3) 第 3 部：安全保證需求 本標準之附錄 A 及附錄 B 僅供參考。 備考 1. 本標準是參照 ISO/IEC 15408 系列標準制定；而 ISO/IEC 15408 系列標準是由共同準則（ Common Criteria， CC）計畫贊助組織，將其資訊技術安全評估共同準則第 1 部至第 3 部，授與 ISO/IEC 而制定之國際標準。 2. ISO/IEC JTC/SC27 根據共同準則詮釋管理委員會（ Common Criteria Interpretation Management Board， CCIMB）已在修訂共

15、同準則相關資訊。根據 CCIMB 公布的資料，資訊技術安全評估共同準則於本標準審定時已有多處修正，參考時宜多加注意（參 考網址： http ：/moncriteria.org/ccc/ri/finalIndex.jsp） 。 8 CNS 15408-3, X 5068-3 1. 適用範圍 本標準定義本系列標準保證 (Assurance)需求，其中，包括用以定義衡量保證尺度(Scale)的評估保證等級 (Evaluation assurance level, EAL)、含有保證等級的個別保證組件 (Component)以及 PP 和 ST 的評估準則 (Criteria)。 1.1 本標準之組織

16、 第 1 節係本標準的簡介和典範 (Paradigm)。 第 2 節描述保證類別 (Class)、屬別 (Family)、組件和評估保證等級的表現(Presentation)結構以及其間關係。它亦刻劃出第 8 至 14 節所述保證類別和屬別的特性。 第 3、 4 和 5 節提供保護剖繪 (Protection profile, PP)和安全標的 (Security Target, ST)評估準則簡介，以及該等評估所使用屬別和組件的詳細解釋。 第 6 節提供詳細的 EAL 定義。 第 7 節提供保證類別簡介，後續第 8 至 14 節提供詳細的該等類別定義。 第 15 和 16 節提供保證維護評估

17、準則簡介，以及該等屬別和組件的詳細定義。 附錄 A 提供保證組件之間相依性的彙總。 附錄 B 提供 EAL 和保證組件之間的交互參考。 1.2 本系列標準保證典範 此小節的目的係載明支持本標準達成保證的理念。瞭解此小節將會讓讀者了解在本標準保證需求背後的理由闡述 (Rationale)。 1.2.1 本系列標準理念 本系列標準理念係宜清楚說明 對安全和組織安全政策承諾的威脅，同時，所建議的安全措施明確足以達成設想的目的。 此外，宜採用可減少發生脆弱性的可能性、操演脆弱性的能力 (也就是蓄意地利用或無意間觸發 )，以及減少從所操演脆弱性所發生損壞範圍的適當措施。另外，宜採用可方便後續識別脆弱性以

18、及抵消、緩和及 /或通知脆弱性已經被利用或觸發的適當措施。 1.2.2 保證方式 本系列標準理念係基於評估 (有效調查 )欲信賴 IT 產品或系統以提供保證。評估係提供保證的傳統方式且 係先前評估準則文件的基礎。為與既存方式一致，本系列標準採用相同的 理念。本系列標準提議資深評估員藉由強調範圍、深度和嚴謹性，以衡量文件及其所產生的 IT 產品或系統的有效性。 本系列標準不排除也不批評其 它獲得保證的方法的相對優點，針對獲得保證的替代方法則持續研究。當 成熟的替代方法從這些研究活動浮現時，它們將被考慮納入本系列標準裡 。本系列標準具相當結構化，故得以在未來引入它們。 1.2.2.1 脆弱性的意義

19、 假定有威脅行動者（ threat agent），不論係為了不法的利益或不安全的好意，積極尋求利用機會以違反安全政策。威脅行動者也可能意外 9 CNS 15408-3, X 5068-3 地觸發安全脆弱性，引起對組織的傷害。由於必需處理敏感資訊和缺乏充份信賴的產品或系統的可用性，所以， IT 的失效將會有重大的風險。因此， IT 安全漏洞 (Security breach)可能會導致重大的損失。 IT 安全漏洞的產生，係在業務事務中的 IT 應用上，透過蓄意地利用或無意間觸發脆弱性。 在 IT 產品和系統中，宜採取步驟以預防脆弱性浮現，在可行的限度下，脆弱性宜： (a) 消除 (Elimina

20、ted) 意即宜採取有效步驟以暴露並移除或消滅所有可操演的脆弱性。 (b) 極小化 (Minimised) 意即宜採 有效步驟以減少脆弱性之任何操演的潛在衝擊至可接受的殘餘位準。 (c) 監視 (Monitored) 意即宜採取有效步驟以確 保將偵測到操演殘餘脆弱性的任何嘗試，以便能採取步驟而限制損壞。 1.2.2.2 脆弱性原因 脆弱性會因下列失效而浮現： (a) 需求 意即 IT 產品或系統可擁有其所需的所有功能和特性，並仍包含安全不合宜或使安全無效的脆弱性。 (b) 建構 意即 IT 產品或系統不符合其規格，及 /或因不良結構化標準或不正確設計的選取已導致具有脆弱性。 (c) 運作 意即

21、 IT 產品或系統已依一正確規格正確地建構，但因在運作上不適當控制已導致具有脆弱性。 1.2.2.3 本系列標準保證（ Assurance） 保證係信賴 IT 產品或系統符合其安全目的的基礎。保證可獲自參考諮詢來源，諸如非實例性判斷、先前相關經驗或特定經驗。然而，本系列標準透過有效調查提供保證。主動調查係經由評估 IT 產品或系統以判定其安全性質。 1.2.2.4 經由評估的保證 評估已經是獲得保證的傳統方式，是本系列標準實施方式的基礎。評估技術能包括，但不限於： (a) 分析和檢查各項處理過程及程序。 (b) 檢查正在應用的處理過程及程序。 (c) 在 TOE 設計表示間的對應性之分析。 (

22、d) 依需求分析 TOE 設計表示。 (e) 查證證據。 (f) 指引文件之分析。 (g) 所發展的功能測試和所提供的結果之分析。 (h) 獨立功能測試。 (i) 脆弱性分析 (包括瑕疵假說 )。 10 CNS 15408-3, X 5068-3 (j) 滲透測試。 1.2.3 本系列標準評估保證尺度 本系列標準理念主張較高保證 來自於較多評估努力的應用，且其目標係應用所需最小的努力，以提供必要的保證等級。提昇等級的努力係基於： (a) 範圍（ scope） 意即因為包括了 IT 產品或系統的較大部分，所以需要較多努力。 (b) 深度（ depth） 意即因為步署較佳等級的設計與實作細節，所以

23、需要較多努力。 (c)嚴謹（ rigour） 意即因為以更結構化、正式方法的應用，所以需要較多努力。 11 CNS 15408-3, X 5068-3 2. 安全保證需求 2.1 結構 下列小節描述用以代表保證類別，屬別，組件和 EAL 以及其彼此之間關係的結構。 圖 2.1 說明本標準所定義的保證需求。請注意最簡要保證需求之收集即稱為類別。每一類別包含數個保證屬別，而保證屬別包含數個保證組件，該等保證組件則包含數項保證元件。類別和屬別用來提供分類法以分類保證需求，同時組件用來規定 PP/ST 裡的保證需求。 2.1.1 類別結構 圖 2.1 說明保證類別結構。 2.1.1.1 類別名稱（ c

24、lass name） 每一保證類別均指定一唯一名稱。該名稱指示保證類別所涵蓋的主題。 亦提供保證類別名稱的唯一縮寫格式。此係參考保證類別的主要方法。採用的規約係 A緊接著關於類別名稱的二個字母。 2.1.1.2 類別簡介 每一保證類別具有一介紹性小節，其描述類別組成且涵蓋該類別意圖的輔助性文字。 2.1.1.3 保證屬別（ assurance family） 每一保證類別至少包含一保證屬別。保證屬別的結構描述於下列小節。 12 CNS 15408-3, X 5068-3 圖 2.1 保證類別 /屬別 /組件 /元件階層 目的應用須知相依性保證元件組件識別應用須知組件分級目的屬別名稱類別簡介類別

25、名稱保證組件保證屬別保證類別共同準則保證需求 13 CNS 15408-3, X 5068-3 2.1.2 保證屬別結構 圖 2.1 說明保證類別結構。 2.1.2.1 屬別名稱 每一保證屬別均被指定一唯一名稱。該名稱提供有關保證屬別所涵蓋主題的描述性資訊。每一保證屬別均放置於包含相同意圖的其它屬別的保證類別內。 本標準提供保證屬別名稱的唯一縮寫格式。這係參考保證屬別的主要方法。採用規約使用短格式的類別名稱，緊接著一底線，然後是關於屬別名稱的三個字母。 2.1.2.2 目的 保證屬別的目的小節係呈現保證屬別的意圖。 此小節描述該屬別所欲述明的目的，特別是關於本系列標準保證典範。保證屬別的描述保

26、持在一般水準。該目的所需要的任何特定細節併入於特定保證組件。 2.1.2.3 組件分級（ component levelling） 每一保證屬別包含一或較多的保證組件。保證屬別的此小節描述可用組件並解釋它們之間的區別。一旦已決定保證屬別是 PP/ST 保證規定中必要或有用的部分，它的主要目的係區別各保 證組件之間的不同。 包含超過一組件的保證屬別應加以分級，並對於組件如何加以分級提供適當的理由闡述。此理由闡述是根據範圍、深度及 /或嚴謹性。 2.1.2.4 應用須知（ application note） 如果存在該保證屬別的應用須知小節時，應包含保證屬別的額外資料。此資訊宜是保證屬別的使用者

27、(例如： PP 和 ST 擬訂者、 TOE 設計者、評估員 )特別感到興趣的。該表現方法係非正規的 (Informal) 並涵蓋例如相關使用限制的警告和可能需要特定注意之區域。 2.1.2.5 保證組件（ assurance component） 每一保證屬別至少具有一保證組件。保證組件的結構提供於下列小節。 14 CNS 15408-3, X 5068-3 2.1.3 保證組件結構 圖 2.2 說明保證組件結構。 圖 2.2 保證組件結構 保證組件組件識別目的應用須知相依性保證元件2.1.3.1 組件識別 (component identification） 組件識別小節提供對識別、分類、登

28、錄和參考組件所必要的描述性資訊。 每一保證組件均指定一唯一名稱。該名稱提供保證組件所涵蓋主體的描述性資訊。每一保證組件放置於分擔其安全的保證屬別目的內。 亦提供保證組件名稱的唯一縮寫格式。這係參考保證組件的主要方法。規約是使用短格式的屬別名稱，緊接一句點，然後是一數字字元。每一屬別內組件的數字字元係循序指定，從 1 開始。 2.1.3.2 目的 保證組件的各目的小節 (若存在 )，應包含特定保證組件的特定目的。對於具有此小節的保證組件，其呈現該組件的特定意圖並詳細解釋該目的。 2.1.3.3 應用須知 保證組件的各應用須知小節 (若存在 )，應包含便於使用該組件的額外資訊。 2.1.3.4 相

29、依性（ Dependency） 當一組件並非自給自足，而需依賴另一組件的存在時，在保證組件之 15 CNS 15408-3, X 5068-3 中會出現相依性。 每一保證組件應提供對其它保證組件相依性的完全表列。一些組件可能表列無相依性，以指示未識別有相依性。所依賴的組件可能對其它組件具有相依性。 相依性表列識別所依賴的最小保證組件。相依性表列內組件的次級組件亦可用以滿足相依性。 在特定情況，所指示的相依性可能不適用。藉由提供指定相依性為何不適用的理由闡述， PP/ST 擬訂者可選取不滿足該相依性。 2.1.3.5 保證元件（ assurance element） 每一保證組件皆備有一組保證元

30、件。一保證元件係一安全需求，如果更進一步區分，將不會產生有意義的評估結果。它是本標準所認知的最小安全需求。 每一保證元件均經識別歸屬於三組保證元件之一： (a) 發展者動作元件：發展者應履行的活動。此一組動作可由下列一組元件所引用的證據資料更進一步取得資格。發展者動作的需求，可藉由附加字母 D至元件號碼而識別。 (b) 證據內容和表現元件：所需要的證據，是證據應展示的是什麼，且證據應傳達什麼資訊。證據的內容和表現的需求，可藉由附加字母 C至元件號碼而識別。 (c) 評估員動作元件：評估員應履行的活動。此一組動作明確地包括在證據內容和表現元件中規定的需求已符合的確認。它亦包括發展者已履行之外的外

31、顯動作和分析。評估員內隱動作亦視為證據內容和表現之需求未涵蓋的發展者動作元件的結果而履行。評估員動作的需求可藉由附加字母 E至元件號碼而識別。 發展者動作及證據之內容和表現，係定義用來代表發展者在展示 TOE安全功能內保證職責的保證需求。藉由符合這些需求，發展者更能信賴 TOE 滿足 PP 或 ST 功能和保證需求。 評估員動作定義評估員在兩方面評估的職責。第一方面是 PP/ST 之驗核 (validation) ，遵照類別裡第 4 和 5 節內的 APE 和 ASE 類別。第二方面是查證 TOE 符合其功能和保證需求。藉由展示 PP/ST 有效且 TOE符合需求，評估員可提供 TOE 將符合

32、其安全目的的信賴依據。 發展者動作元件、證據內容和表現元件以及外顯評估員動作元件，識別應花在查證 TOE 的 ST 內安全聲明的評估員之努力。 2.1.4 保證元件 每一元件代表一待符合的需求。這些需求的陳述應力圖清楚、簡潔且明確。因此，並無複合句子：每一可分離的需求應以個別元件陳述。 元件係以用語的正常字典意思 書寫，儘量不使用許多預先定義的用語，諸如會導致內隱需求的速記。因此，元件係以外顯需求書寫，且無保 留用語。 16 CNS 15408-3, X 5068-3 對照於本系列標準第 2 部，本標準裡的元件並無相關的指定或選取運作；然而，視需要可對本標準元件進行精細化。 2.1.5 EAL

33、 結構 圖 2.3 說明此本標準所定義的 EAL 及其相關結構。請注意在圖形顯示保證組件的內容時，其意欲藉由參 考在本系列標準內所定義的實際組件將此資訊包含在 EAL 中。 2.1.5.1 EAL 名稱 每一 EAL 皆指定一唯一名稱。該名稱提供有關 EAL 意圖的描述性資訊。亦提供 EAL 名稱的唯一縮寫格式。這係參考 EAL 的主要方法。 2.1.5.2 目的 EAL 的目的小節呈現 EAL 的意圖。 2.1.5.3 應用須知 EAL 的各應用須知小節 (若存在 )，應包含 EAL 使用者特定興趣的資訊(例如： PP 和 ST 擬訂者、針對此 EAL 的 TOE 設計者、評估員 )。該表現

34、方式係非正規的，並涵蓋例如相關使用限制的警告和可能需要特定注意的區域。 17 CNS 15408-3, X 5068-3 圖 2.3 EAL 結構 目的應用須知相依性保證元件組件識別應用須知目的EAL名稱保證組件評估保證等級本標準保證等級 18 CNS 15408-3, X 5068-3 圖 2.4 保證和保證等級結合 目的應用須知相依性保證元件組件識別應用須知目的EAL名稱保證組件評估保證等級本標準保證等級目的應用須知相依性保證元件組件識別應用須知組件分級目的屬別名稱類別簡介類別名稱應用組件保證屬別保證類別本標準保證需求 19 CNS 15408-3, X 5068-3 2.1.5.4 保證

35、組件 每一 EAL 已選取一組保證組件。 比指定 EAL 所提供的保證等級具有較高等級可藉由下列項目達成： (a) 包括來自其它保證屬別的額外保證組件；或 (b) 以自相同保證屬別的較高等級保證組件取代保證組件。 2.1.6 在保證需求和保證等級之間的關係 圖 2.4 說明本系列標準所定義保證需求和保證等級之間的關係。當保證組件進一步分解至保證元件內時 ，保證元件無法藉由保證等級獨自地引用。請注意圖形內箭頭代表從一 EAL 參考至其所定義類別內的保證組件。 2.2 組件分類法 本標準包含以相關保證為基礎而分群的屬別和組件的類別。在每一類別開始是一個圖形，係指示類別內屬別和每一類別內的組件。 圖

36、 2.5 樣本類別之圖解 類別名稱屬別1 1 2 3在上圖 2.5 所示，此類別包含單一屬別。該屬別包含三個線性階層的組件 (也就是在特定動作、特定證據或動作或證據嚴謹度上，組件 2 的要求較組件 1多 )。本標準裡的保證屬別 是全部線性階層，雖然對未來可能增加的保證屬別來說，線性並非一必備性準則。 2.3 保護剖繪和安全標的 (Security target)評估準則類別結構 保護剖繪和安全標的評估的需求當做保證類別處理，且使用另一保證類別所使用的相同結構呈現如下。一項值得注意的差別是在相關屬別描述裡缺少一組件分級小節。理由是每一屬別只有單一組件，因此並不會發生分級情形發生。 本標準第 3

37、節內表 3.1、 3.2、 3.3 和 3.4 彙總 APE 和 ASE 類別兩者的構成屬別和縮寫。 APE 屬別的敘述性彙總列明於本系列標準第 1 部，附錄 B， B.2.2 至B.2.6 小節，而 ASE 屬別的敘述性彙總列明於本系列標準第 1 部，附 錄 C， C.2.2至 C.2.8 小節。 2.4 用語釋義 本標準以精確方式所使用的用語表列如下。它們並非詞彙 (Glossary)裡的指標項目，因為它們是一般用語，雖然受限於下列解釋，但是，它們的用法符合字典定義。然而，對於用語的解釋可使用於發展此本標準的指引，並且，宜有助於 20 CNS 15408-3, X 5068-3 一般性瞭解

38、。 檢查（ Check）此用語類似於確認或查證，但較不嚴謹。此用語需要評估員做快速決定，也許僅需要一粗略分析，或也許完全不需要分析。 一貫的（ Coherent）一個體係以符 合邏輯之方式排序且具有可辨別的意義。對於文件來說，基於是否可由其標的閱聽人 (Audience)理解的觀點，此用語說明文件的實際文字和結構兩者。 完全的（ Complete）已提供一個體的所有必要部分。對於文件來說，這意謂文件涵蓋所有的相關資訊，在如此詳細水準使得在該抽象水準不需要進一步解釋。 確認（ Confirm）此用語用來指示某事需 要詳細地審查，且需要執行充分性的獨立判定。所需要的嚴謹等級視主題之本質而定。此用語

39、僅適用於評估員動作。 一致性（ Consistent）此用語描述在二或較多的個體之間的關係，指示在這些個體之間沒有顯著的矛盾。 對抗（ Counter）此用語典型地用在安全目的 (Security objective) 對抗特定威脅的內涵，但不必然指示最後已完全根除威脅。 展示（ Demonstrate）此用語參照導致一結論的分析，比證明 (proof)較不嚴謹。 描述（ Describe）此用語需要提供個體某些特定細節。 判定（ Determine）此用語需要執行一獨立分析， 其目的係達到一特定結論。此用語不同於確認或查證，因為這些其它用語暗示已經履行一分析，其需要審查，然而使用判定暗示一真

40、實的獨立分析，通常在缺少任何已履行的先前分析時。 確保（ Ensure）此用語，獨自使用時暗示在一動作和其結果之間的強烈因果關係。此用語典型地在幫助之後，幫助指示僅基於該動作並未完全確定結果。 窮舉的（ Exhaustive） 針對引導分析或其它 活動，此用語使用於本系列標準內。它跟系統化有關，但更加強烈，指示不僅已依照一明確的計畫採取一方法性方式履行分析或活動，且所依循的計畫足以確保已操演所有可能的途徑。 解釋（ Explain） 此用語與描述和展示兩者不同。其意欲回答問題為什麼 ?而不實際嘗試爭論所採取的動作路徑必然最佳。 內部一致性（ Internal Consistent）在任一相關個

41、體之間並無顯著矛盾。對於文件，這即是意謂在文件裡面並未採取反駁彼此的陳述。 證實（ Justification）此用語參照導至結論的分析，但是比查證更嚴謹。此用語需要嚴謹小心並徹底地解釋一合乎邏輯要旨的每一步驟。 互相支援性（ Mutual Supportive）此用語描述在一群個體之間的關係，指示該等個體在履行他們的任務時擁有不衝突的性質且可協助另一個體。沒有必要 21 CNS 15408-3, X 5068-3 判定在一問題裡的每一個別個體直接地支援該分群裡的其它個體，而是更一般性的判定。 證明（ Prove）此參照其數學上的正規 (Formal)分析，在各方面它均屬完全地嚴謹的。典型上，

42、當想要以高嚴謹度顯示兩個 TSF 表示之間的對應性時，使用證明。 規定（ Specify）此用語用於如描述（ Describe）般的內涵，但意欲更嚴謹和精確。非常類似定義（ Define）。 追蹤 (Trace)這用語用來指示在二個個體之間 僅需要低嚴謹度之非正規對應性。 查證（ Verify）此用語內涵類似確認， 但更嚴謹保守。評估員動作內涵使用該用語時，指示需要評估員獨自努力。 2.5 保證歸類 表 2.1 所示為保證類別、屬別和每一屬別的縮寫。 2.6 保證類別和屬別概論 下列彙總第 8 至 14 節的保證類別和屬別。這些類別和屬別彙總係依其在第 8至 14 節的次序出現。 22 CNS

43、 15408-3, X 5068-3 表 2.1 保證屬別拆解 (Breakdown)和對映 保證類別 保證屬別 縮寫名稱 CM 自動化 ACM_AUT CM 能力 ACM_CAP 類別 ACM： 組態管理 CM 範圍 ACM_SCP 交付 ADO_DEL 類別 ADO： 交付和運作 安裝、產生和啟動 ADO_IGS 功能規格 ADV_FSP 高階設計 ADV_HLD 實作表示 ADV_IMP TSF 內部事宜 ADV_INT 低階設計 ADV_LLD 表示對應性 ADV_RCR 類別 ADV： 發展 安全政策模型化 ADV_SPM 管理者指引 AGD_ADM 類別 AGD： 指引文件 使用者

44、指引 AGD_USR 發展安全 ALC_DVS 缺點修補 ALC_FLR 生命週期定義 ALC_LCD 類別 ALC： 生命週期支援 工具和技術 ALC_TAT 涵蓋 ATE_COV 深度 AT E_ DP T 功能測試 ATE_FUN 類別 AT E： 測試 獨立測試 ATE_IND 隱密通道分析 AVA_CCA 誤用 AVA _ M S U TOE 安全功能強度 AVA _ S O F 類別 AVA： 脆弱性評鑑 脆弱性分析 AVA_VLA 2.6.1 類別 ACM：組態管理 組態管理 (CM)有助於確保保持 TOE 的完整性，其係藉由在 TOE 精細化和修改程序所需要的訓練和控制以及其它

45、相關資訊。 CM 防止對 TOE 未經授權的修改、增加或刪除，因而提供保證該評估所使用的 TOE 和文件與準備要發佈的是相同的。 2.6.1.1 CM 自動化 (ACM_AUT) 23 CNS 15408-3, X 5068-3 組態管理自動化建立用來控制組態項目的自動化等級。 2.6.1.2 CM 能力 (ACM_CAP) 組態管理能力定義組態管理系統的特性。 2.6.1.3 CM 範圍 (ACM_SCP) 組態管理範圍指示需要受組態管理系統控制的 TOE 項目。 2.6.2 類別 ADO：交付和運作 保證類別 ADO 定義與保全交付有關的措施、程序和標準以及 TOE 的安裝和運作使用的需求

46、，確保 TOE 所提供的安全保護在傳輸、安裝、啟動和運作期間不會被破解。 2.6.2.1 交付 (ADO_DEL) 交付涵蓋用來維護在傳輸 TOE 予使用者期間的安全程序，在交付初期及後續修改部分。其包括展示所交付 TOE 真確性所需要的特別程序或運作。該等程序和適當措施是確保 TOE 所提供安全保護不會在傳輸期間破解的基礎。當評估 TOE 而無法判定是否符合交付需求時，可評估發展者已發展分配 TOE 予使用者的程序。 2.6.2.2 安裝、產生和啟動 (ADO_IGS) 需要複製 TOE 的安裝、產生和啟動係由管理者設定組態和啟動以展示與 TOE 主複本 (master copy)具有相同的

47、保護性質。安裝、產生和啟動程序提供信賴管理者知悉 TOE 組態參數和如何影響 TSF。 2.6.3 類別 ADV：發展 保證類別 ADV 定義 TSF 逐步精細化的需求，從 ST 裡的 TOE 彙總規格下至實際實作。每一產生的 TSF 表示提供資訊以幫助評估員判定是否已經符合 TOE 的功能需求。 2.6.3.1 功能規格 (ADV_FSP) 功能規格描述 TSF，且必須是 TOE 安全功能需求的一完全和正確的實例。功能規格也詳細描述至 TOE 的外部介面，預期 TOE 的使用者藉由此介面與 TSF 互相影響。 2.6.3.2 高階設計 (ADV_HLD) 高階設計是將 TSF 功能規格精細化

48、至 TSF 主要構成部分內的高階設計規格。該高階設計識別 TSF 和主要硬體、韌體和軟體元件的基本結構。 2.6.3.3 實作表示 (ADV_IMP) 實作表示是 TSF 的最低抽象表示。它視適用性擷取 TSF 的詳細內部作用，根據原始程式碼、硬體圖面等。 2.6.3.4 TSF 內部事宜 (ADV_INT) TSF 內部事宜需求規定 TSF 的必要內部結構。 2.6.3.5 低階設計 (ADV_LLD) 低階設計是一詳細設計規格，其精細化高階設計至相當詳細程度，以 24 CNS 15408-3, X 5068-3 便能使用作為規劃及 /或硬體建構的基礎。 2.6.3.6 表示對應性 (ADV

49、_RCR) 表示對應性 (correspondence)是在所有可用 TSF 表示毗連之間的展示對映 (mapping)，從 TOE 彙總規格至所提供的最低抽象 TSF 表示。 2.6.3.7 安全政策模型化 (ADV_SPM) 安全政策模型係 TSP 安全政策的結構化表示，且用來提供對映於 TSP安全政策及最終對應至 TOE 安全功能需求的功能規格保證之提昇。這經由在功能規格、安全政策模型和模型化安全政策之間的對應性對映而達成。 2.6.4 類別 AGD：指引文件 保證類別 AGD 以表達發展者所提供的運作性文件的可理解性、涵蓋和完全性來定義需求。此文件 (提供使用者和管理者兩類資訊 )係 TOE 保全運作裡的重要因素。 2.6.4.1 管理者指引 (AGD_ADM) 系統管理指引文件的需求，有助於確保環境限制條件能被 TOE 管理者和操作者了解。系統管理文件是發展者可用的主要方法以提供 TOE管理者詳細、正確的資訊，探討如何以保全方式管理 T