弱點管理掃描工具與風險管理

– 15 分鐘閱讀

在現今複雜的網路環境中，弱點管理已成為確保系統安全的重要環節。從傳統的根據代理和無代理掃描器，到針對容器化環境的映像掃描和執行中容器掃描，選擇合適的工具至關重要。同時，瞭解各種掃描工具，如動態應用程式掃描器（DAST）、靜態應用程式掃描器（SAST）、軟體組成分析掃描器（SCA）、互動式應用程式掃描器（IAST）以及執行階段應用程式自我保護（RASP），才能有效地識別和修復潛在的安全漏洞。此外，建立完善的風險管理流程，並結合變更管理最佳實踐，才能確保系統安全。

弱點管理：根據代理與無代理掃描器的比較

在進行弱點管理時，選擇合適的掃描工具至關重要。目前，主要有兩種掃描模式：根據代理（agent-based）和無代理（agentless）的掃描器。每種模式都有其優缺點，瞭解這些差異對於制定有效的弱點管理策略是必要的。

根據代理與無代理掃描器的安全性比較

無代理掃描器需要高度許可權的憑證才能執行掃描。雖然授予這些憑證的風險通常小於環境中未知漏洞的風險，但這使得無代理掃描器控制檯成為攻擊者的極具吸引力的目標。相比之下，根據代理的掃描器在初始佈署時需要許可權，但掃描器控制檯僅接收來自代理的報告，並且僅具有代理允許控制檯使用的許可權（可能仍然是完全特權存取）。

佈署考量

代理需要被佈署並保持更新，而代理中的漏洞可能會將整個基礎設施置於風險之中。然而，一個設計良好的處於「唯讀」模式的代理可能能夠減輕攻擊者接管掃描控制檯的大部分風險；攻擊者將獲得大量的漏洞資訊，但可能無法獲得所有系統的特權存取。

無代理掃描器不需要佈署任何程式碼，但通常需要組態目標系統以提供對掃描器的存取。例如，可能需要建立一個使用者ID並為該使用者ID提供一定級別的sudo存取許可權。

網路存取需求

無代理掃描器必須具有入站網路存取許可權才能工作。如前所述，允許這種網路存取可能會增加環境的風險。大多數工具還具有在網路內佈署中繼系統的選項，該系統建立出站連線並允許透過該連線進行控制，但中繼系統是另一個需要管理的系統。

根據代理的系統只能建立出站連線，而不允許任何入站連線。

雲端供應商的安全管理工具

一些雲端供應商在其支援中提供根據代理的掃描器，用於您的雲端環境。這些可以更簡單地自動佈署，並且您不需要手動從雲端供應商提取資產清單並將其饋送到掃描器中。

容器掃描器

傳統的根據代理和無代理掃描非常適合虛擬機器，但通常不適用於容器環境。容器旨在成為非常輕量級的程式，為每個容器佈署為虛擬機器環境設計的代理可能會導致嚴重的效能和可擴充套件性問題。此外，如果正確使用，容器通常不允許傳統的網路登入，這意味著為虛擬機器設計的無代理掃描器也會失敗。

目前，有兩種流行的方法：

  1. 映像掃描：這種方法透過分析容器映像來查詢漏洞。如果映像被評為存在漏洞，您就知道要避免佈署根據它的新容器，並替換從它佈署的任何現有容器。這種方法的優點是不需要存取生產系統，但缺點是一旦您識別出一個存在漏洞的映像，您必須擁有足夠好的所有執行中容器的庫存資訊，以確保替換所有存在漏洞的容器。

    # 使用 Trivy 掃描 Docker 映像
trivy image my-vulnerable-image:latest

    內容解密：

    • trivy image 命令用於掃描指定的 Docker 映像。
    • my-vulnerable-image:latest 是要掃描的映像名稱和標籤。
    • Trivy 將列出映像中的已知漏洞。

  2. 執行中的容器掃描：這種方法是在每個容器主機上使用一個代理來掃描該系統上的容器，並報告哪些容器存在漏洞，以便修復（或最好替換）。這樣做的好處是，如果代理佈署在所有地方，您就不會遺漏仍在執行存在漏洞的映像的「被遺忘」的容器。主要缺點是，您必須在每個容器主機上佈署一個代理。

漏洞管理中的多種掃描工具

