• 沒有找到結果。

稽核指導方針的訂定

第五章、 資訊安全管理系統內部稽核作業研究…

5.1 稽核指導方針的訂定

在資訊化的工作環境中,如何控制其契合組織目標的探討,仍不多見,國際 上 的 資 訊 系 統 稽 核 與 控 制 協 會 ( Information Systems Audit and Control Association,簡稱 ISACA),有鑑於此,邀集學者專家參考了三十六份世界公認 的標準與規章等相關報告訂定了一份標題為「資訊及相關技術之控制目標」

(COBIT)作業規範 [32],自 1996 年首次發表,1998 年發表第二版,2000 年 公布第三版以來,已成為一般公認的「資訊環境控制目標」之標準,在此節中將 介紹 COBIT 為滿足對資訊的需求,將針對每一資訊流程訂定出相關的稽核指導 方針;期使稽核人員可依據此方針來執行各項的稽核工作。

COBIT 訂定了資訊環境下企業需求、資訊技術資源、資訊技術流程三個交 互相關的內部控制要素,提供管理當局、使用者,與稽核人員完整的架構,能輔 助管理當局在資訊投資上和風險控制下找出平衡點;幫助使用者在他們獲得的產 品與服務的安全和控制方面獲得保證,且提供稽核人員相關的工具與程序以進行 內部控制。

為滿足組織對資訊的需求,COBIT 強調資訊科技的資源必須以企業流程的 方式來管理。亦即是資訊流程強調建立有效之會計資訊系統與整合資訊系統等,

使組織內的人能夠迅速取得並交換、管理及控制其內部工作流程運作所需之訊 息;資訊流程可以區分為資訊系統規劃及組織、資訊系統獲得及建置、資訊服務

之交付及支援、資訊環境監督四大範圍,正達到稽核作業所涵蓋的範疇。COBIT 這四個範圍中設計了 34 個資訊流程如下:

一、 資訊系統規劃及組織:

1. 擬定策略規劃 2. 擬定資訊架構 3. 決定技術導向 4. 釐定組織及其關係 5. 專案之投資管理

6. 溝通管理的目標與方向 7. 人力資源管理

8. 確保符合外部需求 9. 風險評估

10. 專案管理 11. 品質管理

二、 資訊系統獲得及建置:

資訊系統獲得與實施範圍下有六個資訊流程。並且在這六個資訊流程 下訂定更專門細節的控制目標。

1. 確認解決方案

2. 應用軟體的獲得與維護 3. 技術架構的獲得與維護 4. 開發及維護資訊程序 5. 安裝及認證系統 6. 變更管理

三、 資訊服務之交付及支援:

資訊系統傳送與支援範圍下有十三個資訊流程。並且在這十三個資訊 流程下訂定更專門細節的控制目標。

1. 定義服務層次 2. 外包服務管理 3. 績效及容量管理

5. 確保系統安全 6. 分析及歸屬成本

7. 使用人員的教育及訓練 8. 客戶支援及諮詢

9. 裝備管理

10. 問題及意外管理 11. 資料管理

12. 設施管理 13. 操作管理 四、 資訊環境監控:

最後的領域是資訊環境監控,其下有四個資訊流程。並且在這四個資 訊流程下訂定更細緻的控制目標。

1. 監督各項資訊流程

2. 評鑑內部控制的允當性(註:第二版新增) 3. 是否有獨立的品質保證(註:第二版新增) 4. 稽核獨立

COBIT 亦針對每一資訊流程訂定相關的稽核指導方針,使稽核人員可根據 相關的指導方針,明確的執行各項稽核工作。內部稽核的過程可分為四個階段:

1. 確認資訊系統可能發生之錯誤與舞弊,風險為何:認識企業需求、相關 的風險與控制衡量方法

2. 確認需有那些控制程序存在以降低風險:評量各控制程序的適合度 3. 系統複核和控制測試程序設計:調查測試各控制程序是否如預期的執

行,與是否具有一致性與連續性

4. 評估內部控制缺失:使用分析技術與選擇的資料來偵測未符合控制目標 的風險

資訊環境稽核過程主要重覆依如圖 5.1 所示之四個階段檢驗各項資訊流 程,確保各項資訊流程被適當控管,能產生組織營運活動所需要資訊的品質標 準。COBIT 提出了這個連結資訊技術程序、資訊技術資源及企業策略和目標的 架構。再者,COBIT 整合及涵蓋了良好的規劃及組織、取得及建置、交付及支 援、監控等制度流程,以確保企業資訊和相關技術能維持企業目標[1]。對照圖

