資訊技術安全評估共同準則

**資訊技術安全評估共同準則**（Common Criteria for Information Technology Security Evaluation），簡稱**共同準則**（Common Criteria）或 **CC**，是針對電腦安全認證的國際標準（ISO/IEC 15408）。目前的版本是 3.1 版，第 5 次修訂。

共同準則是資訊安全性的架構，電腦系統的使用者可以在安全標的（Security Target，ST）檔案當中，標示安全機能需求（Security Functional Requirements，SFR）及安全保障需求（Security Assurance Requirement，SAR），也可以從系統的保護剖繪（Protection Profile，PP）中取得這些資料。供應商可以實現或是聲明其產品的安全屬性，測試實驗室可以評估這些產品，確認其是否符合聲明的屬性。換句話說，共同準則提供了保證，電腦安全產品的規格、實現以及評估可以用一個嚴謹、標準化且可重覆的方式進行，而且可以與目標使用環境相稱。共同準則會維護一份已認證產品的清單，其中包括作業系統、存取控制系統、資料庫及密鑰管理系統。

## 相關概念

共同準則評估是實施在電腦安全產品上的，以下是一些相關的概念：

* **評估標的**（Target of Evaluation，TOE）：是指要評估的系統或是產品，評估可以驗證標的效能相關的聲明。為了要符合實務情形，評估需要確認標的的安全特性：可以用以下方式來進行：
  * **保護剖繪**（Protection Profile，PP）：識別某一類安全裝置（例如用來進行數位簽章的智慧卡，或是網路防火牆）安全需求的檔案，多半是使用者或使用者群體所產出，而且其安全裝置是和使用者的特定用途有關。產品的供應商可以讓其產品滿足一個或是多個保護剖繪，並且讓其產品在這些保護剖繪下進行評估。這種情形下，保護剖繪可以是產品安全標的（ST）模版，或是安全標的作者至少會確保，所有相關保護剖繪的需求都會在產品的安全標的檔案中。尋求這類特定產品的顧客可以將重心放在符合其需求的保護剖繪，再找有相關認證的產品。
  * **安全標的**（Security Target，ST）：識別要評估的產品或系統安全性質的檔案。安全標的中可能會聲明此產品符合一個或是多個保護剖繪（PP）。評估標的會針對安全標上所列的安全機能需求（SFR）來評估，不多不少。因此供應商可以調整其評估方式，精準的符合產品預期要有的效能。像網路防火牆不需要符合資料庫管理系統的所有安全需求，不同的防火牆也可能是用完全不同的需求清單來進行評估。一般來說會將安全標的對外發行，因此潛在客戶才可以依評估認證的安全特性來尋找產品。
  * **安全機能需求**（Security Functional Requirements，SFR）：說明產品的安全機能。共同準則會列出這些機能的標準目錄。例如：安全機能需求可能會說明針對以角色為基礎的存取控制的使用者，需以什麼方式進行身分驗證。安全機能需求的列表可能會依不同評估而不同，就算是二個相同種類的產品也可能會有不同的列表。雖然共同準則沒有規定在安全標的中一定要有安全機能需求，不過會列出各個機能（例如依角色限制存取能力的機能）若要正常運作，會和哪些其他機能（例如識別不同角色的能力）有相依性。

評估過程也會透過品質保證的流程，設法建立有關產品安全特性的可信度資訊：

* **安全保障需求**（Security Assurance Requirement，SAR）：敘述在產品開發及評估過程中，為了確認符合安全性功能所進行的措施。例如評估會要求所有的程式原始碼都要放在變更管理系統中，或是要進行全功能測試。共同準則也會提供相關措施的目錄，需求可能會隨評估而不同。特定的產品的需求會列在其保護剖繪（PP）及安全標的（ST）檔案中。
* **評估保障等級**（Evaluation Assurance Level，EAL）：以數值方式來針對評估的深度以及嚴謹性進行評比。每一個 EAL 會對應一包的安全保障需求（SAR），這些安全保障需求包括了產品完全開發的過程，有一定的嚴謹性。共同準則中列有七個等級，其中的 EAL 1 是最基礎的（不論實施或是評估都最便值，EAL 7 最嚴格（也最貴）。一般而言，不會針對個別的保護剖繪（PP）或安全標的（ST）去指定評估保障等級，會針對一整包的保護剖繪及安全標的來定義，也有可能針對一些領域再擴充更高等級的安全需求。高評估保障等級不一定表示「安全性較高」，只表示的評估標的（TOE）所聲明的安全保障已用更深入的方式進行驗證及確認。

