5.2 安全保障評估

1.2　安全保障評估

1.2.1　開發（ADV類）

1.2.1.1　安全架構描述（ADV_ARC.1）

安全架構描述組件評估是確定數據庫的TSF結構是否使TSF不能被篡改或繞過，且提供安全域的TSF是否分離了這些域。安全評估活動的證據包括：安全目標、數據庫安全功能規范、TOE設計文檔、安全架構描述、TOE實現技術資料、操作性用戶指南等。安全架構描述組件安全評估要求如下：

a) 評估者應檢查安全體系結構的描述，以確定證據提供的信息的詳細水平與在細節與功能規范和TOE設計文件中包含的SFR強制實施抽象的描述相稱；

b) 評價者應檢查安全體系結構的描述，以確定它描述了TSF維護的安全域；

c) 評估者應檢查安全體系結構描述以確定初始化過程保持了安全性；

d) 評估者應檢查安全體系結構描述，以確定它包含的信息足以證明TSF能夠保護自身不受非受信活動實體的篡改；

e) 評估者應檢查安全體系結構描述，以確定該描述的分析充分說明了SFR強制實施機制是如何不能被繞過的；

f) 評估者也應確保描述是全面的，表現為每個接口都結合聲明的SFR的全集進行了分析。

1.2.1.2　安全執行功能規范（ADV_FSP.2）

安全執行功能規范組件評估是確認開發者是否對TOE安全功能接口的目的、使用方法機器參數作了充分描述。另外每個安全功能接口的行為、結果、出錯信息描述應足夠充分，以便評估人員能確認TSFI是安全相關的。安全執行功能規范組件評估證據包括：安全目標、功能規范、 TOE 設計。如果TOE的ST有評估證據的話，那么所使用的評估證據應包括：安全架構描述和用戶操作指南。安全執行功能規范組件評估要求如下：

a) 評估者應檢查功能規范，標識出TSF對應的TSFI，以確定該規范完整地描述了TSF的接口；

b) 評估者應檢查功能規范，以確認是否描述了每個TSFI目的，以使得評估者能夠理解這些接口；

c) 評估者應檢查功能規范，以確定該規范完整地描述了每個TSFI的使用方法；

d) 評估者應檢查TSFI的表示，以確定該表示完整地指出了與各TSFI相關的所有參數；

e) 評估者應檢查TSFI的表示，以確定該表示完整和準確地描述了各TSFI相關的所有參數；

f) 評估者應檢查TSFI的表示所有相關行動，以確定外部TOE安全功能接口進行詳細的描述，以使得評估者能夠確定接口是否是與安全相關的；

g) 評估者應檢查TSFI的表示，以確定其充分并正確地描述了各外部接口的相關參數、異常和出錯信息的TOE行為；

h) 評估者應檢查，追查將SFR鏈接到對應的TSFI；

i) 評估者應檢查功能規范，以確定它是TOE安全功能要求的一個完備實例化；

j) 評估者應檢查功能規范，以確定它是TOE安全功能要求的一個準確實例化。

1.2.1.3　帶完整摘要的功能規范（ADV_FSP.3）

帶完整摘要功能規范組件評估是確認開發者是否對TOE安全功能接口的目的、使用方法機器參數作了充分描述。另外每個安全功能接口的行為、結果、出錯信息描述應足夠充分，以便評估人員能比較不同TSFI之間安全相關強度。帶完整摘要功能規范組件評估證據包括：安全目標、功能規范和 TOE 設計。如果TOE的ST有評估證據的話，那么所使用的評估證據應包括：安全架構描述、實現表示、TSF內部描述和用戶操作指南。安全執行功能規范組件評估要求如下：

a) 評估者應檢查功能規范，標識出TSF對應的接口（TSFI），以確定該規范完整地描述了TSF的接口；

b) 評估者應檢查功能規范，以確認是否描述了每個TSFI目的，以使得評估者能夠理解這些接口。

c) 評估者應檢查功能規范，以該規范完整地描述了每個TSFI的使用方法；

d) 評估者應檢查TSFI的表示，以確定該表示完整地描述了與各TSFI相關的所有參數；

e) 評估者應檢查TSFI的表示，以確定該表示完整和準確地描述了各TSFI相關的所有參數；

f) 評估者應檢查TSFI的表示所有相關行動，以確定外部TOE安全功能接口進行詳細的描述，以使得評估者能夠確定接口是否是與安全相關的；

g) 評估者應檢查TSFI的表示，以確定其充分并正確地描述了各外部接口的相關參數、異常和出錯信息的TOE行為；

h) 評估者應檢查TSFI的表示，以確定每個TSFI是否概述了SFR支持和SFR不相關的行為；

i) 評估者應檢查，追查將SFR鏈接到對應的TSFI；

j) 評估者應檢查功能規范，以確定它是TOE安全功能要求的一個完備實例化；

k) 評估者應檢查功能規范，以確定它是TOE安全功能要求的一個準確實例化。

1.2.1.4　完備的功能規范（ADV_FSP.4）

完備的功能規范組件評估時確定開發者是否完全描述了所有TSFI，描述的方式是否可使評估者能夠肯定TSFI完整精確地描述了執行ST的安全功能需求。接口的完整度是基于實現介紹判斷的。完備的功能規范組件評估證據包括：安全目標、功能規范、TOE設計和實現表示。如果TOE的ST有評估證據的話，那么所使用的評估證據應包括：安全體系結構描述、TSF內部描述、安全策略模型。安全執行功能規范組件評估要求如下：

a) 評估者應檢查功能規范，標識出TSF對應的TSFI，以確定該規范完整地描述了TSF的接口；

b) 評估者應檢查功能規范，以確定接口描述的結構化/半結構化、上下一致，并使用常用術語；

c) 評估者應檢查功能規范，以確定它說明了各TSFI接口所提供的功能的總述；

d) 評估這應檢查功能規范，以確定規范給出了各TSFI的使用方法；

e) 評估者應檢查功能規范，以確定TSFI的完整性；

