隨著計算機通信技術的飛速發展，由系統配置而導致的安全問題越來越多，安全內容自動化協議（SCAP）為系統配置的標準化以及對系統配置的脆弱性評估提供了一種統一的方法。越來越多的廠商、組織與社團已加入到SCAP的研究與發展中，也推動SCAP成為真正意義的全球標準。

2010年11月7日至16日，IETF79研討會在北京召開，全球范圍內數以千計的科研工作者參加了這次盛會，其中一個很重要的議題就是討論將安全內容自動化協議（SCAP： Security Content Automation Protocol）引入IETF標準化，使之成為真正意義上的全球標準。

1.SCAP的產生背景

由于計算機通信技術的飛速發展，美國聯邦政府強烈的意識到由于計算機系統配置問題而暴漏出越來越多的安全漏洞，為此，2007年美國聯邦預算管理辦公室（OMB：Office of Management and Budget）提出要求所有的政府部門開始試行聯邦桌面核心配置計劃（FDCC：Federal Desktop Core Configuration）。2008年則開始強制執行。FDCC最初是由美國國家標準與技術研究所聯合OMB、DHS（Department of Homeland Security）、NSA（National Security Agency）以及Microsoft共同開發，用于美國空軍Windows XP的公共安全配置，2008年6月發布第一個版本FDCC1.0，在本文發稿前最新的版本為2009年8月發布的1.2版本。

FDCC定義了針對Windows XP 與Vista操作系統的公共配置準則。為了檢測FDCC的合規性，NIST開發了安全內容自動化協議SCAP，以標準化的方式表達與使用安全數據，以及進行安全問題評估。最初主要針對于Windows操作系統開發檢查列表（checklist），后來逐步擴展到UNIX系統，web瀏覽器，反病毒軟件以及防火墻等。

SCAP提供了一種自動、標準化的方法來維護企業系統的安全，如實現安全配置基線，驗證當前的補丁程序，進行系統安全配置設置的持續性監測，檢查系統的折衷標記（sign of compromise），以及能在任意設定時刻給出系統的安全狀態。SCAP的提出主要源于如下幾個方面的原因：

◆大量的以及多樣的系統需要保護。

大多數組織有需要保護的一些系統，針對每個系統有眾多的應用需要保護。一般一個企業內部裝有多種操作系統及上千種的應用軟件，每個系統或應用都有自己的補丁機制及安全配置管理。相同的軟件在不同主機上的保護機制也可能會有些許的不同。一個單獨的主機針對它的操作系統與應用也會有上千種安全配置設置。所有這些因素使得決定每個系統上需要什么樣的安全變化，快速、正確、一致地實現這些變化，以及驗證安全配置更為復雜。

◆快速響應新的威脅。

一些組織經常需要重新配置軟件或安裝補丁以消除新發現地或成為攻擊者目標的脆弱性。在2009年，有多達5,700個軟件缺陷被加入到美國國家脆弱性數據庫（NVD：National Vulnerability Database）。

◆缺乏互操作性。

大多數系統安全工具采用私有格式、命名法、測量方法與內容，如補丁管理與脆弱性管理軟件。例如，如果脆弱性掃描器沒有采用標準化的弱點命名法，安全管理人員將不清楚多個掃描器的掃描結果報告是否指向相同的脆弱性。這種互操作性的缺乏將導致安全評估的不一致性，延遲制作決定以及做出及時的修正。

2.SCAP協議框架

SCAP包含兩個主要元素。首先，它是一個協議，一組標準化格式與術語的開放規范，通過它軟件安全產品可以互通軟件缺陷與安全配置信息，每一個規范也被稱作一個SCAP組件；其次，SCAP包括軟件缺陷與安全配置標準化的參考數據，也被稱作SCAP內容。

下表列出了目前的SCAP 1.0 協議組件，這些組件按類型分為：列舉（Enumerations）組，為安全與產品相關的信息定義了標準表述符與目錄；脆弱性測量與評分（Vulnerability Measurement and Scoring）組，用于測量脆弱性特征以及根據這些特征給予評分；表述與檢查語言（Expression and Checking Languages）組，運用XML Schema說明檢查列表，產生檢查列表報告，以及說明用于檢查列表的低級測試過程。#p#

