CISSP第二章 信息安全治理與風險管理

信息安全治理與風險管理

主要內容

安全術語和原則,保護控制類型,安全框架、模型、標準和最佳時間,安全企業架構,風險管理,安全文檔,信息分類和保護,安全意識培訓,安全治理

2.1 安全基本原則

AIC三元組:可用性,完整性,機密性
在這裏插入圖片描述

2.1.1 可用性availability

  • 確保授權的用戶能夠對數據和資源進行及時和可靠的訪問
  • 控制措施:廉價磁盤冗餘陣列RAID,羣集,負載均衡,冗餘數據和電源線,軟件和數據備份,磁盤映像,co-location和異地備用設備,回滾功能,故障切換配置

2.1.2 完整性integrity

  • 保證信息和系統的準確性和可靠性,並禁止對數據的非授權更改
  • 控制措施:散列(數據完整性),配置管理(系統完整性),變更控制(進程完整性),訪問控制(物理和技術的),軟件數字簽名,傳輸CRC功能

2.1.3 機密性confidentiality

  • 確保在數據處理的每一個交叉點上都實施了必要級別的安全保護並阻止未經授權的信息披露
  • 控制措施:加密休息中的數據(整個磁盤,數據庫加密),加密傳輸中的數據(IPSec,SSL,PPTP,SSH),訪問控制(物理和技術的)
  • 肩窺shoulder surfing:越過別人的肩膀未授權瀏覽信息
  • 社會工程social engineering:欺騙他人共享敏感信息以獲取未經授權的訪問

2.2 安全定義

脆弱性,威脅,風險,暴露

  • 脆弱性vulnerability:缺少安全措施或者採用的安全措施有缺陷。如未安裝補丁的應用程序,沒有限制的無線訪問點
  • 威脅threat:利用脆弱性而帶來的潛在危險。某人或某個軟件識別出脆弱性,並利用其來危害公司或個人。利用威脅的實體成爲威脅主體。
  • 風險risk:威脅的主體利用脆弱性的可能性以及相應的業務影響。
  • 暴露exposure:造成損失的實例。

控制contorl,對策countermeasure和防護措施safeguard能夠消除/降低潛在的風險。

2.3 控制類型

按類型分:管理控制,技術控制,物理控制

  • 管理控制administrative control:軟控制,安全文檔,風險管理,人員安全和培訓
  • 技術控制technical control:邏輯控制,軟件和硬件組成,防火牆,入侵檢測系統,加密,身份識別,認證機制
  • 物理控制physical control:用來保護設備,人員和資源,保安,鎖,圍牆,照明

按功能分:預防性,檢測性,糾正性,威懾性,補償性

  • 威懾性:威懾潛在的攻擊者
  • 預防性:避免意外事件的發生
  • 糾正性:意外事件發生後修復
  • 恢復性:使環境恢復到正常的操作狀態
  • 檢測性:事件發生後識別其行爲
  • 補償性:向原來的控制措施那樣提供類似保護

正確運用上面的控制措施,才能爲企業提供深度防禦,深度防禦指以分層的方法綜合使用多個安全控制類型,爲使成功滲透和威脅更難實現而採用多種控制措施。

2.4 安全框架

通過隱匿實現安全:把備用鑰匙放在門前臺階上;對產品進行編譯以實現安全;開發私有的加密算法代替行業通用的加密算法;在防火牆上重新映射協議,不使用衆所周知的80端口,而使用8080端口。
上述通過隱匿實現安全的例子,實際並不安全。

真正的安全是基於靈活框架的安全規劃,下面看一些行業標準

2.4.1 ISO/IEC 27000系列

IOS/IEC 27000 是一套系列標準,該標準將信息安全管理體系分爲不同模塊。ISO遵循戴明環(計劃-執行-檢查-處理),經常用於業務流程質量控制程序。
ISO/IEC 27000系列:安全控制管理的最佳行業實踐

