• 沒有找到結果。

資安產品共通準則與安全目標之探討

N/A
N/A
Protected

Academic year: 2021

Share "資安產品共通準則與安全目標之探討"

Copied!
18
0
0

加載中.... (立即查看全文)

全文

(1)

資安產品共通準則與安全目標之探討

資安產品共通準則與安全目標之探討

資安產品共通準則與安全目標之探討

資安產品共通準則與安全目標之探討

林奕廷,劉川綱,趙志宏,李忠憲 中華民國九十三年八月二十日

前言

前言

前言

前言:

::

:

資通安全日益重要,各種安全評估方式推陳出新,但是由於各家資訊產品 各自推出自身的評估方式之際,隨著資訊產品的廣泛流通,卻也因此產生另一 個問題,也就是相互信任的機制,消費者無法判斷所消費的資訊產品是否合乎 自身的安全要求,雖然廠商提供了自身評估的資料,但是還是無法給予消費者 一個具體的評估概念,於是乎共通準則(Common Criteria,簡稱CC)就此被推 出,這樣的準則有助於跨廠商,跨國際的認證不僅節省廠商再次作認證的手續 也給予消費者一個通用的準則來判斷所使用的產品是否合乎自身要求,圖一所 表示即為共通準則的演化歷史,現今更進一步推出CC v2.2,皆下來我們就來簡 介這共通準則。 圖1.1:共通準則歷史

1.

1.

1.

1. 概要

概要

概要

概要

本節將介紹共通準則的主要概念。內容說明此準則適用的對象,評估的內 容,以及用來呈現評估結果的方法。 1.1 1.1 1.1 1.1 簡介簡介簡介 簡介 資訊產品的安全主要就是要保障資訊產品與系統內的資訊,他的正確與否 決定資訊產品是否可以順利運行。而且,這些資訊只容許有授權的人依據他們 需要下適時更改,但絕不可以為未被授權的人影響與修改。每當在執行IT 產品 或者系統的功能時,必須運用訊息,適當的控制防止產品遭受攻擊危險(例如不

(2)

需要或者沒有保證的通訊,改變或者損失)。總之,資訊安全就是涵蓋保護以及 減輕這些危害。 很多的資訊產品的使用者,對於他們所使用的資訊產品缺乏專門技術以及 相關知識以判斷此產品是否值的信賴的,而且他們又不想只是單單依據發展資 訊產品者(開發者)所提供的安全保證來換得心理上的慰藉。所以消費者必須 選擇其他途徑來增加他對他所使用的資許產品的信心。所以藉由有次序而且嚴 謹的安全分析應運而生。共通準則就是被期許當成一個安全分析的利器,他提 供許多適當的資訊產品的評鑑項目以及用來表示評估資訊安全要求的評鑑準 則。接下來我們將介紹共通準則的適用對象以及相關的內容。 1 11 1.2 .2 .2 .2 共通準則的適用的對象共通準則的適用的對象共通準則的適用的對象 共通準則的適用的對象 共通準則有三個適用對象群,這三個適用對象群將在資訊產品或系統的安 全評估中扮演各對應的角色,這三個分別為:資訊產品的消費者、資許產品的 開發者、資訊產品的評估者。在這份共通準則的文件中,都可以支援三個適用 對象的要求。他們也就是共通準則的最主要的使用者。這三個使用群都將在共 通準則中得到他們所要的要求,以下表一我們列出CC這三個部分對他所適用目 標對象的一些相互適用關係 表1.1 CC與適用對象的關係 消費者 開發者 評估者 第一部份 一個指引或一種知 識,使的消費者得 以開發PP 一個指引或一種知 識,使的開發者可 以開發安全要求與 建構產品的安全特 性描述 一個參考或一種知 識,使評估者可以 清楚PP與ST的架構 第二部分 當在描述一個安全 要求,這部分可以 當作一個指引或一 種參考, 當在描述功能要求 以及產品的功能特 性時可做一種參考 當在評估是否安全 要 求 都 有 被 實 現 時,者部分給予評 估參考 第三部分 當要決定所要氣得 安全保證為何,此 部分可以當作一個 指引 當要決定產品的安 全保證為何,此部 分可以當作一個指 引 此次份可以當作一 個準則以決定此產 品的安全保證等即 為何 接下來我們簡介CC的一般概念。

2.

2.

2.

2.

一般

一般

一般概念

一般

概念

概念

概念

這章主要是說明有關CC模型的基礎概念 2.1 2.1 2.1 2.1 安全內容安全內容安全內容 安全內容

(3)