Table 1 SCAP 1.0 協議組件

SCAP 組件	描述	維護組織
列舉
通用配置列舉（CCE：Common Configuration Enumeration）	定義了與安全相關的系統配置項的標準標識符與目錄	MITRE Corporation
通用平臺列舉（CPE：Common Platform Enumeration ）	定義了平臺及版本大多標準名稱與目錄	MITRE Corporation
通用脆弱性與漏洞列舉（CVE：Common Vulnerabilities and Exposures )	定義了與軟件缺陷相關的標準標識符與目錄	MITRE Corporation
脆弱性測量與評分
通用脆弱性評分系統（CVSS：Common Vulnerability Scoring System )	定義了脆弱性對系統影響的評分	Forum of Incident Response and Security Teams (FIRST)
表述與檢查語言
擴展配置檢查列表描述格式（XCCDF：Extensible Configuration Checklist Description Format )	定義了檢查列表與檢查報告的XML描述格式	National Security Agency (NSA) and NIST
開放脆弱性評估描述語言（OVAL：Open Vulnerability and Assessment Language )	定義了用于檢查列表的低級測試過程	MITRE Corporation

關于SCAP content，存在多個資源，例如，NVD擁有CPE與CVE標識項，MITRE公司擁有OVAL數據庫，并且維護CCE標識項的列表。每一個SCAP組件提供唯一的功能，可以被獨立地運用，但是聯合的運用能帶來更大的好處，例如，用XCCDF格式依據CPE表達CCE的能力形成了用于SCAP表達檢查列表的基本元素，換句話說，SCAP表達的檢查列表用一種標準化的語言（XCCDF）來表達所討論的平臺是什么（CPE），訪問什么安全設置（CCE）。運用SCAP表達檢查列表可以很容易的幫助組織實現對系統的安全控制，進行安全監測，自動化高級安全需求的合規性報告。

總之檢查列表用SCCDF來描述評估什么，用OVAL在目標系統做相應的測試，用CPE標識檢查列表是有效的以及運行測試的平臺，用CCE標識在檢查列表中被訪問或被評估的安全配置設置，用CVE參考已知的脆弱性，CVSS用于分級這些脆弱性。

2.1.XCCDF

XCCDF基本數據模型由以下四個主要的對象數據類型組成：

◆基準（Benchmark）。可以簡單理解為檢查列表，一個XCCDF只能擁有一個基準對象，它相當于一個容器，包含條目及其它的對象。

◆條目（Item）。條目是一個基準對象中的命名要素，每一條目有一個唯一的參考ID。條目包含以下三種類型：

a).組（Group）。這種類型條目可以包含其它條目，即一個組可以包含其它的組以及規則與值。一個組可以被選擇，也可以不被選擇。

b).規則（Rule）。這種類型條目定義具體的檢查規則，可以擁有檢查參考與評分權重。一個規則可以被選擇，也可以不配選擇。

c).值（Value）。這種類型條目是一命名的數據值，可以理解為允許用戶為每種規則預定義的可選值。

◆輪廓（Profile）。輪廓定義了對規則、組與值對象的共性收集。

◆測試結果（TestResult）。測試結果對象記錄單獨的設備或系統的合規性測試結果。#p#

下圖顯示了這幾種數據對象類型的關系。

XCCDF的目的是提供一種統一的方式描述安全檢查列表與檢查列表的評估結果。XCCDF文檔由一個或多個XCCDF規則組成。每一個XCCDF規則是系統中一個技術檢查點的高級定義。一個規則沒有直接說明怎樣做一個檢查，而是間接的通過OVAL的定義文件來說明相應的檢查方法。

2.2.OVAL

OVAL用于表達標準化的、機器可讀的規則，這些規則能用于評估系統的狀態。在SCAP框架下，OVAL通常用于決定存在的缺陷與不安全配置。一套用于檢查安全問題的指令(例如：一不正確的最小口令長度設置)被稱作一個OVAL定義（Definition），包含一個或多個OVAL定義的文件稱為一個OVAL定義文件。

有四種類型的OVAL定義：

◆脆弱性定義：定義了針對特定的脆弱性的出現，在計算機上必須存在的條件。

◆補丁定義：定義條件以決定是否一個特定的補丁適合一個系統。