2.4.2 企業架構開發

  1. 爲何需要企業架構框架
    業務人員和技術人員對問題看法的分歧會引發混亂失敗以及資金浪費,因此需要一個工具能讓業務和技術人員使用以減少衝突,優化業務功能,避免浪費時間和金錢。
  2. Zachman框架:由John Zachman開發的企業框架開發模型,是一個二維模型,目標是讓人們能從不同的視角出發瞭解同一個組織。
    6個基本的疑問詞:什麼,如何,哪裏,誰,何時,爲何
    不同的視角角色:計劃人員,所有者,設計人員,建設人員,實施人員,工作人員
  3. 開放羣組框架結構
    TOGAF框架,開放式羣組架構框架(The Open Architecture Framework),由美國國防部開發並提出設計,實施和治理企業信息架構的方法。
    用於開發業務架構,數據架構,應用程序架構,技術架構
  4. 面向軍事的架構框架
    4.1 美國國防部架構框架DoDAF:Department of Denfense Architecture Framework,保障軍事任務完成過程中系統間的互操作性,確保所有的系統、過程和人員協調一致的共同完成使命。
    4.2 英國國防部架構框架MODAF:British Ministry of Denfense Architecture Framework,主要應用在軍事任務支持方面,能夠以正確的格式獲取數據並以最快的速度傳給正確的人。
  5. 企業安全架構
    定義了信息安全戰略,包括各層級的解決方案、流程和規程、以及他們與整個企業的戰略、戰術和運營鏈接的方式。
  6. 企業架構和系統架構
    企業架構解決的是組織的架構,系統架構解決的是軟件和計算機組件的結構。
  7. 舍伍德商業應用安全架構SABSA:Sherwood Applied Business Security Architecture,用於企業信息安全架構開發的模型和方法論。

2.4.3 安全控制開發

Cobit和NIST,分別包含私營部門和聯邦信息系統組織的控制目標。
這些控制目標是爲信息系統準備的管理、運營和技術控制,用來保護系統及其信息的保密性完整性可用性。

  1. Cobit框架,Control Objectives for Information and related Technology,信息及相關技術的控制目標,定義了控制目標,使用這些控制目標可以正確管理IT並確保IT到業務需求的映射。
    Conbit分爲四個領域,計劃和組織(Plan and Organize),獲得與實現(Acquire and Implement),交付與支持(Deliever and Support),監控與評價(Monitor and Evaluate)
    Cobit是IT治理模型。
  2. SP 800-53:由美國國家標準和技術研究院NIST開發的保護美國聯邦系統的控制集。

2.4.4 COSO

COSO是企業治理模型,其派生出的CobiT是IT治理模型。
COSO處理的是戰略層問題,CobiT關注運作層面。
COSO由反欺詐財務報告全國委員會發起組織委員會COSO開發,旨在幫助降低財務欺詐風險的國內公司控制集。

2.4.5 流程管理開發

  1. ITIL:Information Technology Infrastructure Library信息技術基礎設施庫
    ,英國商務部開發的用於IT服務管理的過程
  2. Six Sigma:是一種過程改進方法論,也是一種“新的和改進的”全面質量管理Total Quality Management。
  3. CMMI:Capability Maturity Model Integration 能力成熟度模型集成,模型由卡內基梅隆大學開發,目的是實現開發過程改進
    自頂向下的方法:安全規劃應使用自頂向下的方法,啓動支持和方向都來自於高層管理人員。

2.4.6 功能與安全性

信息安全與業務需達到平衡,纔不會影響生產效率

2.5安全管理

安全管理包括所有爲保持程序安全啓動、運行和演變所需要的活動。它包括風險管理、文檔化、安全控制實現和管理、流程和過程、人員安全、審計和持續的安全意識培訓。
風險分析—標識、實現和維護保護性措施—安全教育和意識培訓

2.6 風險管理

信息風險管理:Information Risk Management,縮寫IRM,是識別並且評估風險、將風險降至可接受級別、執行適當機制來維護這種級別的過程。
公司面臨的風險具有多種形式:
物理破壞,人爲破壞、設備故障、內部與外部攻擊、數據誤用、應用程序錯誤

2.6.1 誰真正瞭解風險管理

安全領域之外,很少有人真正瞭解風險管理。
真正地實施風險管理意味着你全面瞭解組織,瞭解它所面臨的威脅,知道應該採取什麼樣的應對措施來處理這些威脅,並持續監控以確保風險級別處於可接受的級別。