安全就是針對所有可能對資安有影響的威脅(threat)進行防衛,而可能被 侵犯的資料叫稱為我們的資產(asset),安全目的就是要防止我們的資產被侵 犯。這些安全威脅主要使我們的資訊產品受到侵犯並且因此使我們的資訊安全 出現漏洞,這些漏洞會使產品因此有以下的缺點漏洞: 1) 消費者對資訊產品安全信心不足; 2) 資訊產品完整性不足; 3) 可用性降低; 圖2.1所表示的就是安全內容的概念,擁有資訊產品的開發者必須要對可能 的威脅進行監控,並且防衛他們可能的攻擊行為,這些威脅也需要事先定義以 及察覺,這些定義也必須由開發者對自身的環境下可能遭受到的攻擊做出判 斷,訂出威脅種類,如此才能及時了解資訊產品正遭受哪一個威脅攻擊。所以 在這張圖中我們可以看的到開發者給予安全資產一個值,而這個值就是來判斷 受到攻擊的量化表現,開發者與威脅者必需互相攻防,開發者會開發一些對策 來對抗這些威脅者的攻擊,使資訊產品所受到的風險降到最低,如果所採去的 對策有弱點以致於風險增加,那就必須採取另外的對策。反之,威脅者就是用 盡所有方式使的所謂的安全資產值降低,增加風險,或利用開發者所採取的對 策之弱點去增加風險。整個攻防過程就是資訊安全最基本的概念。 開發者 威脅者 對策 弱點 威脅 風險 資產 產生 產生 產生 增加 利用 影響 影響 對抗 保護 圖2.1:安全概念 2.3 2.3 2.3 2.3 共通準則方法共通準則方法共通準則方法 共通準則方法 對資訊產品的信心可以經由以下過程中所採取的行為來得到,這些過程有 三個:開發產品過程,評估過程,以及操作過程 2.4 2.4 2.4 2.4 安全概念安全概念安全概念 安全概念 2.4.1 2.4.1 2.4.1 2.4.1 環境環境環境 環境 安全的環境包含所有的規範,組織的安全策略,顧客,專門技術以及相關 的技術,所以主要是要定義產品所處的環境。安全的環境也包括對這環境有影 響的威脅,為了要建立安全的環境。PP或ST的撰寫人必須考量以下的三個因素: 一、為產品的實體環境,一切對產品安全有顧慮的因素,包括已知的實體和 人為的安全操作。

(4)

二、為產品需要保護的資產為何,這些資產諸如直接影響性質的檔案,資料 庫或是間接對安全有影響的認證以及產品的實作過程。 三、則是產品的用途為何。 安全的策略,威脅,以及風險的審視都應該要有一些安全上特別的陳述 一、為安全的假設陳述。 二、為威脅的陳述,這些威脅在CC的內容中用一個個的威脅者來表示。 三、為組織安全策略的陳述。 這些陳述將有助於對建立現在的環境是很方便的。 2.4.2 2.4.2 2.4.2 2.4.2 安全標的安全標的安全標的 安全標的 分析安全環境後,得到的結果有助於我們設定產品的安全標的,因為分析 的結果可以提供我們知道要對付的安全威脅為何,應該要達到的對應結果為 何,當然這樣的安全標的要與產品原本要達到的功能要能相符,也就是說不可 以為了要避免安全威脅或對抗安全攻擊而犧牲某些產品的功能進而影響產品原 本的作用,這樣的話將失去維護安全的意義,換言之,安全目的就是要解決所 有的安全相關問題,並且說明可以經由直接解決的安全問題進而改善產品為何 以及由安全環境方能解決的問題為何,這樣的安全標的的描述必須經由工程判 斷,安全策略,經濟因素,以及可以接受的風險決定的過程來完成,這裡需要 說明的是只有因產品以及IT的環境所訂下的安全標的會被IT安全要求所解決。 2.4.3 2.4.3 2.4.3 2.4.3 安全要求安全要求安全要求 安全要求 簡單說,所謂的IT安全要求就是針對之前所訂下的安全標的作一詳細的分 析並且定下相對應的一條條對評估標的(Target of Evaluation,簡稱 TOE) 與安全環境的安全要求,如果TOE可以符合這些要求那麼他就可以達到所訂下的 安全標的了。 共通準則將這些安全要求分類為兩種:一為功能要求,另一個為安全保證要求, 接下來我們簡述這兩個安全要求的內容為何 a) 功能要求 功能要求就是在TOE的所提供功能中加入對IT產品的安全的支援,以及定義安全 功能的相關安全行為, CC就有定了許多安全功能要求提供使用,這樣的例子像 是加入確認與認證的功能或是安全稽核等。 b)安全保證要求 安全保證要求是一個等級式的要求隨著安全要求的嚴苛程度會有所不同,因此 他通常都以安全保證的零件增加的等級來表示,CC的第三部分就定義了安全保 證要求以及經由安全保證要求零件的使用方法或等級來定義評估保證等級,安 全保證要求由開發者的行為以及產品的產生依據和評估者的行為來完成,這樣 的例子可以像是對開發的過程與要求作限制或者分析潛在的安全弱點。 確保安全標的是否可以經由定下的安全要求達到的因素有兩個 a)安全功能的執行是否正確。

(5)