f) 評估者應檢查TSFI的表示，以確定該表示完整地指出了與各TSFI相關的所有參數；

g) 評估者應檢查TSFI的表示，以確定該表示完整和準確地描述了各TSFI相關的所有參數；

h) 評估者應檢查TSFI的表示，以確定該表示完整地、準確地描述了與各TSFI相關的所有行動；

i) 評估者應檢查TSFI的表示，以確定該表示完整地、準確地描述了調用各TSFI產生的所有錯誤信息；

j) 評估者應檢查TSFI的表示，以確定該表示完整和準確地描述了調用各TSFI產生的所有錯誤信息；

k) 評估者應檢查功能規范，以確定規范完整地、準確地描述了調用一個TSFI不會產生的所有錯誤信息；

l) 評估者應檢查功能規范，以確定對于每一個包含在TSF實現內但不是從TSFI調用中產生的錯誤，該規范都給出了原因；

m) 評估者應檢查，追查將SFR鏈接到對應的TSFI；

n) 評估者應檢查功能規范，以確定它是TOE安全功能要求的一個完備實例化；

o) 評估者應檢查功能規范，以確定它是TOE安全功能要求的一個準確實例化。

1.2.1.5　TSF實現表示（ADV_IMP.1）

TSF實現表示組件評估是確定開發者編寫的實現介紹適合于給其他分析活動使用；其適用性由它與該組件需求的一致性決定。TSF實現表示組件評估證據包括：實現表示、與ALC-TAT相關的開發工具文檔和TOE設計描述。TSF實現表示組件評估要求如下：

a) 評估者應檢查實現表示，以確定其無歧義地定義了TSF，且詳細程度達到了不需要進一步的設計就能生成TSF的程度；

b) 評估者應檢查開發者提供的實現表示，以確定它是以開發人員使用的形式提供的；

c) 評估者應檢查TOE設計描述與實現表示示例之間的映射應能證明它們的一致性的。

1.2.1.6　基礎設計（ADV_TDS.1）

基礎設計組件評估是確定TOE的設計是否提供了一個足以確定TSF邊界的描述，以供評估者確定TOE完整、準確地執行了SFR。基礎設計組件評估證據包括：安全目標、功能規范、安全架構描述和TOE設計描述。基礎設計組件評估要求如下：

a) 評估者應檢查TOE設計，以確定它以子系統方式描述了整個TOE結構；

b) 評估者應檢查TOE設計，以確定整個TSF所有子系統都進行了標識；

c) 評估者應檢查TOE設計，以確定TSF的SFR支持或SFR不相干子系統行為被足夠描述清楚，以保證評估人員能區分SFR支持或SFR不相干子系統；

d) 評估者應檢查TOE設計，以確定它完整、準確和詳細地描述了TSF的SFR子系統SFR強制實施行為；

e) 評估者應檢查TOE設計，以確定它描述了TSF各子系統之間的相互作用；

f) 評估者應檢查TOE設計，以確定TSF子系統和TSF功能接口規范之間的映射是完整的；

g) 評估者應檢查TOE安全功能需求和TOE設計，以確定TOE設計覆蓋了TOE所有安全功能需求；

h) 評估者應檢查TOE設計，以確定設計是所有安全功能要求的正確且完全的實例。

1.2.1.7　結構化設計（ADV_TDS.2）

結構化設計組件評估是確定高層設計是否按照子系統提供了TSF的描述，提供了這些子系統接口的描述，并是功能規范的一個正確實現。結構化設計組件評估證據包括：安全目標、功能規范、安全架構描述和TOE設計描述。結構化設計組件評估要求如下：

a) 評估者應檢查TOE設計，以確定它以子系統方式描述了整個TOE設計；

b) 評估者應檢查TOE設計，以確定整個TSF所有子系統都進行了標識；

c) 評估者應檢查TOE設計，以確定TSF的SFR不相干子系統的行為描述足夠讓評估者確認SFR不相干的子系統；

d) 評估者應檢查TOE設計，以確定它完整、準確和詳細地描述了TSF的SFR子系統SFR強制實施行為；

e) 評估者應檢查TOE設計，以確定它完整和準確地提供了SRF強制實施的SRF支持和SRF不相干子系統的高層行為描述；

f) 評估者應檢查TOE設計，以確定它完整和準確地提供了SRF強制實施的高層行為描述；

g) 評估者應檢查TOE設計，以確定它描述了TSF各子系統之間的相互作用；

h) 評估者應檢查TOE設計，以確定TOE設計中描述的所有行為能夠映射到調用它的TSFI；

i) 評估者應檢查TOE安全功能需求和TOE設計，以確定TOE設計覆蓋了TOE所有安全功能需求；

j) 評估者應檢查TOE設計，以確定確定設計是所有安全功能要求的正確且完全的實例。

1.2.1.8　基礎模塊設計（ADV_TDS.3）

基礎模塊設計評估是確定TOE設計是否提供了一個足以確定TSF邊界的描述，且以模塊方式描述了TOE內部描述。它提供了SFR強制實施模塊和SFR支持模塊的詳細描述，以供評估者確定TOE完整、準確地執行了SFR。基礎模塊設計組件評估證據包括：安全目標、功能規范、安全架構描述和TOE設計描述。基礎模塊設計組件評估要求如下：

a) 評估者應檢查TOE設計，以確定它以子系統方式描述了整個TOE設計；

b) 評估者應檢查TOE設計，以確定完整的TSF是以模塊方式描述的；

c) 評估者應檢查TOE設計，以確定整個TSF所有子系統都進行了標識；

d) 評估者應檢查TOE設計，以確定TSF的每個子系統描述了它在安全目標中SRF強制實施的角色；

e) 評估者應檢查TOE設計，以確定TSF中每個SFR不相干子系統描述的足夠讓評估者確認它是SFR不相干子系統；

f) 評估者應檢查TOE設計，以確定TSF各子系統之間的相互作用已經描述；

g) 評估者應檢查TOE設計，以確定提供了TSF子系統到TSF模塊間的映射關系