5.1 與圖 3.2,BS 7799-2:2002 中資訊安全管理系統過程模式中之「計畫階段」

表 5.1:COBIT 資訊技術控管作業程序項目

COBIT 資訊技術控管架構如圖 5.2 所示,可區分為資訊技術資源、符合組織 營運所需之品質準則及資訊技術作業等三方面加以分析;資訊技術之控管目的可 整理成圖 5.3 所示,任一資訊作業之控管目的均可按照圖 5.3 之模式加以套用,

並予以描述。

階段 (Domains)

作業程序 (Processes)

細步工作 (Activities/Tasks)

圖 5.2:資訊技術控管架構示意說明

資訊技術作業

營運需求

控管措施 控管目的

控管項目

符合

方法

考量

圖 5.3:資訊技術控管塑模示意

因 COBIT 之目的在於能確保達成組織營運所需之品質標準,並用以發現重 大缺失;為了達成 COBIT 之標的,其遵循之資訊系統準則如表 5.2 所示。自 COBIT 第三版發行後,其中要求之合格證明準則已不斷地推陳出新,除 BS7799-2:2002 已整理於表 2.2 外,分別將 ISO/IEC 15408 與 ISO/IEC TR 15504 之沿革整理以圖 5.4 與表 5.3 及表 5.4 來表示,並契合如表 5.5 所示之資訊技術保證框架之 ISO/IEC 正研訂中成熟度標準上之要求 [7]。

表 5.2:COBIT 遵循之資訊系統準則 1.遵循規範:OECD 與 ISACA 等公布之原則。

2.技術標準:ISO 與 EDIFACT 等公布之標準。

3.合格證明準則(Qualification Criteria):

3.1 ISO 9000 (BS7799-2:2002)。

3.2 ISO/IEC 15408。

3.3 ISO/IEC TR 15504 (SPICE)。

4.專業標準:COSO 與 ISACA 等公布之標準。

5.作業規範與需求:英國貿工部(Department of Trade and Industry,簡稱 DTI)及 NIST 等公布之作業規範與需求。 US Federal Criteria

(FC)

for Information Technology Security

1. ISO/IEC 15408 (CC 2.1) 2. Common Methodology for Information Technology Security Evaluation (CEM 1.0)

2003(?) ISO/IEC 18045

(CEM 1.0 (?)) 1994

Security Requirements for Cryptographic Modules

說明:1. 表示研究工作,產出物為技術報告。

2. 表示已溶入正式文件中。

表 5.3:資訊技術安全評估準則認證機制簡史

1. 1997年10月7日,美國公告了針對ISO/IEC 15408(以下簡稱CC)通過後認證機制 所需之TTAP(Trust Technology Assessment Program) Laboratories,接受植基於 CC之測試與評估工作,做為NIAP (National Information Assurance Partnership) CCEVS(Common Criteria Evaluation and Validation Scheme)認證機制建立前之 過渡期因應方案。

2. 1997年11月8日,TTAP提出植基CC之認證、驗證檢測工作建議。

3. 1999年4月,美國、加拿大、德國、英國、法國共同簽署CCMRA(Mutual Recognition Agreement),預期歐洲、亞太其他各國將陸續加入。

4. 1999年5月14日,美國公告了CC認證計畫,同時宣布密碼模組認證計畫將併入 此計畫。

5. 1999年6月8日,美國宣布CC 2.1版正式成為ISO/IEC 15408。

6. 2000年5月23~25日,在美國Baltimore International Convention Center舉辦第1 次CC國際研討會。

7. 2000年8月30日,美國公告Computer Science Corporation(CSC),CygnaCom Solutions, Science Applications International Corporation (SAIC) 與 TUViT Incoporated 4家民間實驗室已經通過 NIAP的認可CCTLS(Common Criteria Testing Laboratories)。

8. 2000年10月13日,美國公告COACT Inc. CAFÉ Laboratory成為通過NIAP認可 之第5家CCTLS

9. 2001年7月18~19日,在英國Brighton舉辦第二次CC國際研討會。

10.2002年2月15日,美國公告 Booz-Allen & Hamilton, Inc. Common Criteria Testing Laboratory成為通過NIAP認可之第6家CCTLS

11.2002年5月13~14日,在加拿大Ottawa舉辦第三次CC國際研討會。

12.2003年9月7~9日,在瑞典Stockholm舉辦第四次CC國際研討會。

