https://ad.doubleclick.net/ddm/trackclk/N1114924.376585INFORMATIONSECURI/B26202047.309881952;dc_trk_aid=502706469;dc_trk_cid=155369661;dc_lat=;dc_rdid=;tag_for_child_directed_treatment=;tfua=;ltd=
https://ad.doubleclick.net/ddm/trackclk/N1114924.376585INFORMATIONSECURI/B26202047.309881952;dc_trk_aid=502706469;dc_trk_cid=155369661;dc_lat=;dc_rdid=;tag_for_child_directed_treatment=;tfua=;ltd=

觀點

共同準則評估文件品質要求簡介(上)以防火牆與智慧卡評估為例

2007 / 12 / 18
編輯部
共同準則評估文件品質要求簡介(上)以防火牆與智慧卡評估為例

共同準則好處
共同準則(CC, Common Criteria)為針對資訊安全相關產品或系統所訂定的安全評估準則,且已被接受為國際標準(ISO/IEC 15408)。這份準則的建立,提供一般資訊安全產品的業主(Sponsor)與開發者(Developer)、評估員(Evaluator)及消費者(Consumer),於資訊安全產品的開發、評估與使用等各階段,有一份共同依據的安全準則。

這個國際流通的共同標準產生之後,越來越多資訊安全產品與系統的相關業者,逐漸認同此一國際趨勢,將產品與系統送交共同準則評估實驗室進行評估,希望能通過一定的安全等級評估而取得驗證。此舉除確保資訊安全產品的評估保證等級(EAL, Evaluation Assurance Level),並可增加其產品於消費者心目中之可信度,實為加強其產品競爭力的好方法。而藉此達成國際品牌之建立,對於產品出產國家形象的提升,更是有莫大的助益。

第32期《資安人》曾針對共同準則ISO/IEC 15408國際標準作一個簡單之介紹,本文不再贅述。本文主要提出看法及相關建議,以期驗證申請者、產品開發者與評估實驗室間對於共同準則安全評估在時間、人力投注及文件品質上能達成一定的共識,使評估過程能更加的順利。


文件流程機制
評估相關文件流程介紹

對於共同準則的評估員而言,無論是進行保護剖繪或是評估標的的共同準則安全評估,驗證申請者提供之評估文件與評估者產出之評估報告皆應循圖1所顯示之共同準則評估工作流程進行。

很明顯地,於評估工作進行開始時,業主與評估員皆需致力於探討供共同準則安全評估時所用的評估文件及其管理。而評估工作執行時,為求最後得到良好之評估結果,則需藉由評估員與業主間的觀察報告(OR, Observation Report)往返機制,讓該評估文件修訂成更加符合共同準則評估所需。下一小節將介紹觀察報告之往返機制。

觀察報告往返機制

評估員針對評估文件之內容詳加審視後所提供之觀察報告,應被業主與開發者視為需重視之修改建議;並藉由不斷溝通的機會,將評估文件修訂的更加完善。接下來,我們來討論此觀察報告往返機制。

當評估員收到一份來自於業主(或是開發者)所提供的評估文件時,觀察報告的往返提供了一個良好機制以利雙方溝通。評估員可於觀察報告中要求闡明文件中所述之所有事項。此外,並可由評估員角度提出其所發現的問題,以避免因誤解而造成負面之評估結論。當評估結果為「不通過(Fail)」時,評估員一定要提供相對應的觀察報告以反應此評估結論。否則,此觀察報告僅為評估員用來要求更詳盡證據資料的方式之一。

對於觀察報告的每一項目,評估員必須忠實表達下列要件:

? 受評估的保護剖繪或是評估標的之清楚識別名稱。

? 此份觀察報告是執行何項評估工作/子工作項目時產生。

? 審核時的觀察發現。

? 該發現結果之嚴重性,標示出將會導致的後果。例如:將導致「不通過(Fail)」的結論、延長評估所需的時程或是需要更詳細的解說才能有效判定等。