h) 評估者應檢查TOE設計，以確定每一個SFR-執行模塊，包括它的目的及與其它模塊間的相互作用；

i) 評估者應檢查TOE設計，以確定每一個SFR-執行模塊，包括它的安全功能要求相關接口、其它接口的返回值、與其它模塊間的相互作用及調用的接口；

j) 評估者應檢查TOE設計，以確定描述每一個SFR-支撐或SFR-無關模塊，包括它的目的及與其它模塊間的相互作用；

k) 評估者應檢查TOE設計，以確定映射關系應論證TOE設計中描述的所有行為能夠映射到調用它的TSFI。

1.2.2　指導性文檔（AGD類）

1.2.2.1　操作用戶指南（AGD_OPE.1）

操作用戶指南組件是判斷用戶手冊是否描述了每個用戶角色的安全功能和TSF接口，是否說明了TOE的安全使用方法，是否所有操作模式的安全步驟，是否有簡易的TOE不安全狀態的預防和探測，以及是否有歧義或其它不合理內容。操作用戶指南組件評估依據包括安全目標、功能規范、TOE設計和用戶操作指南。操作用戶指南組件安全評估內容如下：

a) 評估者應檢查用戶操作手冊，以判斷它是否描述了，每個用戶角色的可用的功能，在安全處理環境控制下的權限，包括適當的警告；

b) 評估者應檢查用戶操作手冊，以判斷它是否描述了每個用戶角色相應的TOE提供接口的安全用法；

c) 評估者應檢查用戶操作手冊，以判斷它是否描述每個用戶角色可用的功能和接口，特別是用戶可以控制的安全參數，指出安全參數合適的數值；

d) 評估者應檢查用戶操作手冊，以判斷它是否描述了每個用戶角色每種需要演示的功能的安全相關事件，包括在TSF控制下的實體的屬性變更和運行失敗和錯誤之后的操作；

e) 評估者應檢查用戶操作手冊和其它評估證據，以判斷手冊是否指出所有可能的TOE操作的模式（包括，可選的，運行失敗和錯誤之后的操作），它們對維護安全操作的影響和后果；

f) 評估者應檢查用戶操作手冊，以判斷它是否對每個用戶角色描述了，應當運用的安全措施，以滿足ST描述的安全操作環境的安全目標；

g) 評估者應檢查用戶操作手冊，以判斷它是否清晰；

h) 評估者應檢查用戶操作手冊，以判斷它是否合理。

1.2.2.2　準備程序（AGD_PRE.1）

準備程序組件判斷TOE的安全準備步驟是否被記錄并得到安全的配置。準備程序組件評估依據包括安全目標、TOE及其準備步驟和開發者提供服務的步驟。準備程序組件安全評估內容如下：

a) 評估者應檢查接受步驟，以判斷是否描述了所有安全接受TOE交付的必要步驟，以及和開發商交付步驟的配合；

b) 評估者應檢查所提供的安裝步驟，以判斷是否描述了，TOE安全安裝的所有必要步驟；為了達到依據ST描述了操作環境的安全目標，所需進行的安全準備步驟；

c) 評估者應運行所有必要的TOE準備步驟，以判斷只有用給定的準備步驟，TOE和它的操作環境可以被安全的準備

1.2.3　生命周期支持（ALC類）

1.2.3.1　CM系統的使用（ALC_CMC.2）

CM系統的使用組件判斷開發者是否已經清晰地定義了TOE及其相關的配置項，對這些配置項的修改是否恰當地由工具自動控制，以使得CM系統更少地受到人為錯誤或疏忽的影響。CM系統的使用組件評估的依據包括安全目標、適合測試的TOE和配置管理文檔。CM系統的使用組件安全評估內容包括：

a) 評估者應核查所提交評估的TOE是否標記了參照號；

b) 評估者應核查所使用的TOE參照號的一致性；

c) 評估者應核查所使用CM文檔應有用于描述唯一標識配置項的方法；

d) 評估者應核查CM系統所有配置項以在CM文檔中各配置項的一致性。

1.2.3.2　授權控制（ALC_CMC.3）

授權控制組件判斷開發者使用CM唯一標識了所有的系統配置項，且每個配置項的修改都被CM系統控制。授權控制組件評估的依據包括安全目標、適合測試的TOE和配置管理文檔。授權控制組件安全評估內容包括：

a) 評估者應核查所提交評估的TOE是否標記了參照號；

b) 評估者應核查所使用的TOE參照號的一致性；

c) 評估者應核查所使用CM文檔應有用于描述唯一標識配置項的方法；

d) 評估者應核查CM系統所有配置項標識與CM文檔中各配置項方法相一致；

e) 評估者應核查在CM計劃中描述的CM訪問控制措施使得只能對配置項進行授權變更；

f) 評估者應核查在CM文檔應包括一個CM計劃；

g) 評估者應核查 CM計劃應描述CM系統是如何應用于TOE的開發過程；

h) 評估者應核查證據應證實所有配置項都正在CM系統下進行維護；

i) 評估者應核查證據應證實CM系統的運行與CM計劃是一致的。

1.2.3.3　生產支持和接受程序及其自動化（ALC_CMC.4）

生產支持和接受程序及其自動化組件判斷開發者是否已經清晰地定義了TOE及其相關的配置項，對這些配置項的修改是否恰當地由工具自動控制，以使得CM系統更少地受到人為錯誤或疏忽的影響。生產支持和接受程序及其自動化組件的依據包括安全目標、適合測試的TOE和配置管理文檔。生產支持和接受程序及其自動化組件評估內容包括：

a) 評估者應核查所提交評估的TOE是否標記了參照號；

b) 評估者應核查所使用的TOE參照號的一致性；

c) 評估者應核查所使用CM文檔應有用于描述唯一標識配置項的方法；

d) 評估者應核查CM系統所有配置項標識與CM文檔中各配置項方法相一致；

e) 評估者應核查在CM計劃中描述的CM訪問控制措施使得只能對配置項進行授權變更；