目前，大部份的保護剖繪，大部份評估的安全標的及認證的產品都是 IT 產品（例如防火牆、作業系統、智慧卡等）。
有時在 IT 流程中會列出共同準則認證。其他標準也可能會包括，例如互操作性、系統管理、使用者訓練、供應商的 CC 評估以及其他產品標準。例子包括有 ISO/IEC 27002 及德國的 IT 基準保護。

評估標的中密碼學實現的細節不在 CC 的範圍內。不過像是 FIPS 140-2 等國際標準會列出密碼模組的規格，也有許多的標準要求加密使用的演算法。

最近保護剖繪（PP）中也會加入 CC 評估的加解密要求，一般會包括在 FIPS 140-2 評估內，透過對方案的特定解釋來加大 CC 的應用範圍。

有些國際評估方案已不考慮以 EAL 為基礎（EAL-based）的評估，只考慮已核可的保護剖繪，接受和這些保護剖繪嚴謹相容的評估。美國目前只接受以保護剖繪為基礎（PP-based）的評估，加拿大也開始要排除以 EAL 為基礎的評估。

## 測試組織

測試實驗室需符合 ISO/IEC 17025，認證體也要是 ISO/IEC 17065 核可的組織。

ISO/IEC 17025 的合規性一般是由國家級的認證單位來進行：

