1、1 印月968月 本標準非經本局同意得翻印 中華民國國家標準 CNS 總號 號 ICS 35.040 X605015099經濟部標準檢驗局印 公布日期 修訂公布日期 968月21日 月日 (共136頁)資訊技術系統安全工程能力成熟度模型 Information technology Systems security engineering Capability maturity model 目錄 節次 頁次 導論 2 1.適用範圍 5 2.引用標準 5 3.用語釋義 5 4.背景 . 9 4.1 發展之理由 9 4.2 安全工程之重要性 .10 4.3 共識 .10 5.本標準之結構 .11
2、6.本標準模型架構 .11 6.1 安全工程 11 6.2 安全工程過程概觀 .13 6.3 本標準模型架構描述 .17 6.4 彙總圖表 27 7.安全基礎實務 .27 7.1 PA01管理者安全控制措施 28 7.2 PA02評鑑衝擊 .32 7.3 PA03評鑑安全風險 35 7.4 PA04評鑑威脅 .39 7.5 PA05評鑑脆弱性 .42 7.6 PA06建立保證論述 45 7.7 PA07協調安全 .48 7.8 PA08監視安全態勢 50 7.9 PA09提供安全輸入 55 7.10 PA10規定安全需要 59 7.11 PA11查證與確認安全 .63 附錄 A (規定 )同屬
3、實務 66 A.1 一般 66 2 CNS 15099, X 6050 A.2 能力等級 1非正式履行 66 A.3 能力等級 2已規劃與追蹤 .67 A.4 能力等級 3已良好定義 72 A.5 能力等級 4已定量控制 76 A.6 能力等級 5持續改進 78 附錄 B(規定 ) 專案與組織基礎實務 81 B.1 一般 81 B.2 同屬安全考量 .81 B.3 PA12確保品質 81 B.4 PA13管理組態 86 B.5 PA14管理專案風險 89 B.6 PA15監視與控制技術工夫 .92 B.7 PA16規劃技術工夫 95 B.8 PA17定義組織系統工程過程 101 B.9 PA1
4、8改進組織系統工程過程 103 B.10 PA19管理生產線演進 106 B.11 PA20管理系統工程支援環境 108 B.12 PA21提供持續之技巧與知識 111 B.13 PA22與供應者協調 116 附錄 C(參考 )能力成熟度模型概念 120 C.1 一般 120 C.2 過程改進 .120 C.3 預期結果 .121 C.4 常見誤解 .121 C.5 重要概念 .122 參考書目 .126 英中名詞對照表 132 導論 許多不同種類組織於發展電腦程式時，無論是作業系統軟體、安全管理與施行功能、軟體或應用程式之中介軟體，會施行安全工程。因此，產品發展者、服務提供者、系統整合者、系
5、統管理者，甚至安全專家皆需要適當之方法與實務。某些組織會處理高階事宜 (例如：處理運作使用或系統架構事宜 )、其他組織則專注於低階事宜 (例如：機制的選取或設計 )，還有一些組織會同時處理此二類事宜。組織可能專長於某種特別型式之科技，或某專門環境 (例如：海上 )。 本標準 ( 即系統安全工程能力成熟度模型 (System Security Engineering Capability Maturity Model, SSE-CMM)係針對所有此等組織而設計。本標準 (模型 )之使用不宜暗示某項重點比另項重點好，或是必須使用某個重點。組織之營運重點不需因使用3 CNS 15099, X 605
6、0 本標準而偏離。 依組織之焦點，某些 (但非全部 )已定義之安全工程實務將適用。此 外，組織可能需審視模型中不 同實務間之相互關係，以決定其適用性 (applicability)。下列範例說明各種不同組織可將本標準應用於軟體、系統、設施發展及運作之方法。 安全服務提供者 為量測履行風險評鑑之組織的過程能力，可使用數群實務。在系統發展或整合期間，需要依據組織的能力來評鑑組織，以決定並分析其安全脆弱性，並且評鑑運作上的衝擊。就運作而言，需要評鑑組織關於監視系統安全態勢 (security posture)、識別與分析安全脆弱性，以及評鑑運作之衝擊等之能力。 對策發展者 對專注於發展對策 (cou
7、ntermeasure)之群組而言，組織之過程能力係以本標準實務之組合描述特性。本標準模型所包括之實務，是要闡明決定及分析安全脆弱性、評鑑運作之衝擊，並提供對其他所涉及之群組 (例如：軟體群組 )之輸入與指引。提供發展對策之服務的群組，需瞭解此等實務間之關係。 產品發展者 本標準包含專注於取得對客戶安全需要之瞭解的實務。必須要與客戶互動，才能確定顧客要求。就產品而言，若產品之推演發展獨立於特定客戶，則客戶被視為通稱(generic)。在此情形下，若有需要，可用產品行銷群組或另一群組當假想客戶。 安全工程從業者體認產品全景及用以完成產品發展之方法和產品本身一樣多樣化。然已知有些和產品與專案全景相
8、關事宜，會對產品之構思、生產、交付及維護的方法造成衝擊。下列事宜特別對本標準具重要性。 (1) 客戶群 (customer base)的型式 (產品、系統或服務 )。 (2) 保證要求 (高與低對比 )。 (3) 對發展與運作組織二者之支援。 以下討論本標準中兩個互異客戶群間之差異，保證要求程度之差異，以及每一種差異的衝擊。此等是以說 明組織或產業別 (industry segment)如何在其環境中，決定本標準之適當使用方式的範例呈現。 特定產業別 各產業皆有其本身特有之文化、術語及溝通風格。藉由將角色相依性與組織結構隱含性極小化，可預期所有產業別均可輕易將本標準模型概念，轉換成其自身之用語
9、與文化。 宜如何使用本標準模型，依下列之規定。 本標準模型及應用此模型之方法 (亦即，考評方法 (appraisal method)，意圖用為。 (1) 工程組織用以評估其安全工程實務並定義改善措施之工具。 4 CNS 15099, X 6050 (2) 安全工程評估組織 (例如：驗證者與評估者 )所使用之方法，可建立對組織能力的信心度，以作為系統或產品安全保證之一個輸入。 (3) 客戶用以評估提供者之安全工程能力之標準機制。 若模型與考評方法之使用者，徹底瞭解模型之適切應用法及其固有之限制，則可應用考評技術進行自我改善及選擇供應者。使用過程評鑑之額外資訊，可參照 ISO/IEC 15504-
10、4 資訊技術 過程評鑑 第 4 部：過程改善與過程能力判定之使用指引。 使用本標準之益處 安全趨勢已從保護機密政府資料 (classified government data)，轉移至更廣泛範圍的考量，包括金融交易、合約協議、個人資訊及網際網路。維護及保護資訊之產品、系統及服務之相對激增已浮現。此等安全產品與系統通常以下列兩條途徑之一進入市場透過冗長與昂貴的評估 (evaluation)，或未評估。在前者之情形下，受信賴產品通常是在其特性被需要許久後才上市，因此安全系統之部署已無法因應現行威脅。在後者之情形下，獲取者與使用者必須僅依賴產品、系統發展者或運作者所宣稱之安全。再者，安全工程服務傳統
11、上是在貨物既出概不退換 (caveat empto)之基礎上行銷。 此情況需要組織以更成熟之方式施行安全工程。具體地說，在安全系統與受信賴產品之生產與運作中，需具有下列品質。 (1) 持續性 (continuity)：於先前工夫中所獲取之知識，用於未來之工夫。 (2) 可重複性 (repeatability)：確保專案可以重複成功經驗之方法。 (3) 效率 (efficiency)：協助發展者與評估者更有效率地工作之方法。 (4) 保證 (assurance)：對安全需要已予因應之信心度。 為提供此等要求，需要指引組織瞭解並改善其安全工程實務的機制。為因應此等需要，本標準已發展出可以促進安全工
12、程實務之狀態，其目標是要改善安全系統、受信賴產品以及安全工程服務之品質與可用性，並且降低交付成本。特別是，可預期獲得下列好處。 對於工程組織而言 工程組織包括系統整合者、應用發展者、產品經銷者及服務提供者。對於此等組織本模型的益處包括 (1) 以可重複的、可預期的過程與實務減少重做工作而節約。 (2) 有履行之真實能力的信譽，尤其是在來源選擇 (source selection)。 (3) 聚焦於已量測之組織勝任能力 (成熟度 )與改善措施。 對於獲取組織而言 獲取者包括從外部 /內部來源來獲取系統、產品 及服務的組織，也包括終端使用者。獲取者包括從外部 /內部來源獲取系統、產品及服務之組織，
13、也包括終端使用者。對此等組織而言，本標準之益處包括 (1) 可重複使用之標準建議書徵求文件 (Request for Proposal, RFP)用語與評估方法。 (2) 降低挑選到不合格投標者的風險 (效能、成本及排程 )。 5 CNS 15099, X 6050 (3) 因採基於產業標準之一致之評鑑，較不會招致抗議。 (4) 在產品或服務中，有可預期、可重複之信心度等級。 1. 適用範圍 本標準規定系統安全工程 (Systems Security Engineering, SSE)之能力成熟度模型(Capability Maturity Model, CMM)。本標準係一過 程參考模型 (
14、process reference model)，其聚焦於在資訊技術安全 (Information Technology Security, ITS)領域系統或相關系統系列中實作安全之要求。在 ITS 領域內，本標準模型聚焦於用以達成 ITS之過程，最具體來說，即該等過程之成熟度。本標準模型並未試圖規定組織必須使用某特定過程，更遑論特定方法論。此模型之用意反而是希望採用本模型之組織，宜繼續使用其本身既有且遵循任何其他 ITS 指引文件之過程。 備考：本標準模型係 SSE-CMM，修改自 SE-CMM及 CMM。 本標準包括如下。 (1) 安全產品或受信賴系統 (trusted system)之
15、系統安全工程活動 (activity)，此等活動涵蓋整個完整之生命週期，包括概念 定義、要求分析、設計、發展、整合、安裝、運作、維護及除役 (de-commissioning)。 (2) 對產品發展者、安全系統發展者與整 合者、以及提供電腦安全服務與電腦安全工程之組織的要求。 (3) 適用於所有不同型式及規模之安全工程組織，範圍從商業界到政府以及學術界。 雖然本標準之模型是改進並評鑑安全工程能力之獨特模型，但並不意謂著安全工程可以脫離其它之工程專業領域而單獨實施。相反地，本標準之模型提倡整合，此種整合採取安全為遍及跨越所有工程專業領域 (例如：系統、軟體及硬體 )之觀點，並定義此模型之諸組件以
16、因應此等考量。共同功能 (common feature)： “協調安全實務 ”體認需將安全與專案 (或組織內 )之所有涉及之專業領域以及群組相 整合。相似地，過程領域 (process area)： “協調安全 (coordinate security)”定義用於協調安全工程活動之各項目標與機制。 本標準與 CNS 14785 有關，尤其是第 2 部，因為兩者皆是關於改善過程與評鑑能力成熟度。然 CNS 14785 特別著重於軟體過程，而本標準著重於安全。 2. 引用標準 CNS 14785-2 資訊技術軟體過程評鑑第 2 部：過程與過程能力參考模型 CNS 14785-4 資訊技術軟體過程評
17、鑑第 4 部：履行評鑑指導 CNS 14785-9 資訊技術軟體過程評鑑第 9 部：詞彙 CNS 14837 資訊技術軟體生命週期過程 CNS 14929-1 資訊技術資訊技術安全管理指導綱要第 1 部：資訊技術安全概念與模型 CNS 15008 系統工程系統生命週期過程 CNS 17799 資訊技術資訊安全管理之作業規範 6 CNS 15099, X 6050 3. 用語釋義 本標準適用下列用語釋義。 3.1 可歸責性 (accountability) 此性質為確保個體之動作 (action)可唯一地追溯到該個體 (entity)。參照 CNS 13204-2 3.2 認證 (accredi
18、tation) 於本標準之全文中：由受指定核准 之機構所發出，正式宣布一系統使用一組已規定之保護措施，於特定安全模式下運作。 備考： 安全社群內通常接受此定義；在 ISO 內較常使用之定義是：主管機構對某人或某機構 給予認可，證明其有能力執行某特定工作之程序。 CNS 13606 3.3 評鑑 (assessment) 使用相對應之評鑑方法查證產品、系統或 服務是否符合標準，以建立遵循性(compliance)並決定保證 (assurance)。 ISO/IEC TR 15443-1 3.4 資產 (asset) 任何對組織有價值之物。 CNS 14929-1 3.5 保證 (assuranc
19、e) 本標準之全文中：可交付物符合其安全目的之信心基礎 (grounds for confidence)。 CNS 15408-1 備考： 安全社群內通常接受此定義；在 ISO 內較常使用之定義是：提供信心度之聲明的活動，其提供產品、過程或服務達到所規定之要求的信心度。CNS 13204-2 3.6 保證論述 (assurance argument) 一組用證據及推理所支持之結構化保證宣稱，明確解說已如何滿足保證之需要。 3.7 保證宣稱 (assurance claim) 系統滿足安全需要之斷言 (assertion)或支持之斷言 (supporting assertion)。宣稱可以同時因
20、應直接威脅 (例如：系統資料可免受外部人員之攻擊 )與間接威脅 (例如：系統程式碼具最少缺陷 )。 3.8 保證證據 (assurance evidence) 可據以作保證宣稱之判定或結論之 資料。證據可由觀察、測試結果、分析結果以及考評 (appraisal)所組成。 3.9 鑑別性 (authenticity) 此性質為確保物件或資源之識別如 所聲稱者。鑑別性適用於個體，諸如：使用者、過程、系統及資訊。 CNS 14929-1 3.10 可用性 (availability) 根據經授權個體之要求，可存取或可使用之性質。 CNS 13204-2. 3.11 基準 (baseline) 已正式
21、審查並達成協議之規格或產品，其後作為進一步發展之基礎，而且唯有7 CNS 15099, X 6050 透過正式之變更控制程序才可變更。 IEEE-STD-610 3.12 驗證 (certification) 本標準之全文中，驗證是針對系統之安全功能與其他保護措施，履行整體性評估後，產生書面結果之過程，其目的是要確立系統之設計與實作滿足一組已規定之安全需求。 備考： 安全社群內通常接受此定義；在 ISO 內較常使用之定義是：對某一項產品、過程或服務能符合規定要求，由第三方出具書 面保證之程序。CNS 13606 3.13 機密性 (confidentiality) 此性質為未經授權之個人、個體
22、或過程，無法取得或揭露資訊。 CNS 13204-2 3.14 一致性 (consistency) 文件或系統或組件之各部份間之劃一性 (uniformity)、標準及不矛盾之程度。IEEE-STD-610 3.15 正確性 (correctness) 針對所規定之安全需求，產品或系統之表現顯示要求之實作為正確。 3.16 客戶 (customer) 供應者所提供之產品的接收者。 備考 1. 在有合約情況中，客戶稱為購買者 (purchaser)。 2. 舉例而言，客戶可能是最終消費者、使用者、受益者或購買者。 3. 客戶可能在組織外部，或在組織內部。 ISO 8402 CNS 14785 3
23、.17 有效性 (effectiveness) 系統或產品之一項性質，代表在其所提議使用或實際運作使用之全景中，其提供之安全性的優良程度。 3.18 工程群組 (engineering group) 負責與特定工程專業領域 (例如：硬體、軟體、軟體組態管理、軟體品質保證、系統、系統測試、系統安全 )相關之專案或組織活動之一群人 (同時包括管理者和技術人員 )。 3.19 證據 (evidence) 過程及 /或產品之直接可量測的特性，用以表示特定活動滿足所規定要求之客觀及可展示的證明 (demonstrable proof)。 3.20 完整性 (integrity) 完整性是定義為保全資訊及
24、處理 方法之準確度 (accuracy) 與完全性(completeness)。 3.21 維護 (maintenance) 系統或組件交付後，用以修改系統或組件之過程，以校正缺陷、改進效能或其它屬性，或是調適系統或組件以適應已變更之環境。 IEEE-STD-610 3.22 方法論 (methodology) 標準、程序及支援方法之組合，定義發展產品或系統之完整作法。 8 CNS 15099, X 6050 3.23 滲透 (penetration)剖繪 欲實行滲透所需之各項活動的定義。 3.24 程序 (procedure) 履行給定任務之動作方針的書面描述。 IEEE-STD-610 3
25、.25 過程 (process) 一組彼此相關之活動，將輸入轉換成輸出。 CNS 15008 3.26 可靠度 (reliability) 一致的行為與結果之性質。 CNS 14929-1 3.27 殘餘風險 (residual risk) 於實作保護措施之後剩餘之風險 CNS 14929-1。 3.28 風險 (risk) 已知威脅利用單一或一群資產之脆弱性 造成資產損失或損壞的潛在可能性。CNS 14929-1 3.29 風險分析 識別安全風險、決定風險大小、以及識別需要保護措施之區域 的過程。 CNS 14929-1 3.30 風險管理 評鑑與量化風險，並建立組織可接受風險等級之過程。
26、CNS 14929-1 3.31 安全政策 (security policy) 本標準之全文中：指在組織 與其系統中，治理如何管理、保護與分配資產 (包括敏感資訊 )之各項規則、 指令及實務，特別是該等會對系統與相關元件造成衝擊者。 3.32 安全相關要求 (security related requirement) 對系統之安全運作有直接影響或強制符合所規定安全政策之要求。 3.33 系統 分離、可區別之個體，此個體具有實體存在和明確目的，並且完全由整合且互動之組件所組成 ，而其中之每個組件無法單獨達成所需之整體目的。 CNS 15008 備考 1. 在實務上，系統是以觀者之角度而言，其意義
27、常以複合名詞 (associative noun)闡明之，例如：產品系統、飛機系統 。亦可以相關之上下文相依同義字 (context dependent synonym)代替 “系統 ”一詞，例如：產品、飛機，然此種表示法可能會模糊系統原理觀點。 2. 系統在其生命週期中，可能需藉由其他系統滿足其要求。例如：運作系統可能需供構思、發展、生產、運作、支援或汰除之系統。 3.34 威脅 (threat) 可能對資訊、程式或系統造成損害，或導致其危害到他者，之敵對者的能力、意圖和攻擊方法，或是來自外部或內部之任何環境或事件。 3.35 威脅者 (threat agent) 刻意或意外之人為威脅的發起
28、者與 /或起始者。 9 CNS 15099, X 6050 3.36 確認 (validation) 藉由檢查與提供 客觀證據，確認是否滿足特定預期使用之特別要求。 CNS 15008 3.37 查證 (verification) 藉由檢查及提供客觀之證據，以確認是否滿足所規定之要求。 CNS 15008 3.38 脆弱性 (vulnerability) 包含會受到威脅利用之單一或一群資產弱點。 CNS 14929-1 3.39 工作產出 (work product) 與過程之執行相關之加工產出品。 CNS 14785-9 備考： 過程可以使用、產生或變更工作產出。 4. 背景 系統安全工程能
29、力成熟度模型 (SSE-CMM)(即本標準模型 )描述組織之安全工程過程中所不可或缺之特性，其必須存在以確保良好之安全工程。本模型並未預設特定之過程或順序，而是採用產業之常見實務 (practice)。此模型係安全工程實務之標準量度 (metric)，涵蓋如下。 (1) 整個生命週期，包括發展、運作、維護以及除役等之各項活動。 (2) 整個組織，包括管理、組織及工程等活動。 (3) 與其他專業領域間同時互動，例如： 系統、軟體、硬體、人因及測試工程，以及系統管理、運作和維護。 (4) 與其他組織之互動，包括獲取、系統管理、驗證、認證及評估。 本標準模型之描述 (model descriptio
30、n)提供本模型所依據之原理與架構的整體描述、模型執行概觀、對模型之適當使用建議、模型內包含之實務、以及模型屬性之描述。其亦 包括用以發展此模型之要求。本標準之考評方法 (appraisal method)係對照本標準描述評估組織之安全工程能力的過程和工具。 4.1 發展之理由 客戶與供應者兩者皆會關切改進安 全產品、系統以及服務之發展。安全工程領域具有許多普遍已接受之原理，但 是目前卻缺乏評估安全工程實務之綜合性框架 (comprehensive framework)。本模型藉由識別此種框架，提供量測 (measure)與改進安全工程原理之應用效能方法。 必須強調安全工程是獨特之專業領 域，需
31、要獨特知識、技巧及過程，才能針對安全工程發展出傑出的能力成熟度 模型。此與先前在系統工程範圍中已建置的安全工程並不衝突。事實上，有良 好定義且可接受之系統工程活動，將能有效地在所有範圍中實作安全工程。 現代統計過程控制建議，透過加強 生產產品之過程品質，以及加強該等過程本身之組織實務成熟度，可以較具成 本效益地產出品質較高之產品。若投入更多所需成本與時間於安全系統與受信 賴產品之發展，則保證過程會更有效率。安全系統之運作與維護有賴人員與科 技間聯繫之過程。藉由加強所使用過程之品10 CNS 15099, X 6050 質，以及加強過程本身組織實務之 成熟度，可以更具成本效益地管理此等相互依賴關
32、係。 本標準模型專案 (SSE-CMMProject)之目標是 要提升安全工程，使其成為已定義的、成熟的及可量測的專業領域 。發展本模型與各種考評方法使下列事項成為可能。 (1) 由工程群組將投資集中在安全工程的工具、訓練、過程定義、管理實 務及改進。 (2) 以能力為基礎之保證，亦即一種值得信賴性 (trustworthiness)，其為基於對工程群組之安全實務和過程成熟度之信心度。 (3) 依投標者之能力等級與相關風險規劃，區分出投標者差異，以選擇適當合格之安全工程提供者。 4.2 安全工程之重要性 隨著社會對資訊依賴的增加，保護 資訊變得愈來愈重要。許多產品、系統及服務皆需要去維護並保護
33、資訊。安全工程之 重點已從主要在保護機密政府資料(classified government data)，擴展到更廣泛的應用，包括金融交易、 合約協議、個人資訊及網際網路，此等趨勢皆顯示安全工程之重要性。 4.3 共識 (consensus) 本模型是由 50 個以上組織所發展出來者，其中有許多皆是跨國公司。此專案有許多來自不同國家的代表，特別是澳大利亞、加拿大、歐洲及美國。 除此之外，本模型持續地透過不同之場合尋找 參與者，包括在會議中進行報告並設置攤位以及透過公開網站 (www.sse-cmm.org)。 此等參與者組成指導委員會 (steering group)以及一些工作組 (work
34、ing group)。大部分之發展工作皆由工作組履行， 而指導委員會則是負責整個專案之進度和專案可交付事項之核准 (approval)。 本標準模型係透過共識過程所發展 出來之模型。所有會員組織可以推派代表參加工作組會議，並且採取多數決方 式。停會期間所有貢獻或建議皆會利用電子方式傳送給工作組之所有成員。基 本上每個月皆會舉行會議，將所得到之建議進行討論、修訂及協商。工作組之 會議紀錄要詳細記錄每次會議的任何投票結果，並且保管此等紀錄。 本模型之每個版本，必須先通過工 作組核准，並由工作組負責發展，其次要通過指導委員會之審查與核准。指導委員會核准版本之後，交給一群由 ITS 社群選出之 “關鍵
35、審查者 ”(key reviewer)進行審查與評論。然後，對外發表每個版本，以徵求大眾之審查與反應。大體上 ，根據關鍵審查者與社群之反應，指導委員將會決定出本模型之最終公告版本。 本模型必須先經過工作組層級之核准，其次要經過指導委員會 (steering group)層級之核准，接著要取得關鍵審查者層級之認同，最終要經過社群 (community)層級之同意。因此，基本上要經過四個層級之核准。 由於此模型之應用會對不同的應用領域造成衝 擊，所以在先導考評 (pilot appraisal)期間已先達成額外的核准與共識。共同準則專案 (Common Criteria 11 CNS 15099,
36、 X 6050 Project) 之替代方 案保證工作組 (Alternative Assurance Working Group, AAWG)，已審查本模型，評估 其作為產生保證替代方案之適用性，並提供 IT系統安全社群之共識回饋給專案。 此模型每個主要版本，皆是透過一 組未參與模型發展之獨立審查者審查，審查者的意見被統合、審查及合併在模 型內。最後，每一版本的文件應經公開審查(CDR 與二個公開研討會 ) ，接受評論，並因應之。 5. 本標準之結構 第 4 節討論：本標準之背景及其發展緣由。第 6 節闡明本標準模型架構，以及系統安全工程角色。第 7 節詳細描述系統安全工程之過程領域與基礎實
37、務 (base practice)。附錄 A 描述能力成熟度等級，以及同屬實務 (generic practice)。附錄 B 描述專案與組織過程領域以及基礎實務。附錄 C 描述能力成熟度模型的概念。CNS14785-4 亦適用於本模型之使用。 6. 本標準模型架構 本標準模型：係已知最佳 安全工程實務之彙編 (compilation)。為了要瞭解此模型，需具有一些安全工程背景。本節提供安全工程之高階描述，之後再描述此模型架構如何反映此基本認知。 6.1 安全工程 (Security Engineering) 6.1.1 何謂安全工程 ? 促使網路、電腦、應用程式甚至是企業朝向遍及之互連性 (
38、interconnectivity)和互運性 (interoperability)其驅動力係對系統和產品之安全建立更重要角色，需針對所有系統和產品之安 全，建立更重要角色。安全焦點已從保全政府機密資料，擴展到更廣泛的 應用，包括金融交易、合約協議、個人資訊及網際網路。因此，任何應用皆必須考慮並決 定潛在之安全需要，例如：機密性、完整性、可用性、可歸責性、私密性 (privacy)及保證。 安全事宜之焦點轉移提高了安全 工程之重要性。安全工程會變成一個愈來愈具關鍵性之專業領域 (discipline)，而且宜為跨多重專業領域、併行、工程團隊中之重要組件。此適用於系統與應用 軟體之發展、整合、運作
39、、管理、維護以及演進，並適用於產品之 發展、交付以及演進。企業與營運過程之定義、管理以及再造工程 (re-engineering)皆必須因應諸安全考量。於是，安全工程就能在系統中、產品中，或者是當作服務交付。 6.1.2 安全工程之描述 安全工程是演進之專業領域。就 其本身而論，目前尚不存在精準且為社群共識之定義。然部分共識是可能的。安全工程之幾點目標如下。 (1) 瞭解與企業相關之安全風險。 (2) 根據已識別之風險，建立一組相對應之安全需要。 (3) 將安全需要轉換成安全指導綱要，使其可整合於專案所使用之其他專業領域活動，並轉換成系統組態或運作之描述。 12 CNS 15099, X 60
40、50 (4) 於安全機制之正確性與有效性上，建立信心度或保證。 (5) 決定於可忍受之系統或系統運 作之殘餘安全脆弱性 (可接受之風險 )下，之運作衝擊 (operational impact)。 (6) 將所有工程專業領域與專長之工夫，整合成系統之值得信賴性的整體瞭解。 6.1.3 安全工程組織 許多不同型式組織均會執行安全工程活動，例如： (1) 發展者 (developer)。 (2) 產品經銷者 (product vendor)。 (3) 整合者 (integrator)。 (4) 獲取者 (acquirer)(獲取組織 (acquisition organization)或終端使用者
41、 (end user)。 (5) 安全評估組織 ( 系統驗證者 (system certifier)、產品評估者 (product evaluator)或運作認證者 (operation accreditor)。 (6) 系統管理者 (system administrator)。 (7) 受信賴第三方 (驗證機構 (certification authority)。 (8) 顧問 /服務組織。 6.1.4 安全工程生命週期 所有生命週期階段期間皆會實施安全工程活動，此等階段包括如下。 (1) 概念階段 (concept stage)。 (2) 發展階段 (development stage)。
42、 (3) 生產階段 (production stage)。 (4) 使用階段 (utilization stage)。 (5) 支援階段 (support stage)。 (6) 汰除階段 (retirement stage)。 6.1.5 安全工程與其他專業領域 安全工程活動會與許多其他專業領域有介面，此等專業領域包括如下。 (1) 企業工程。 (2) 系統工程。 (3) 軟體工程。 (4) 人因工程。 (5) 通訊工程。 (6) 硬體工程。 (7) 測試工程。 (8) 系統管理。 備考 1. CNS 15008 標準對系統工程有更進一步資訊，該標準是以系統觀點看待安全。 2. CNS 14
43、837 標準對軟體工程有更進一步資訊，該標準是以軟體觀點看待安全。 13 CNS 15099, X 6050 安全工程活動必須與許多外部個 體協調，因為建立殘餘運作衝擊之保證與可接受性，與發展者、整合者、 獲取者、使用者、獨立評估者及其他組有關。相當多之組織皆需要此等介 面和必要之互動，因此使安全工程比其他工程專業領域特別複雜且不同。 6.1.6 安全工程專業 雖然安全工程和資訊技術安全， 係目前安全和營運環境之重要驅動專業領域，然亦不宜忽略其他更傳統之 安全專業領域，例如：實體安全和人員安全。若上述專業領域及許多其他 次專業領域之工作效能達到最好之效率與效益，則安全工程將需引用之。 下列提供
44、一些可能需要之次安全專業領域的例子，以及簡短描述。次安全專業領域例子包括如下。 (1) 運作安全 (operations security)，以運作環境之安全與維持安全運作態勢(posture)為標的。 (2) 資訊安全 (information security)，於資訊調處 (manipulation)與處理期間有關資訊與其安全之維護。 (3) 網路安全 (network security)，涉及網路硬體、軟體及協定 (包括在網路上通訊之資訊 )之保護。 (4) 實體安全 (physical security)，著重在建築物與實體位置的保護。 (5) 人員安全 (personnel sec
45、urity)，關聯於人員、其值得信賴性及其對安全考量之認知 (awareness)。 (6) 行政管理安全 (administrative security)，關聯於安全之行政管理層面以及行政管理系統之安全。 (7) 通訊安全 (communications security)，關聯於不同安全領域間資訊之通訊安全，特別要保護該等透過傳輸媒介傳送之資訊。 (8) 發射安全 (emanation security)，處理所有能傳送資 訊至安全區域外之機器所產生之非預期信號。 (9) 電腦安全 (computer security)，特別是處理所有型式之安全計算裝置。 6.2 安全工程過程概觀 本標
46、準將安全工程分成三個基本領域 ：風險、工程及保證，參照圖 1。雖然此等領域絕非彼此獨立，然卻可分別 討論各領域。在最簡單層級中，風險過程識別及優先排序產品或系統本身存在 的危險。安全工程過程與其它工程專業領域一起運作，以針對危險所呈現的問 題，決定並實作解決方案。最後，保證過程會對此等安全解決方案建立信心度，並將其傳達給客戶。 14 CNS 15099, X 6050 圖 1 安全工程過程具有三個主要領域 保證引產品、系統或服務工程過程保證過程 風險過程風險資訊同時，此三個領域可一起運作，以確保安全工程過程之結果能達成前述目標。 6.2.1 風險 安全工程主要目標之一是降低風險。風險評鑑是識別
47、尚 未發生之問題過程。風險之評鑑是經由檢查發生 威脅與脆弱性之可能性，並經由探討意外事故可能造成之潛在衝擊，參照圖 2 。與可能性相關的是不確定性(uncertainty)因子，此因子會隨 著特定情況而有所不同。換言之，只能在特定的限制下預測可能性。此外， 評鑑特定風險所造成之衝擊也和不確定性有關，例如：非所欲事故可能不 會以所預期之情況發生。由於各項因子存在大量不確定性，而不能準確預 測，所以安全之規劃與衡量很難。有個具成本效益，可用以解決部分問題 之方法，即實作用以偵測發生非所欲事故之技術。 非所欲事故是由三個組件所組成 ：威脅、脆弱性及衝擊。脆弱性是可能被威脅所利用之資產性質並包含弱 點
48、。若威脅與脆弱性二者之一未出現，則不會發生非所欲事故，因而不會 有風險。風險管理是評鑑並量化風險之過程，而且此過程會為組織建立可 接受之風險等級。管理風險是安全管理之重要部分。 15 CNS 15099, X 6050 圖 2 涉及威脅、脆弱性及衝擊之安全風險過程PA02:評鑑衝擊PA03:評鑑安全風險PA04:評鑑威脅威脅資訊脆弱性資訊衝擊資訊PA05:評鑑脆弱性風險資訊風險經實作保護措施減輕，因保 護措施可因應威脅、脆弱性、衝擊或是風險本身。然完全減輕所有風險， 或是完全減輕任何特定風險是不可行的。此大部分是歸因於減輕風險的成 本與相關的不確定性。因此總要接受某些殘餘風險。若出現高度不確定
49、性 ，則風險接受度會因其不準確本質，而變得非常難決定。風險承受者能控 制的少數領域之一，為系統所伴隨的不確定性。本標準模型之過程領域包括該等確保提供者組織分析威脅、 脆弱性、衝擊及相關風險之活動者。 6.2.2 工程 安全工程就像其他工程專業領域一樣，為 一個從概念、設計、實作、測試、部署 (deployment)、運作、維護到除役之過程。在此整個過程中，安全工程皆必須與其他系統工程團隊密切 合作。本標準模型強調安全工程師乃是大團隊之一部分，並需要與其他專 業領域工程師協調其活動。此有助於確保安全是較大過程中不可或缺之一部分，而非獨立之個別活動。 安全工程師使用來自上述風險過程之資訊，以及關於系 統要求的其他資訊、有關法律以及政策，與客戶一起工作，以識別安全需要，參照圖 3。一旦識別出需要，安全工程師識別並追蹤特定之要求。 找出安全問題之解決方案的過程 ，通常涉及識別可能的替代方案，然後評估此等替代方案，以決定最佳者 。將此活動與其餘的工程過程整合之困難是不能僅就安全考量即決定