◆詳細清單定義：定義條件以決定是否軟件的特定部分被安裝在系統上。

◆合規性定義：定義條件以決定是否計算機已符合特定的策略或配置描述。

OVAL語言借助XML語法描述，包含三種核心的Schema，即OVAL定義Schema，對以上四種類型的OVAL定義進行描述；OVAL系統特征Schema，根據系統的實際特征進行相應的編碼描述；OVAL結果Schema，是對分析結果的詳細編碼描述。#p#

下圖說明了怎樣運用OVAL三種核心Schema描述與分析一個實際系統脆弱性過程。

   

2.3.CPE，CVE與CCE

這部分描述來了SCAP1.0中的三個列舉規范：CPE 2.2，CCE 5與CVE。SCAP列舉基本上都包含一個ID，一個相關的描述或定義，與一個支持的參考列表。下面對每一個規范以及它們之間的相互依賴關系給予說明。

CPE 2.2是對操作系統、硬件與軟件的標準命名規范，它使得不同的組織可以共享相同的名字，以及針對特定平臺獲得相同的解決方案。一個單獨的CPE命名語法如下：

cpe:/{part}:{vendor}:{product}:{version}:{update}:{edition}:{language}

例如，"cpe:/o:redhat:enterprise_linux:2.1::es "是指RedHat企業服務器版2.1，"o"指示這個CPE描述一個操作系統，在這個例子中，"edition"域是空白，表示這個CPE應用于RedHat企業版服務器2.1的所有版本。CPE在SCAP中應用有以下幾種方式：

◆XCCDF： 在一個XCCDF檢查列表中，CPE名字能用于標識一個XCCDF對象（benchmark，profile，group或rule）應用的硬件或軟件平臺。

◆CCE：CCE通過關聯CPE用以說明配置缺陷發生的平臺。

◆CVE：CVE被關聯到CPE描述的一個或多個平臺。這種映射關系被保存在NVD中。#p#

CCE 5用于標準化安全配置問題與條目。每一種安全相關的配置問題被分配一個唯一的ID以便于快速、精確地發現多個信息源與工具之間配置數據的相互關系。MITRE公司維護與出版CCE列表，每個 CCE條目包括5種屬性：一個唯一的ID，一個配置問題的描述，CCE的邏輯參數，相關的技術機制，與附加信息源的參考。下面是一個用于Windows XP中CCE條目的例子。

CCE ID: CCE-3108-8

Definition: The correct service permissions for the Telnet service should be assigned.

Parameters: (1) set of accounts (2) list of permissions

Technical Mechanisms: (1) set via Security Templates (2) defined by Group Policy

References: Listed at http://cce.mitre.org/lists/cce_list.html

在一個XCCDF檢查列表中，CCE用于說明哪些安全配置設置應被檢查，OVAL運用CCE條目也是同樣的目的。

CVE用于標準化公共已知的軟件缺陷。這種通用的命名機制允許多個組織間共享數據，有效地集成服務于工具。例如，一個糾錯工具可以運用幾個掃描器與檢測傳感器的CVE信息來制定一種集成的風險消除解決方案。CVE的好處表現在：

◆公共已知軟件缺陷的全面的列表

◆一個全球唯一的名字來標識每一個脆弱性

◆討論脆弱性特性與風險的基礎

◆是用戶集成脆弱性信息到不同工具與服務的方式

每個CVE條目由一個唯一名字，一個簡短描述與參考組成。下面是一CVE條目的例子。

CVE ID: .CVE-2000-0001

Description: RealMedia server allows remote attackers to cause a denial of service via a long ramgen request.

References: BUGTRAQ: 19991222 RealMedia Server 5.0 Crasher (rmscrash.c)

BID: 888. URL:http://www.securityfocus.com/bid/888

2.4.CVSS

CVSS2.0提供了一種可重復的方法以評估和表達軟件缺陷的風險。運用這種共享的評分模型可以很容易的比較脆弱性的嚴重程度。CVSS提供了以下三種尺度用以權重脆弱性的評分：

◆基本因素，脆弱性的內在因素決定的基本分數。

◆時間因素，捕捉隨時間而改變的外部因素，考慮時間因素來調整基本分數。