b)安全功能的效率是否值得信賴,就是說所訂下的安全功能要求是否真的可以 達到安全目的。 TOE總結特性 這個主要是由ST所提供,他定義TOE的安全要求,以及安全要求的高層次規劃定 義以滿足所訂下的功能要求,還有安全保證的測試以檢視是否滿足安全保證要 求 TOE TOE TOE TOE 實現實現實現 實現 TOE的實作就是根據安全功能要求以及TOE總結特性實現TOE,這樣的實作主要是 加入安全與工程技術的過程 2.5 CC 2.5 CC 2.5 CC 2.5 CC描述工具題材描述工具題材描述工具題材 描述工具題材 CC 提供一個架構來描述CC的內容,這樣的目的是為使評估更容易, 2.5.1 2.5.1 2.5.1 2.5.1 安全要求呈現安全要求呈現安全要求呈現 安全要求呈現 圖2.2:安全要求呈現架構 CC定義一系列的架構來更有意義地表示安全要求,這樣可以用來為產品或 系統建立安全要求項目,接下來就來介紹此一架構,此一架構下,CC的安全要 求將被階級化,由種類(class)、族群(family),與零件(component)組成 a) 種類 等級是最普通的安全要求族群,同屬一個等級的所有成員都有共同的目標只是 安全標的的涵蓋程度不同而已,一個class的成員們由族群來表示個別成員 b) 族群 一個族群就是安全要求集合的一個族群,她們有共同的安全標的但是所強調的 部分卻有些許不同,一個族群又可以由個別零件組成 c) 零件 一個零件表示一個特定的安全要求集合,也是CC所定義最小的安全要求集合, 一個族群內的零件集合會被依安全要求的嚴苛程度來排序,有些零件以非階級 式的方式來排序,零件由個別的元素所組成,所以元素是最低層級的標示也是 無法再細分的安全要求,零件裡面有幾個特性需要說明,其中有相依性以及零 件可以允許的動作,現在簡述如下:

(6)

相依性: 各個零件中存在相依性,相依性就是表示當一個零件無法充分表示所要的安全 標的而必須搭配其他的零件來完成,所以相依性存在於功能要求零件與安全保 證零件中, 零件操作動作: CC的零件可以透過可以允許的動作改變零件的內容以滿足特定的安全策略或者 對抗特定的安全威脅,這些動作包括有四個 1.重述: 允許一個零件能夠重複使用; 2.指定: 這是說當執行某一零件時,可以指定特定的參數完成此零件; 3.選擇: 允許選擇一個零件所列出特定的一個項目; 4.重新定義: 允許在使用零件時有額外詳細的說明或定義以更符合我們的安全 要求。 有些動作是在撰寫PP時完成或在ST完成,不過,所有的動作都必需在ST內完 成。 2.5.2 2.5.2 2.5.2 2.5.2 安全要求的使用安全要求的使用安全要求的使用 安全要求的使用 CC定義三種要求架構: Package,PP以及ST,圖2.3則可以看出三個之間的關 係,接下就來介紹三個種類 安全要求 包件(package) 防衛文件(PP) 安全標的(ST) 圖2.3 安全要求的使用 安全要求的來源 評估標的的安全要求可以由以下文件撰寫出來 a) 現有的PPs, b) 現有的Packages, c) 現有的要求與安全保證要求組件, d) 延伸的安全要求。

3.

3.

3.

3.

安全目標

安全目標

安全目標