* 加拿大的加拿大標準委員會（SCC）依實驗室認可計劃（PALCAN）會針對共同準則評估機構（Common Criteria Evaluation Facilities，CCEF）進行認證。
* 法國的法國認證委員會（COFRA）會針對共同準則的評估機構進行認證，評估機構一般會稱為資訊技術安全評估中心（CESTI）。評估是依國家資訊系統安全域（ANSSI）的規範及標準進行。
* 義大利的 IT 安全認證機構（Organismo di Certificazione della Sicurezza Informatica，OCSI）會針對共同準則的評估機構進行認證。
* 英國的英國認證服務（UKAS）會認證商業評估機構 (Commercial Evaluation Facilities，CLEF），英國自 2019 年起只是 CC 生態系中的消費者，不提供認證。
* 美國的國家標準技術研究所（NIST）的國家自願實驗室認可計劃（NVLAP）會認證通用準則測試實驗室（Common Criteria Testing Laboratories，CCTL）
* 德國的國家級認證單位是聯邦資訊安全辦公室（BSI）
* 西班牙的國家密碼學中心（CCN）會認證西班牙架構下的通用準則測試實驗室。
* 荷蘭的 IT 安全領域的認證計劃（Netherlands scheme for Certification in the Area of IT Security，NSCIB）會認證 IT 安全評估機構（IT Security Evaluation Facilities，ITSEF）。
* 瑞典的 IT 安全認證機構（Swedish Certification Body for IT Security，CSEC）會認證 IT 安全評估機構（IT Security Evaluation Facilities，ITSEF）。

這些組織的特性會在 ICCC 10 中進行檢驗及說明。

## 相互認可協定

除了資訊技術安全評估共同準則以外，也有子條約等級的共同準則相互認可協定（MRA，Mutual Recognition Arrangement），其中的各國家認可其他國家所進行的共同準則評估。相互認可協定最早是由加拿大、法國、德國、英國、美國、澳洲及紐西蘭在 1998 年簽署，之後芬蘭、希臘、以色列、義大利、荷蘭、挪威和西班牙在 2000 年加入。協定後來更名為「通用標準識別協定」（Common Criteria Recognition Arrangement，CCRA），成員也繼續擴充中。CCRA 相互認可的評估最多只到 EAL 2（包括缺陷修復的增強版本）。在以前 ITSEC 範圍內的歐盟國家也認可更高等級的 EAL。EAL5 或更高等級的評估一般會涉及目的國家的安全要求。

## 問題

### 需求

資訊技術安全評估共同準則是通用性的準則，沒有特定產品（產品類別）安全機能需求的列表，這是依 ITSEC 的作法，但以往有其他規範性更強的標準，例如 TCSEC 或 FIPS 140-2。

### 認證的價值

資訊技術安全評估共同準則本身無法保證安全性，只能確認待評估產品聲稱的安全屬性已經過獨立驗證。經過此方式評估的產品有明確的驗證，在規格、實現、評估的各過程都有嚴謹且標準化的做法。

許多的微軟視窗系統（包括 Windows Server 2003 及 Windows XP）都已通過認證，但微軟仍然會針對安全漏洞發行安全補丁。其可能原因是因為取得此認證的過程允許供應商限制安全機能分析時的分析範圍，並且針對產品的應用環境以及威脅強度進行假設。而且，為了成本效益以及有用的安全認證，此認證認為有必要限制評估範圍，因此受驗證產品是以依保證程度或保護剖繪的指定的細節來進行測試。因此，評估活動不論其深度、使用時間、資源都有一定限度，在預期的環境下可以提供合理的保證。

受驗證的微軟 Windows 作業系統在沒有安裝安全漏洞補丁的情形下，評估保障等級可以到 EAL4+。這可以看出評估組態的限制以及強度。

### 批評

2007 年 8 月時，Government Computing News（GCN）中的專欄作家 William Jackson 針對共同準則的方法論以及美國的通用標準評估與驗證計劃（Common Criteria Evaluation and Validation Scheme，CCEVS）進行了嚴格的檢驗。同時也存取了安全產業的的主管，研究者，以及美國國家資訊保障合作組織（National Information Assurance Partnership，NIAP）的代表。文章中提出來，反對共同準則的意見如下：

* 評估很花錢（會耗費數十萬美元），而供應商投資所得到的不一定是更安全的產品。
* 評估主要是確認評估檔案，不是針對實際的安全性、技術正確性或產品的優點。只有 EAL5 或更高等級的評估才會有美國國家安全局的專家參與評估，只有 EAL7 及以上的評估才會進行完全程式碼的分析。
* 要準備評估證據以及評估相關檔案花的心力以及時間都非常的煩瑣，因此當評估完成時，評估的產品往往已經過氣，沒有競爭力了。
* 產業界的意見，包括像是通用標準供應商（Common Criteria Vendor's Forum）等組織的意見，在整個過程中沒有什麼影響力。

## 相關條目

* Bell–LaPadula 模型
* 中國強制性產品認證
* 評估保障等級
* FIPS 140-2
* 資訊保障
* ISO 9241
* ISO/IEC 27001
* 可用性測試
* 驗證及確認
* 可控式存取保護設定檔（CAPP）

## 參考資料

## 外部連結

* The official website of the Common Criteria Project （頁面存檔備份，存於網際網路檔案館）
* The Common Criteria standard documents （頁面存檔備份，存於網際網路檔案館）
* List of Common Criteria evaluated products （頁面存檔備份，存於網際網路檔案館）
* List of Licensed Common Criteria Laboratories （頁面存檔備份，存於網際網路檔案館）
* Towards Agile Security Assurance
* Important Common Criteria Acronyms （頁面存檔備份，存於網際網路檔案館）
* Common Criteria Users Forum （頁面存檔備份，存於網際網路檔案館）
* Additional Common Criteria Information on Google Knol
* OpenCC Project – free Apache license CC docs, templates and tools （頁面存檔備份，存於網際網路檔案館）
* Common Criteria Quick Reference Card （頁面存檔備份，存於網際網路檔案館）
* Common Criteria process cheatsheet （頁面存檔備份，存於網際網路檔案館）