2.6.2 信息風險管理策略

IRM策略應該涉及以下內容:

  • IRM團隊的目標
  • 公司可接受的風險級別和定義
  • 風險識別的形式化過程
  • IRM策略與組織機構的戰略規劃過程之間的聯繫
  • IRM的職責以及履行這些職責的角色
  • 風險和內部控制之間的映射關係
  • 爲響應風險分析而改變員工行爲和資源分配的方式
  • 風險與業績目標和預算之間的映射關係
  • 監控控制效率的主要指標

2.6.3 風險管理團隊

IRM團隊的總體目標在於以最低預算確保公司安全。
大部分公司的IRM團隊成員並非由專門從事風險管理工作的員工組成,團隊成員已在公司擁有一份全職工作,只是暫時承擔風險管理任務。

2.7 風險評估和分析

風險分析的4個主要目標:

  1. 標識資產和它們對於組織機構的價值
  2. 識別脆弱性和威脅
  3. 量化潛在威脅的可能性及其對業務的影響
  4. 在威脅的影響和對策的成本之間達到預算的平衡

2.7.1 風險分析團隊

風險分析團隊的成員是任何來自組織機構關鍵領域的關鍵人員,如管理人員、應用程序編程人員、IT人員、系統整合人員或運營部經理等,團隊還必須要包括瞭解各個部門工作流程的人。

2.7.2 信息和資產的價值

信息的價值決定了所要採取的安全舉措。

2.7.3 構成價值的成本

在爲資產定價時,應考慮下面的方面:

  1. 獲取或開發該資產的成本
  2. 維護和保護該資產的成本
  3. 該資產對所有者和用戶具有的價值
  4. 該資產對競爭對手具有的價值
  5. 其他人爲購買該資產願意付出的價值
  6. 在損失的情況下更換該資產所需的費用
  7. 在該資產不可用的情況下損失的運作和生產能力
  8. 該資產貶值的債務問題
  9. 該資產在組織結構中的用處和角色

2.7.4 識別脆弱性和威脅

風險:威脅主體利用脆弱性對資產造成傷害的可能性以及導致的業務影響
在這裏插入圖片描述
延時損失:次生災害,發生在脆弱性被利用之後。延時損失包括公司聲譽受損、市場份額減少、延時處罰增加、民事訴訟和從客戶手中回籠資金出現延遲等。

2.7.5 風險評估方法

核心組件:識別脆弱性,分析威脅,計算風險值
風險評估方法一:信息技術體系風險管理指南 NIST800-30
NIST開發了一套風險方法,叫信息技術體系風險管理指南(Risk Management Guide for Information Technology System),專門針對IT威脅及其信息安全風險的關聯方法。步驟如下:

  1. 系統特徵描述
  2. 威脅識別
  3. 脆弱性識別
  4. 控制分析
  5. 可能性確定
  6. 影響分析:完整性,可用性,機密性損失
  7. 風險確定
  8. 控制建議
  9. 結果記錄
    在這裏插入圖片描述

風險評估方法二:便利的風險分析過程 FRAP
FRAP:Faciliated Risk Analysis Process
核心是隻關注那些的確需要評估以降低成本和時間的系統。
目的是把評估控制在小範圍內,簡化評估流程,提高效率和降低成本。

風險評估方法三:操作性關鍵威脅、資產和脆弱性評估 OCTAVE
OCTAVE:Operationally Critical Threat,Asset,and Vulnerability Evaluation
評估所有系統、應用程序和組織內的業務流程

風險評估方法四:AS/NZS 4360
用於瞭解公司的財務、資本、人員安全和業務決策風險。
商業的角度而不是安全的角度來關注公司的健康狀況。

風險評估方法五:ISO/IEC27000系列
可以集成到安全計劃中,側重IT和較軟的安全問題(文檔、人員安全和培訓等)

風險評估方法六:失效模式和影響分析 FMEA
FMEA:Failure Modes and Effect Analysis,是一種確定功能、標識功能失效並通過結構化的過程評估失效原因和失效影響的方法。
目標是標識出最容易出現故障的環節,之後修復故障或者採取措施降低故障影響。

