金錢 x 安全 x 道德
Bounty Program 制度在這幾年來已經慢慢成行、不少公司已經有用各種方式提供相關管道。
為了讓外部資源 (研究人員) 提交有安全疑慮的資訊、讓產品與服務能夠更加安全，公司需要提供一個管道讓研究員可以提交報告 ，並提供獎勵制度讓研究員有動力提交、而不是直接公開資訊或賣給惡意的第三方。
建立 Bounty Program 對公司而言有一定的推力 (缺點) 與拉力 (優點)： 保守的公司對於公開資訊的接受度較低、對公開安全漏洞也抱持疑慮與擔憂，認為這對於公司的形象與品牌有負面的影響。 相反的、透過外部資源可以讓公司減少培養/聘雇相關人員的成本、也可以讓公司的產品與服務更加安全。
目前有不少平台提供相似服務，像是 Bugcrowd 、 HackerOne 、 Synack ，在台灣則有 HITCON ZeroDay 。 這些平台提供了一個平台串接公司與研究人員兩邊、讓公司減少建置成本，也可以讓研究人員有統一方式提報問題。 但公司可能希望報告不經過第三方、希望保留彈性、或者有預算考量，改而選擇建立自己的 Bounty Program 制度。
在開始之前可以先確定公司是否真的需要建立 Bounty Program，這需要考慮到公司預算、擁有的資源、以及預期的目標。 在公司發展初期、產品的設計與發展是第一優先目標，將資源投入在安全上可能不是最佳的選擇，因此建立 Bounty Program 就不會是最佳的選擇。但對於擁有成熟產品、擁有一定規模與預算的公司，已經將穩定、安全、以及品牌名聲視為重要目標， 建立 Bounty Program 就是一個不錯的選擇。
下面會根據過往建立 Bounty Program 的經驗、介紹需要考量的幾個部分：
- 定義 Bounty Program 的範圍 (與排除範圍)。
- 處理機制與流程。
- 檢視與調整 Bounty Program。
Setup
在建立 Bounty Program 前要先確認公司的預算、資源、以及目標，這些都會影響到 Bounty Program 的設計。
Bounty Program 活動建構在獎勵 (Bounty) 上。研究員會花時間研究與提交報告，都為了物質上或者精神上的獎勵。 不同的獎勵會吸引到不同等級與專長的研究人員、也會影響到其投入程度。獎勵範圍則侷限研究人員的投入方向、同時暗示公司對其重視程度。 最後整個運作流程將決定 Bounty Program 的成敗、也會影響到公司的資源投入。
Scope
每一個 Bounty Program 都會預先定義好獎勵範圍 (Scope)，這會影響到研究人員的投入方向。
範圍包含 (但不限於) 產品、服務、網站、行動應用程式、API Server、硬體等，定義哪些是屬於公司產品與服務。 其中還會細分哪些屬於有效 (eligible) 的安全問題或者漏洞、哪些會被判定為範圍之外的 (Out of Scope)、而那些不屬於安全問題。 在範圍之下還可以針對不同的產品或服務的特性，定義不同的獎勵範圍、以及定義哪些是不被允許行為，像是 DDoS、SPAM、Phishing、 Social Engineering 等。
透過定義無效的問題與範圍外的問題、可以讓研究人員專注在有效問題、避免研究人員的誤解而提交無效的報告， 造成資源浪費與不必要的爭議。
Verify
在建置階段需要定義不同問題的危害程度 (Severity)、這也跟後續的評估獎勵有關。
問題的危害程度可透過 CVSS 3.0 評分來判斷。CVSS (Common Vulnerability Scoring System) 是一個公開的評分系統， 目前定義到 3.0 版本 。這個評分系統用相同的方式、對於不同的問題給予對應的分數，對於熟悉這個系統的研究人員跟公司、 可以透過分數快速評斷問題的危害程度。這個系統將安全問題分為三個部分：基礎評分 (Base Score)、暴露評分 (Temporal Score) 與環境評分 (Environmental Score)。
基礎評分 (Base Score) 代表問題本身的危害程度，這個分數是不會改變的。暴露評分 (Temporal Score) 代表問題的危害程度會隨著時間改變， 例如問題已經被修正、或是攻擊者已經有能力利用問題。環境評分 (Environmental Score) 代表問題的危害程度會隨著環境改變， 例如問題存在於內部網路、或是存在於 DMZ 網路。在評估問題危害程度時、可以簡單評估基礎的 CIA 三個維度，也就是 Confidentiality (機密性)、Integrity (完整性) 與 Availability (可用性)，這三個分別影響的安全問題。 這三個維度可以快速判斷問題的嚴重程度。當一個問題同時影響到這三個維度時、這個問題的危害程度就會很高。
- Confidentiality：機密性代表資料的機密性、判斷資料是否會洩漏。
- Integrity：完整性代表資料的完整性、判斷資料是否會被竄改。
- Availability：可用性代表資料的可用性、判斷資料是否會被破壞。
Reward
獎勵則是 Bounty Program 的核心：為了讓外部研究人員有動力提交報告，公司需要提供一個獎勵制度吸引研究人員。 這邊的獎勵可以是物質獎勵 (像是金錢、禮物、紀念品等) 或者精神獎勵 (像是感謝信、感謝狀、感謝名單等)。
明確定義好的獎勵讓整個 Bounty Program 的運作更加透明、吸引到更多的研究人員參與。 獎勵制度困難的點在於如何將危害程度跟獎勵連結起來。每一間公司對於 Bounty Program 有不一樣的預算、預期得到的報告也不盡相同。 透過公開的獎勵標準、可以讓研究人員知道自己的報告會得到什麼樣的獎勵，也可以讓公司預估獎勵的成本。
一個模糊的標準則會讓整個 Bounty Program 有爭議、讓研究人員對於整體活動產生疑慮、也會影響到研究人員的投入程度。 過於寬鬆的評估機制讓研究人員、提交大量的低危害程度的報告，這樣的報告對於公司的幫助不大也提高公司成本。而過於嚴格的評估機制， 會讓研究人員不願意提交報告，也讓研究人員印象變差而選擇將報告提交地下市場。
Example
用 Amazon 為例、他是透過 HackerOne 提供 Bounty Program 的服務。
在一開始的 Rewards section 中定義了獎勵的範圍與金額、這也是大多數賞金獵人 (Bounty Hunter) 所關心的部分。 透過 CVSS 3.0 評分來判斷獎勵的金額、根據危害程度給予以下的獎勵。可以看到、這邊將危害程度分成五個等級、 不同等級也對應的不同獎勵金額。
| SEVERITY | Amount (in USD) |
|---|---|
| Critical | 10,000 ~ 20,000 |
| High | 1,500 ~ 5,000 |
| Medium | 350 ~ 500 |
| Low | 150 |
| Biz Accepted Risk or Informational | 0 |
在個 Policy Section 則定義了 Scope 與 Out of Scope：這邊定義哪些服務、產品，同時也說明在 AWS IP Space 下的 IP 則不在獎勵範圍之內。其中也提到一個有效 (eligible) 的報告必須包含以下幾個部分 (節錄)：
- 詳細的描述。
- 禁止使用暴力破解 (Brute Force)、DDoS 攻擊等。
- 禁止入侵或測試不屬於你的帳號。
最後明確列出哪些問題的危害範圍 (Severity Range)、以及哪些問題不被視為是安全問題 (Non-eligible Vulnerabilities)、 以及哪些不在這次獎勵範圍 (Out-of-Scope Issues)。這樣可以讓研究人員清楚知道哪些問題可以提交、哪些問題不可以提交， 同時公司也可以避免收到不必要的報告。
Process
建立好完整的 Bounty Program 後就需要訂定相關的處理流程。一個好的流程會有良好體驗、更加吸引研究人員投入， 流程的設計也會影響公司的資源投入。這不是一個單向或不能改變的的流程，他是一個循環且持續改變、根據不同的狀況而改變的處理方式。
處理流程代表從接收報告開始、獎勵研究人員、到最後修正問題的整個流程，其中包含了以下幾個部分： 接收報告 (Receive)、驗證報告 (Verify)、修正問題 (Fix) 與獎勵 (Reward)。
Receive
一個好的管道可以讓研究人員有動力提交報告、也可以讓公司有效管理報告。
當接收到研究人員的報告時、需要明確回覆給對方、讓對方知道報告已經收到。這是一個重要且不能避免的步驟。 在收到報告的同時給予研究人員初步回覆、讓研究人員知道報告的狀態、以及下一步的流程。 在這個步驟可以讓雙方建立起信任、讓研究人員知道公司已經收到報告並正在處理。對於研究人員來說、這是一個很重要的部分。 少了這個部分、研究人員可能認為溝通管道失靈、或公司私下修復問題而不給予獎勵。這會讓研究人員對於公司產生不信任感、 進而不願意提交報告或將報告轉賣給地下市場。
一個好的初步回覆可以明確定義在 Bounty Program 的規則下，像是定義會在 24 小時內給予初步回覆、 超過時間就可以判斷是回報機制失效，研究人員就可以重複提報或選擇其他的回報機制。
接下來則根據公司的政策與習慣、將收到的報告儲存在獨立的 Bug Tacker 中。這個步驟可以讓公司有效管理報告、 讓對應的工程團隊可以知道哪些問題需要處理。這邊的獨立系統、是為了避免其他公司成員看到報告、導致額外的資訊外洩風險。 透過最小權限原則 (Principle of Least Privilege)、僅讓 Bounty Program 以及相關成員可以看到報告，降低不必要的安全疑慮。
Verify
當公司接收到報告且給研究人員初步回覆後，接下來就是驗證報告的內容。 公司首先確認提交安全問題是否存在，也就是重製問題 (Reproduce)。
一個好的報告可以讓公司簡單且快速的重製問題，但部分報告提供的資訊不足而無法重製問題時、這時候就需要跟研究人員來回溝通， 請研究人員提供更詳細的資訊。這時候就需要一個良好且有效的溝通管道、讓公司可以快速的跟研究人員互動、找出問題所在並快速釐清問題， 進而重製問題。確認可以重製問題時也需要判斷問題的危害程度，這時候就需要讓相關團隊來判斷問題的危害程度。 之後就進入到修正問題的階段。
對於報告本身、可以請研究人員提供 PoC (Proof of Concept) 讓公司可以重製問題。但這邊需要注意 PoC 本身的安全性與可靠性。 公司成員使用 PoC 驗證問題時、最好在一個獨立環境中測試，避免因為測試導致產生額外的安全問題。
Fix
透過提交的報告以及重製的結果、公司方面已經確認問題存在且判斷其危害程度，接下來的則是修復這個問題並釋出修正版本。
對於功能性的 Bug 而言、公司修正問題後就可以釋出修正版本。 但對於安全性的問題、修正本身可能會影響到使用者的體驗、影響原本的功能、或者需要移除整個功能。 這部分需要跟對應的開發團隊討論跟確定修正的方向。
當決定好修正方向時、也可以跟研究人員討論，確定修正方式是否正確、是否有修正問題、或有有延伸的安全性問題等。 這部分可以根據公司政策、提供給研究人員測試版本或測試環境，
跟正常的問題修正 (Bug Fix) 一樣、根據公司的規模與習慣將問題寫成一個 Regression Test ， 確定相同的問題不會在若干次版本後再次出現。同時也根據這份報告、重新檢視現有系統是否存在相似的安全性問題。
Reward
在整個 Bounty Program 的最後流程中、就是根據危害程度評斷獎勵的範圍。
在這個階段可以根據 Bounty Program 建立時候的機制、計算出對應的獎勵範圍，同時可以根據研究人員的表現調整獎勵。 像是一個完整且詳細、同時給予修正方向與建議的建議，就可以給予額外的獎勵。
除了給予物質獎勵外、公司方面也可以選擇提供致謝 (Acknowledgement) 感謝研究人員，讓研究人員的付出得到肯定。
Review
運作Bounty Program 一段時間之後，站在公司角度需要回顧整體的運作狀況、並根據狀況調整 Bounty Program 的設計。
當事件結案時可以在團隊內簡單回顧整體流程跟運作狀況，同時根據運作狀況調整 Bounty Program 的運作方式。 像是負責的團隊、是否在第一時間給予研究人員回覆、判斷問題的標準是否符合實際情況等。
當運作到一個週期時 (像是一季或者半個年度) 就需要整理一份運作報告，其中包含多少份報告提交、有效的報告數量、 問題危害程度的比例、修正問題的時間、獎勵發放分析等。這份報告可以讓公司了解 Bounty Program 的運作狀況、 也能夠讓公司高層理解 Bounty Program 帶來的價值與效益。同時間、也可以根據報告調整 Bounty Program 的設計。 像是修改獎金的範圍、調整獎勵的方式、調整獎勵的標準等。