心智圖資源庫 CISSP-6-安全評估與測試
CISSP-資訊系統安全專業認證之安全評估與測試心智圖,主要內容有基本概念、評估與測試策略、收集安全流程資料、內部及第三方稽核、稽核管理控制。
編輯於2021-11-10 12:04:23Microbiologia medica, Infezioni batteriche e immunità riassume e organizza i punti di conoscenza per aiutare gli studenti a comprendere e ricordare. Studia in modo più efficiente!
La teoria cinetica dei gas rivela la natura microscopica dei fenomeni termici macroscopici e le leggi dei gas trovando la relazione tra quantità macroscopiche e quantità microscopiche. Dal punto di vista del movimento molecolare, vengono utilizzati metodi statistici per studiare le proprietà macroscopiche e modificare i modelli di movimento termico delle molecole di gas.
Este é um mapa mental sobre uma breve história do tempo. "Uma Breve História do Tempo" é um trabalho científico popular com influência de longo alcance. Ele não apenas introduz os conceitos básicos da cosmologia e da relatividade, mas também discute os buracos negros e a expansão. Do universo. questões científicas de ponta, como inflação e teoria das cordas.
Microbiologia medica, Infezioni batteriche e immunità riassume e organizza i punti di conoscenza per aiutare gli studenti a comprendere e ricordare. Studia in modo più efficiente!
La teoria cinetica dei gas rivela la natura microscopica dei fenomeni termici macroscopici e le leggi dei gas trovando la relazione tra quantità macroscopiche e quantità microscopiche. Dal punto di vista del movimento molecolare, vengono utilizzati metodi statistici per studiare le proprietà macroscopiche e modificare i modelli di movimento termico delle molecole di gas.
Este é um mapa mental sobre uma breve história do tempo. "Uma Breve História do Tempo" é um trabalho científico popular com influência de longo alcance. Ele não apenas introduz os conceitos básicos da cosmologia e da relatividade, mas também discute os buracos negros e a expansão. Do universo. questões científicas de ponta, como inflação e teoria das cordas.
安全評估和測試
基本概念
安全評估和測試
安全評估和測試包含廣泛的現行和基於時間點的測試方法用於確定脆弱性及其相關風險。
T&E的基本目標
T&E能衡量系統與能力發展進展
T&E的專長就是中對系統生命週期在開發過程提供系統強度與弱點的初期認知
為協助在開發、生產、營運和維護系統能力過程中的風險管理提供相應的知識。
能夠在部署系統之前識別技術的、操作的和系統缺陷以便開發適當的及時的糾正行為。
T&E策略
測試和評估策略的內容是具有應用於獲取/開發流程、所提供的能力要求以及技術驅動所需能力的功能。
傾向於
管理風險所需認知
驗證模型和模擬的經驗數據
技術性能和系統成熟度的測試
運維效能、適應性和生存能力的確定
目標
識別、管理和降低風險
評估與測驗策略 Assessment and Test Strategies
T&E策略
策略的作用
管理風險所需認知
驗證模型和模擬的經驗數據
技術性能和系統成熟度的測試
運維效能、適應性和生存能力的決定。
系統工程師與安全專家
與主辦單位一塊建立或評估用於支援程序獲取/開發的T&E策略;
提供能深度管理風險的T&E的方法;
監控T&E流程以及可能需要的變更;
評估測試計劃和程序是否適用於開發測試或執行測試,並提供建議;
進一步被希望理解獲取/開發程序的背後的理由以用於建立和執行T&E策略;
期望理解T&E測試的具體活動,如互通性測試;
企業需要建立工作小組
這個小組通常被稱為T&E整合產品團隊,由T&E專家、客戶用戶代表和其他利害關係人組成;
T&E策略是活動文檔,該小組負責在需要時進行更新;
該小組需要確保T&E流程包含獲取策略以及系統滿足基於用於能力的操作要求;
日誌評審
日誌與電腦安全有關
如路由日誌分析有利於識別安全事故、策略違反、詐欺行為和操作問題等。
日誌作用
執行審計和取證調查;
支持內部調查;
建立基線;
識別運作趨勢以及發現長期問題;
挑戰
需要平衡有限的日誌管理資源和持續產生的日誌數據
日誌的生產和存儲
不同的日誌來源
不一致的日誌內容、格式以及時間戳記等
日誌資料的大量生成
需要保護日誌的完整性、機密性和可用性
確保安全性、系統和網路管理員定期有效的分析日誌資料。
日誌管理的方針和程序
定義日誌需求和目標
開發清晰定義日誌管理活動的強制要求和建議要求
包括日誌的產生、傳遞、儲存、分析和廢棄
整合和支援日誌管理要求和推薦
管理層應提供必要的支持
日誌需求和建議應與實施和維護日誌所需的資源和細節分析技術一塊生成
原始日誌的保護
將網路流量日誌的拷貝傳送到中心設備
優化日誌管理Prioritize Log Management
優化日誌和需求,基於組織風險減少的感知以及執行日誌管理所需資源和預期的時間。
建立日誌管理的職責和角色
建立和維護日誌管理架構
日誌管理架構包含硬體、軟體、網路和媒體用於產生、傳輸、儲存、分析和處置日誌。
設計日誌管理框架時應考慮管理框架現在和未來的需求以及整個組織的獨立日誌來源。
集中式日誌伺服器和日誌資料存儲
需要處理的日誌資料量,
網路頻寬,
線上和離線資料存儲
資料的安全要求
員工分析日誌所需的時間和資源
為所有員工的日誌管理職責提供適當支持
系統的管理員應獲得足夠的支援;
包括資訊傳播、提供訓練、提供問題解答的聯絡點、 提供具體的技術指南、提供相應的工具和文件等。
標準日誌管理流程
日誌管理員職責
監控日誌狀態
監控日誌輪替與歸檔流程
檢查日誌系統補丁,取得、測試及部署補丁
確保日誌來源系統保持時鐘同步
當策略或技術變更時,必要的話,重新配置日誌
記錄和報告日誌異常
確保日誌整合存儲,例如安全資訊和事件管理系統(SIEM)
日誌管理流程
配置日誌來源、執行日誌分析、 啟動對識別的認知的回應和管理日誌的長期儲存。
日誌來源
網路和基於主機的軟體
防毒軟體
IDS和IPS系統
遠端存取軟體
Web代理
漏洞管理軟體
驗證伺服器
路由器
防火牆
網路存取控制 (NAC)/網路存取保護 (NAP) 伺服器
作業系統事件和審計記錄
基於應用
客戶端請求和伺服器回應
帳號資訊
使用資訊
重要的操作活動
挑戰
日誌的分佈屬性、日誌格式的不一致以及日誌的容量都構成日誌管理的挑戰
必須保護日誌的完整性、機密性和可用性
組織還需要保護其日誌的可用性。
存檔日誌的機密性和完整性也需要保護。
系統和網路管理員
需要分析日誌
無法有效進行日誌分析
沒有收到良好的培訓
沒有工具支撐
日誌分析常常是響應型的 reactive
許多日誌分析需要即時或近乎即時的
關鍵實踐
在全組織適當的最佳化日誌管理
監理日誌管理策略和程序
建立和維護安全日誌管理基礎設施
為所有員工的日誌管理提供適當的支持
合成交易 (Synthetic Transactions) Vs. 真實交易 (Real Transactions)
真實使用者監控RUM
Web監控方法,旨在擷取或分析Web或應用程式上每個使用者的每筆交易
又稱real-user measurement真實使用者測量, real-user metrics真實使用者指標, or end-user experience monitoring (EUM)最終使用者體驗監控
passive monitoring被動監控的方式
依賴Web監控服務持續取得系統活動,追蹤其可用性、功能和敏感度。
監控模式
由下而上 bottom-up forms
為重新重構使用者體驗而擷取服務端資訊;
由上而下 top-down client-side RUM
客戶端RUM,能直接看到使用者如何與應用程式互動及其體驗方式
專注於網站速度和使用者的滿意度,提供關於優化應用元件和提升所有的效能的深入視角。
合成交易
proactive monitoring 主動或預先回應監控的方式
包含使用外部代理(agent)運行腳本交易的方式而不是Web應用。
這些腳本依照典型使用者體驗,如使用者搜尋、查看產品、登入和付款等方式來評估使用者體驗。
綜合監控是輕量級和低水平的代理方式,但很Web瀏覽器有必要運行發生在頁面上處理JavaScript, CSS, and AJAX呼叫。
並不追蹤真實的使用者會話
在一個已知的位置以固定的時間間隔執行一組已知的步驟,其性能是可預測的。 比RUM更適合評估網站可用性和網路問題。
Selenium
http://docs.seleniumhq.org
客戶端完全可控 full control over the client
不像沙盒JAVA腳本方式驅動的RUM,細節的獲得可以更客觀
微軟系統中心操作管理軟體
Web站點監控
資料庫監控
TCP 連接埠監控
提升價值
7x24 系統可用性監控 Monitor application availability 24 x 7.
了解遠端站點是否可達
瞭解第三方服務對業務應用系統造成的效能影響
監控SaaS應用的效能和可用性
測試使用SOAP、REST或其他Web服務的 B2B Web站點
監控關鍵資料庫的可用性
衡量服務等級協定(SLAs)
在低業務流量時段作為真實使用者監控的補償
建立效能基線,進行效能趨勢分析
程式碼評審和測試
導致漏洞的常見原因 vulnerabilities are caused
不恰當的程式設計模式,如缺少檢查影響使用者的數據,SQL注入(輸入驗證)
安全基礎架構的誤配:存取控制權限過大或脆弱的加密配置;
安全基礎設施的功能錯誤:存取控制強制設施本身不限制系統的存取;
實施流程的邏輯錯誤:例如使用者下訂單而不用支付
常見軟體漏洞 Common Software Vulnerabilities
Top 25
■ 不安全的元件互動(Insecure Interaction between Components)
■ 有風險的資源管理(Risky Resource Management )
■ 漏洞百出的防禦(Porous Defenses)
測試技術 testing techniques
白盒(結構性測試/開箱測試) vs. 黑盒測試(功能性測試/閉箱測試)
動態測試 VS. 靜態測試 Dynamic Testing vs. Static Testing
手工 vs. 自動化 Manual Testing vs. Automated Testing
安全測試考慮 security testing considering
攻擊面
應用程式類型
品質
支援技術
效能和資源利用率
規劃與設計階段 During Planning and Design
架構安全評審
先決條件:架構模型
優點:驗證架構偏離安全標準
威脅建模 Threat Modeling -
先決條件:業務用例或使用場景
識別威脅、及其影響以及具體到軟體產品開發過程中的潛在控制措施。
STRIDE 模型
應用開發階段 During Application Development
Static Source Code Analysis (SAST) and Manual Code Review(靜態程式碼分析與手動程式碼評審)
為尋找弱點而不執行應用程式而分析應用程式碼。
先決條件:應用原始碼
優點:偵測不安全的程式設計、過時的程式碼庫以及錯誤配置
Static Binary Code Analysis and Manual Binary Review(靜態二進位程式碼分析和手工二進位審查)
對已編譯的應用進行分析來發現弱點,並不執行應用。
不精確且不提供修復建議。
在測試環境中可執行 Executable in a Test Environment
手動或自動化滲透測試
像攻擊者一樣發送資料並發現其行為。
優點:在部署的應用上識別大量的弱點;
自動化漏洞掃描
測試使用已知不安全的系統組件或配置的應用。
設定預攻擊模式,分析系統指紋。
優點:檢測已知漏洞
Fuzz Testing Tools 模糊測試工具
優點:檢測至關重要的應用程式的崩潰(例如,由緩衝區溢位引起的)。
發送隨機資料(常常遠比應用程式所期望的更大區塊) 到應用程式輸入管道來造成應用程式的崩潰。
系統運作和維護中的測試
軟體測試特點
建議使用被動安全測試技術監測系統行為和分析系統日誌
軟體維護過程中,補丁的測試非常重要
修補程式需要進行徹底的安全測試
軟體測試有其限制,不可能100%測試完成
測試了所有程式功能和所有程式碼並不代表程式就是100%正確的!
測試計劃和測試案例應盡可能早的在軟體開發階段進行開發
程式碼層級的測試 Code-based testing
軟體的安全測試一般起始於單元層級的測試和結束於系統層級測試
結構化測試 (「白盒」測試) 開箱測試
結構化測試主要是放在模組層級的測試;
結構化測試等級可以用被測試的軟體結構的百分比來作為指標來衡量;
測試案例基於從原始程式碼、細節設計規格說明和其他開發文件中獲得的知識;
Common structural coverage 測試覆蓋率(適用於白盒)
Statement Coverage 語句覆蓋率
Decision (Branch) Coverage 判斷覆蓋率
Condition Coverage 條件覆蓋率,
Multi-Condition Coverage 多條件覆蓋率
Loop Coverage 循環覆蓋率
Path Coverage 路徑覆蓋率
Data Flow Coverage 資料流覆蓋率
功能性測試或“黑盒”測試/閉箱測試 (functional testing or blackbox testing)
測試案例是基於軟體產品具體要做什麼來定義的;
測試案例的主要挑戰是預期用途和程序功能以及程式的內部和外部介面;
功能性測試應用於任意等級的軟體測試,從單元測試到系統層級的測試
軟體功能測試 functional software testing
Normal Case 普通用例
Output Forcing 輸出需求,
Robustness 穩健性
Combinations of Inputs 輸入組合
weakness 弱點
很難將結構化和功能化測試的完成標準與軟體產品的可靠性連結起來;
統計測試方法 statistical testing
提供高結構化覆蓋率
從基於運行環境(軟體產品的預期使用、危險使用或惡意使用)定義的分佈來產生隨機資料;
產生大量測試數據並用於覆蓋到特別領域或所關注的地方,提供增加識別單一和極其罕見的運行狀況的可能性,這些運行狀況沒有被設計者和測試人員所預測;
軟體變更測試
原因
調試發現的問題並進行修正;
新的或變化的需求;
發現設計的修改能更有效率或有效實施;
目的
變更已正確實施
未對其他部分造成不利影響
迴歸分析和測試
迴歸分析:確定變更的影響,基於相關文檔 (軟體規格說明、設計規格、原始碼等)的評審, 也是為識別運用必要的迴歸測試;
回歸測試:運用之前程式執行正確的測試案例, 比對現有結果和先前的結果發現軟體變化的非預期結果。
嚴格和完整的測試 (V字模型)
Unit (module or component) level testing 單元測試
Integration level testing 整合測試(測模組之間的介面)
由上而下(Top-Down)
由下而上 (Bottom-Up)
三明治方法
System level testing 系統測試
安全性和隱私(例如,加密功能、安全日誌報告)
效能問題(例如,反應時間、可靠性測量)
壓力情況下的反應(例如,最大負荷下的表現)
內部外部安全特性的操作
恢復步驟的有效性
可用性 Usability;
不同配置下的表現
文件的準確性
與其他軟體的兼容性
驗收測試
UAT(使用者驗收測試)
QAT(品質保證測試)
測試注意事項
系統測試將呈現在特定環境中軟體產品的行為;
測試程序、測試數據和測試結果應以獲得允許通過/失敗決策的方式記錄;
企業的軟體產品是複雜的,軟體產品的測試需要保持一致性、完整性和有效性;
軟體維護任務和硬體維護不一樣,硬體有預防性維護措施而軟體沒有;
需要有效驗證變更
其他的維護任務
Software Validation Plan Revision軟體驗證計畫修訂,
Anomaly Evaluation異常驗證,
Problem Identification and Resolution Tracking 問題識別和解決跟踪,
Proposed Change Assessment 請求變更評估
Task Iteration 任務迭代,
Documentation Updating 文件更新
用例和誤用例
用例 Use cases
站在正常使用者使用系統的角度的測試案例
誤用例 misuse case:
來自對系統懷有惡意的人員視角的用例。
正向測試方法 Positive testing
確定應用程式按照所預期的方式進行工作,如果在正向測試中發現錯誤則失敗
負向檢定 Negative testing
確保應用程式可以妥善處理無效輸入或非預期使用者行為。
介面測試(interface test)
目的
主要檢查應用或系統開發的不同組件彼此是否同步;
從技術層面接口測試主要用於確定不同功能諸如 資料在系統的不同元素中是否依照設計進行傳輸。
用於確保軟體的品質
滲透測試
應所有者的要求模擬攻擊一個網路及其係統的過程
滲透測試類型屈居於組織機構、它的安全目標和管理階層的目標
滲透測試報告應該提交給管理層
應簽署授權測試範圍的授權書(需要管理階層的書面的授權)
步驟
發現,收集目標的相關資訊(discovery)
發現作業系統的版本 CentOS 5.1
dig
DNS footprinting 工具,發現階段收集信息
枚舉,執行連接埠掃描和資源標識方法
nbtstat 屬於 enumeration, 是在列舉階段,不是在發現階段
脆弱性勘探,在確定的系統和資源中標識脆弱性
脆弱性測試分類
人為脆弱性
物理脆弱性
系統和網路脆弱性
利用,嘗試利用脆弱性進行未授權訪問
向管理階層報告,想管理階層提交報告和安全建議
分類
黑盒測試,零了解,滲透團隊在不了了解測試目標的情況下測試
灰盒測試,在了解一些與測試目標相關的資訊上測試
白盒測試,了解目標的本質的基礎上測試
滲透性測試團隊分類
0知識
對目標一無所知
部分知識
知道目標的部分知識
全部知識
完全了解目標的情況
舉例 :戰爭撥號
從一系列電話號碼中撥號尋找可用的數據機
有些組織仍然使用調變解調器用於通訊備用
戰爭撥號是一種旨在避開防火牆和入侵偵測系統(IDS)侵入組織網路的形式
戰爭撥號攻擊包括透過撥入存取試圖獲得組織的內部運算和網路資源存取權, 這給了駭客入侵便利性。
自我測試
管理員以戰爭撥號法測試組織內 未經授權安裝的數據機, 對組織中隨意安裝者進行再教育。
其他脆弱性類型
Kernel flaws 內核漏洞
內核層存在漏洞
對策:確保安全修補程式到作業系統足夠的測試後,及時部署在環境中保持盡可能小的漏洞視窗。
Buffer overflows緩衝區溢出
對策:良好的程式設計實踐和開發教育,自動掃描器的源代碼, 增強程式庫,採用強語言類型不允許緩衝區溢出
Symbolic links 符號鏈接
駭客重新定向符號鏈接,從而達到非授權訪問的目的。
對策:在編寫程式(尤其是腳本)時,無法規避文件的完整路徑
File descriptor attacks 文件描述攻擊
檔案描述符是許多作業系統用來表示進程中開啟檔案的數字.某些檔案描述符數是通用的,對所有程式都有相同的意義。
如果程式不安全地使用檔案描述符,可能會導致攻擊者利用程式特權將意外的輸入提供給程序,或導致輸出到意外的地方
對策:良好的程式設計實踐和開發教育,自動化原始碼掃描器和應用程式安全測試都是減少這種類型的漏洞的方法。
Race conditions 竟態條件 (多進程和多執行緒環境下)
在執行程序前未消除環境的脆弱性因素
會導致攻擊者讀取或寫入意外資料或執行未經授權的命令
對策:良好的程式設計實踐和開發教育,自動化原始碼掃描器和應用程式安全測試
父行程建立子行程要專注於競態條件和最小授權
File and directory permissions 檔案和目錄權限
不適當的文件或目錄權限
對策:檔案完整性檢查,也應檢查預期的檔案和目錄的權限
收集安全流程資料 Collect Security Process Data
Information security continuous monitoring(ISCM)資訊安全持續監控
ISCM
用於定義現行資訊安全、漏洞和危險的意識用於支持組織資訊安全風險決策;
用於支援跨組織的資訊安全監控的任何努力和流程必須開始與高階領導定義的複雜ISCM策略;
ISCM策略
是建立在清晰理解組織風險容忍度並幫助企業設定優先順序和管理整個組織的風險一致性;
包含度量指標來提供在所有組織層面的安全狀態的真實意義;
確保所有安全控制的持續有效;
驗證由組織使命/業務職能、國家法律法規、指南、指南標準所驅動的資訊安全要求的符合性;
所有組織的IT資產都被告知並協助維護資產安全的可見性;
確保組織系統和環境變更的知識和控制;
保持威脅和脆弱性的意識.
NIST SP 800-137
聯邦資訊系統和組織的資訊安全持續監控(ISCM)
特點
ISCM方案的建立收集依據預設測量指標的數據,部分透過已實施的安全控制來利用資訊變更更加容易。
組織範圍的風險監控不能有效的依靠單獨的手動流程或單獨的自動化流程來獲得:
開發ISCM策略流程
基於風險容忍度定義ISCM策略以維護資產的可見性、漏洞的意識、威脅資訊的更新以及使命/業務影響;
建立ISCM方案確定測量指標、狀態監控頻率、控制評估頻率並建立ISCM技術架構;
實施ISCM方案和收集用於測量、評估和報告所需的安全相關資訊。盡可能的自動收集、分析和報告;
分析所有收集的數據並報告發現,確定適當的回應。有必要收集其他資訊來澄清或補充現有監控數據;
透過技術、管理和操作的活動來回應發現,這些活動包括削減活動或接受,轉移/共享,或避免/拒絕等。
評審和更新ISCM方案,調整ISCMC策略和成熟的測量能力來增加資產的可見度和脆弱性意識,更多的啟用組織資訊安全架構並以資料驅動的控制,增加組織的彈性。
測量指標 Metrics
測量指標定義及內容
測量指標包含所有來自評估和監控並由自動化工具以及手動程序所產生的安全相關信息,並組織成有意義的信息來支持決策和報告要求。
測量指標應由維持或改善安全態勢的具體目標所驅動。
測量指標開發系統層級的數據使得使命/業務背景或組織風險管理變得有意義;
測量指標從不同時間獲得的安全相關資訊並帶有不同程度的延遲。
例子examples
測量指標建立原則 NIST SP 800-137
Security Control Volatility安全控制波動
System Categorizations/Impact Levels系統分類/影響的水平
Security Controls or Specific Assessment Objects Providing Critical Functions安全控製或特定評估物件所提供的關鍵功能
Security Controls with Identified Weaknesses已辨識出弱點的安全控制
Organizational Risk Tolerance組織風險容忍度,
Threat Information威脅訊息
Vulnerability Information
Risk Assessment Results風險評估結果
Reporting Requirements通報要求
變更的因素
作為組織風險管理架構 Risk Management Framework (RMF) 的關鍵步驟
提供組織官方按需存取安全相關資訊的能力, 進行及時風險管理決策包括授權決策。
內部和第三方審計(Internal and Third-Party Audits)
審計需求
法律法規需求
如美國聯邦資訊安全法案(FISMA Federal Information Security Management Act)要求聯邦機構每年至少對組織的資訊安全系統進行一次自我審計和獨立的第三方審計;
資訊安全專家需要理解法律標準中所概述的要求以提供保護,但極少做到完全的保護或資訊系統的風險管理;
資訊安全專家必須確保適當的範圍和裁剪為目標系統在正確的層級上獲得適當數量的控制
合規
業務驅動
組織為了集中核心競爭力、減少開支和更快速的部署應用新的應用功能, 不斷將系統、業務流程和資料處理外包給服務提供者;
組織常更新外包服務商的監控流程以及管理與外包的風險;
歷史上,許多組織經常藉鏡Statement on Auditing Standards (SAS) 70 reports 審計準則說明以獲得對外包活動的安慰,然而SAS 70關注財務報告內部控制(ICOFR),而不關注系統可用性和安全。
SAS70報告已在2011退休,取而代之的是SOC(Service Organization Control)報告;
內部稽核(第一方稽核)
組織擁有自己的審計團隊,以實現持續改善您的組織的安全態勢。
優點
他們熟悉組織內部的工作流程。
工作效率高
能夠很準確地找出最有問題的點
可以使審計工作更有靈活,管理階層可不斷變換審計需求讓審計團隊對應調整審計方案
缺點
他們接觸到資訊系統的相對有限
存在利益衝突的可能性,妨礙客觀性。
第三方審計
優點
審計過很多種不同的資訊系統,經驗豐富
他們不知道目標組織內部的動態和政治。將會保持客觀中立
缺點
成本高
你仍然需要處理增加的資源來組織他們並監督他們的工作即使簽了保密協議。
缺乏對組織內部運作的了解。
Statement on Auditing Standards (SAS) 70
specifically on risks related to internal control over financial reporting (ICOFR) 財務報告內部控制
過去,多數組織使用外包服務要求SAS70報告, 但僅從財務角度出發,許多用戶開始關注安全、可用性而後隱私;
SOC 報告
作為SAS70報告的替代,使用SOC報告;
SOC 1報告
與SOC 1/SOC 2報告相反的地方是,SOC1 報告需要服務提供者描述他的系統並定義控制目標和控制,這些與財務報告內部控制有關;
SOC1報告通常不涵蓋那些與使用者ICOFR報告無關的服務和控制。
SOC1報告在2011年開始被許多服務商用於核心財務處理服務;
SOC 2 / SOC 3 報告
Period of time reports covering design and operating effectiveness 一段時間內包含設計和維運有效性的報告
原則和準則具體定義安全性、可用性、機密性、處理完整性和隱私;
提供超越財務報告內部控制(ICOFR);
可以基於服務提供者及其使用者的需求,採用模組化的方式便於 SOC2/SOC3報告能夠涵蓋一個或多個原則;
IT服務提供者沒有影響或存在間接影響到使用者的財務系統,則使用SOC2報告;
SOC3報告一般用於向大範圍使用者通報其保障等級而不需要揭露細部控制和測試結果;
審計管理控制
帳號管理
新增帳號
1.新進員工應閱讀並簽署可接受使用政策 (AUP)
2.透過審計員工帳號,確認員工遵守AUP的情況。
3.從人力資源部門調取新員工清單與IT部門在系統中開設員工帳號進行對照,以確保兩個部門溝通的有效性。
4.策略也應明確帳號過期時間、密碼原則、使用者可存取資訊範圍。
修改帳號
使用特權帳號的問題
1.通常情況每個電腦使用者帳號都具有本機管理員權限,伺服器管理維護人員具有網域管理員權限,且均有較大風險。
2.帳號的增加、刪除或修改,均應嚴格控制並文件化。
3.實施管理員帳號權限分級管理。
4.僅在必須時才使用特權帳號,日常維護工作使用受限帳號。
暫停帳號
1.要暫停不在使用的帳號。
2.從人力部取得短期、長期離職離職人員清單, 與IT系統帳號狀況對比,刪除長期離職離職人員帳號, 並暫停短期離職離職帳號使用權限。
備份驗證
資料類型
使用者檔案
存在多個版本和備份地點文件不一致的情況,以及有悖資料保留原則的情況
資料庫
確保當需要時資料庫備份能夠恢復到生產環境。
郵件數據
考慮到伺服器儲存空間有限,中大型郵件不備份;郵件伺服器應與電子取證手段結合
驗證方法
測試資料備份狀況
分析組織可能面臨的威脅各種場景
開發一個計劃來測試每個場景中所有關鍵任務資料備份
利用自動化,盡量減少審計人員的工作量,確保測試定期發生
盡量減少資料備份測試計劃對業務流程的影響,以便它可以定期執行
確保覆蓋範圍,使每個系統進行測試,但不一定在同一個測試中。
記錄結果,這樣你就知道什麼是工作,什麼是需要工作的
修正或完善你記錄的任何問題。
災難復原和業務連續性
測試和修改業務連續性計劃
測試類型
Checklist Test 檢查清單測試
BCP拷貝分發給每個關鍵業務部門的經理
請他們評審適合他們部門的計畫部分
Structured Walk-Through Test 結構化穿行測試
作為計劃初始測試的工具,但不是最好的測試方法
目標
確保來自所有領域的關鍵人員熟悉BCP
確保計劃反應組織從災難中恢復過來的能力
特點
會議室聯繫,低成本
Simulation Test 模擬測試
比桌面演練包含的內容更多
參加者選擇特定的事件場景應用在BCP中
Parallel Test 平行測試
包含真實人員移動到別的站點試圖依照DRP規定建立通訊和實施真實的恢復流程
主要是確定如果人員應用DRP規定中的程序,關鍵系統是否能夠在備用處理站點恢復
Full-Interruption Test 全中斷測試
風險最高的測試
盡可能模擬真實的場景
不能影響業務
安全培訓和安全意識培訓
安全訓練與安全意識宣灌的區別
安全訓練是指教導一種技能或一套技能,使人們更好地執行特定功能的過程.
安全意識培訓是把人們暴露在安全問題的過程中,以便他們能夠認識到他們,並更好地應對他們。
社會工程學
在資訊安全的背景下,是操縱個人的過程,使他們執行違反安全協議的行為。
Online Safety 線上安全
網路釣魚是透過數位通訊進行的社會工程.。
一個驅動下載是一個自動攻擊,只需訪問惡意網站觸發。
資料保護
文化
關鍵績效和風險指標
關鍵績效指標(KPI)
關鍵績效指標(KPI)測量組織在一個給定的時間執行一個給定的任務的效率
關鍵風險指標(KRI)
測量執行給定動作或動作集合所固有的風險.。
報告
一個有效的報告,必須寫在一個特定的觀眾心目中。
技術報告
一個技術報告應該比一個自動掃描工具或一個普通清單的輸出要多。
好的審計技術報告所包含的要素
威脅
脆弱性
脆弱性被利用的機率
影響程度
改進建議
行政摘要
呈給高階領導者的報告應簡潔易懂,主要包括關鍵的調查結果和建議
最好將風險量化描述,量化風險的一種方法是用貨幣術語來表達風險.
常見風險計量法
成本計算法
最通用的計算方法
所得計算法
一般公式為價值等於預期(或潛在)收入除以資本化率。
市場計算法
市場的方法是基於確定有多少其他公司支付類似的資產在市場上。
管理評審
管理評審是高階組織領導者決定管理系統是否有效地實現其目標的正式會議。
管理評審前
管理評審應週期性地進行,否則將使檢查風險變主動為被動。
會議的頻率也應與執行前一次評審的決定所需時長同步。
評審輸入
一個關鍵的輸入是相關審計的結果,包括外部和內部。
除了使審計報告可供審查,也有必要產生執行摘要,描述的主要發現,對組織的影響,以及建議的變化(如果有的話)。記住用商務語言寫這些摘要。
另一個意見是上次評審發現問題及整改狀況的清單
客戶評價
最後輸入是基於所有其他輸入的改進建議。
管理行動
高階領導考慮所有的輸入訊息,通常問一些有針對性的問題,然後決定批准,拒絕或推遲的建議。
高階管理層將決定是接受它的全部的建議,或接收意見但做細小改變,或拒絕意見,或要求ISMS團隊重新收集更多支持數據或重新設計建議選項。