風險評估方法七:故障樹
風險評估方法六在查找多個系統或子系統中存在複雜失效模式方面有所欠缺。在這種情況下,故障樹分析方法更有用。
繪製故障樹時,必須準確列出一個系統中可能出現的所有威脅或故障。

風險評估方法八:中央計算和電信機構風險分析與管理方法 CRAMM
CRAMM:Central Computing and Telecommunication Agency Risk Analysis and Management Method
該方法分爲三個階段:定義目標,評估風險和標識對策
每一樣都是自動化工具格式,包括問券,資產依賴建模,評估公式和合規報告。

以上八種風險評估方法各自具有獨特的方法和關注點。
如果要在全組織範圍內部署風險管理程序並將它集成到安全計劃中,用ISO/IEC 27005或OCTAVE;
如果需要在評估過程中重點關注IT安全風險,用NIST800-30;
如果預算有限,但需要重點評估一個單獨的系統或進程,用FRAP;
如果想深入瞭解具體某一系統內的安全缺陷是如何產生衍生效應的,用FMEA或者故障樹;
如果需要了解所有在公司的商業風險,用AS/NZS 4360

風險評估過程:

  1. 制定風險管理政策
  2. 組建風險管理團隊
  3. 標識公司待評估的資產
  4. 計算每個資產的價值
  5. 標識能夠影響已確定資產的脆弱性和威脅
  6. 選擇最適合需要的風險評估方法

在這裏插入圖片描述

2.7.6 風險分析方法

定量/定性
定量:

  1. 自動風險分析方法
    脆弱性評估≠風險評估,脆弱性評估是找出脆弱性,風險評估是計算脆弱性被利用的可能性以及產生的業務影響。
  2. 風險分析的步驟
    單一損失期望(single loss expectancy,SLE)
    年度損失期望(annual loss expectancy,ALE)
    ***SLE是爲某個事件賦予的貨幣價值,表示特定威脅發生時的公交公司潛在的損失。
    資產價值
    暴露因子=SLE
    暴露因子(Exposure Factor,EF):某種特殊資產被已發生的風險損壞所造成的損失的百分比。如倉庫資產價值15萬美元,火災後約25%的價值遭到破壞,SLE就是15萬
    25%=37500美元
    SLE
    年發生比率=ALE
    年發生比率(Annual occurrence ratio,ARO):一年內發生特定威脅的預計頻率
    在這裏插入圖片描述
  3. 風險分析的結果
  • 賦予資產的貨幣價值
  • 所有可能威脅和重要威脅的綜合列表
  • 每種威脅的發生概率
  • 12個月時間內公司在每種威脅下能夠承受的潛在損失
  • 建議的防護措施、對策和行動

2.7.7 定性風險分析

定性分析技術包括判斷、最佳實踐、直覺和經驗。
收集數據的定性技術示例有Delphi、集體討論、情節串聯、焦點羣體、調查、問卷、檢查表、單獨會談以及採訪。

定量與定性的對比
在這裏插入圖片描述

定性缺點:

  • 評估方法及結果相對主觀
  • 無法爲成本/收益分析建立貨幣價值
  • 使用直觀衡量很難跟蹤風險管理目標
  • 沒有對應的標準,每個供應商解釋其評估過程和結果的方式各不相同
    定量缺點:
  • 計算複雜,不利於管理層理解
  • 沒有可供利用的自動化工具,這個過程完全需要手動完成
  • 需要做大量基礎性的工作,以收集與環境相關的詳細信息
  • 沒有對應的標準,每個供應商解釋其評估過程和結果的方式各不相同

定性和定量結合使用時最好的,定量用於有形資產,定性用於無形資產。

2.7.8 保護機制

確定現行的安全機制並評估其有效性。
如何爲計算機系統識別和選擇正確的對策, 以及在比較各種不同的軟件對策時,如何找出所需的最佳特徵和進行調查的所有成本概述。

  1. 對策的選擇
    好的對策一定是收益大於成本的,對於給定的防護措施所使用的成本/收益計算公式:ALE是年度損失期望
    實現防護措施前的ALE-實現防護措施後的ALE-防護措施每年的成本=防護措施對公司的價值

