1、1 印行年月94年10月 本標準非經本局同意不得翻印 中華民國國家標準 CNS 總號 類號 ICS 35.080 X300814802經濟部標準檢驗局印行 公布日期 修訂公布日期 93年1月9日 年月日 (共12頁)資訊技術-系統與軟體完整性層級 Information technology System and software integrity levels 1. 適用範圍：本標準介紹軟體完整性層級以及軟體完整性需求的觀念。它定義完整性層級的概念、定義決定完整性層級的程序以及軟體完整性需求，並將需求放在每個程序上。本標準不規定特定的完整性層級或者軟體完整性需求。它們必須由以企劃為基礎的企
2、劃或特定的部門和/或國家所制定。本標準只適用於軟體。本標準只需要有系統完整性層級和非軟體組件的完整性層級，就能決定軟體組件的完整性層級。 本標準旨在提供軟體產品或包含軟體之系統的發展者、使用者、採購者和評鑑者，為了這些產品和系統的管理與技術支援而使用。 軟體完整性層級是表示將系統風險維持在可容忍限度內所需要的軟體特性範圍值。對於履行緩和功能的軟體而言，特性是指軟體必須履行緩和功能的可靠度。對於失效時能威脅到系統的軟體而言，特性是指失效的頻率及或然率之限度。 軟體完整性需求包括符合軟體工程程序中用來開發軟體的需求、符合軟體技術產品的需求以及/或在時間上必須滿足軟體的效能需求，以便提供與軟體完整性
3、層級相稱之軟體的信賴度。 本標準不規定跟系統工程生命週期過程整合之完整性層級的判定方式。 2. 規範性參考資料：以下的標準包含經過參考本文由本標準的規定所構成的規定。在發表時，所指出的版本是有效力的。所有的標準都可能修訂，而且，鼓勵團體對於以本標準為基礎的協議進行審查，應用在以下所述最新版標準的可能性。IEC和ISO的會員保持目前合法國際標準的登記。 CNS 9359：1993，資訊處理詞彙（第1部：基本用語） CNS_（ISO/IEC 2382-20）：1995，資訊處理詞彙（第20部：系統發展） CNS 12889：1994，品質管理與品質保證詞彙 CNS_IEC 50-191：1990，
4、國際電子技術字彙，第191章：依賴度和服務品質 CNS_IEC 300-3-9：1995，依賴度管理第3部：應用指導第9部：技術系統的風險分析 CNS_（ISO/IEC 12207）：1995，資訊技術軟體生命週期過程 3. 用語釋義：除了用以下的定義修改或補充以外，CNS 9359、CNS_（ISO/IEC 2382-20）、CNS 12889和CNS_（IEC50-191）提供的定義，均適用於本標準。 3.1 組件（Component）：在系統特別的分析層級考量範圍內，具有不連續結構的個體，諸如：組合體或軟體模組。 3.2 信賴度（Degree of confidence）：本標準的信賴度
5、用語專指軟體符合其需求的 2 CNS 14802, X 3008 3.3 設計當局（ Design authority）：負責產生系統設計的人員或組織。 3.4 失效（ Failure）：履行必要功能之能力的終止或者，在先前已規定的限度內履行之失能。 3.5 故障隔絕（ Fault isolation）：子系統為避免來自於其他子系統的故障而造成故障之能力。 3.6 功能（ Function）：系統之預定行為的樣子。 3.7 啟動事件（ Initiating event）：能夠導致威脅的事件。 3.8 完整性保證當局（ Integrity assurance authority）：評鑑是否符合完
6、整性需求的獨立人員或組織。 3.9 完整性層級（ Integrity level）：表示將系統風險維持在可容忍限度內所需要項目特性的範圍值。對於履行緩和功能的項目而言，特性是指項目必須履行緩和功能的可靠度。對於失效能導致威脅的項目而言，特性受限於該失效的頻率。 3.10 項目（ Item）：能夠個別考量的個體諸如：零件、組件、子系統、 設備或系統，項目可能由硬體、軟體或者兩者所組成。 3.11 緩和功能（ Mitigating function）：如果能成功地使用此功能，就能防止啟動事件變成特定威脅，則稱此功能為緩和功能。 3.12 風險（ Risk）：可能發生已知威脅以及該 威脅發生之潛在的
7、不利影響之作用。 3.13 風險維度（ Risk dimension）：從所做的系統風險 (例如安全、經濟、保全 )評鑑所得到的全貌。 3.14 安全（ Safety）：預期系統在既定條件下不會導致危及人類生命、健康、財產或環境的狀態。 3.15 保全（ Security）：保護系統項目免於發生意外或者惡意的存取、使用、修改、破壞或揭露。 3.16 軟體完整性層級（ Software integrity level）：軟體項目的完整性層級。 3.17 子系統（ Subsystem）：子系統是較大系統內之一部分的任一系統。 3.18 系統（ System）：由一個以上之過程、硬體、軟體、設施與人
8、員所構成，能提供滿足所述需求的或目的之能力的綜合體。 3.19 系統化失效（ Systematic failure）：以必然方式關連到只能利用修改設計、製造程序、操作程序、文書或其他相關因素來排除之某種原因的失效。 3.20 系統完整性層級（ System integrity level）：系統的完整性層級。 3.21 威脅（ Threat）：能夠導致一個以上已知風險維度之不利影響的系統環境或系統環境之狀態。 4. 符號和縮寫 本標準並未使用符號，若適當時，在內文中第一次出現縮寫的地方會顯示全部的文字。 5. 軟體完整性層級的框架 5.1 如何使用本標準 獨立完整性保證當局的概念是適當使用本標
9、準的基礎。完整性保證當局是負責 3 CNS 14802, X 3008 驗證符合完整性需求的人員或組織。在設計當局和完整性保證當局磋商期間所做的決定載明於文件。待磋商的決定包括決定相關風險維度、要使用的特定完整性層級、指定每個層級的特定準則、設計的特定架構性特點可容許利益的程度以及造成指定之特定完整性層級的影響之軟體需求。 雖然描述於本標準的程序之呈現不同於整體系統工程程序，不過本標準並未意圖妨礙與系統工程程序之整合。不管如何實作程序，都要符合本標準範圍內所有需求。 第 5.2 節提供決定完整性層級和軟體完整性需求程序的概觀。第 6、 7 和 8 節更詳細地描述此程序，並定義課以這些程序的需求
10、。 5.2 概觀 圖 1 所示為決定系統與軟體完整性層級以及軟體完整性需求所要求的程序之概觀。針對三個主要程序：完整性層級之判定、軟體完整性層級之判定和軟體完整性需求之判定中的每一個程序，表 1 列出輸入和輸出。 在本標準內使用以風險為基礎之完整性層級判定方式，因此，首先決定對應之系統完整性層級之第一步涉及風險分析的履行。 IEC 標準 300 3 9“技術系統的風險分析 ”提供履行風險分析的指引。必須要獲取關於系統、該系統環境以及與系統有關的風險維度之足夠資訊，以便履行風險分析。風險分析宜涵蓋所有的相關風險維度，諸如：設計當局和完整性保證當局所同意的安全、經濟和保全。 必須評估風險分析所識別
11、的任何風險以決定此風險是否可容忍。一旦系統設計已經分析並評估到具有可容忍的風險，則指定一系統完整性層級給系統，系統完整性層級反映伴隨系統的風險的最壞情況。 在系統範圍內的軟體完整性層級剛開始與系統完整性層級的指定相同。此處，可能分析系統設計，以決定證實把比系統的完整性層級還低的完整性層級指定給軟體的系統設計，是否有架構上的特點。 4 CNS 14802, X 3008 圖 1 軟體完整性層級的判定程序與應用之概觀 風險控制 (伴隨軟體) 新的威脅 軟體完整性需求風險排除/降低的可能性 風險的可容忍度系統定義 風險維度 風險排除/降低的可能性 系統設計 風險 風險威脅 啟動事件 整個系統工程 系
12、統工程 硬體工程 軟體工程 威脅識別 頻率分析 影響分析 風險預測 風險分析 風險的可容忍度之決定 系統完整性層級的判定 軟體完整性層級的判定 軟體完整性需求的判定 風險評估 5 CNS 14802, X 3008 表 1 輸入和輸出 程序 輸入 輸出 系統完整性層級的判定 相關的風險維度 系統定義 環境定義 系統架構 風險 威脅 威脅發生之可容忍頻率 /或然率 啟動事件 啟動事件頻率 /或然率 系統完整性層級 軟體完整性層級的判定 系統完整性層級 子系統 /軟體架構 威脅列表以及每一威脅： 威脅發生的可容忍頻率或或然率 可能導致威脅的啟動事件 發生每個啟動事件的預期頻率或或然率 子系統 /軟
13、體完整性層級 相信降低完整性層級的架構特點 軟體完整性需求的判定 子系統 /軟體完整性層級 軟體完整性需求 系統是指一個以上的組件所組成之整合性組合 (Composite)。組件可能只是軟體、只是硬體或者可能是由更多拆解組件所組成的子系統。開始時，系統的完整性層級指定系統的任何軟體組件。軟體完整性層級的判定涉及系統架構分析以決定子系統的完整性層級能否比系統完整性層級還降低。此程序能夠遞迴地應用直到已經判定只含軟體之子系統的完整性層級，或者直到設計當局和完整性保證當局為了指定子系統的任何軟體組件，而可接受包括軟體之子系統的完整性層級。 在架構的分析期間可能識別在先前風險分析期間沒有判定的新威脅和
14、風險。這將會在考量新的風險資訊下要求重作風險分析。 軟體完整性層級是表示緩和功能提供的 可靠程度或者必須要限制可能造成威脅的失效頻率。嚴格來說，軟體失效是系統化失效，所以軟體完整性層級是可靠地提供緩和功能或造成威脅之失效不會發生的信賴度指標。 軟體完整性層級的判定和應用是整個風險管理程序的一部分。系統或軟體產品的整個生命期間都要進行風險管理，並且，當判定各種層級的設計細節或設計開發可能疊代地 (Iteratively)做已決定的。圖 1 顯示整個系統工程程序與風險分析、風險評估和風險控制的風險管理程序之間的關係。 6 CNS 14802, X 3008 如果將系統設計修改以併入風險排除 /降低
15、的可能性、如果當指定系統和軟體完整性層級時識別新的威脅或者如果系統設計不會造成可容忍的風險，則疊代能發生。 相對於軟體組件，軟體完整性層級是用來判定將如何控制風險，其係藉用識別軟體和軟體工程程序之什麼需求為真，以便得到相對於系統風險的同等角色之軟體信賴層級。這些需求歸諸於軟體完整性需求。 6. 系統完整性層級的判定 系統完整性層級對應於伴隨系統之可容忍的風險層級。因為系統的失效可能導致威脅或者因為影響可能導致威脅的系統環境啟動事件的功能 (包含緩和功能 )，所以系統會伴隨著風險。若要判定系統完整性層級，必須執行下列步驟： a. 風險分析判定伴隨系統的風險層級。風險分析是使用可用資訊以識別威脅並
16、估計(Estimation)伴隨威脅之風險的程序。 b. 風險評估 (Evaluation)是判斷風險可容 忍度的程序。風險分析和風險評估的結果能夠導致系統設計變更以消除或降低風險，其會要求重覆進行風險分析和評估程序。 c. 一旦系統設計已經確定可容忍風險，就要做系統完整性層級的指定。從所做的選擇以及區別層級之間的標準所得到完整性層 級的真正數值應該由設計當局和完整性保證當局商議。 6.1 風險分析 風險分析應該要被履行以回答三個基本問題： 何者可能出毛病 (由威脅識別回答 )？ 多常會發生此事 (由頻率分析回答 )？ 影響是什麼 (由影響分析回答 )？ 利用這些分析的結果，能夠計算風險。每個
17、已識別風險的風險分析的結果包括： a. 以適當項目之風險的表達。 b. 伴隨風險的威脅。 c. 伴隨每個威脅的啟動事件。 d. 假定之啟動事件的發生頻率。 風險評估程序使用導源於風險分析的風險表達，來判定風險是否可容忍。系統和軟體完整性層級判定程序使用來自於風險分析的所有結果，以判定系統中所需要之軟體組件的完整性層級。 IEC300-3-9“技術系統的風險分析 ” 是風險分析適當的指導。如同使用在IEC300-3-9 的安全特定用語中的“危險 (Hazard)”和“損害 (Harm)”用語分別解譯為“威脅 (Threat)”和“不利的影響 (Adverse effect)”。 風險分析可能涵蓋
18、多風險維度諸如：安全、經濟和保全。要涵蓋的特定風險維度應該由設計當局和完整性保證當局判定。 6.1.1 威脅識別 伴隨系統的威脅宜與可能導致 威脅的啟動事件一起識別。如果系統失效能 7 CNS 14802, X 3008 夠導致威脅、如果特定的系統 操作能夠導致威脅或者如果在能導致威脅的環境下系統履行相對於啟動事 件的緩和功能，則威脅伴隨系統。要識別不是先前認知的威脅，宜使用適用特 定情況的方法並將之載明於文件 (參照IEC300-3-9)。在威脅識別期間，應該要考量系統架構 (若為可用 )以確保能夠針對系統內所使用的技術考量其失效模式。 6.1.2 頻率分析 頻率分析用來估計由威脅識別 所決
19、定的每個啟動事件的可能性。當系統失效是一個啟動事件時，頻率分 析並不估計失效發生的可能性，而是代之以決定用跟可容忍風險標的一致且實務上可達成之失效頻率的限制。 應該使用相關的歷史資料估計、使用諸如故 障樹或事件樹分析合成 (參照IEC300-3-9)或使用專家的判斷估計事件頻率。 在系統整合判定程序期間所完 成的頻率分析應該對待系統如同黑箱一般，並且，不應該考量系統的架構 ，在軟體完整性層級判定程序期間將考量系統的架構。由頻率分析決定的 事件頻率可用定量或定性表示頻率程度的用語表達諸如：經常、可能、偶而、極少、不像會發生或很難相信會發生。 頻率分析應該考量某些啟動事 件結合其他事件或者做為一序
20、列事件的一部分將只會造成威脅。 6.1.3 影響分析 一旦發生啟動事件，影響分析 用來估計威脅的嚴重性。宜識別可能緩和啟動事件影響的任何措施 (Measure)。每個威脅應該伴隨一組描述各種影響嚴重性的種類 (例如：災難、重大、嚴重或輕微 )中的一個影響種類。 6.1.4 風險計算 使用關於啟動事件影響嚴重性 與啟動事件發生頻率的風險矩陣計算伴隨每個威脅的風險。風險矩陣指定風險類別給頻率和嚴重性的每一組合，例如：高度風險、中度風險、低度風險、微度風險。表 2 顯示 IEC300-3-9 的風險矩陣範例。 表 2 範例：風險矩陣 發生的頻率表示的頻率(每年 ) 影響的嚴重性 災難 重大 嚴重 輕
21、微 經常 1 高度 高度 高度 中度 可能 1-10 1高度 高度 中度 低度 偶而 10 1-10 2高度 高度 低度 低度 極少 10 2-10 4高度 高度 低度 低度 不像會發生 10 4-10 6高度 中度 低度 微度 很難相信會發生 10 6中度 中度 微度 微度 8 CNS 14802, X 3008 設計當局和完整性保證當局應 該認可用來計算風險的任何風險矩陣。若要認可風險矩陣必須要認可啟動 事件的頻率的適當範圍、影響的種類和它們的定義以及伴隨每對頻率範圍和影響種類的風險類別。 6.2 風險評估。 設計當局和完整性保證當局應該要針對 風險分析程序所計算之風險的可容忍度做判斷。部
22、分的判斷可能會與部門管理機構制定的管理限制衝突。 6.3 系統完整性層級的指定。 系統完整性層級剛開始會把最高度風險類別指定給任何伴隨系統的威脅。完整性層級的數量會與已確認的風險類別數量一致。表 3 顯示風險類別標示系統完整性層級的範例。 表 3 風險類別標示系統完整性層級 風險類別 系統完整性層級 高度 A 中度 B 低度 C 微度 D 本標準不規定完整性層級的數量或使用的符號。 7. 軟體完整性層級的判定。 軟體完整性層級表示將系統完整性層級配置到包含軟體組件或只是 由組成軟體的子系統。子系統的軟體完整性層級剛開始應該與系統完整性層級相同。 此情況會持續維持，除非經由考量下列三點以降低軟體
23、完整性層級： a. 緩和子系統失效的影響否則會造成系統威脅發生的系統架構特點。 b. 提供過多的緩和功能，以致於能夠不管在配置緩和功能的子系統範 圍內是單一或多重失效，都會緩和啟動事件之架構特點。 c. 是否子系統扮演相對於識別啟動事件或緩和功能的任何角色。 7.1 軟體完整性層級判定的假設。 a 系統都存在系統完整性層級之指定。 b. 應該要足夠詳細的定義系統架構特點，才可以識別子系統角色和它們的介面。 c. 輸入包括： 系統完整性層級。 威脅清單以及每個威脅的以下資料： 可能導致威脅的啟動事件。 啟動事件發生的預期頻率或或然率 足夠詳細的系統架構定義以決定每個子系統的角色和識別架 構的任何
24、 9 CNS 14802, X 3008 緩和特點。 d. 輸出為軟體完整性層級。 7.2 軟體完整性層級的降低。 若要決定軟體完整性層級的降低，則應該履行以下的步驟： a. 識別一起組成這個完全系統的子系統。 b. 決定是否任何子系統的失效將造成威脅，不論與其他的子系統狀態隔絕或組合。如果造成威脅的子系統失效是隔絕的，則子系統的完整性層級會指定成跟系統相同的完整性層級。如果只有跟其他子系統狀態組合的子系統失效才會造成威脅，則子系統的完整性層級可能會依照第 7.3 節定義的評鑑結果調降。第 7.3 節的評鑑並非必備，只有想要較低的子系統完整性層級時，方宜履行第 7.3 節的評鑑。 c. 決定是
25、否任何子系統的失效將造成緩和功能無法交付，不論與其他的子系統狀態隔絕或組合。如果造成緩和功能無法交付的子系統失效是隔絕的，則子系統的完整性層級會指定成跟系統相同的完整性層級。如果只有跟其他子系統狀態組合的子系統失效才會造成緩和功能無法交付，則子系統的完整性層級可能會依照第 7.3 節定義的評鑑結果調降。第 7.3 節的評鑑並非必備，只有想要較低的子系統完整性層級時，才要完成第 7.3 節的評鑑。 d. 決定是否有軟體組件的子系統失效不會導致威脅以及它的功能沒有伴隨任何系統事件的緩和。任何此類軟體應該要指定最低的完整性層級。為了確保軟體失效不會導致威脅必須要隔絕故障。設計當局和完整性保證當局必須
26、同意適當的架構特點以確保適當的故障隔絕。如果故障隔絕由失效處理機制完成，則應該把跟系統完整性層級相同的軟體完整性層級指定給這個機制。 由架構特點提供從指定的系統完整性層級降低軟體完整性層級的利益程度，應該由完整性保證當局和設計當局定義並同意之。 遞迴地應用步驟 a 到 d 描述的程序，直到已經決定所有只由軟體組成的子系統的完整性層級，或者直到設計當局和完整性保證當局為了指定這些子系統的任何軟體組件而接受所有包含軟體的子系統的完整性層級為止。 7.3 降低失效會造成威脅之軟體的軟體完整性層級。 對於失效會造成威脅的系統，系統完整性層級部分以系統失效頻率的限制為基礎，系統失效頻率跟可容忍風險的標的
27、是一致的。如果只有跟其他子系統狀態組合的軟體，在特殊狀態下失效才會造成威脅時，則軟體失效頻率指定的嚴格限制可能會比系統使用的嚴格限制還要低。頻率分析可用來決定跟可容忍風險的標的是一致的系統失效頻率的最低嚴格限制，並會評估子系統之間的依存關係。能夠使用較高的軟體失效頻率限制的判定，重覆風險預測以決定風險類別和如此較低的軟體完整性層級是否有任何變更。 能夠使用失效處理機制偵測軟體失效並做防止它們變成啟動事件的動作。在失效發生且失效處理機制是無效的情況下，軟體失效只能變成啟動事件。失效處理機制的範例是： 10 CNS 14802, X 3008 資料完整性檢查 (軟體機制 ) 硬體看守定時器 (硬體
28、機制 ) 手動恢復 (人為機制 ) 假如避免在冗餘子系統之間共同模式失效，則能夠使用冗餘以預防導致威脅的失效要。如果軟體組件之間使用冗餘，則必須使用如軟體差異的策略以避免共同模式失效。當軟體差異是用在軟體失效頻率限制的嚴格性較低時，設計當局和完整性保證當局應該同意由軟體差異 提供的利益程度以及構成足夠差異的定義。 7.4 降低失效會造成緩和功能供應不足的軟體的軟體完整性層級。 如果只有跟其他子系統狀態組合的子系統失效才會造成緩和 功能無法交付時，則軟體的可靠度會低於系統對緩和功能要求的可靠度。如同第 7.3 節，使用在頻率分析的技術能夠用來決定從系 統要求的可靠度降低軟體可靠度的程度。 8.
29、軟體完整性需求的判定 8.1 信賴度 軟體完整性層級是指定緩和功能需要提供的可靠度，或者可能造成威脅的失效頻率要求的限制。因為嚴格來說，軟體失效是系統功能的失效，軟體完整性層級表示相信提供可靠緩和功能或不會發生造成威脅的失效的需求程度。這個需求由軟體和其生命週期過程來滿足。如果滿足，會依據軟體完整性需求，提供的必要的信賴度。 在軟體中得到信賴的一些策略有： a. 應用導致錯誤最小化的技術。 b. 應用錯誤偵測最詳盡的查證 (Verification)和確認 (Validation)技術。 c. 透過運作歷史展示軟體可靠地提供 緩和功能或失效頻率不會超過已定義的上限。 8.2 達到軟體信賴度的方
30、法 表 4 提供一些軟體工程活動、活動輸出的屬性以及用來完成要達到屬性的各種信賴度方法的綱要範例。本標準並未意圖要規定採用特殊的軟體生命週期，其他在 ISO/IEC12207 中所描述的生命週期程序一樣可以應用。 如果軟體已經存在且操作一段時間，也許可以由軟體操作的歷史評鑑來達到對軟體的信賴。操作歷史所提供的信賴度 ，將相依於各項因素諸如軟體的複雜性、操作歷史的成功以及操作的用法對軟體在系統範圍內預定用法的相似性。 8.3 軟體信賴度與完整性層級的伴隨 本標準並不規定要滿足特定需求，以達到適合已知軟體完整性層級的信賴度。 設計當局和完整性保證當局應該同意要滿足的需求，以達到每個完整性層級之軟體
31、所需要的信賴度。 11 CNS 14802, X 3008 表 4 範例：程序活動、屬性以及信賴度 活動 屬性達到每個完整性層級軟體信賴度的方法軟體需求分析 精確性、完全性、正確性、抽象化、一致性、查證性 1. 結構化方法 2. 前項加上半正規的記法 3. 第 1 項加上正規的記法4. 第 3 項加上正規的證明軟體設計 對需求分析之可追踪性、查證性、模組化及抽象化 1. 結構化方法 2. 前項加上半正規的記法 3. 第 1 項加上正規的記法4. 第 3 項加上正規的證明軟體編碼 對設計之可追踪性 明確的程式結構 程式語言的標準化及 可維護性 1. 結構化程式規劃 2. 前項加上強化型式的語言
32、3. 第 2 項加上對“語言 ”之“安全子集 ”的限制 4. 第 3 項加上正規的證明引用標準： CNS 9359 資訊處理詞彙（第 1 部：基本用語） CNS 12889： 1994, 品質管理與品質保證詞彙 ISO/IEC 2382 1： 1993, Information technology Vocabulary Part 1： Fundamental terms. ISO/IEC 2382 20： 1995, Information technology Vocabulary Part 20： System development. ISO/IEC 12207： 1995, Info
33、rmation technology Software life cycle processes. IEC 50 191： 1990, International Electrotechnical Vocabulary, Chapter 191： Dependability and quality of service. IEC 300 3 9： 1995, Dependability management Part 3： Application guide Section 9： Risk analysis of technological systems. 相對應國 際標準： ISO/IEC
34、 15026： 1998, Information technology System and software integrity levels. 12 CNS 14802, X 3008 英中名詞對照表 C Component 組件 Composite 組合 Consequence 影響 D Degree of confidence 信賴度 Dependability 依賴度 Design authority 設計當局 F Failure 失效 Fault 故障 Fault isolation 故障隔絕 Function 功能 I Initiating event 啟動事件 Integrity assurance authority 完整性保證當局 Integrity level 完整性層級 Item 項目 M Mitigating function 緩和功能 R Reliability 可靠度 Risk 風險 Risk dimension 風險維度 S Safety 安全 Security 保全 Software integrity level 軟體完整性層級 Subsystem 子系統 System 系統 Systematic failure 系統化失效 System integrity level 系統完整性層級 T Threat 威脅
