在本節中，我們將詳細討論如何做好萬全準備，讓貴機構做好準備並成功執行安全漏洞揭露計畫，其中包括如何填補發現缺口的實用建議。
找出錯誤
與外部安全性研究人員擴充現有的安全性計畫，是找出複雜問題及隱匿安全漏洞的絕佳方法。不過，使用 VDP 找出可能在內部發現的基本安全性問題，意味著資源浪費。
素材資源管理
尋找錯誤時，如果想瞭解一切，只能從哪裡著手。您可以購買一百個安全性工具，但如果團隊可能在您不知情的情況下自行設定應用程式、系統和服務，則不會有任何改變；特別是如果您無法探索並執行這些資產的安全評估時，這些工具並不會帶來任何影響。詢問負責協助建構新應用程式、系統和服務的個人和團隊，瞭解他們是否有既定的程序，可以建立及維護即將啟動的目錄和其擁有者。如果目前沒有程序目前的程序，不妨把握機會與這些團隊合作建構程序。找出攻擊途徑時，最好先瞭解機構資產。在這個過程中，安全性團隊應參與新的基礎架構實作的開發工作，以提供安全性審查。建議您充足的資產與擁有者目錄。如果需要某些系統暫時關閉新的修補程式，這種清查就能派上用場。它會針對需要更新資訊的個人或團隊提供藍圖，說明哪些系統會受到影響。制訂完善的資產管理程序，可確保程序及早發現擁有者、定期更新，以及整個機構中的所有系統都能按預期運作。
除了主動式資產管理之外，也請考慮您可以採用哪些被動措施來識別屬於機構的資產，但打破了標準化資產管理程序的裂痕。這可能包括安全性研究人員採用的「偵探」程序 (參與 VDP 和抓錯獎賞方案)。例如，您可以使用免費的開放原始碼工具，掃描並列舉可能屬於網際網路的 IP 範圍或網域。在 Google 搜尋「Bugunty Recon」時，系統會產生各種提示與秘訣，協助您從機構中從未註意到的資產中找到。
基本安全漏洞掃描
現在您已有了明確的基礎，知道要找出安全性問題的位置，接著就來深入瞭解實際執行這項功能的「方式」。您可以根據機構的資源來深入不同層級，但必須在安全漏洞外洩計畫中的內部安全防護機制與外部入侵社群之間找到平衡。每個機構的餘額都不同，實際情況視可用資源而定。
選擇工具
您可以運用許多不同的工具找出安全漏洞。部分安全漏洞掃描工具可免費使用，有些則需付費使用。根據您的個人需求尋找合適的工具。
- 貴機構的需求條件
- 各項工具是否符合這些需求的要求
- 如果工具的好處超過成本 (財務和實作)。
您可以使用這個需求範本 (OpenDocument .ods、Microsoft Excel .xlsx)，依照您的需求評估各種工具。範本會包含一些需求條件，但您應與安全性、IT 和工程團隊討論，確認必要的能力。在推出安全漏洞揭露計畫之前，您至少希望可以針對任何外部資產 (例如網站、API、行動應用程式) 執行安全漏洞掃描。在邀請外部安全性研究人員利用這些資產和服務進行測試之前，這有助於您找出並修正容易發現的安全漏洞。
掃描設定
自動化安全漏洞掃描可以發現許多問題，但也可能產生偽陽性。因此，在與受影響的團隊分享結果前，有必要先備妥資源來驗證結果。您需要實作程序，以確保系統會定期執行掃描，並確認掃描結果已確實解決。每種機構都會採用不同的設定，但請務必至少判斷：
- 掃描頻率
- 連續
- 每週
- 每月
- 正在掃描哪些資產
- 憑證
- 已驗證與未驗證的掃描結果
- (提示：如果您「並未」使用憑證執行掃描，那麼在您啟動 VDP 時，安全性研究人員使用憑證進行測試時，可能會發現安全漏洞數量大幅增加)
- 角色和責任
- 找出負責執行掃描作業的團隊成員
- 視需要設定輪播
- 掃描結果
- 驗證掃描結果
- 針對已驗證的安全漏洞回報錯誤
- 識別擁有者以修正錯誤
- 向負責人確認修復事宜
本指南稍後的「修正錯誤」一節將詳細介紹如何確保發現安全性問題已經修正。
安全性審查程序
雖然安全漏洞掃描是有效找出機構中安全性問題的好方法，但實作安全性審查程序仍有助於避免一開始就產生安全漏洞。在本指南中，「安全性審查」一詞是指會觸發安全性團隊成員進行人工審查的任何情況。一般來說，這包括如果系統認為變更很有風險，就有權封鎖變更。如果您的安全性團隊無法封鎖有風險的變更，您還是需要有程序來記錄風險。這有助於確保推送變更的人員知道相關風險，並主動接受這些風險。
安全性審查標準
何時應進行安全性審查？建立一組觸發安全性審查的條件，有助於確保所有人都瞭解相同頁面。以下列舉幾個可能觸發安全性審查的情境。
- 我們提議推出與敏感使用者資料相關的新功能
- 這項新功能可讓使用者在地圖上分享位置資訊
- 要求使用者提供潛在的機密資訊，例如住家地址、出生日期或電話號碼
- 現有功能的重大更新
- 以使用者可能期待的新方式擷取現有資料， 卻沒有提供選擇退出的機會
- 驗證、授權和工作階段管理的任何相關功能異動
- 公司實際工作環境的異動
- 網路設定變更，尤其是可能導致對外公開服務的變更
- 安裝會處理敏感使用者資料的新軟體，一旦遭駭，即可間接存取使用者的機密資料
- 啟動新系統或服務
- 與新供應商互動，或變更與現有廠商合作的方式
- 新廠商可處理敏感的使用者資料
- 與導致廠商處理機密使用者資料的現有供應商合作方式有所異動
這份清單並未列出所有項目，但您可以開始思考哪些變更項目需要經過安全性審查。定義安全性審查的必要/不需要安全性審查時，請與組織內的重要相關人員討論，以確保以下事項：
- 相關人員有機會審查條件並提供意見回饋
- 相關人員同意
- 相關人員同意主動要求安全性審查
記下這項標準，以及如何要求安全性審查 (例如將錯誤回報錯誤至安全團隊監控的佇列)，讓貴機構輕鬆遵守這項程序。
安全性審查資源
有別於自動掃描，安全性審查可能會耗用更多資源。每個安全性團隊每天都有很長的時間要完成多項工作，因此請根據您的條件估算可能產生多少安全性審查。如果您發現團隊的壓力不堪負荷，進度落後，安全性團隊就會對等待這些功能推出的使用者感到不滿。這可能會導致機構文化改變，導致資安團隊被評估為阻礙，而非合作夥伴。如果安全性審查程序效率不佳，許多人員和團隊會嘗試完全略過這項程序。如果資源有限，請考慮放寬要求安全性審查的條件，並且願意接受更多剩餘風險。如果事件是因缺乏資源無法執行安全性審查而發生，這將有助於證明需要使用更多安全性資源。
執行安全性審查
在決定要執行哪些安全性審查及如何執行這些審查時，您需要有優先順序的佇列來提取。為機構中的其他人員提出標準化申請，要求他們提供必要的資訊，以妥善安排各項資訊的優先順序。舉例來說，假設問卷中包含變更性質等項目，包括變更的簡要摘要，以及哪些類型的使用者資料可能受到影響。您可以根據這些問題的答案，自動將潛在的安全性審查歸入高風險、中低或低風險。如果變更具有高風險，您可能需要更深入的安全性審查程序。如果變更的風險較低，您或許可以實作更精簡的安全性審查程序，藉此減少所需資源並加快程序，進而讓業務更臻完善。建議您在團隊中設置輪替作業，負責管理安全性審查佇列，確保團隊成員會接受新的安全性審查，並追蹤現有的安全性審查進度。實際的安全性審查程序會因要檢查的內容而異。舉例來說，行動應用程式中的新功能可能需要安全性工程師審查程式碼，並尋找潛在的安全漏洞。安裝的新軟體可能需要審查，確保存取權控管設定正確無誤。與外部廠商合作時，過程可能完全不同。如需參考資料，請參閱 Google 的供應商安全性評估問卷。
修正錯誤
找出錯誤很重要，但只有在修正錯誤後，安全性才會有所改善。瞭解貴機構存在哪些風險是很不錯的做法，但能夠有效因應風險是更好的做法。
安全漏洞管理
安全漏洞來自各種資源，包括內部人力 (例如安全漏洞掃描和安全性審查)、第三方滲透測試和稽核，甚至是外部安全性研究人員，會在 VDP 正式發布前透過支援管道通知您。貴機構需要將全新和現有的安全漏洞分門別類，確保這些安全漏洞已傳達給合適的相關人員、以正確方式排定優先處理順序，並及時進行修正。啟動 VDP 時，會有一連串新的安全漏洞進入安全漏洞管理程序。建立可靠的程序來處理這些安全漏洞，有助於追蹤修復進度，並回應外部安全性研究人員的要求，以取得最新資訊。若能快速排定安全漏洞的處理優先順序，並且向 VDP 參與者說明修復時程，不但能提高與安全性研究人員社群的互動，還可提高貴機構安全性的聲譽。以下各節概略說明推出 VDP 前，您希望能採取的安全漏洞管理計畫的各個面向。
制定嚴重程度標準和修復時程
為安全漏洞嚴重程度和與其相關的理想修復時程建立共通語言，可讓您更輕鬆地為機構設定標準期望。如果將每個安全漏洞視為緊急狀況，貴機構就會耗盡資源，並重新對安全性團隊加油。如果每個安全漏洞都受到低優先順序的影響，安全漏洞就永遠無法修正，而侵害事件的風險也會增加。每個機構的資源有限，因此您需要建立嚴重性排名。這項排名機制可協助貴機構瞭解安全漏洞的嚴重程度，以及與各嚴重性相關的預期修復時程。草擬一組嚴重性準則，並與機構組織中的重要相關人員分享，取得意見回饋。舉例來說，如果工程涉及到建構嚴重性標準，這些標準就較有可能認同這些標準，並在修正特定時間範圍內修正安全漏洞時遵循這些標準。這些嚴重性指南可能會根據貴公司獨有的風險而有所差異。建議您透過威脅模擬練習，思考哪些威脅最有可能對貴機構影響，並納入各嚴重性類別的問題示例。以下是金融機構的嚴重程度標準和修復時程範例。
| 嚴重性 | 說明 | 修復時程 | 範例 |
|---|---|---|---|
| 最高 | 會對我們的使用者或業務造成立即威脅的問題。 | 擁有者： 應在 8 小時內找到負責確保安全漏洞修正的主要擁有者。視需要呼叫和專頁資源，包括一般營業時間。 修正方式：問題應盡快修正，或至少在三個工作天內緩解風險。 |
入侵包含所有使用者財務記錄的實際工作環境資料庫。 攻擊者設法取得商業機密，例如我們擁有的專屬投資演算法。 發生未公開的事件，包括攻擊者取得內部網路或敏感實際工作環境系統的存取權。 |
| 高 | 這類問題會帶來重大損害。 | 負責人：應在一個工作天內識別主要擁有者。 修正方式：10 個工作天內 (約 2 週)。 |
可能導致使用者存取敏感使用者資料或功能的安全漏洞 (例如任何使用者竊取他人資金的能力)。 |
| 媒介 | 不易遭利用或不會直接造成損害的問題。 | 負責人：應在五個工作天內確認主要擁有者。 修正方式：20 到 40 個工作天內 (約 1 到 2 個月)。 |
由自動掃描工具找出的已驗證問題，例如沒有已知的漏洞為安全性更新的修補程式。 資訊揭露問題，可能有助於進一步攻擊。 可能會遭惡意運用的頻率限制問題 (例如持續猜測使用者密碼)。 |
| 低 | 影響最小的問題；主要用於記錄已知問題。 | 無須在指定的時程內尋找擁有者或進行修正。 | 不會有潛在風險的資訊揭露，但這類資訊不需要對外公開。 |
理性錯誤
我們現在不討論理髮，也就是如何確保錯誤格式正確，以便輕鬆修正錯誤。請按照上一個資料表做為指南，自行建立嚴重性定義。這些定義可用於將錯誤分為多種嚴重程度，並傳達給擁有者。
除了指派每個安全漏洞的嚴重性外，您也必須確保錯誤採用標準格式，以利接收團隊處理。安全漏洞會以各種格式進入您的安全漏洞管理程序，例如自動掃描工具結果，或由安全性審查手動寫入。請花點時間將每個安全漏洞轉換為標準格式，讓接收團隊能快速理解並解決問題的機會增加。
此格式或範本可能會因您的機構而異，以及最有用的資訊，可協助擁有者修正獲派的錯誤，但您可以使用以下範本。稍後為研究人員建立安全漏洞揭露計畫提交表單時，您即可重複使用這個範本。
標題：<一行說明，通常該安全漏洞類型以及受影響的資產/服務等。 視需要加入嚴重程度，或將嚴重程度對應到問題追蹤工具中的特定欄位> 摘要：<簡要說明這項漏洞及其重要性> 重製步驟：<如何顯示相關漏洞，說明該漏洞可能如何影響，以及受影響的資產/服務等。 重製步驟：以下是潛在高嚴重性的安全漏洞示例：
Title: [HIGH] 個人資料頁面中的不安全直接物件參考資料 (IDOR) 摘要：我們在應用程式的個人資料頁面功能中發現 IDOR，可讓任何使用者在未經授權的情況下，查看及編輯其他使用者的個人資料，包括對方的全名、住家地址、電話號碼和出生日期。經審查記錄後，我們似乎尚未發現這個問題。這個問題是內部發現。重現步驟：
- 設定 Proxy (例如 Burp Suite) 以攔截已安裝應用程式的行動裝置流量。
- 前往個人資料頁面，然後攔截相關聯的 HTTP 要求。
- 將 profileID=###### 修改為 profileID=000000 (這是測試使用者)，並隨著 HTTP 要求傳送。
- 應用程式會顯示使用者 000000 的個人資料，您將能查看及編輯他們的資訊。
攻擊情境 / 影響：任何使用者都能利用這個安全漏洞，查看及編輯其他使用者的個人資料。在最糟的情況下，攻擊者可能會將整個系統中每位使用者的設定檔資訊擷取程序自動化。雖然我們目前應該遭到他人濫用，但請務必將這個問題視為標準的「高」嚴重性問題。如果我們觀察到利用情形，可能會嚴重提升至「嚴重」的嚴重程度。 修復步驟：實作伺服器端檢查，確保提出要求的使用者應有權查看/編輯透過 profileID 值所要求的設定檔。舉例來說，如果 Alice 登入且擁有 profileID 123456，但 Alice 觀察為要求 profileID 333444，則使用者應會看到錯誤訊息，而嘗試存取其他使用者的設定檔時，系統應記錄這項嘗試。如要進一步瞭解 IDOR 和修正方式，請參閱此錯誤的 OWASP 相關資料。
您可以設法將各種來源的安全漏洞自動轉換為標準格式，藉此節省時間和手動作業。建立安全漏洞時，您可以在修復步驟中找到共同主題。除了一般錯誤格式範本之外，您也可以針對常見安全漏洞類型建立其他範本。
尋找擁有者
漏洞管理中，最棘手的其中一個就是識別擁有者協助修正錯誤，以及取得他們的認同，將資源分配到實際修正錯誤的進度。如果您已設定資產管理程序，這個部分會更為簡單。如果不是的話，這或許會做為達成此目標的動機。視貴機構的規模而定，尋找擁有者可能相當簡單或非常複雜。隨著貴機構的規模擴大，判斷新發現的安全性問題的負責人員同樣加劇了。請考慮實作作業輪輻輪替。值班人員則負責審查未指派的安全漏洞、追蹤擁有者，以及依據嚴重程度排定優先處理順序。即使您能夠找出安全漏洞的修正者並指派給錯誤，您還是需要說服他們實際修正問題。這個方法可能因團隊或個人及他們所處理的其他項目而異。如果您已按照嚴重程度標準和修復時程獲得機構認可，可以參考這些標準，但有時可能需要請特別親臨才能修正錯誤。以下是修復安全漏洞的一般提示：
- 說明原因： 如果有人指派要修正的安全漏洞，通常是非預期的工作。請說明這個問題為何需及時修正 (例如影響 / 攻擊情境)，並確保擁有者瞭解這個問題。
- 收集背景資訊：在某些情況下，只有一人具備修正錯誤的知識，而他們可能有其他正在處理的工作。請花一些時間找出這些漏洞，因為其他工作可能比近期的安全漏洞修正還更重要。展現對修復時程的同理心和彈性，將有助於您贏得良好機會，並鞏固與修正安全漏洞所需的人士的關係。請注意，不要釋出太多資源，否則貴機構不會認真考慮您的修復時程。
- 說明方法：即使錯誤包含修復建議，修正問題的擁有者仍可能會感到困惑，或需要幫助瞭解如何修正錯誤。如果他們需要協助，瞭解如何修正，請向他們說明。 如果只是向擁有者回報錯誤而未提供協助，就會傷害機構與安全性團隊的合作關係。盡可能協助他人，將有助於修正目前和日後的安全漏洞，並協助教導他人。
- 調整要求： 各個團隊和個人可能已採取現有程序，以瞭解如何接受及排定待處理的工作要求。有些團隊可能會想將所有傳入要求都送交主管。有些人則想以標準格式提交協助要求。部分模型僅能處理衝刺中預先定義的項目。無論是什麼情況，都建議您花一些時間調整要求內容，以便讓團隊或個人通常用來提出要求的格式，讓我們有機會優先處理並採取行動。
- 僅在不得已的情況下提報：如果您已嘗試上述所有方法，而負責修正安全漏洞的個人或團隊沒時間修正嚴重安全性問題，請考慮視需要向主管提報。您應一律不得不這麼做，因為這可能會破壞您與相關人員或團隊的關係。
根本原因分析
除了找出並修正個別安全漏洞外，執行根本原因分析 (RCA) 還能協助您找出並解決系統性安全性問題。每個人都因資源有限，所以可能會不想執行這個步驟。不過，投入時間來分析安全漏洞資料的趨勢，並進一步探究重大和高嚴重性錯誤，有助於節省時間並降低風險。舉例來說，假設您發現應用程式中不斷出現相同的安全漏洞類型 (例如意圖重新導向)。您決定與導入這個安全漏洞的團隊討論，並使大部分團隊無法瞭解意圖重新導向的原因、重新導向的重要性或預防方法。我們整理了一份講座和一份指南，協助您向貴機構中的開發人員說明這個安全漏洞。這項漏洞可能不會完全消失，但出現率可能會降低。啟動 VDP 時，第三方回報的每項安全漏洞都會從現有的內部安全性程序取得。從 VDP 針對錯誤執行 RCA 即可進一步深入分析，如何有系統地改善安全性計畫。
偵測與回應
偵測與回應指的是您為了偵測及回應可能針對組織發動的攻擊，所採取的任何工具和程序。這可能是購買解決方案或自行開發的解決方案，用來分析資料，以找出可疑行為。舉例來說，在破產錯誤一節中，我們談到每當使用者嘗試在未經授權的情況下存取另一位使用者的設定檔時，系統都會記錄事件。如果您發現有使用者在短時間內嘗試存取其他使用者的個人資料，並收到大量失敗的嘗試，系統可能就會產生信號或快訊。您甚至可以自動封鎖相關程序，禁止使用者在一段時間內存取您的任何服務，或是無限期地封鎖直到可手動審查及還原存取權為止。如果您目前還沒有偵測與回應機制，請考慮與專家顧問合作，協助您為貴機構打造數位鑑識與事件回應 (DFIR) 計畫。如果您目前已經有偵測和回應機制，不妨考慮是否有五、十，甚至一百個安全性研究人員對網際網路攻擊途徑進行測試的影響。這會對現有 IDS/IPS (入侵偵測和預防系統) 產生重大影響。
潛在風險包括：
- 快訊超載：大量看似惡意攻擊的快訊或信號，但實際上是來自參與 VDP 的安全研究人員的正常核准測試。產生的雜訊可能會過多，使您難以區分實際攻擊和正當的安全性測試。
- 事件回應假警報：如果您安排在星期六凌晨 2:00 將網頁顯示給相關網頁的使用者，對於喚醒及調查的潛在侵害情況，實際上只是安全性研究人員執行合法測試的情況，他們就不會感到很開心。
- 封鎖安全性研究人員：如果您設置了敏感的 IPS (預防入侵系統)，最後可能會封鎖試圖執行掃描作業的安全性研究人員的 IP 位址，或是進行手動測試等，藉此找出安全漏洞並回報給您。尤其是在 VDP 的情況下，如果安全性研究人員在測試五分鐘後就遭到封鎖，可能會失去興趣，並轉而專注於其他機構的計畫。這可能會導致安全性研究人員整體並未參與您的計畫，進而提高未發現的安全漏洞，以及貴機構所不知道的安全漏洞。雖然您可能不想過度減少 IPS 本身，但您可以採取其他措施來降低流失研究人員的風險。
因應這些風險的方式，主要取決於與外部安全性研究人員合作採用的方式。如果您需要更黑箱的測試方式來模擬實際攻擊，您可能不執行任何操作。在這種情況下，研究人員的流量會產生快訊，而您的團隊可能會採取行動調查問題並做出回應。這將有助於您的團隊練習回應看似真實攻擊的行為，但可能會降低安全性研究人員的參與度，特別是當他們無法進行測試時。這也可能導致在進行合法測試時錯失真正的攻擊。如果您需要更多灰色方塊方法，可以考慮與安全性研究人員合作，自行識別其測試流量。這樣就能將流量加入許可清單，或篩除來自測試和產生的快訊。您的團隊將能夠更明確地區分真實攻擊與已核准的測試，研究人員將能尋找及回報安全漏洞，而不會受到您的入侵預防系統的影響。有些機構會要求安全性研究人員提交表單，以申請專屬 ID。這個 ID 可附加至研究人員產生的要求標頭中。這樣一來，機構就能將研究人員的流量加入許可清單，還能判斷研究人員是否開始超出商定的測試「範圍」。如果發生這種情況，您可以與研究人員聯絡，並要求對方保留，直到雙方合作進行測試計畫為止。