在現代軟體開發中，漏洞管理是確保系統安全性的關鍵步驟。隨著容器技術和微服務架構的普及，各種掃描工具應運而生，以幫助開發者和安全團隊識別和修復潛在的安全漏洞。本文將介紹幾種主要的掃描工具，包括動態應用程式掃描器（DAST）、靜態應用程式掃描器（SAST）、軟體組成分析掃描器（SCA）、互動式應用程式掃描器（IAST）以及執行階段應用程式自我保護（RASP）。

動態應用程式掃描器（DAST）

動態應用程式掃描器針對正在執行的Web應用程式或REST API進行掃描，透過模擬使用者行為來發現諸如跨站指令碼攻擊（XSS）或SQL注入等漏洞。這些掃描器通常需要應用程式的登入憑證。某些由動態掃描器發現的漏洞也可以透過Web應用程式防火牆（WAF）來阻擋。

程式碼範例：使用DAST工具掃描Web應用程式

# 使用OWASP ZAP進行DAST掃描
zap-scanner --target https://example.com --output report.html

內容解密：

  1. zap-scanner：這是OWASP ZAP的命令列工具，用於進行DAST掃描。
  2. --target https://example.com：指定要掃描的目標URL。
  3. --output report.html：將掃描結果輸出到report.html檔案中。

靜態應用程式掃描器（SAST）

靜態應用程式掃描器直接檢查開發者編寫的原始碼，可以在佈署流程中早期發現安全相關的錯誤，如記憶體洩漏或越界錯誤。由於SAST工具分析的是原始碼，因此必須使用支援目標程式語言的掃描器。

程式碼範例：使用SAST工具掃描原始碼

// Java範例程式碼
public class Example {
    public static void main(String[] args) {
        // 可能導致安全問題的程式碼
        String userInput = getUserInput();
        System.out.println(userInput);
    }
}

使用SonarQube進行SAST掃描：

sonar-scanner -Dsonar.projectKey=example -Dsonar.sources=src/main/java

內容解密：

  1. sonar-scanner：這是SonarQube的掃描工具，用於分析原始碼。
  2. -Dsonar.projectKey=example：指定SonarQube中的專案金鑰。
  3. -Dsonar.sources=src/main/java：指定要分析的原始碼目錄。

軟體組成分析掃描器（SCA）

軟體組成分析工具主要檢查專案所使用的開放原始碼元件及其版本，以識別已知漏洞。許多應用程式大量使用開放原始碼元件，因此SCA工具對於維護系統安全性至關重要。

程式碼範例：使用SCA工具檢查開放原始碼元件

<!-- Maven依賴範例 -->
<dependencies>
    <dependency>
        <groupId>org.apache.commons</groupId>
        <artifactId>commons-lang3</artifactId>
        <version>3.12.0</version>
    </dependency>
</dependencies>

使用Dependency-Check進行SCA掃描：

dependency-check --project target --scan target

內容解密：

  1. dependency-check：這是OWASP Dependency-Check的命令列工具，用於檢查專案依賴的安全性。
  2. --project target：指定要檢查的專案目錄。
  3. --scan target：指定要掃描的目標目錄。

互動式應用程式掃描器（IAST）

互動式應用程式掃描器結合了靜態和動態掃描的特點，透過在應用程式執行時監控其行為來發現漏洞。IAST工具通常與功能測試或動態掃描器結合使用，以提高檢測的準確性。

執行階段應用程式自我保護（RASP）

執行階段應用程式自我保護工具與IAST類別似，也是透過在應用程式執行時進行監控，但其主要目的是阻擋攻擊而非僅檢測漏洞。RASP工具可以提供類別似於分散式WAF的功能。

弱點管理與修復方法

在資安領域中，發現與修復弱點是確保系統安全的關鍵步驟。除了自動化掃描工具外，還有多種方法可以用來找出系統中的弱點並進行修復。

人工程式碼審查

人工程式碼審查是一種耗時且昂貴的方法，但它在某些情況下比自動化測試工具更有效，尤其是對於某些特定型別的弱點。透過人工審查，不僅可以找出弱點，還可以透過他人的解釋來學習如何避免類別似的錯誤。

在許多高安全性環境中，程式碼審查是標準做法。即使在其他環境中，也會對與安全性相關的程式碼片段進行審查，例如實作加密或存取控制的部分。

滲透測試

滲透測試是由專業人員嘗試入侵系統，以找出其中的弱點。與自動化掃描不同，滲透測試需要專業人員的參與，通常由外部供應商或內部團隊執行。