安全目標(

(Security Target

Security Target

Security Target)

Security Target

ST 對一個 TOE 來說,它是開發者的需求,和開發者與評估單位之間協議的 基礎,也是消費者對於 TOE 安全特性的需求,亦是評估的範圍標準。一份 ST 可 能包含 PP 的需求,或是包含許多彼此相容的 PP。

(7)

一份 ST 應該遵守共通準則第一部份附錄 C 中的內容需求 ,ST 應該被描述 成使用者導向的文件,應該盡可能的減少引用其他的資料,因為 ST 的使用者很 有可能並不具備其他相關資料。 一份完整的 ST 基本上有以下的架構: 3.1 ST 3.1 ST 3.1 ST 3.1 ST 介紹介紹介紹介紹 ST 介紹應該包含下列的文件處理以及概要資訊 a. ST 鑑定應該提供標記符號和所需的敘述性資訊來控制和鑑定 ST,以及 ST 所談論的 TOE。 b. ST 概要應該用敘述的形式來總結 ST,而盡可能的提供詳盡的資訊給消 費者,讓消費者可以決定這樣的 TOE 是否適合。ST 概要應該也適合在 評價的產品目錄的結合下,作為一單獨的立場使用。 c. 共通準則的相容性需求應該陳述 TOE 中任何可以評估的相容性需求,這 個部分被定義在共通準則第一部份的 5-4 節中。 圖 3.1:ST 的架構 安全目標 安全目標 安全目標

安全目標(Security Target(Security Target(Security Target)(Security Target)))

2. TOE 描述 5. IT 安全需求 1. ST 介紹 4.安全目的 3. TOE 安全環境 6. TOE 摘要說明 7. PP 主張 8.原理的闡述 假設 威脅 組織安全策略 TOE 功能性需求 TOE 保證需求 IT 環境需求

(8)

舉例來說,

1.1ST 鑑定

- 標題: AIX 5.2 Security Target, Version 1.2

- 關 鍵 字 : AIX 5.2, general-purpose operating system, POSIX, UNIX.

- 這是一份 AIX 5.2 operating system 產品的共通準則評估的 ST

文件,相容於資訊技術安全評估的共通準則。

1.2ST 概要

- 這一份 ST 為 AIX 5.2 operating system 的安全特性提供說明。

1.3共通準則相容性

- 這 一 份 ST 相 容 於 Controlled Access Protection Profile version 1.d。 - 這 一 份 ST 是 共 通 準 則 第 二 部 分 延 伸 , 以 及 第 三 部 分 增 加 ALC_FLR.1 並相容於評估保證等級四的文件。 1.4功能強度 - 對於 TOE 所需求的功能強度為:中等等級。 1.5架構 1.6詞彙表 3.2 TOE 3.2 TOE 3.2 TOE 3.2 TOE 描述描述描述描述 這個部分應該描述 TOE,用來幫助對於安全需求的瞭解,也應該滿足產品 或是系統的型式。TOE 的範圍與邊界應該用比較普通的術語,分成兩個部分來 描述,一個是物理的方面,包括硬體與軟體、或是零件與模組,另一個是邏輯 方面,包括 IT 以及 TOE 所提供的安全特徵。 TOE 描述應該提供評估的背景。在 TOE 描述中所呈現的資訊將會被用在評 估的過程中去確認不協調的地方。如果 TOE 是一個以安全功能為主的產品或是 系統的話,這一個部分將會被用來描述某些 TOE 所適合的應用背景。 基本上,這個部分對於瞭解 TOE 是非常重要的。 舉例來說, 2 TOE 描述 - 2.1 預期使用的方法 - 2.2 安全特徵的總結 . 2.2.1 鑑定與認證 . 2.2.2 稽核 . 2.2.3 無條件存取控制 . 2.2.4 目標重新使用 . 2.2.5 安全管理

. 2.2.6 TOE 安全功能(TOE Security Function, 簡稱 TSF)保護

- 2.3 軟體

. 2.3.1 檔案系統

. 2.3.2 使用的技術環境

(9)

3.3 3.3 3.3

3.3 TOETOETOE 安全環境TOE安全環境安全環境安全環境

TOE 安全環境的陳述應該描述有關於使用環境的安全觀點,諸如預期中如 何使用 TOE,以及使用 TOE 的方法等等,陳述的方向應該包括以下三點:

- 威脅

- 組 織 安 全 策 略 ( Organizational Security Policies, 簡 稱 OSP ) - 假設 需要注意的是,如果 TOE 是分散式的產品或系統,必須針對不同的 TOE 使 用領域,個別討論安全環境的觀點。 舉例來說, 3.1 簡介 3.2 威脅 - 3.2.1 TOE 所反抗的威脅 - 3.2.2 TOE 使用環境下經過測量所反抗的威脅 3.3 OSP 3.4 假設 - 3.4.1 物理觀點 - 3.4.2 個人觀點 - 3.4.3 網路連線觀點 以下分別針對威脅、OSP、假設分別做說明 3. 3. 3. 3.3.13.13.13.1---- 威脅威脅威脅 威脅 威脅的描述應該包含對於資產所有的威脅,當 TOE 或是使用環境需要特別 保護的時候。需要注意的是,我們並不需要列出所有可能遭遇的威脅,因為這 可能太多了,我們只需要列出在操作 TOE 時相關的安全考量即可。 威脅應該就鑑定過的威脅代理人、攻擊,以及遭受攻擊的資產這幾個方面 做討論。威脅代理人應該描述有關於專業技術、可得到的資源,以及動機等觀 點,攻擊方面則需要描述攻擊方法、會被利用的弱點,以及攻擊機會。當安全 目的只來自於組織安全策略及假設時,威脅的描述則可以省略。 舉例來說, 3.2.1 TOE 所反抗的威脅 - T.UAUSER 攻擊者可能假裝授權過的 TOE 使用者,當然也有可能是某 一位授權過的使用者企圖去假裝另一位授權過的使用者。 - T.UAACCESS 授權過的使用者在沒有經過管理人員允許的情況下,任 意存取資訊來源。 - T.UAACTION 未被偵測的安全策略改變有可能是經由攻擊者企圖去執 行未被授權的單獨行為。 3.2.2 TOE 使用環境下經過測量所反抗的威脅 - TE.HWME 有特權的系統管理員或是普通的使用者,都會因為硬體發 生故障而遺失儲存的資料。

(10)

- TE.COR_FILE TOE 中執行安全及相關的檔案,在系統管理員沒有偵測 到的情況下,會被做手腳或是偶然的竄改。 - TE.HW_SEP 持續執行 TOE 的硬體的基本功能,在使用沒有授權的程 式 時 , 並 沒 有 提 供 足 夠 的 能 力 去 支 援 評 估 標 的 安 全 功 能 ( TOE Security Function, 簡稱 TSF)的自我保護。 3. 3. 3. 3.3.3.3.3.2222---- OS OS OSP OSPPP

OSP 的描述應該確認並解釋每一個 OSP 的陳述或 TOE 必須遵守的規則,允 許被使用的程度上,在設定清楚的安全目地下,闡述需要呈現每一個個別策略 的陳述。當安全目的只來自於威脅及假設時,組織安全策略的描述則可以省 略。 舉例來說, 3.3 組織安全策略 - P.AUHORIZED_USERS 只有被授權的使用者可以存取系統的資訊。 - P.NEED_TO_KNOW 存取特殊資料物件的權力是由以下的基礎來裁定 的, a) 物件的所有人;及 b) 企圖做存取的主題的身份;及 c) 物件所有人所授予的,包括固有的和明確的存取權力。 - P.ACCOUNTABLE 系統的使用者應該對他們在系統內所執行的行為, 有義務做詳細的說明。 3. 3. 3. 3.3.3.3.3.3333---- 假設假設假設 假設 假設的描述應該敘述 TOE 使用,或是預期使用的環境的安全觀點, 包含以 下二項, - 有關於 TOE 的預期使用,包括諸如預期的應用,可能的資產價值, 和使用上的限制等資訊。 - 有關於 TOE 的使用環境,包括物理、個人,和網路連線觀點等資 訊。 舉例來說, 3.4.1 物理觀點 - A.LOCATE TOE 的程序來源應該置於受控制的存取設備,如此才可以 避免沒有授權的存取行為。 - A.PROTECT 安全策略執行的關鍵 TOE 硬體與軟體,應該保護其不能 遭受物理修改。 3.4.2 個人觀點