f) 評估者應核查在CM計劃中提供了自動化的措施使得只能對配置項進行授權變更；

g) 評估者應核查TOE生產系統支持程序以確定CM系統應以自動化的方式支持TOE的生產；

h) 評估者應核查在CM文檔應包括一個CM計劃；

i) 評估者應核查 CM計劃確認是否描述了CM系統是如何應用于TOE的開發過程；

j) 評估者應核查 CM計劃確認是否描述了TOE配置項修改和增減的程序規范；

k) 評估者應核查證據應證實所有配置項都正在CM系統下進行維護；

l) 評估者應核查CM文檔以確認它包含了CM計劃規定的CM配置記錄內容；

m) 評估者應核查證據應證實CM系統的運行與CM計劃是一致的。

1.2.3.4　部分TOE CM覆蓋（ALC_CMS.2）

部分TOE CM覆蓋組件判斷TOE中的配置列表是否包括了TOE所有組成，包括相關的評估證據。這些配置項應與ALC_CMC受控程序相一致。部分TOE CM覆蓋組件的安全評估依據包括安全目標和配置列表。部分TOE CM覆蓋組件評估內容包括：

a) 評估者應核查配置列表以確認包括：TOE本身、安全保障要求的評估證據和TOE的組成部分；

b) 評估者應核查配置列表以確認能唯一標識使用配置項；

c) 評估者應核查配置列表以確認對于每一個TSF相關的配置項，配置項列表應簡要說明該配置項的開發者。

1.2.3.5　實現表示CM覆蓋（ALC_CMS.3）

實現表示 CM覆蓋組件判斷TOE中的配置列表是否包括了TOE所有組成，TOE實現表示和相關的評估證據。這些配置項應與ALC_CMC受控程序相一致。實現表示CM覆蓋組件的安全評估依據包括安全目標和配置列表。實現表示CM覆蓋組件評估內容包括：

a) 評估者應核查配置列表以確認包括：TOE本身、TOE實現表示、安全保障要求的評估證據和TOE的組成部分；

b) 評估者應核查配置列表以確認能唯一標識使用配置項；

c) 評估者應核查配置列表以確認對于每一個TSF相關的配置項，配置項列表應簡要說明該配置項的開發者。

1.2.3.6　問題跟蹤CM覆蓋（ALC_CMS.4）

問題跟蹤 CM覆蓋組件判斷TOE中的配置列表是否包括了TOE所有組成，TOE實現表示、安全弱點和相關的評估證據。這些配置項應與ALC_CMC受控程序相一致。問題跟蹤CM覆蓋組件的安全評估依據包括安全目標和配置列表。問題跟蹤CM覆蓋組件評估內容包括：

a) 評估者應核查配置列表以確認包括：TOE本身、TOE實現表示、安全保障要求的評估證據、安全缺陷報告及其解決狀態和TOE的組成部分；

b) 評估者應核查配置列表以確認能唯一標識使用配置項；

c) 評估者應核查配置列表以確認對于每一個TSF相關的配置項，配置項列表應簡要說明該配置項的開發者。

1.2.3.7　交付程序（ALC_DEL.1）

交付程序組件評估目的是確定交付文檔是否描述了在將 TOE分發到用戶現場時，用于保持其安全性的所有程序。交付程序組件安全評估證據包括安全目標和交付文檔。交付程序組件安全評估內容如下：

a) 評估者需要檢查交付文檔，以確定它描述了在將TOE版本及其部件發布給消費者時，所有維護安全性所需的過程；

b) 評估者應檢查交付過程的各個方面，以確定其使用了交付程序。

1.2.3.8　安全措施標識（ALC_DVS.1）

安全措施標識組件評估目的是確定開發者在開發環境中的安全性操作足以提供TOE設計和實現的保密性和完整性。安全措施標識評估依據安全目標和安全開發。安全措施標識安全評估內容包括：

a) 評估者應檢查開發安全性文檔，以確定它細化了在開發環境中用到的所有安全性度量，確認TOE設計和實現的保密性和完整性所必需的所有物理的、程序的、人員的及其它方面的安全措施；

b) 評估者應檢查開發的保密性和完整性策略，以確定使用的安全性措施是足夠的；

c) 評估者需要檢查開發安全性文檔及相關的安全評估證據，以確定各種安全措施都已經被應用。

1.2.3.9　開發者定義的生命周期模型（ALC_LCD.1）

開發者定義的生命周期模型組件評估目標是確定開發者是否使用了文檔化且可度量的TOE生命周期模型。開發者定義的生命周期模型組件安全評估依據包括安全目標和生命周期定義文檔。開發者定義的生命周期模型組件安全評估內容包括

a) 評估者應檢查所使用的生命周期模型的文檔化描述，以確定它覆蓋了開發和維護的過程，包括其計算參數的細節和/或用于度量TOE開發的指標；

b) 評估者應檢查生命周期模型，以確定由生命周期模型描述的程序、工具和技術的使用將對TOE的開發和維護作出必要的積極貢獻；

c) 評估者應檢查生命周期輸出文檔，以確定它提供了使用可度量的生命周期模型的TOE開發的度量結果。

1.2.3.10　明確定義的開發工具（ALC_TAT.1）

明確定義的開發工具組件安全評估目的是確定開發者和他的分包商是否使用了良好定義的、產出一致的和預期的結果的開發工具（比如編程語言或者計算機輔助設計系統（CAD）），并確定是否應用了實現標準。明確定義的開發工具評估依據包括開發者標識的用于開發TOE的每個工具和每個開發工具所選取的實現依賴選項。明確定義的開發工具安全評估內容包括：

a) 評估者應核查用于實現的每個開發工具都應是明確定義的；

b) 評估者應核查每個開發工具的文檔應無歧義地定義所有語句和實現用到的所有協定與命令的含義；

c) 評估者應核查每個開發工具的文檔應無歧義地定義所有實現依賴選項的含義。

1.2.4　安全目標評估（ASE類）

1.2.4.1　符合性聲明（ASE_CCL.1）