白箱測試、黑箱測試和灰箱測試

  • 白箱測試：測試人員會獲得系統設計的資訊，但不會獲得機密資訊，如密碼或API金鑰。
  • 黑箱測試：測試人員在沒有任何先前資訊的情況下進行測試。
  • 灰箱測試：介於白箱和黑箱測試之間，測試人員擁有有限的資訊。

白箱和灰箱測試通常比黑箱測試更有效，因為測試人員可以花更多時間找出實際的弱點，而不是花在偵察上。

使用者回報

在理想情況下，所有錯誤和弱點都應該在使用者發現之前被修復。但實際上，使用者可能會回報安全弱點，因此需要有一個明確的流程來驗證、修復和與使用者溝通。

回報處理流程

  1. 驗證弱點：確認使用者回報的弱點是否真實存在。
  2. 修復弱點：對確認的弱點進行修復。
  3. 與使用者溝通：向使用者說明處理進度和結果。

弱點與組態管理工具範例

大多數工具都可以整合到雲端環境中，並且許多雲端服務提供商都有與供應商的合作夥伴關係，或擁有自己的專有弱點管理工具。

以下是一些雲端弱點和組態管理領域的代表性解決方案：

工具選擇考量

選擇合適的工具時，需要考慮其與現有系統的整合度、檢測弱點的能力以及報告和修復的功能。

@startuml
skinparam backgroundColor #FEFEFE
skinparam componentStyle rectangle

title 弱點管理掃描工具與風險管理

package "Kubernetes Cluster" {
    package "Control Plane" {
        component [API Server] as api
        component [Controller Manager] as cm
        component [Scheduler] as sched
        database [etcd] as etcd
    }

    package "Worker Nodes" {
        component [Kubelet] as kubelet
        component [Kube-proxy] as proxy
        package "Pods" {
            component [Container 1] as c1
            component [Container 2] as c2
        }
    }
}

api --> etcd : 儲存狀態
api --> cm : 控制迴圈
api --> sched : 調度決策
api --> kubelet : 指令下達
kubelet --> c1
kubelet --> c2
proxy --> c1 : 網路代理
proxy --> c2

note right of api
  核心 API 入口
  所有操作經由此處
end note

@enduml

此圖示說明瞭弱點管理的流程，包括人工程式碼審查、滲透測試、使用者回報等方法，以及檢測、修復和驗證的步驟。

風險管理與漏洞管理工具

在漏洞管理過程中，瞭解組織中最脆弱的區域以及用於發現和修復漏洞的工具和流程至關重要。為了有效地管理漏洞，需要一個系統來優先處理無法快速修復的漏洞。

漏洞管理工具

以下是一些常見的漏洞管理工具，這些工具可能與檢測和回應、存取管理、資產清單和資料資產管理等領域有所重疊。這些工具的選擇並不代表對特定工具的認可或對其他工具的忽視。

  • Amazon Inspector：根據代理的掃描器，用於掃描Linux和Windows系統中缺失的補丁和不良組態。
  • Ansible：無代理的自動化引擎，可用於幾乎任何任務，包括組態管理。
  • AWS Config：檢查AWS資源的詳細組態並保留這些組態的歷史記錄。
  • AWS Systems Manager (SSM)：涵蓋多個領域的安全管理工具，包括清單、組態管理和補丁管理。
  • AWS Trusted Advisor：對多個領域進行檢查，例如成本、效能、容錯能力和安全性。
  • Azure Security Center：安全管理工具，可與合作夥伴（如Qualys和Rapid7）整合，以取得漏洞資訊。
  • Azure Update Management：根據代理，主要用於管理作業系統安全補丁，但也可以執行軟體清單和組態管理功能。
  • Burp Suite：動態Web應用程式掃描套件。
  • Chef：根據代理的自動化工具，用於組態管理，InSpec專案專門針對與安全性和合規性相關的組態。
  • Contrast：提供IAST和RASP解決方案。
  • Google Cloud Security Command Center：安全管理工具，可以從Google Cloud Security Scanner和其他第三方工具中取得資訊，並提供清單管理和網路異常檢測功能。
  • Google Cloud Security Scanner：用於Google App Engine上託管的應用程式的DAST工具。
  • IBM Application Security on Cloud：SaaS解決方案，使用多個IBM和合作夥伴產品，提供IAST、SAST、DAST和SCA。
  • IBM BigFix：根據代理的自動化工具，用於組態和補丁管理。
  • IBM Security Advisor：安全管理工具，可以從IBM Vulnerability Advisor取得漏洞資訊以及網路異常資訊。
  • IBM Vulnerability Advisor：掃描容器映像和正在執行的例項。
  • Puppet：根據代理的自動化工具，用於組態管理。
  • Qualys：產品涵蓋多個類別，包括網路漏洞掃描、動態Web應用程式掃描等。
  • Tenable：產品範圍包括Nessus網路掃描器、根據代理和無代理的Nessus補丁和組態管理掃描器，以及容器掃描器。
  • Twistlock：對容器映像、正在執行的容器和容器執行所在的主機執行組態和漏洞管理。
  • WhiteSource：SCA解決方案。