表 5.4:ISO/IEC TR 15504 與 ISO/IEC 21827 發展簡史 1. 1991年:

1.1 1991年6月,國際標準組織(ISO)與國際電子技術委員會(IEC)第一聯合技術 委 員 會 (Joint Technical Committee 1 , 簡 稱 JTC1) 得 第 七 子 委 員 會 (Sub-Committee 7,簡稱SC7)提出發展軟體過程評鑑國際標準的議案,經決議通 過,由ISO/IEC JTC1/SC7之第十工作小組(Working Group 10,簡稱WG10) 成立研究小組,先行準備。

1.2 1991年8月15日,美國卡內基大學(Carnegie Mellon University)的軟體工程研 究院(Software Engineering Institute,簡稱SEI)公布軟體能力成熟度模式 (Capability Maturity Model,簡稱CMM)第1版。

2. 1992年6月:ISO/IEC JTC1/SC7大會時,決定成立第十工作小組(WG)執行1991 年6月之ISO/IEC JTC1/SC7提案之決議。

3. 1993年:

3.1 1993 年 1 月 , ISO/IEC JTC1/SC7/WG10 成 立 軟 體 程 序 改 進 與 能 力 測 定 (Software Process Improvement and Capability dEtermination,簡稱SPICE)專 案,執行ISO/IEC JTC1/SC7提案。

3.2 1993 年 4 月,系統安全工程 (System Security Engineering CMM ,簡稱 SSE-CMM)研發工作起動。

4. 1994年:英國貿工部(DTI)遵循ISO 9000,公布軟體品質管理系統建構與驗證 指 引 (Guide to Software Quality Management System Construction and Certification,簡稱TickIT)。

5. 1995年1月:舉辦第一次SSE-CMM研討會。

6. 1996年10月:SEI公布SSE-CMM第1版。

7. 1997年:

7.1 1997年第1季:SEI公布SSE-CMM鑑定方法(SSE-CMM Appraisal Method,

簡稱SSAM) 第1版。

7.2 1997年7月:舉辦第二次SSE-CMM研討會。

8. 1998年10月:SSE-CMM送交 ISO/IEC JTC1/SC7。

9. 1999年:

9.1 1999年4月12日:SEI公布SSE-CMM第2版。

9.2 1999年4月16日:SEI公布SSAM第2版。

10. 2002年10月1日:ISO公布源自SSE-CMM之ISO/IEC 21827。

表 5.5:資訊風險治理成熟度示意說明 成熟度

階段 內 容 0 無:

(1)程序或商業決策的風險評鑑作業均付諸闕如。組織未考慮安全脆 弱性對業務會帶來哪些影響。組織尚未體認資訊技術的解決方案 與服務和風險管理之間有何關係。

(2)組織不瞭解資訊安全的必要性。無人負責安全事務。無任何支援 資訊安全管理的作為。若發生資訊安全事件,亦無資訊安全報告 或處理程序。未見任何安全管理程序。

(3)管理單位不瞭解資訊作業或服務有哪些風險、脆弱性和威脅。

1 初步、特別狀況:

(1)組織以特別案例的角度思考資訊風險的問題,未按照既定的工作 程序或政策。採用的風險評鑑作業不是以正式的專案方式進行。

(2)組織已體認到資訊安全的必要性,但對安全的警覺性因人而異。

已對資訊安全有處理動作,但無測量標準。若發現資訊安全漏洞,

相關人員只會互踢皮球,因權責劃分尚不明確。對資訊安全事件 的處理方式無法預估。

(3)負責業務持續運作的權責劃分不明確,權限不高。管理單位已瞭 解業務持續運作會有的風險與必要性。

2 可重複,但仍靠直覺:

(1)已漸漸瞭解資訊風險的重要性,以及審慎考量的必要性。已有風 險評鑑的方式,但程序尚未成熟,且仍在改進中。

(2)資訊安全的權責已派任給資訊安全協調人員,但無管理權限。對

安全的警覺性分散且有限。有安全資訊,但未進行分析。安全工 作只針對事件作處理,採用的是第三人廠商提供的產品,未針對 組織的特定需求做修改。安全政策已制訂,但人員技術與工具仍 嫌不足。資訊安全報告不夠完整,或有誤導的可能。

(3)已指派人員負責使服務不中斷。但無維護服務持續運作的整套方

(3)已指派人員負責使服務不中斷。但無維護服務持續運作的整套方