符合性聲明組件安全評估目的是確認安全目標與安全要求（保護輪廓）的一致性。符合性聲明組件安全評估依據包括開發者提供的符合性聲明和符合性聲明的基本原理。符合性聲明組件安全評估內容包括：

a) 評估者應核查安全目標的符合性聲明，確認標識出ST和TOE聲明符合性遵從的GB/T 18336的版本；

b) 評估者應核查安全目標的符合性聲明，確認描述了ST和GB/T 18336.2的符合性，無論是與GB/T 18336.2相符或是與GB/T 18336.2的擴展部分相符；

c) 評估者應核查安全目標的符合性聲明，確認描述了ST和GB/T 18336.3的符合性，無論是與GB/T 18336.3相符或是與GB/T 18336.3的擴展部分相符；

d) 評估者應核查GB/T 18336.2的符合性聲明，確認功能擴展組件定義是相一致的；

e) 評估者應核查GB/T 18336.2的符合性聲明，確認保障擴展組件定義是相一致的；

f) 評估者應核查符合性聲明應標識ST聲明遵從的所有PP和安全要求包；

g) 評估者應核查符合性聲明，對ST中每一個可標識，描述了符合性聲明，無論是與包的相符或是與擴展包相符；

h) 評估者應核查符合性聲明的基本原理，證實TOE類型與符合性聲明所遵從的PP中的TOE類型是相符的；

i) 評估者應核查符合性聲明的基本原理，證實安全問題定義的陳述與符合性聲明所遵從的PP中的安全問題定義陳述是相符的；

j) 評估者應核查符合性聲明的基本原理，證實安全目的陳述與符合性聲明所遵從的PP中的安全目的陳述是相符的；

k) 評估者應核查符合性聲明的基本原理，證實安全要求的陳述與符合性聲明所遵從的PP中的安全要求的陳述是相符的。

1.2.4.2　擴展組件定義（ASE_ECD.1）

對擴展組件定義的評估需要確定這些組件是明確的、沒有歧義的并且是必要的。擴展組件定義安全評估內容包括：

a) 評估者應核查安全目標中所有不是標識為擴展安全要求的安全要求來自于GB/T 18336.2或GB/T 18336.3；

b) 評估者應核查安全目標中擴展組件定義，確定每一個擴展的安全要求都定義一個擴展的組件；

c) 評估者需要核查擴展組件定義，確定每個擴展的組件使用了GB/T 18336提供的組件、族和類定義格式，及與GB/T 18336已有的組件、族和類關聯性；

d) 評估者應核查擴展組件定義，確定每個擴展組件定義標識了這個組件所有可能的依賴關系；

e) 評估者應核查擴展組件定義，確定功能擴展組件的描述使用了GB/T 18336.2組件作為其陳述的模型；

f) 評估者應核查擴展組件定義，確定功能擴展組件族的描述使用了GB/T 18336.2族作為其陳述的模型；

g) 評估者應核查擴展組件定義，確定擴展組件類的描述使用了GB/T 18336.2類作為其陳述的模型；

h) 評估者應核查擴展組件定義，確定保障擴展組件的描述使用了GB/T 18336.3組件作為其陳述的模型；

i) 評估者應核查擴展組件定義，確定提供了每個保障擴展組件的評估方法

j) 評估者應核查擴展組件定義，確定保障擴展組件族的描述使用了已有的保障族作為其陳述的模型；

k) 評估者應核查擴展組件定義，確定保障擴展組件類的描述使用了已有的保障類作為其陳述的模型；

l) 評估者應核查擴展組件定義，確保擴展組件是由可測量的和客觀的元素組成，以便于證實這些元素之間的符合性或不符合性；

m) 評估者應核查擴展組件定義，以確認擴展組件不能利用已經存在的組件明確的表達。

1.2.4.3　ST引言（ASE_INT.1）

對ST引言的評估需要證實ST和TOE被正確標識，TOE的三層抽象方式描述正確，并且這三方面的描述相互一致。ST引言安全評估內容包括：

a) 評估者應核查開發者提供的ST引言，確認它包含ST參照號，TOE參照號，TOE概述和TOE描述；

b) 評估者應核查ST參照號, 確認它能唯一標識ST；

c) 評估者應核查TOE參照號，確認能唯一標識TOE；

d) 評估者應核查TOE參照號，確認它不會誤導消費者辨識TOE；

e) 評估者應核查TOE概述，確認它正確的概括TOE的用法及其主要安全特性；

f) 評估者應核查TOE概述，確認它正確標識了TOE類型；

g) 評估者應核查TOE概述，確認它不會誤導消費者辨識TOE類型；

h) 評估者應核查TOE概述，確認它標識了任何TOE要求的非TOE范圍內的硬件/軟件/固件；

i) 評估者應核查TOE描述，確認它正確的描述TOE的物理范圍；

j) 評估者應核查TOE描述，確認它正確的描述TOE的邏輯范圍；

k) 評估者應核查TOE參照號，TOE概述和TOE描述，確認它們之間的相互一致性。

1.2.4.4　安全目的（ASE_OBJ.2）

安全目的評估是確定安全目的描述是否完備和一致，并確定安全目的是否能對抗已標識的威脅，實現已標識的組織安全策略并遵循規定的假設。安全目的安全評估內容包括：

a) 評估者應核查開發者提供的安全目的的陳述，確認它描述TOE的安全目的和運行環境安全目的；

b) 評估者應核查安全目的基本原理，確認TOE的每一個安全目的能追溯到安全目的所對抗的威脅及安全目的實施的組織安全策略；

c) 評估者應核查安全目的基本原理，確認TOE運行環境的每一個安全目的能追溯到安全目的所對抗的威脅、安全目的實施的組織安全策略和安全目的支持的假設；

d) 評估者應核查安全目的基本原理，能證實安全目的能抵抗所有威脅；

e) 評估者應核查安全目的基本原理，能證實安全目的執行所有組織安全策略；

f) 評估者應核查安全目的基本原理，能證實運行環境安全目的支持所有的假設。