? 指定負責處理並回應的部門或角色。

? 建議回應的時程要求。

? 清楚說明若不解決此項目時將導致的後果。

觀察報告與其運行機制的對象取決於報告的內容與體制要求。體制可能會區分不同型態的觀察報告種類,或是根據所需資訊與讀取報告的對象而設定其他的報告型態。



評估文件
評估文件的內容與深度

共同準則對於送交驗證的產品或系統,針對七大類的保證類別(Assurance Class)進行評估,分別為組態管理(ACM, Configuration Management)、交付與運作(ADO, Delivery and Operation)、開發(ADV, Development)、指引文件(AGD, Guidance Documents)、生命週期支援(ALC, Life Cycle Support)、測試(ATE, Tests)與脆弱性評鑑(AVA, Vulnerability Assessment)。每個保證類別各自有其所屬之保證屬別(Assurance Family);而每個保證屬別依照其深度不同,會有1到5不等的保證組件(Assurance Component)。不同的評估保證等級(EAL),根據EAL1~EAL7,各有其所涵蓋的保證屬別及其不同深度的保證組件。保證組件與保證等級的關係如表1所示。

在整個評估過程中,業主必須負責提供所有評估文件以包含符合其宣稱之資訊安全等級之證據資料,製作成評估文件,送交評估實驗室。若所宣稱的評估保證等級中,某保證組件出現,表示評估員將針對該組件的要求進行評估工作。此時,就必須有該份評估文件做為評估的對象。以下試以防火牆與智慧卡之評估為例。

以防火牆之評估為例,若欲通過EAL3的共同準則評估,評估文件的要求如下:

? 對於「組態管理」,需提供ACM的評估文件以供ACM_CAP.3與ACM_SCP.1的評估。

? 對於「交付與運作」,需提供ADO的評估文件以供ADO_DEL.1與ADO_IGS.1的評估。

? 對於「開發」,需提供ADV的評估文件以供ADV_FSP.1、ADV_HLD.2與ADV_RCR.1的評估。

? 對於「指引文件」,需提供AGD的評估文件以供AGD_ADM.1與AGD_USR.1的評估。

? 對於「生命週期支援」,需提供ALC的評估文件以供ALC_DVS.1的評估。

? 對於「測試」,需提供ATE的評估文件以供ATE_COV.2、ATE_DPT.1、ATE_FUN.1與ATE_IND.2的評估。

? 對於「脆弱性評鑑」,需提供AVA的評估文件以供AVA_MSU.1、AVA_SOF.1與AVA_VLA.1的評估。

以智慧卡之評估為例,若欲通過EAL4的共同準則評估,相較於上述EAL3的評估,評估文件將有更高的要求,列述如下:

? 對於「組態管理」,所提供ACM評估文件需要增加供ACM_AUT.1的評估,並將ACM_CAP.3與ACM_SCP.1提高至ACM_CAP.4與ACM_SCP.2的評估。

? 對於「開發」,所提供ADV評估文件需要增加供ADV_IMP.1、ADV_LLD.1與ADV_SPM.1的評估,並將ADV_FSP.1提高至ADV_FSP.2的評估。

? 對於「生命週期支援」,所提供ALC評估文件需要增加供ALC_LCD.1與ALC_TAT.1的評估。

? 對於「脆弱性評鑑,所提供ADV評估文件需要將AVA_MSU.1與 AVA_VLA.1分別提高至AVA_MSU.2與 AVA_VLA.2的評估。

以上的例子可知,評估保證等級的高低,對於評估文件準備的範圍與深度皆有很大的影響。在此,本文不考慮各式各樣產品類別及不同評估等級所造成之差異,僅著重於各評估文件的共通部分。下期將繼續討論文件品質之重要性及其要求,並提出產品送檢之建言,供業主與開發者參考運用。