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

資訊技術安全評估共同準則（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 baseline protection。
評估目標中密碼學實現的細節不在CC的範圍內。不過像是FIPS 140-2等國際標準會列出密碼模組的規格，也有許多的標準要求加密使用的演算法。
最近保護輪廓（PP）中也會加入CC評估的加解密要求，一般會包括在FIPS 140-2評估內，透過對方案的特定解釋來加大CC的應用範圍。
有些國際評估方案已不考慮以EAL為基礎（EAL-based）的評估，只考慮已核可的保護輪廓，接受和這些保護輪廓嚴謹相容的評估。美國目前只接受以保護輪廓為基礎（PP-based）的評估，加拿大也開始要排除以EAL為基礎的評估。

**測試組織**
需符合ISO/IEC 17025，認證體也要是ISO/IEC 17065核可的組織。
的合規性一般是由國家級的認證單位來進行：- 加拿大的Standards Council of Canada（SCC）依實驗室認可計劃（PALCAN）會針對共同準則評估機構（Common Criteria Evaluation Facilities，CCEF）進行認證。- 法國的Comité français d'accréditation（COFRA）會針對共同準則的評估機構進行認證，評估機構一般會稱為Centre d'évaluation de la sécurité des technologies de l'information（CESTI）。評估是依Agence nationale de la sécurité des systèmes d'information（ANSSI）的規範及標準進行。- 義大利的IT安全認證機構（Organismo di Certificazione della Sicurezza Informatica，OCSI）會針對共同準則的評估機構進行認證。- 英國的United Kingdom Accreditation Service（UKAS）會認證商業評估機構(Commercial Evaluation Facilities，CLEF），英國自2019年起只是CC生態系中的消費者，不提供認證。- 美國的國家標準技術研究所（NIST）的National Voluntary Laboratory Accreditation Program（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- 可用性測試- 驗證及確認- Controlled Access Protection Profile（CAPP）

**參考資料**

**外部連結**
  The official website of the Common Criteria Project date=20060718074701 -  The Common Criteria standard documents date=20201128162438 -  List of Common Criteria evaluated products date=20210513154247 -  List of Licensed Common Criteria Laboratories date=20210417013448 -  Towards Agile Security Assurance-  Important Common Criteria Acronyms date=20120309225637 -  Common Criteria Users Forum date=20201113040140 -  Additional Common Criteria Information on Google Knol -  OpenCC Project – free Apache license CC docs, templates and tools date=20180821022903 -  Common Criteria Quick Reference Card date=20210131073004 -  Common Criteria process cheatsheet date=20210129222401