1.2.4.5　推導出的安全要求（ASE_REQ.2）

本組件評估目的是確定TOE安全要求（包括TOE安全功能要求和TOE安全保證要求）和IT環境安全要求是否完備和一致，并為TOE的開發提供充分的基礎，將達到其安全目的。推導出的安全要求組件安全評估內容包括：

a) 評估者應核查安全要求的陳述是否描述了TOE安全功能要求；

b) 評估者應核查安全要求的陳述是否描述了TOE保障安全要求；

c) 評估者應核查安全目標，確認安全功能要求和安全保障要求中使用的所有主體、客體、操作、安全屬性、外部實體及其它術語進行了定義；

d) 評估者應核查安全要求的陳述，確認對安全要求的所有操作進行了標識；

e) 評估者應核查安全要求的陳述，確認所有賦值操作都應被正確地執行；

f) 評估者應核查安全要求的陳述，確認所有迭代操作都應被正確地執行；

g) 評估者應核查安全要求的陳述，確認所有選擇操作都應被正確地執行；

h) 評估者應核查安全要求的陳述，確認所有細化操作都應被正確地執行；

i) 評估者應核查安全要求的陳述，確認安全要求間的依賴關系應滿足，或者安全要求基本原理應證明不需要滿足某個依賴關系；

j) 評估者應核查安全要求的基本原理，確認每一個安全功能要求可追溯至對應的TOE安全目的；

k) 評估者應核查安全要求的基本原理，證明安全功能要求可滿足所有的TOE安全目的；

l) 評估者應核查安全要求的基本原理，確認有安全保障要求的選擇理由。

1.2.4.6　安全問題定義（ASE_SPD.1）

安全問題定義評估是確定ST中TOE安全問題的陳述是否為有關TOE及其預期應用環境的安全問題提供了一個清晰、一致的定義。安全問題定義評估內容如下：

a) 評估者應核查安全問題定義描述了威脅；

b) 評估者應核查安全問題定義，確認對所有的威脅都根據威脅主體、資產和敵對行為進行了描述；

c) 評估者應核查安全問題定義描述了組織安全策略；

d) 評估者應核查安全問題定義描述了TOE運行環境的相關假設。

1.2.4.7　TOE概要規范（ASE_TSS.1）

TOE概要規范評估是確定TOE概要規范是否為安全功能和安全保障措施提供了清晰的、一致的高層定義，且滿足指定的TOE安全要求。TOE概要規范安全評估內容如下：

a）評估者應核查TOE概要規范，是否描述了描述TOE是如何滿足每一項安全功能要求的；

b）評估者應核查TOE概要規范，確認TOE概要規范與TOE概述、TOE描述是一致的。

1.2.5　測試（ATE類）

1.2.5.1　覆蓋證據（ATE_COV.1）

覆蓋證據組件評估目的是確定開發人員是否已經測試了所有的TSFI（評估對象安全功能接口），并且開發人員的測試覆蓋憑證可以證明測試文檔定義的測試與功能規范描述的TSFI相對應。覆蓋證據組件評估目的依據是開發者提供的測試覆蓋的分析。覆蓋證據組件評估內容包括：評估者應檢查測試覆蓋分析，以確定測試文檔中的測試項與功能規范中的接口準確對應。

1.2.5.2　覆蓋分析（ATE_COV.2）

覆蓋分析組件評估目的是確定開發人員是否已經測試了所有的TSFI（評估對象安全功能接口），并且開發人員的測試覆蓋憑證可以證明測試文檔定義的測試與功能規范描述的TSFI相對應。覆蓋分析組件評估目的依據是開發者提供的測試覆蓋的分析。覆蓋分析組件評估內容包括：

a) 評估者應檢查測試覆蓋分析，以確定測試文檔中的測試項與功能規范中的接口準確對應；

b) 評估者應檢查測試計劃，以確定對于每一個接口的測試方法與該接口期望的行為相對應；

c) 評估者應檢查測試程序，以確定測試條件、測試步驟和與其測試結果可以充分測試每一個接口；

d) 評估者應檢查測試覆蓋分析，以確定功能規范中的接口與測試文檔中的測試項的對應性是完備的。

1.2.5.3　測試：基本設計（ATE_DPT.1）

測試：基本設計安全評估目的是確定開發人員是否已經對照TOE設計和安全結構描述，測試了所有的TSF子系統和模塊。安全評估活動的證據包括：安全目標、功能規范、TOE設計、安全架構描述、測試文檔和測試深度分析。安全執行模塊組件安全評估要求如下:

a） 評估者應檢查測試深度分析，以確定測試文檔中包括TSF子系統行為及其交互行為的描述；

b） 評估者應檢查測試計劃、測試條件、測試步驟和期望結果以確定對于行為描述的測試方法與TOE設計中描述的子系統行為相對應；

c） 評估者應檢查測試計劃、測試條件、測試步驟和期望結果以確定對于行為描述的測試方法與TOE設計中描述的子系統交互行為相對應；

d） 評估者應檢查測試程序，證實TOE設計中的所有TSF子系統都已經進行過測試。

1.2.5.4　測試：安全執行模塊（ATE_DPT.2）

測試：安全執行模塊組件確定開發人員是否已經對照TOE設計和安全結構描述，測試了所有的TSF子系統和模塊。安全評估活動的證據包括：安全目標、功能規范、TOE設計、安全架構描述、測試文檔和測試深度分析。安全執行模塊組件安全評估要求如下:

a) 評估者應檢查測試深度分析，以確定測試文檔中包括TSF子系統行為及其交互行為的描述；

b) 評估者應檢查測試計劃、測試條件、測試步驟和期望結果以確定對于行為描述的測試方法與TOE設計中描述的子系統行為相對應；

c) 評估者應檢查測試計劃、測試條件、測試步驟和期望結果以確定對于行為描述的測試方法與TOE設計中描述的子系統交互行為相對應；

d) 評估者應檢查測試深度分析以確定測試文檔中包括TSF模塊接口；