- A.MANGE 假設有一個或一個以上彼此競爭的個體,來管理 TOE 和 TOE 所包含資訊的安全。

- A.NO_EVIL_ADMIN 系統管理人員不可以粗心、疏忽,或不友善,並 會密切注意與持執行管理人員使用說明所提供的指令。

(11)

3.4.3 網路連線觀點 - A.NET_COMP 假設資料可以正確的通過所有的網路設備,好比橋接器 和路由器,並且資料不能被更改。 - A.PEER 假設與 TOE 連接的其他系統,應該受到相同的管理,並在相 同的安全策略限制下操作。我們並不需要針對外部系統,或是連接到 外部系統的連結做安全上的需求。 - A.CONNECT 所有周邊設備的連接和網路上的連接必須存在於受控制 的存取設備。內部的連接路徑,比如終端機或是其他系統的連接,則 假設其受到充分的保護。 3.4 3.4 3.4 3.4 安全目的安全目的安全目的 安全目的 安全目的應該反映出指定的目的,並適當的反抗所有鑑定過的威脅,以及 涵蓋確認的 OSP 與假設,以下二項目的種類應該被確認, 1. TOE 的安全目的需要被清楚的陳述,並追溯 TOE 所反抗的威脅,及 TOE 所遭遇的 OSP。 2. 使用環境的安全目的也要被清楚的陳述,並追溯 TOE 無法反抗的威 脅,以及 TOE 沒有遭遇的 OSP 與假設。 使用環境的安全目的有可能是 TOE 安全環境的假設部分,全部的或是部分的重 申。 舉例來說, 4.1 TOE 的安全目的

- O.AUTHORIZATION TOE 必須保證只有被授權的使用者可以存取 TOE 和 它的資源。 - O.DISCRETIONARY_ACCESS TSF 必須基於使用者的身份來控制資源的 存取,TSF 也必須准許被授權的使用者明確說明,哪些資源可能被某些 使用者所使用。 - O.AUDITING TSF 必須記錄 TOE 使用者的安全相關動作,TSF 也必須 避免這些動作的資訊被授權的管理人員得知。 - O.RESIDUAL_INFO 當資源再利用的時候,TOE 必須保證,所有包含於 受保護的資源的資訊,不能夠被公布。 4.2 TOE 使用環境的安全目的 - O.ADMIN TOE 的管理員必須是有能力,並且是個別值得信任的,足以 管理 TOE 和 TOE 所包含資訊的安全。 3.5 3.5 3.5 3.5 安全需求安全需求安全需求 安全需求

安全需求詳細地定義 TOE 或是 TOE 使用環境必須滿足的 IT 安全需求。IT 安全需求應該陳述下列幾項, 1. TOE 安全需求的陳述應該定義功能與保證兩方面的安全需求,而這兩 方面的需求是為了滿足 TOE 安全目的而設計的。 2. IT 使用環境的安全需求的選擇性陳述應該定義 IT 安全需求要如何地 符合 TOE 的 IT 使用環境。如果 TOE 並沒有聲明有關於 IT 使用環境的 依賴關係,則此選擇性陳述的部分可以省略。

(12)