對策的成本包括:
產品成本,設計/規劃成本,實現成本,環境更改,與其他對策的兼容性,維護需求,測試需求,修復替換或更新成本,運行 和支持成本,對工作效率的影響,預訂成本,監控和響應警報所需的額外人工成本,解決這款新工具帶來的問題的成本。

  1. 對策的功能和有效性
    在購買防護措施之前,需要考慮一些特徵,如默認最小權限、防護措施及其保護的資產相互獨立、最少的人爲干預、審計功能、最小化對其他組件的依賴…

2.7.9 綜合考慮

  1. 確定必須保護的資產及保護的程度,說明保護資產所需的金額
  2. 評估可用保護措施的功能,確定哪些保護措施對環境最有利
  3. 評估各種保護措施的成本進行比較

2.7.10 總風險和剩餘風險

剩餘風險:沒有百分之百安全的系統和環境,我們漏掉的一些需要預防的風險,就是剩餘風險。
總風險:公司在不實現任何防護措施的情況下所面臨的風險。

定期重新評估風險可以確定防護措施的效果。

總風險=威脅x脆弱性x資產價值
剩餘風險=(威脅x脆弱性x資產價值)x控制間隙

總風險-對策=剩餘風險

2.7.11 處理風險

處理風險的4種方式:轉移、規避、緩解、接受
轉移:通過多種保險來保護資產,買保險
規避:終止引入風險的活動,如停止IM服務
緩解:風險被降低至可接受的級別,如安裝防火牆、培訓、部署入侵/檢測保護系統
接受:在成本/收益率表明採取對策的成本超出潛在的損失價值時,接受風險

2.7.12 外包

可以外包功能,但不能外包風險,出現數據泄露這類事情,公司還要擔責。
公司在外包業務時爲降低風險可以做的事:

  • 進行現場檢查和採訪
  • 審覈合同以確保就安全和保護級別達成的一致意見
  • 簽署保密協議
  • 等等

2.8 策略、標準、基準、指南和過程

2.8.1 安全策略

安全策略是高級管理層制定的全面聲明,規定安全在組織機構內扮演的角色。

  • 組織化的策略
  • 針對特定問題的策略/針對系統的策略
    策略的種類:規章性策略,建議性策略,指示性策略

2.8.2 標準

標準指強制性的活動、動作或規則,它可以爲策略提供方向上的支持和實施。
戰術目標是達到終極目標所需要的步驟,戰略目標是終極目標。
標準、指南和措施是戰術目標,用於達到和支持安全策略中的指示,安全策略是戰略目標。

2.8.3 基準

基準可以指一個在將來變更時進行比較的時間點,也可以用於定義所需要的最低保護級別。
組織機構內應該有面向技術和非面向技術的基準。

2.8.4 指南

沒有標準時向用戶、IT人員、運營人員及其他人員提供的建議性動作和操作指導。
指南能夠處理技術、人員和物理安全方面的各種方法。

2.8.5 措施

措施是爲了達到特定目標而應當執行的詳細的、分步驟的任務。
措施說明了如何將策略、標準和指南應用到實際操作環境中。

2.8.6 實施

將安全策略、標準、措施、基準和指南寫入文檔
安全意識培訓、手冊、報告、新聞簡訊以及法律標語等

2.9 信息分類

數據分類的目的是說明需要爲每種數據集設定的機密性、完整性和可用性保護級別。
數據分類有助於保證以成本最爲低廉的方式保護數據。

2.9.1 分類級別

商業公司的信息敏感級別:機密,隱私,敏感,公開
軍事機構的信息敏感級別:絕密,祕密,機密,敏感但未分類,未分類

組織機構可能用於決定信息敏感度的一些準則參數:
數據的用途,價值,壽命
數據泄露可能導致的損失級別
數據被修改或出現訛誤可能導致的損失級別
保護數據的法律法規或合約責任
數據對安全的影響
誰能夠訪問這些數據
由誰維護這些數據
誰能夠重造這些數據
如果數據不可用或者訛誤那麼造成的機會損失有多少

數據,應用系統,以及整個系統都需要分類。