e) 評估者應檢查測試計劃、測試條件、測試步驟和期望結果以確定對于每一個TSF模塊接口的測試方法與該接口期望的行為相對應；

f) 評估者應檢查測試程序以確定TSF子系統行為及交互行為的所有描述都被測試；

g) 評估者應檢查測試程序以確定所有TSF模塊的所有安全功能都被測試。

1.2.5.5　功能測試（ATE_FUN.1）

功能測試是是確定開發人員是否在測試文檔中正確描述了測試項。安全評估活動的證據包括：安全目標、功能規范和測試文檔。功能測試組件安全評估要求如下:

a) 評估者應檢查測試文檔是否包括測試計劃、預期測試結果和實際測試結果；

b) 評估者應檢查測試計劃以確定它描述了每個測試執行的場景；

c) 評估者應檢查測試計劃，以確定TOE測試配置是否與在ST中列出的評估配置一致；

d) 評估者應檢查測試計劃以確定對于任何順序的依賴性測試計劃提供足夠的規程；

e) 評估者應檢查測試文檔以確定其包括所有期望的測試結果；

f) 評估者應檢查測試文檔中的實際測試結果與預期測試結果相一致；

g) 評估者應報告評估者的測試工作，概要性的闡述測試方法、配置、深度和結果。

1.2.5.6　獨立測試—抽樣（ATE_IND.2）

獨立測試—抽樣組件通過對TSF的一個子集進行獨立測試，確定TOE是否按規定運轉，并通過執行開發者測試的一個例子，以獲得對開發者測試結果的信任。安全評估活動的證據包括：安全目標、功能說明書、TOE設計、用戶指南、管理員指南、配置管理文檔、測試文檔和適合測試的TOE。獨立測試—抽樣組件安全評估要求如下:

a) 評估者應檢查TOE，以確定測試配置與ST規定的評估配置是一致的；

b) 評估者應檢查TOE，以確定它已被正確安裝并處于某個已知狀態；

c) 評估者應檢查開發者提供的資源集，以確認它們與開發者做TSF功能測試時使用的資源集等同；

d) 評估者應根據開發者測試計劃和程序設計一個測試子集；

e) 評估者應核查所有的實際測試結果，是否與預期測試結果一致；

f) 評估者選擇一個適合于TOE的測試子集和測試策略；

g) 評估者應為測試子集編制測試文檔，以便有足夠的細節使得測試是可再現的；

h) 評估者使用所開發的測試文檔作為對TOE進行測試的基礎，對TOE實施測試；

i) 評估者應記錄包含在測試子集中的如下測試信息：

1) 待測試的安全功能行為的標識；

2) 連接和設置執行測試所需要的所有測試設備的規程；

3) 建立測試所需的先決條件的規程；

4) 激發安全功能的規程；

5) 觀察安全功能行為的規程；

6) 所有預期結果的描述，以及對觀察到的行為進行的必要分析，該分析是為了與預期結果進行比較；

7) 結束測試和為TOE建立必要的測試后狀態的規程；

8) 實際測試結果。

j) 評估者應核查所有的實際測試結果，是否與預期測試結果一致；

k) 評估者應在ETR中報告評估者的測試工作，概要性的闡述測試方法、配置、深度和結果；

1.2.6　脆弱性評定（AVA類）

1.2.6.1　脆弱性分析（AVA_VAN.2）

脆弱性分析組件確保數據庫管理系統在其運行環境下是否存在會被具有中等攻擊潛力的攻擊者利用的脆弱性。安全評估活動的證據包括：安全目標、功能說明書、TOE設計、安全架構描述、TOE實現表示、指導文檔、適合測試的TOE、支持潛在脆弱性識別的公開信息、基本設計測試的結果和當前關于公共域潛在脆弱性和攻擊的信息。脆弱性分析組件安全評估要求如下：

a) 評估者應檢查TOE以確定測試配置和ST所說明的測試配置一致；

b) 評估者應檢查TOE以確定它被正確安裝并且處于一個已知狀態；

c) 評估者應檢查公共可資源，以識別TOE中可能的潛在漏洞；

d) 評估者應對ST、指導文檔、功能說明、TOE設計、安全結構描述和實現表示進行系統的分析以識別TOE中可能的潛在漏洞；

e) 評估者應在ETR中記錄待測試的并且可應用于TOE運行環境的識別出的潛在漏洞；

f) 評估者應在獨立搜索潛在脆弱性的基礎上，進行穿透性測試；

g) 評估者應為基于潛在脆弱性列表的穿透性測試撰寫足夠詳細的穿透性測試文檔，以提供測試的可重復性；測試文檔包括：

1) 用于測試的TOE安全漏洞標識；

2) 驅動穿透性測試需要的所有測試裝置的連接和設置指令；

3) 建立所有穿透性測試準備條件的指令；

4) 仿真TSF的指令；

5) 觀察TSF行為的指令；

6) 所有預期結果的描述和針對期望結果對觀察行為進行比較分析指令；

7) 總結TOE測試和測試后對TOE后期狀態維護指令。

h) 評估者應對TOE進行穿透性測試；

i) 評估者應記錄穿透性測試的真實結果；

j) 評估者應在ETR中報告評估者對穿透性測試的努力，主要包括測試方法、測試配置、測試深度和測試結果；

k) 評估者應檢查所有穿透性測試的結果以確定TOE在它的運行環境下能抵御具有基本攻擊潛力的攻擊者的攻擊；

l) 評估者應在ETR中報告所有可利用的脆弱性和剩余脆弱性，詳細包括：

1) 它的來源（例如，在CEM評估活動中發現的、評估人員知道的或 在公共資源中閱讀到的）；

2) 安全功能要求沒有滿足；

3) 具體描述；

4) 在運行環境中是否可以利用（即可利用還是殘留）；

5) 時間長短、專業化水平和TOE知識水平，以及對標識漏洞進行攻擊需要的攻擊及可能性等，包括相應的利用價值。

1.2.6.2　關注點脆弱性分析（AVA_VAN.3）