3. 需要注意的是,有關於非 IT 使用環境的安全需求部分,並不需要合 乎 ST 的標準格式,因為它們與 TOE 的實作沒有直接的關係,儘管它 們有可能是常常被使用的。 在共通準則需求的架構中,功能與保證需求的分類方法主要有兩種,組 合式與等級制,而它們主要是由下列四種等級構成, 1. 種類(classes):種類是共享共有事項的族群的集合。在種類的結 構主要包含種類的名稱、種類的簡介,及組成種類的族群。 2. 族群(families):族群是共享安全目的零件的集合,當我們用比較 精確的眼光去審視時,它們彼此是相異的。在族群的節構主要包含族 群名稱、族群行為、零件層級、管理相關幸、稽核,及組成族群的零 件。 3. 零件(components):零件是最小可選擇的元素的集合,它們通常包 含於 PP、ST,或是包(package)。零件的結構主要包含零件鑑定、 組成零件的元素、及相關性。 4. 元素(elements):元素即是個別的安全需求。 圖 3.2 說明共通準則安全需求的建構方塊,基本上我們要先確認安全需求 是屬於功能的或是保證的安全需求,之後再決定種類,最後才決定元素。圖 3.3 說明安全需求的命名慣例,每一個安全需求的第一字母決定這個安全需求 是屬於功能的(F)或是保證的(A)需求,之後的兩個字母則是種類的名稱, 再之後的三個字母則是族群的名稱,之後的阿拉伯數字是零件的編號,最後的 數字則是元素的編號。圖 3.4 說明零件之間的相關性,圖中同種類之間的零件 可能彼此有相關性,比方說 FDP_ACC.1 這個零件相關於零件 FDP_MSA.1,不同 種類之間的零件也有可能彼此有相關性,比如零件 FDP_SMR.1 相關於零件 FIA_UID.1。相同族群底下的零件彼此之間除了相關性,還有階層式的關係,圖 3.5 中說明族群 FAU_SAA(Security Audit Analysis)下四個不同零件彼此的階 層關係,在這樣的階層架構下,零件 2 會同時滿足零件 1 的安全需求,零件 4 會滿足零件 3 和零件 1 的需求,但是零件 3 並無法滿足零件 2 的安全需求。

圖 3.2:共通準則安全需求的建構方塊

FAU_GEN.1.1 and FAU_GEN.1.2

需求目錄

需求目錄

需求目錄

需求目錄

種類

種類

種類

種類

族群

族群

族群

族群

零件

零件

零件

零件

元素

元素

元素

元素

例如:功能需求 FAU – 安全稽核 FAU_GEN – 安全稽核資料衍生 FAU_GEN.1 – 安全稽核資料衍生

(13)

圖 3.3:安全需求的命名慣例。

圖 3.4:零件之間的相關性

圖 3.5:族群 FAU_SAA(Security Audit Analysis) 下四個不同零件彼此的階層關係

FAU_GEN.1.1

F=功能的 A=保證的 種類識別符 (兩個字母) 族群識別符 (三個字母) 零件號碼 元素號碼 FDP_ACC.1 FDP_IFC.1

FDP_ACF.1 FDP_MSA.1 FDP_IFF.1

FDP_SMR.1 FDP_MSA.3 FIA_UID.1 FAU_SAA 1 2 3 4 族群族群族群 族群 零件 零件零件 零件

(14)

3. 3. 3. 3.5.1 5.1 5.1 5.1 零件的操作零件的操作零件的操作 零件的操作 功能性的零件通常會被修改以致於能夠滿足特殊的安全目的。修改的操作 必須被限制於眾所公認的範圍內。這些操作通常伴隨著功能性的零件一起被描 述。目前被允許的操作有以下四項, - 重述:允許一個零件被使用一次以上,使用的過程中可以伴隨著不 同的操作。(並非必須的操作) - 指定:允許確認的參數詳述操作。 - 選擇:允許從清單當中選擇一個或一個以上的元素。 - 重新定義:允許額外的詳細說明。(並非必須的操作) 以下針對上述四種操作模式做說明 3. 3. 3. 3.5.1.1 5.1.1 5.1.1 5.1.1 重述重述重述 重述 重複使用相同的安全需求去強調不同的觀點,比如說要確認許多不同類 型的使用者。重述被使用來對安全需求做多樣的、不同的舉例說明。 舉例來說, 好比共通準則裡陳述的,

- FMTFMTFMTFMT----MTD.1.1MTD.1.1MTD.1.1 The TSF shall restrict the ability to MTD.1.1 [selection:

change_default, query, modify, delete,

clear, [assignment:

other operations]] the [assignment:

list of TSF data] to [assignment:

the authorized

identified roles].

在經過重述的操作後,則分成兩個陳述部分,

- FMT_MTD.1.1aFMT_MTD.1.1aFMT_MTD.1.1aFMT_MTD.1.1a The TSF shall restrict the ability to modify the enrolled images db to the authorized administrator.

- FMT_MTD.1.1bFMT_MTD.1.1bFMT_MTD.1.1bFMT_MTD.1.1b The TSF shall restrict the ability to backup/restore the enrolled images db to the authorized operator. 3. 3. 3. 3.5.1.2 5.1.2 5.1.2 5.1.2 指定指定指定 指定 所謂的指定就是當使用零件的時候,填入參數說明。它是一個填入空格 的操作,允許 PP 或 ST 撰寫者提供給安全需求的應用相關資訊。 舉例來說, 好比共通準則裡陳述的,