風險管理流程

在發現漏洞後，需要一個系統來優先處理無法快速修復的漏洞。這需要進行風險評估，以瞭解發生不良事件的可能性及其影響。在許多情況下，可能會接受風險作為業務成本。然而，風險評估可能會導致緩解策略，例如增加檢測或預防工具或流程。

風險評估框架

使用現有的風險評估框架（如NIST 800-30或ISO 31000）可以比從頭開始更容易。一個簡單的風險登記冊和商定的風險嚴重性評估流程可以帶來很大的價值。

風險管理指標

指標有助於推動持續改進並揭示問題，但也可能導致錯誤的決定。在審查指標和結果時，需要進行健全性檢查，以確保沒有不合理的減輕因素或指標被操縱。

漏洞管理指標

有多種不同的指標可用於漏洞管理，許多工具可以自動計算這些指標。指標通常可以按單獨的團隊或業務單位報告。透過指標來評估漏洞管理的有效性，並根據需要進行調整。

指標的重要性

指標有助於評估漏洞管理的有效性，並推動持續改進。然而，需要謹慎使用指標，以避免導致錯誤的決定或被操縱。

弱點管理指標與變更管理最佳實踐

在進行弱點管理時，不同組織的需求和指標會有所不同，但某些特定的衡量標準已被證明是有效的。以下將探討一些有用的指標和變更管理的最佳實踐。

弱點管理指標

工具覆寫率（Tool Coverage）

對於每個工具，瞭解其能夠涵蓋的系統比例是非常重要的。例如，動態應用程式掃描器能夠測試多少百分比的網頁應用程式？網路掃描器能夠掃描多少百分比的雲端 IP 位址？這些指標可以幫助識別資產和弱點管理流程中的漏洞。理想情況下，這些指標應該隨著時間的推移接近 100%，前提是每個工具的系統範圍被正確定義。

平均修復時間（Mean Time to Remediate, MTTR）

根據不同的嚴重性和環境細分此指標非常有用。例如，根據嚴重性（希望更快地修復「關鍵」專案而非「低嚴重性」專案）和系統型別（內部或導向網際網路）進行區分。可以根據這些時間框架決定是否代表可接受的風險。

具有開放弱點的系統/應用程式

此指標通常以百分比表示，因為隨著追蹤專案的增加，絕對數字會上升。此指標通常根據不同的系統/應用程式分類別（如內部或導向網際網路）、弱點的嚴重性以及是否由於缺少補丁或組態錯誤而進行細分。

假陽性百分比（Percentage of False Positives）

此指標可以幫助瞭解工具的效能，以及由於工具問題而給團隊帶來的管理負擔。某些型別的工具可能會出現假陽性，但如果假陽性過多，該工具可能就沒什麼用處。

假陰性百分比（Percentage of False Negatives）

追蹤應該被某個工具或流程檢測到的弱點，但卻被其他方式發現的數量。具有太多假陰性的工具或流程可能會導致虛假的安全感。

弱點重複率（Vulnerability Recurrence Rate）

如果弱點在修復後再次出現，可能表明工具或流程存在嚴重的問題。

弱點評分注意事項

對於給定的弱點，第一個問題通常是：「它有多糟糕？」最廣泛接受的標準是通用弱點評分系統（CVSS）。雖然 CVSS 有其支援者和批評者，但大多數安全專業人員同意，從 CVSSv2 或 CVSSv3 獲得的基本分數並不能完全反映特定環境下的情況。調整 CVSS 分數以適應威脅態勢和特定環境是非常重要的。

變更管理