2.9.2 分類控制

  • 對敏感數據和計劃採用嚴格而細粒化的訪問控制
  • 對存儲和傳輸中的數據加密
  • 審計和監控
  • 責任分離
  • 定期審查
  • 備份與恢復措施(定義與文檔化)
  • 變更控制措施(定義與文檔化)
  • 物理安全保護(定義與文檔化)
  • 信息流通道
  • 數據字典審查
  • 正確的處理動作,如粉碎,消磁等(定義與文檔化)
  • 標記,標籤和處理步驟

2.10 責任分層

出了錯,誰負責?

2.10.1 董事會

董事會由企業股東選出的一組人員組成,負責監督企業憲章的執行情況。
成立董事會是爲了確保股東的利益得到保護,並且企業能夠平穩運行。董事會成員應該是沒有偏見的獨立個人,他們負責監督行政人員在管理方面的表現。

SOX法案規定,如果公司不能適當維護內部的企業治理架構,並且(或者)公司向SEC上報的財務報表存在錯誤,那麼董事會成員可能要承擔個人責任,甚至判罰或入獄。

2.10.2 執行管理層

執行管理層由頭銜以字母C開頭的人組成。
CEO:首席執行官,負責組織機構的日常管理工作,通常由董事會主席擔任,是公司內地位最高的人
CFO:首席財務官,負責公司的賬目和財務活動以及組織機構的的總體財務結構

2.10.3 CIO 首席信息官

負責機構內部信息系統和技術的戰略使用與管理
CIO既要涉足技術管理,又要參與業務運營

2.10.4 CPO 首席隱私官

負責確保客戶,公司和僱員數據的安全
通常由律師擔任,並直接參與有關數據收集,保護和數據交付給第三方的策略制定
CPO一般像CSO提交報告

2.10.5 CSO 首席安全官

負責瞭解公司面臨的風險和將這些風險緩解至可接受的級別,確保業務不會因爲安全問題而出現任何形式的中斷。
這個角色的設立是安全行業取得勝利的標誌,這意味着安全被視爲一種業務能力

隱私 安全
隱私:一個人應該能夠擁有和認爲自己擁有的自身敏感信息的控制權
安全:用來提供控制權的機制
PII:個人身份信息,個人信息的綜合,包括姓名地址電話和賬戶號碼等
組織機構必須制定隱私策略和控制措施來保護員工和客戶的PII

CSO CISO
CISO:更關注技術問題,且有IT背景,向CSO彙報
CSO:需要更深入的理解業務風險,包括物理安全

2.11 安全指導委員會

由來自組織機構各部門的人員組成,CEO領導,同時CFO,CIO,各部門經理和首席內部審計員都參與其中。

安全指導委員會的職責:

  • 定義組織機構的可接受風險級別
  • 確定安全目標和戰略
  • 根據業務需求決定安全活動的優先級別
  • 審查風險評估和審計報告
  • 監控安全風險的業務影響
  • 審查重大的安全違規和事故
  • 批准安全策略和計劃的任何重要變更

2.11.1 審計委員會

董事會任命,以幫助其審查和評估公司的內部運作,內部審計系統以及財務報表的透明度和準確性

2.11.2 數據所有者

決定其負責的數據的分類,確保實施必要的安全控制,定義每種分類的安全需求和備份需求,批准任何泄露活動,保證應用適當的訪問權限,定義用戶訪問準則。
處理與其所負責數據有關的安全違規行爲,以對數據進行保護。
可以將數據保護機制的日常維護工作委託給數據看管員。

2.11.3 數據看管員

也稱信息看管員,負責數據的保護和維護工作,通常由IT或安全部門員工擔任
負責實施和維護安全控制措施,執行數據的常規備份,定期驗證數據的完整性,從備份介質還原數據,保存活動記錄,以及實現公司關於信息安全和數據保護的信息安全策略,標準和指南所指定的需求。

2.11.4 系統所有者

負責將安全因素集成到應用程序和系統購置決策及項目開發中。
通過必要的控制,密碼管理,遠程訪問控制,操作系統配置等措施保證足夠的安全。
確保系統的脆弱得到正確評估。

