> For the complete documentation index, see [llms.txt](https://firmianay.gitbook.io/cissp-notes/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://firmianay.gitbook.io/cissp-notes/d6_security_assessment_and_testing.md).

# 域6：安全評估與測試

* [域6：安全評估與測試](#域6安全評估與測試)
  * [D6-1：構建安全評估和測試方案](#d6-1構建安全評估和測試方案)
    * [一、安全測試（Security Testing）](#一安全測試security-testing)
    * [二、安全評估（Security Assessments）](#二安全評估security-assessments)
    * [三、安全審計（Security Audits）](#三安全審計security-audits)
  * [D6-2：開展漏洞評估](#d6-2開展漏洞評估)
    * [一、漏洞描述](#一漏洞描述)
    * [二、漏洞掃描](#二漏洞掃描)
    * [三、滲透測試](#三滲透測試)
    * [四、合規檢查](#四合規檢查)
  * [D6-3：測試軟體](#d6-3測試軟體)
    * [一、程式碼審查和測試](#一程式碼審查和測試)
    * [二、介面測試](#二介面測試)
    * [三、誤用案例測試](#三誤用案例測試)
    * [四、測試覆蓋率](#四測試覆蓋率)
    * [五、網站監測](#五網站監測)
  * [D6-4：安全管理流程](#d6-4安全管理流程)
    * [一、日誌審查](#一日誌審查)
    * [二、賬戶管理](#二賬戶管理)
    * [三、災難恢復和業務連續性](#三災難恢復和業務連續性)
    * [四、培訓和意識](#四培訓和意識)
    * [五、關鍵績效和風險指標（KPI/KRI）](#五關鍵績效和風險指標kpikri)

## D6-1：構建安全評估和測試方案

### 一、安全測試（Security Testing）

1. 驗證控制措施是否正常執行，應定期開展測試。
2. 通常情況下，自動化測試頻率高，手工測試頻率低。
3. 典型場景如測試備份功能是否正常、病毒庫更新是否正常。

### 二、安全評估（Security Assessments）

更全面的安全性審查（涵蓋安全測試的內容），會執行風險評估、識別安全漏洞、提出修復意見等，安全評估的成果通常提交管理層審閱。

安全評估可以由內部團隊執行，也可以委託專業的第三方團隊執行。

NIST 800-53A評估內容

1. 規範：查管理制度；
2. 機制：查技術措施；
3. 活動：查人員行為；
4. 人員：查人員。

### 三、安全審計（Security Audits）

安全審計是為了向第三方證明控制措施有效性而進行的評估，因此審計必須具有獨立性。

1. 審計型別

* 內部審計：由組織內部審計人員執行，直接向CEO或董事會進行彙報。
* 外部審計：由外部審計公司執行，具有很高的公信力，如四大。
* 第三方審計：實際上也是外部審計。

1. 審計標準

* 美國-認證業務標準18號文（SSAE 18）
* 國際-國際認證業務3402（ISAE 3402）
* 這兩個審計標準通常被稱為服務組織控制（SOC）審計。
* 資訊和相關技術控制目標（COBIT）-ISACA
* SO 27001資訊保安管理、ISO 27002 資訊保安控制-ISO

1. SOC報告型別

* SOC 1：評估可能影響財務報告準確性的組織控制措施。
* SOC 2：評估影響系統中儲存的資訊保安性和隱私的組織控制。報告是機密的，需要簽署保密協議才可與外部組織進行共享。
* SOC 3：SOC 2報告的摘要資訊，可公開展示。
* Type 1：報告覆蓋一個特定時間點，審計管理制度描述的控制措施內容。
* Type 2：報告覆蓋一段較長時間（最少6個月），審計管理制度描述的控制措施實際執行情況。

## D6-2：開展漏洞評估

### 一、漏洞描述

安全內容自動化協議（SCAP）為漏洞描述和評估提供通用語言。

1. 通用漏洞及披露（CVE）：描述安全漏洞的命名系統，即漏洞編號。（<http://cve.mitre.org）>
2. 通用漏洞評分系統（CVSS）：描述安全漏洞嚴重性的標準化評分系統，即漏洞級別。（<https://www.first.org/cvss/）>
3. 通用配置列舉（CCE）：描述系統配置問題的命名系統，即基線配置編號。（<https://cce.mitre.org）>
4. 通用平臺列舉（CPE）：描述作業系統、應用程式及裝置的命名系統，即漏洞影響的廠商、元件、版本等。（<https://cpe.mitre.org）>
5. 可擴充套件配置檢查表描述格式（XCCDF）：描述安全檢查表的語言，包括其他元素的大集合。（<https://csrc.nist.gov/Projects/Security-Content-Automation-Protocol/Specifications/xccdf）>
6. 開放漏洞評估語言（OVAL）：描述安全測試過程的語言，即描述漏洞如何檢測的過程。（<https://oval.mitre.org）>

### 二、漏洞掃描

漏洞掃描工具具備自動化功能，應定期測試內部風險變化，且可被駭客利用作為攻擊工具使用。

1. 網路發現掃描

用於掃描IP地址，探測系統開放的埠，不涉及漏洞探測。

常見掃描技術

* TCP SYN掃描：傳送含SYN標誌位的包，如果返回SYN-ACK則埠開放，也被稱為半開放（half-open）掃描。
* TCP Connect掃描：如果使用者沒有半開放掃描許可權，則需要進行全連線掃描。
* TCP ACK掃描：傳送含ACK標誌位的包，主要用於確定是否有防火牆攔截。
* Xmas掃描：傳送含FIN、PSH、URG標誌位的包，如果返回RST則埠開放， 也被稱為聖誕樹（ Christmas tree）攻擊。

網路發現掃描代表工具nmap

開源免費使用，能夠掃描IP、埠、版本號等等，整合外掛還可以進行漏洞掃描，但在考試範疇裡就是掃IP、埠的。

nmap能夠提供埠的狀態

* 開放：埠在系統上是開放的，即服務正常執行；
* 關閉：埠在系統上是關閉的，即服務沒有執行；
* 過濾：檢測到防火牆干擾，無法判斷是否開啟還是關閉。

TIPs

* 網路發現掃描如果未經授權開展，則會認定是違法行為。
* 網路發現掃描的最主要應用場景是對目標進行資訊收集，方便後續的滲透測試活動。
* 可以使用netstat命令檢視系統當前開放的埠號和連線建立情況。

1. 網路漏洞掃描

網路漏洞掃描不僅可以掃描IP和埠，還可以基於漏洞庫檢測目標系統存在的已知漏洞，即無法檢測0 day漏洞。

* 誤報（false positive report）：漏掃工具報出漏洞，但目標系統實際不存在該漏洞的情況。
* 漏報（false negative report）：是目標系統實際存在漏洞，但漏掃工具未檢測到的情況。
* 基於軟體版本號檢測，檢測到低版本號後匹配該版本的漏洞資訊進行漏洞報告，誤報率高、檢測效率高。
* 基於攻擊載荷檢測，實際傳送漏洞利用的載荷到目標系統，檢測目標系統的返回包來確定漏洞是否存在，誤報率低、檢測效率低。
* 未經身份驗證的掃描（unauthenticated scans）：偏向於攻擊者視角，但由於沒有經過身份驗證，某些頁面或功能無法獲取，因此發現的漏洞相對較少。
* 經過身份驗證的掃描（authenticated scans）：經過身份驗證後可以提高掃描的範圍和準確度，發現的漏洞相對較多。

常見服務的埠號

![](https://366271701-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8rn090lRzHL4UfRBIqer%2Fuploads%2Fgit-blob-32b7bf3ba22cbf9c996328b69e9e02ce2ad93410%2F6_ports.png?alt=media)

常見漏掃工具

* Nessus 商業/免費 傳統網路
* OpenVAS 免費 傳統網路
* AirCrack 免費 無線網路

1. Web應用漏洞掃描

與網路漏洞掃描的最大區別在於其對Web應用進行更為深入的漏洞探測，就像IPS和WAF的關係。

常見Web漏洞掃描工具

* Acunetix 商業
* Nikto 開源
* Wapiti 開源
* Burp Suite 代理工具

1. 資料庫漏洞掃描

資料庫漏洞掃描工具通常可以同時對資料庫和Web應用進行掃描，試圖找到資料庫漏洞。

典型資料庫漏掃工具有sqlmap。

1. 漏洞管理工作流程

* 檢測：發現漏洞；
* 驗證：手工確認漏洞是否真是存在，避免誤報；
* 修復：對漏洞進行修復，方法包括但不限於升級、打補丁、部署防護裝置等。

### 三、滲透測試

與漏洞掃描最大的區別在於是否發動了真是的攻擊行為，且滲透測試往往是人工參與的。

1. 滲透測試階段

![](https://366271701-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8rn090lRzHL4UfRBIqer%2Fuploads%2Fgit-blob-527a4577d5c82cad94d847f5d3fb4c87b6f37ba5%2F6_pentest.png?alt=media)

* 規劃（planning）：確定測試範圍和規則，確保測試團隊與管理人員對測試性質達成共識，明確測試是經過授權的。
* 資訊收集和發現（information gathering and discovery）：結合人工和自動化工具收集目標資訊，包括網路發現掃描和各類漏洞掃描。
* 嘗試攻擊（attack seeks）：利用手工和自動化利用工具來企圖破壞系統安全。
* 報告（reporting）：總結滲透測試結果，並提出修復建議。 典型滲透測試工具有Metasploit。

1. 滲透測試種類

* 白盒滲透測試（White-Box Penetration Test）：向攻擊者提供目標系統的詳細資訊，可以縮短攻擊事件、提高發現漏洞的可能性，也叫已知環境（known environment）測試。
* 灰盒滲透測試（Gray-Box Penetration Test）：向攻擊者提供目標系統的部分資訊，平衡黑白盒的優缺點，也叫部分已知環境（particularly known environment）測試。
* 黑盒滲透測試（Black-Box Penetration Test）：不向攻擊者提供任何資訊，模擬駭客攻擊場景，也叫未知環境（unknown environment）測試。

入侵與攻擊模擬（Breach and Attack Simulations）是Gartner在2021年提出的一個風險管理趨勢，BAS工具用於自動化執行無危害的攻擊行為，旨在測試組織內的安全控制措施有效性。

### 四、合規檢查

組織必須遵循各種法律法規的約束，因此定期執行合規檢查可以避免不可預見的監管問題。

## D6-3：測試軟體

軟體是系統的核心組成部分，會影響很多不同元件的安全，如作業系統、中介軟體、資料等，因此不不僅需要關注軟體的正常功能測試，而且需要關注軟體處理處理意外活動的能力，即異常處理（exception handing）。

### 一、程式碼審查和測試

1. 程式碼審查（code review）

程式碼審查也稱為同行評審（peer review），編寫程式碼的開發人員之外的其他開發人員會對程式碼進行檢查以發現漏洞，決定程式碼是否可以上線。

Fagan inspections步驟

![](https://366271701-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F8rn090lRzHL4UfRBIqer%2Fuploads%2Fgit-blob-cd332231bda383b5477a4d54d27fe4d5fbff2b89%2F6_fagan.png?alt=media)

規劃（planning）、概述（overview）、準備（preparation）、審查（inspection）、返工（rework）、跟進（follow-up）

Fagan審查是最為嚴格的程式碼審查方法，適用於程式碼缺陷可能引發災難性危害的場景，如涉及人身安全的應用程式開發。

稍微寬鬆的程式碼審查方法

* 開發團隊會議上成員走查（walk through）程式碼
* 高階研發人員手工審查
* 自動化程式碼審查工具

1. 靜態測試

靜態應用程式安全測試（Static application security testing，SAST）：不執行軟體的情況下進行測試，往往使用自動化檢測工具。

1. 動態測試

動態應用程式安全測試（Dynamic application security testing，DAST）：執行軟體的情況下進行測試，一般使用web漏掃工具進行。

TIPs：

* 模擬事物（synthetic transactions）：動態測試中用於驗證系統的效能。
* 互動式應用程式安全測試（Interactive application security testing，IAST）：針對執行時的行為、應用程式效能、HTTP\HTTPS流量、框架、元件和後端連線進行實時分析，動態測試的一種。
* 執行時應用程式自我保護（Runtime Application Self-Protection，RASP）：執行在伺服器上的工具，可以攔截應用程式呼叫和驗證資料請求，是一種防護技術。
* 道德披露（ethical disclosure）：安全人員檢測到廠商的漏洞後，有責任向廠商報告漏洞詳情，為他們提供開發補丁或其他補救措施的機會。應為廠商提供合理的時間來糾正問題，但如果未按時糾正可公開漏洞，以便為其他使用者使用此產品提供參考。（可參考烏雲的運作模式）

1. 模糊測試

模糊測試（Fuzz testing）是一種動態測試技術，向軟體提供不同型別的輸入測試其限制以發現漏洞。

模糊測試型別

* 突變模糊測試（Mutation or Dumb Fuzzing）：將輸入值進行隨機改變來測試軟體反饋（不動腦）。
* 智慧模糊測試（Generational or Intelligent Fuzzing）：開發資料模型建立新的值來測試軟體反饋（動腦子）。

模糊測試雖然重要，但無法覆蓋所有程式碼的測試，僅限於不涉及業務邏輯的簡單漏洞測試。

### 二、介面測試

應用程式開發都是抽象的，因此互動都要依靠介面（interface）完成，對介面進行測試也是軟體測試的重要部分。

介面型別

1. 應用程式設計介面（API）：應用程式之間互動的通道。
2. 使用者介面（UI）：包括影象使用者介面（GUI）和命令列介面（CLI），前段和後端交換的通道。
3. 物理介面（Physical Interfaces）：操控機械裝置、邏輯控制器或其他物理裝置的應用程式交換通道，物理介面測試需慎重，因為影響較大。

### 三、誤用案例測試

測試人員梳理錯誤使用應用程式的場景，然後透過手工活自動化的方式對應用程式進行測試。

### 四、測試覆蓋率

測試軟體是無法做到測試所有部分的，就像風險無法被完全消滅，因此衡量對軟體的測試程度使用測試覆蓋率分析。

測試覆蓋率=已測用例的數量/全部用例的數量

五個常見標準

1. 分支覆蓋率（branch coverage）：是否每一個if語句都已被執行。
2. 條件覆蓋率（condition coverage）：是否每一個邏輯都已被測試。
3. 函式覆蓋率（function coverage）：是否每個函式都已被呼叫。
4. 迴圈覆蓋率（loop coverage）：是否每個迴圈都已被執行。
5. 語句覆蓋率（statement coverage）：是否每行程式碼都已被執行。

### 五、網站監測

組織應對網站進行持續監測，可以實現效能管理、故障排除、安全問題識別等。

1. 被動監測（passive monitoring）：對真實流量進行監測，用於發現網路活動；其中真實使用者監測（RUM）是被動監測的變體，側重於使用者活動的監測。
2. 主動監測（active monitoring）：也叫綜合監測（Synthetic monitoring），模擬事務交易來測試網站效能。

被動監測具有滯後性，出了問題才能發現，而主動監測可以提前檢測到問題。

## D6-4：安全管理流程

### 一、日誌審查

1. 安全資訊和事件管理（SIEM），對日誌進行自動化收集、分析、審查。
2. 大部分裝置、作業系統和應用程式都支援syslog，但window需要額外安裝第三方軟體才能支援。
3. 確保日誌時間戳的一致性，必須實施網路時間協議（NTP）。
4. 在調查安全事件時，網路流（netflow）日誌非常有用。

### 二、賬戶管理

賬戶管理審查（account management review）確保使用者僅保留被授予的許可權，並未發生未授權的修改。

1. 全面審查（full review）：對所有賬戶的許可權進行審查，由於時間成本，往往選擇僅對特權賬戶進行審查。
2. 抽樣審查（sampling review）：隨機抽取部分賬戶進行審查。
3. 自動審查：身份和訪問管理（IAM）可以支援自動化審查，並提供審計蹤跡（audit trail）。

### 三、災難恢復和業務連續性

備份程式對於災難恢復計劃至關重要，管理人員應定期檢查備份結果，涉及審查日誌、檢查雜湊值、要求真實還原一個系統或檔案。

對災難恢復和業務連續性控制進行定期測試，可以確保組織能夠有效地防止業務運營中斷。

### 四、培訓和意識

安全培訓和安全意識有助於各類安全計劃的開展。

### 五、關鍵績效和風險指標（KPI/KRI）

安全管理人員應持續監測關鍵績效和風險指標，如：

1. 未修復漏洞數量
2. 已修復漏洞數量
3. 漏洞/缺陷重現次數
4. 被盜用賬戶數量
5. 軟體上線前漏洞數量
6. 審計結果重新次數
7. 使用者訪問惡意站點的數量