◆環境因素，它標識了一個組織操作環境的上下文中這種脆弱性的嚴重程度。

CVSS可以幫助組織理解多種脆弱性的相對重要性，從而使他們能有效地評估、優化與消除脆弱性。因為每周會公開發布數百個脆弱性問題，因此找到一種容易的方法標識哪些脆弱性會對系統帶來重要的影響是非常重要的。NVD分析專家為所有的CVE條目計算與發布CVSS基本評分，但是每個組織將根據他們特定的時間因素與環境因素來裁剪基本評分以得到實際的脆弱性評分。#p#

3.標準的評估認證

NIST已經建立了SCAP產品認證體系與SCAP實驗室委任體系，這些體系一起確保SCAP產品的測試與驗證過程。SCAP測評實驗室需要經過美國國家實驗室自愿認可計劃（NVLAP）的授權。實驗室一經授權，實驗室就可以根據NISTIR （National Institute of Standards and Technology Interagency Report） 7511中的DTR (Derived Test Requirements)的描述進行SCAP產品測試。產品經測試后，測評實驗室將發布測試報告（包括特定產品的需求列表，被需要的開發商文檔，由實驗室做的詳細的測試總結）給SCAP產品認證體系，產品認證體系專家將審閱測試報告，然后發布產品認證。

一個產品可以被認證符合六個SCAP組件規范的一個或多個，或單獨的符合一個特定的SCAP能力。所謂SCAP能力不是指產品類型 ，而是產品運用SCAP的方式，如認證的脆弱性掃描器、認證的配置掃描器、入侵檢測與預防、漏洞修補、錯誤配置修補、設備管理、脆弱性數據庫等等。隨著SCAP被應用到更多類型的安全工具，SCAP能力列表將隨著時間而不斷發展。SCAP認證體系保證一個產品符合一套SCAP能力與/或一個或多個SCAP組件規范。

如果沒有重新認證的話，SCAP產品的認證有效期僅為一年，這保證SCAP產品始終與SCAP技術發展同步，持續的結合SCAP的參考數據為基礎，使用最新的與改進的方法對產品進行重新測試。

4.SCAP展望

截至此文章發稿前，已有30個廠商獲得了掃描與審計產品的SCAP認證，正式通過SCAP認證的廠商可以參考鏈接：http://nvd.nist.gov/scapproducts.cfm。我們不難發現越來越多的廠商，組織與社團加入到SCAP的研究與發展中，它已經成為業界事實上的標準，目前正式發布的版本為SCAP 1.0（包括XCCDF 1.1.4，OVAL 5.3與5.4，CPE 2.2，CCE 5，CVE與CVSS 2.0）,SCAP1.1目前處于修訂中，并且SCAP已經正式提交IETF討論組，相信不久的將來即會成為正式的全球標準。

參考文獻

[1] SCAP Homepage. http://scap.nist.gov

[2] The Extensible Configuration Checklist Description Format (XCCDF) Version 1.1.4. https://datatracker.ietf.org/doc/draft-waltermire-scap-xccdf/

[3] Naming Conventions for Vulnerabilities and Configurations. https://datatracker.ietf.org/doc/draft-landfield-scap-naming/

[4] Open Vulnerability and Assessment Language (OVAL). http://oval.mitre.org/

[5] Common Configuration Enumeration (CCE). http://cce.mitre.org/

[6] Common Platform Enumeration (CPE). http://cpe.mitre.org/

[7] Common Vulnerabilities and Exposures (CVE). http://cve.mitre.org/

[8] Common Vulnerability Scoring System (CVSS). http://www.first.org/cvss/

[9] National Voluntary Laboratory Accreditation Program (NVLAP). http://ts.nist.gov/standards/accreditation/index.cfm

[10] SCAP Validated Tools. http://nvd.nist.gov/scapproducts.cfm

[11] National Checklist Program. http://checklists.nist.gov

[12] National Vulnerability Database. http://nvd.nist.gov

作者介紹

張力（1973 -），男，西安電子科技大學碩士，高級咨詢顧問，主要從事FIPS 與CC方面的研究、咨詢與測評工作。

【本文為51CTO.com特稿、atsec和作者技術共享類文章，旨在共同探討信息安全業界的相關話題。轉載請注明出處以及atsec和作者名稱。】