- FMT_SMR.1.1FMT_SMR.1.1FMT_SMR.1.1FMT_SMR.1.1 The TSF shall maintain the roles: [assignment: the authorized identified roles].

在經過指定的操作後,

- FMT_SMR.1.1FMT_SMR.1.1FMT_SMR.1.1FMT_SMR.1.1 The TSF shall maintain the roles: authorized administrator, security officer, operator.

3. 3. 3.

(15)

所謂的選擇即是從零件所提供的清單當中,選擇出所需要的元素說明。 選擇可以是複選的操作,它允許 PP 或 ST 撰寫者從提供的選擇清單中選擇所需 的操作。

舉例來說,

好比共通準則裡陳述的,

- FAU_GEN.1.1FAU_GEN.1.1FAU_GEN.1.1FAU_GEN.1.1 The TSF shall be able to generate an audit record of the following auditable events:

a) Start-up and shutdown of the audit functions;

b) All auditable events for the [selection: minimum,

basic, detailed, not specified] level of audit;

and …

在經過選擇的操作後,

- FAU_GEN.1.1FAU_GEN.1.1FAU_GEN.1.1FAU_GEN.1.1 The TSF shall be able to generate an audit record of the following auditable events:

a) Start-up and shutdown of the audit functions;

b) All auditable events for the minimum level of audit; and … 3. 3. 3. 3.5.1.4 5.1.4 5.1.4 5.1.4 重新定義重新定義重新定義 重新定義 所謂的重新定義就是藉由明確的額外說明,按照順序地限制可被接受的 實作的階層。 舉例來說, 好比共通準則裡陳述的,

- FAU_SAA.1.1 The TSF shall be able to apply a set of rules in monitoring the audited events and based upon these rules indicate a potential violation of the TSP. 在經過重新定義的操作後,

- FAU_SAA.1.1 The TSF shall be able to apply a set of rules in monitoring the audited events and based upon these rules indicate a potential violation of the TSP by notifying the Security Officer immediately.

目前已經被定義的功能性種類總共有十一種,表一列出這十一個種類的名稱及 簡單的說明。表二則列出保證性種類的名稱與說明。 表二 功能性安全需求的種類名稱與說明 種類名稱 說明 FAU 安全稽核 FCO 通訊

(16)

FCS 密碼支援 FDP 使用者資料保護 FIA 身份識別與確認 FMT 安全管理 FPR 隱私 FPT TOE 安全功能的保護 FRU 資源利用 FTA TOE 存取 FTP 可信任的路徑或是頻道 表三 保證性安全需求的種類名稱與說明 種類名稱 說明 ACM 安裝管理 ADO 運送與操作 ADV 發展 AGD 引導文件 ALC 生命週期支援 ATE 測試 AVA 弱點評估 3.6 3.6 3.6

3.6 TOETOETOE 摘要說明TOE摘要說明摘要說明摘要說明

TOE 摘要說明提供了對於安全功能和保證測量的描述,TOE 安全功能的陳述 應該涵蓋 IT 的安全功能,以及明確說明這些功能是如何滿足 TOE 的安全功能需 求。這些陳述應該包含功能和需求之間雙向的對應,並清楚的顯示哪一個功能 會滿足哪一個需求,直到所有的需求都被滿足為止。而保證性測量的陳述指出 TOE 的保證測量如何滿足所需的保證需求。這些保證性測量應該被追溯到特定 的保證性需求,以確認這些測量是對滿足哪些需求具有貢獻。 舉例來說, 6.1 安全實施零件概要 6.1.1 簡介 6.1.2 核心服務 6.1.3 非核心 TSF 服務 6.1.4 網路服務 6.1.5 安全策略概要 6.1.6 TSF 結構

(17)

6.1.7 TSF 介面 6.1.8 安全與非安全狀態 6.2 安全實施功能的設計細節 6.2.1 簡介 6.2.2 身份識別與確認 6.2.2.1 使用者身份識別與資料確認管理 6.2.2.2 一般確認方法 6.2.2.3 人機登入與相關方法 6.2.2.4 使用者身份變更 6.2.2.5 登入程序 6.2.2.6 登出程序 6.2.3 稽核 6.2.4 任意存取控制 6.2.5 目的再利用 6.2.6 安全管理 6.2.7 TSF 保護 6.3 非 TSF 的支援功能 6.4 保證性測量 6.5 TOE 安全功能需要功能強度分析 3.7 3.7 3.7 3.7 PPPPPP 主張PP主張主張主張 ST 可能選擇性地主張說,TOE 遵守一份或一份以上 PP 的要求。對每一個 PP 相容性主張來說,ST 應該包含 PP 的主張,主要有關於解釋、驗證,以及其 他對於 PP 主張可以舉例說明的支援工具。 如果 PP 相容性主張已經完成,那麼 PP 主張的陳述應該包含以下的工具, - 「「「「PPPPPPPP 參考文獻參考文獻參考文獻參考文獻」」」」的陳述應該確認 PP 裡哪一些主張已經被承諾,加 上哪一些主張以外的擴充是需要的。一個有效的主張暗示說 TOE 滿 足所有 PP 的需求。 - 「「「「PPPPPPPP 修改修改修改修改」」」」的陳述應該確認 IT 安全需求的陳述是否滿足被允許的 PP 操作,或是更進一步使得 PP 需求合格。 - 「「「「PPPPPP 附加PP 附加附加」附加」」」的陳述應該確認 TOE 目的和需求的陳述,是否有被附 加於 PP 目的和需求。 舉例來說, 7.1 PP 參考文獻