許多組織都有某種形式的變更管理功能。最簡單的形式是，變更管理確保變更在獲得批准後才進行，並且對變更風險進行了評估。變更管理可以透過確保建議的變更不會引入新的安全弱點來協助弱點管理。如果做得不好，變更管理也可能阻礙弱點管理，增加整體風險。

雲端環境中的變更管理

在雲端環境中，一些新技術可能會降低整體中斷的風險，因此需要較少的手動變更管理來達到相同的營運風險水平。整體雲端弱點管理計劃的一部分可能是修改變更管理流程。例如，將新程式碼與安全性修復一起推播到生產環境可能是一種常規業務活動，透過變更控制委員會自動批准，只要有快速還原到良好狀態的流程即可。

弱點管理流程設計與實踐

在現代化的微服務架構中，弱點管理（Vulnerability Management）是一個至關重要的環節。本章節將透過一個簡單的三層範例應用程式，展示如何在 Kubernetes 環境中設計一個完善的弱點管理流程。

範例應用程式架構

首先，回顧一下第一章提到的簡單三層範例應用程式，其架構如 圖 1 所示。

此圖示展示了一個傳統的三層架構。在現代的容器化微服務環境中，該應用程式的架構可能會有所不同，但其核心的三層結構仍然保持不變，如 圖 2 所示。

弱點管理流程中的角色

在這個範例中，我們定義了幾個關鍵角色：

  1. 滲透測試人員（Pentester）：在佈署之前，嘗試入侵系統，就像真正的攻擊者一樣。這項測試可以由外部團隊執行，也可以由內部紅隊（Red Team）進行不定期的系統測試。

  2. 使用者：如同前面的範例，使用應用程式。在某些情況下，終端使用者可能會報告安全漏洞和功能性錯誤。

  3. 管理員/開發者：這個角色兼具開發和維運/管理職責。他們需要：

    • 確保基礎設施和平台元件（如 Kubernetes 主節點和工作節點）保持最新狀態。
    • 進行程式碼更新，這些更新可能代表新的微服務或對現有微服務的修改。
    • 將更新佈署到生產環境，並/或將流量切換到新版本的應用程式。

  4. 程式碼審查者：可能是另一個開發者或專門的程式碼審查團隊。手動程式碼審查可以有效發現關鍵程式碼區域的安全漏洞。

自動化佈署流程

接下來，我們來看看佈署流程：

  1. 管理員/開發者提交程式碼變更，觸發自動化佈署流程。

  2. 靜態程式碼掃描器 檢查自有程式碼中的問題，如未經驗證的輸入。同時，軟體成分分析（SCA）工具 檢查開源依賴元件是否存在已知漏洞。理想情況下，開發者會立即收到問題反饋，嚴重的問題會阻止新程式碼的佈署。

  3. 自動化流程在測試環境中啟動新程式碼，並執行測試案例以驗證功能性。

  4. 自動化流程呼叫 動態應用程式測試工具 以發現問題。同樣，開發者會被通知任何問題，嚴重的問題會停止佈署流程。

  5. 如果所有測試透過，新程式碼將被佈署到生產環境，管理員可以選擇將部分或全部生產流量導向新例項。

定期掃描工具

在圖示的頂部，我們可以看到幾個定期掃描工具：

  1. 網路漏洞掃描器 測試叢集中工作節點的所有 TCP 和 UDP[^3] 連線埠。如果組態正確，掃描器應該只看到 HTTPS（tcp/443）連線埠開放，但可能會發現相關問題，如弱 TLS 加密套件。

  2. 容器掃描器 檢查每個執行中的容器是否存在問題，如作業系統元件的已知漏洞。

  3. 安裝在每個工作節點上的代理程式 監控作業系統元件的更新狀態，並確保作業系統符合 CIS Benchmarks 標準。

  4. IAST（互動式應用程式安全測試）代理程式 和 RASP（執行時應用程式自我保護）代理程式 分別通知其控制檯發現的問題並嘗試阻止攻擊。

重點與實踐建議

雖然上述工具和流程看似複雜，但實際上許多產品可以執行多種功能。關鍵在於瞭解不同型別工具的作用，以選擇最能應對您最大威脅的工具。

購買工具並安裝只是第一步，更重要的是根據工具提供的資訊採取行動。專注於建立良好的反饋迴圈，並使用有用的指標進行衡量，然後再新增更多工具。

玄貓 BlackCat

玄貓 BlackCat

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。