關注點脆弱性分析組件確保數據庫管理系統在其運行環境下是否存在會被具有中等攻擊潛力的攻擊者利用的脆弱性。安全評估活動的證據包括：安全目標、功能說明書、TOE設計、安全架構描述、TOE實現表示、指導文檔、適合測試的TOE、支持潛在脆弱性識別的公開信息、基本設計測試的結果和當前關于公共域潛在脆弱性和攻擊的信息。關注點脆弱性分析組件安全評估要求如下：

a) 評估者應檢查TOE以確定測試配置和ST所說明的測試配置一致；

b) 評估者應檢查TOE以確定它被正確安裝并且處于一個已知狀態；

c) 評估者應檢查公共可資源，以識別TOE中可能的潛在漏洞；

d) 評估者應對ST、指導文檔、功能說明、TOE設計、安全結構描述和實現表示進行系統的分析以識別TOE中可能的潛在漏洞；

e) 評估者應在ETR中記錄待測試的并且可應用于TOE運行環境的識別出的潛在漏洞；

f) 評估者應在獨立搜索潛在脆弱性的基礎上，進行穿透性測試；

g) 評估者應為基于潛在脆弱性列表的穿透性測試撰寫足夠詳細的穿透性測試文檔，以提供測試的可重復性；測試文檔包括:

1) 用于測試的TOE安全漏洞標識；

2) 驅動穿透性測試需要的所有測試裝置的連接和設置指令；

3) 建立所有穿透性測試準備條件的指令；

4) 仿真TSF的指令；

5) 觀察TSF行為的指令；

6) 所有預期結果的描述和針對期望結果對觀察行為進行比較分析指令；

7) 總結TOE測試和測試后對TOE后期狀態維護指令。

h) 評估者應對TOE進行穿透性測試；

i) 評估者應記錄穿透性測試的真實結果；

j) 評估者應在ETR中報告評估者對穿透性測試的努力，主要包括測試方法、測試配置、測試深度和測試結果；

k) 評估者應檢查所有穿透性測試的結果以確定TOE在它的運行環境下能抵御抵抗具有增強型基本攻擊潛力的攻擊者的攻擊；

l) 評估者應在ETR中報告所有可利用的脆弱性和剩余脆弱性，詳細內容包括：

1) 它的來源（例如，在CEM評估活動中發現的、評估人員知道的或 在公共資源中閱讀到的）；

2) 安全功能要求沒有滿足；

3) 具體描述；

4) 在運行環境中是否可以利用（即可利用還是殘留）；

5) 時間長短、專業化水平和TOE知識水平，以及對標識漏洞進行攻擊需要的攻擊及可能性等，包括相應的利用價值。

1.3　評估方法

1.3.1　評估原則

依照GB/T 30270-2013，評估者對安全目標進行評估后，對GB/T 20273-201X規定的安全要求給予裁決。依據GB/T 30270-2013，給予裁決的最小結構是本標準規定的安全功能組件和安全保障組件的評估者行為元素。作為執行相應評估方法行為及其組成工作單元的結果，GB/T 20273-201X的每一個要求均被賦予一個裁決。如安全目標未聲明GB/T 20273-201X符合性要求，則安全評估人員對未包含在本標準中的安全組件，按照GB/T 30270-2013獨立選擇相應的組件進行評估。

1.3.2　評估方法

安全功能組件和安全保障組件采用的評估方法包括但不限于：

a) 檢查（examine）：評估者通過采用專業技能分析形成一個裁決。使用此動詞的語句表明哪些是需要分析的以及什么樣的屬性需要分析。

b) 核查（check）：評估者不必采用專門技能僅通過簡單比較形成一個裁決。評估者做出一個快速決定，但可能只需要一個快速分析或完全不用分析。

c) 獨立測試（independent testing）：評估者依據評估對象的功能組件，采用抽樣測試，或評估者自己設計測試用例的測試，完成數據庫安全功能組件的功能測試；

d) 穿透性測試（penetration testing）：評估者采用專門技能，以未經授權的動作繞過某一系統的安全機制的方式，檢查數據庫管理系統的安全功能，以發現安全問題的手段.也稱滲透性測試或逆向測試。

e) 確認（confirm）：已對某事項進行了詳細的審核以做出獨立的決定；所需要的嚴格程度依賴于事項的本質特征。這個術語僅用于評估者行為；

f) 確定（determine）：通過獨立分析來肯定一個特定的結論，該分析以達成一個特定的結論為目的。

g) 確保（ensure）：保證在行為及其結果之間存在牢固的因果關系。

h) 證實（demonstrate）：得出一個由分析獲得的結論，它不如“證明”那樣嚴格；

i) 論證（justification）：分析以得出一個結論。“論證”比“證實”更嚴格。從需要非常仔細、全面地解釋邏輯論證的每一步來說，這個術語要求十分嚴格；

j) 證明（prove）：通過數學意義上的形式化分析來說明對應關系；

k) 驗證（verity）：通過嚴格細致地審查，獨立地確定充分性。

1.3.3　評估內容

依照GB/T 30270-2013，評估者對GB/T 20273-201X(表1所示）設計相應的功能測試用例的安全功能要求進行測試評估。

1.3.4　評估結果

本標準認可三種互相排斥的裁決情形：

a) 通過：評估者完成了GB/T 30270-2013 “評估者行為元素”，并確定接受評估的PP、ST或TOE的要求得到滿足。通過評估的條件在相關行為的組成工作單元中給定。

b) 待定：評估者未完成與GB/T 30270-2013評估者行為元素相關的一個或多個評估方法行為工作單元；

c) 不通過：評估者完成了GB/T 30270-2013評估者行為元素并確定接受評估的PP、ST或TOE未滿足要求。

所有的裁決最初都是“待定”，直到被賦予“通過”或“不通過”裁決為止。

當且僅當所有組成部分的裁決都為“通過”，總體裁決才為“通過”。如果某個評估者行為元素的裁決為“不通過”，則相應保證組件、保證類的裁決和總體裁決都為“不通過”。