2.11.5 安全管理員

負責實施和維護企業內具體的安全網絡設備和軟件。
常用的控制措施:防火牆,IDS,IPS,反惡意軟件,安全代理,數據損失防禦等

安全管理員 網絡管理員
安全管理員側重維護網絡的安全,網絡管理員側重網絡的更新和運行。

2.11.6 安全分析員

幫助制定策略,標準和指南,並設立各種基準。這個角色的工作主要在設計層面,而非實現層面。

2.11.7 應用程序所有者

某些應用程序專門爲單獨的業務部門設計,如財務部門使用財務系統。
應用程序所有者往往是業務部門經理,負責規定哪些人有權訪問他們的應用程序,並保應用程序的安全,包括測試,修補,執行計劃變更控制。

2.11.8 監督員

也稱業務經理,負責所有用戶活動以及這些用戶建立並擁有的資產。
需要及時向安全管理員通報角色的變化信息。

2.11.9 變更控制分析員

負責批准或否決變更網絡,系統或軟件的請求。

2.11.10 數據分析員

負責保證公司以最佳方式存儲數據,還可能負責構造一個保存公司信息的新系統。
數據分析員與數據所有者合作,幫助保證建立的數據結構符合並支持公司的業務目標。

2.11.11 過程所有者

安全不是一款產品,而是一個過程
負責正確定義,改進並監控過程

2.11.12 解決方案提供商

公司遇到問題或需要改進某個過程時,向解決方案提供商尋求幫助。

2.11.13 用戶

用戶必須擁有必要的數據訪問級別,有義務遵守操作安全措施,從而保證數據對其他人的機密性,可用性和完整性。

2.11.14 生產線經理

這個角色必須瞭解業務推動力,業務過程以及支持兩者所需的技術。
需要評估市場上的各種產品,與供應商合作,向管理層和各業務部門提出滿足其目標的解決方案購置建議。

2.11.15 審計員

審計員的目標是確保組織機構遵循了自己指定的策略和適用的法律法規。
組織可以有內部審計員和外部審計員,外部審計員代表法律機構,確保組織符合法規要求。

2.11.16 爲何需要這麼多角色

主要是要構建一個組織結構,包含所有必要的角色並給這些角色分配正確的安全職責

2.11.17 人員安全

聘請有資歷的人,進行背景調查,使用詳細的崗位說明,提供必要的培訓,實施嚴格的訪問控制,以及在辭退人員時保護各方利益

職責分離:預防性的管理控制,確保一個人不能單獨開展某項活動,知識分割或雙重控制
合謀:兩個或兩個以上的人一起工作,聯合開展欺詐活動
崗位輪換:檢測性的管理控制,在金融機構中普遍採用
強制休假:檢測性的管理控制,要求一個人離開組織一段時間以發現潛在的欺詐活動

2.11.18 招聘實踐

簽訂保密協議,背景調查

2.11.19 解僱

公司應當制定一組特定的措施來管理每種解僱事件,如在保安或經理的監督下立即離開公司等

2.11.20 安全意識培訓

目的:讓每名僱員都瞭解安全對於公司和個人的重要性,必須闡明期望的責任和可接受的行爲,修正員工對安全的錯誤行爲和態度。
受衆:管理層,職員,技術人員

2.11.21 學位或證書

在這裏插入圖片描述

2.12 安全治理

安全治理是一個框架,允許組織的安全目標由高級管理人員設置並傳達,通過在組織不同層面交流傳達,授予需要實施和加強安全措施的實體權限,並提供一種方法來驗證這些必要的安全活動的執行。

信息安全不只是技術解決方案,而是必須貫穿於整個組織,需要在多點設立職責說明和問責方法。
安全治理是一個將安全集成到過程中的條理分明的系統,有助於一致性的監督,問責制和合規性。

度量
需要一種方法來評估工作的有效性
度量結果可能是熱度圖,曲線圖,餅狀圖或記分卡。平衡記分卡是一個傳統的戰略工具,用於在商業界的績效考覈。
在這裏插入圖片描述

2.13 小結

安全計劃應從戰略,戰術,操作角度來解決各種問題。
在這裏插入圖片描述

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章