- 主 張 相 容 於 控 制 存 取 保 護 剖 繪 ( Controlled access protection profile, 簡稱 CAPP)1.d 版。 7.2 PP 修改 - 因為 AIS 32,一個安全功能需求已被附加(FMT_SMF.1)。定義在 PP 裡的兩個 SFRs(FIA_UAU.1 和 FIA_UID.1)由階層中較高級的兩個 (FIA_UAU.2 和 FIA_UID.2)取代,對於 PP 的需求來說,SFR 已經變 得更完善。

(18)

- 相 關 威 脅 已 經 被 赴 加 上 去 , 另 一 個 有 關 於 TOE 使 用 環 境 (A.NET_COMP)的假設已經被赴加上去,以反應 TOE 的分散式特性。 - TOE 的安全目的已經被附加: a) OE.ADMIN b) OE.INFO_PROTECT c) … 3.8 3.8 3.8 3.8 原理的闡述原理的闡述原理的闡述 原理的闡述 「原理的闡述」支援主張 ST 是需求的完整、凝聚集合。相容的 TOE 在安全 環境中提供有效率的 IT 安全對策,而 TOE 摘要說明則滿足那些需求,「原理的 闡述」應該包含以下幾個部分, - 安全目的闡述安全目的闡述安全目的闡述安全目的闡述 「安全目的闡述」應該證明所陳述的安全目的皆可回溯到所有定義 在 TOE 安全環境中的觀點,並且可以適當地涵蓋它們。 - 安全需求闡述安全需求闡述安全需求闡述安全需求闡述 「安全需求闡述」應該證明安全需求的集合,包括 TOE 和 TOE 使用 環境的安全需求,可以適當地滿足並且可回溯到安全目的。

- TOETOETOETOE 摘要說明闡述摘要說明闡述摘要說明闡述 摘要說明闡述

「TOE 摘要說明闡述」應該呈現 TOE 安全功能和保證性測量可以適 當地滿足 TOE 安全需求。 - PPPPPPPP 主張闡述的陳述主張闡述的陳述主張闡述的陳述 主張闡述的陳述 「PP 主張闡述的陳述」應該解釋 ST 安全目的和安全需求之間每一 個相異處,並解釋每一個相容 PP 之間上述的相異之處。如果沒有 相容 PP 的主張,或是 ST 安全目的和安全需求完全相同於每一個 PP 的主張,則這個部分可以省略。 ST 架構中最後一個部分「原理的闡述」是非常重要的一部份,因為它提供 使用於 ST 評估中的證據,並聲明以下四項, - ST 是需求的完整、凝聚集合; - 相容的 TOE 在安全環境中提供有效率的 IT 安全對策; - TOE 摘要說明滿足那些需求; - 每一個相容性 PP 是有效的。 當我們要撰寫一篇 ST 的時候,「原理的闡述」總是開始於 ST 發展的中期,而 卻是最後被完成的部分。

4.

4.

4.

4. 參考文獻

參考文獻

參考文獻

參考文獻

1. Common Criteria, Version 2.1, Part 1, 2, 3. 2. Controlled Access Protection Profile (CAPP)

3. SuSE Linux Enterprise Server V8 with Service Pack 3 Security Target for CAPP Compliance.

數據

圖 3.2:共通準則安全需求的建構方塊
圖 3.3:安全需求的命名慣例。

參考文獻

相關文件

5 個資法第二十七條 非公務機關保有個人資料檔案者,應採行適當之安全措施,防止個

瞭解各種安全防護 器具(含滅火器、安 全帽、護目鏡、防 凍手套、絕緣手 套、高空作業安全 帶、噪音防護及氣 銲設備回火安全裝 置等)之種類及功 用。.

33 (3) 對需考慮資訊安全的公司或單位,下列何者是屬於進出公司 必要進行安全管制的可攜式設備或可攜式儲存媒體?手

本次修正是因藥物 Canagliflozin 詴驗團隊發布之 安全性資訊更新資料顯示,比較使用詴驗藥物 Canagliflozin

動態時間扭曲:又稱為 DTW(Dynamic Time Wraping, DTW) ,主要是用來比

所以 10 個數字 個數字 個數字 個數字 pattern 就產生 就產生 就產生 就產生 10 列資料 列資料 列資料 列資料 ( 每一橫 每一橫 每一橫

為要達成普通話科的整體學習目 標,學校每周安排 2-3 教節是最理 想的。但個別學校可能因為暫時的 困難,只能為普通話科安排 1

 安瑟莫給出的答案是:天主的慈悲不是與 我們的行為對應,而是與他自身和他的仁