Categories
程式開發

GitHub:我們如何進行威脅建模


在GitHub,我們花了很多時間思考並構建安全產品,其中一個關鍵的方面就是威脅建模。 在這類實踐中,我們讓安全團隊與工程團隊齊聚一堂來討論系統,最終生成改善系統安全性的執行項目。 威脅建模可以促進安全團隊與工程團隊進行溝通,令安全審查進程更具有主動性,並使得系統的設計更可靠也更安全。

什麼是威脅建模?

在進一步討論威脅建模的方法前,我們先要統一一下理解。 定義進程的目標,有助於讓大家對結果建立預期。

在GitHub,威脅建模未必是指某個特定的工具或交付成果,而是一種過程,它會促進安全團隊與工程團隊就現有系統或新系統進行討論。威脅建模是一種安全協作實習,協助我們針對新服務或已有服務,進行設計及任務計劃的評估與驗證。該實習涉及了在思考對服務可能產生負面影響的潛在安全漏洞時,所需要用到的結構化思維。

每個威脅建模的對話都應當至少包含下列目標:

  • 首先,針對提議或已有的架構進行深入研究,確保所有人都理解系統的運作原理(如果沒有其他問題,這就行了。請用文檔記錄下來運作原理);

  • 然後,針對整體全局進行評估,找出最可能的漏洞點。 這些就是關鍵的交付內容;

  • 為每個漏洞點設計可執行的修復方案。 由於每個人的資源都不是無限的,很可能要安排優先級。

我們的威脅建模過程是怎麼樣的?

決定何時進行威脅建模

在GitHub,我們通常會在任何對架構產生重大改變的新功能發布前,以特定節奏針對各個功能團隊進行威脅建模。 根據單個功能所需的工程量,你可能需要加快節奏(每隔兩個月)或放慢節奏(每年一次)。 如果軟件審查已經設定了節奏,根據我們的發現,將其與那些已有的進程集成,有助於讓大家適應新安全進程的添加。 無論時間表如何,請設置指導並在實踐中靈活應用。

構建威脅模型

威脅建模通常屬於協作實習,因此,產品的工程團隊及安全團隊會聚在一起,討論整個架構以及潛在的安全問題。 我們的安全團隊會預先將有效威脅建模的文檔與案例提供給工程團隊。 我們通常要求各個工程團隊提前生成模型,並涵蓋系統的重要部分,作為單個的威脅建模對話來審查。 提早設立這些預期(並提前預習)有助於確保會議的效果。

不過相較於特定的輸出成果,這些進程和討論更重要。 在GitHub,我們要求工程團隊以微軟的威脅建模工具,或開放Web應用程序安全項目(OWASP)的威脅建模工具Threat Dragon(兩個都是免費的!)輸出威脅模型。 這些工具讓團隊能清晰呈現威脅模型的重要信息,如API、信任邊界、依賴關係、數據存儲、身份驗證機制等。 除了協助團隊保持一致性之外,需要遵守各種安全性要求時,這些文件也能作為重要的附屬內容共享給審計人員。

審查威脅模型

當審查威脅模型時,我們通常會安排一小時的會議,並將其分為兩部分。 每個會議的前5-10分鐘,用來幫助工程團隊理解要審查的系統的設計。 這個時間段,要確保所有人的理解達成一致,將準備好的威脅模型拿出來,澄清所有存在歧義的部分,包括要使用的技術,以及任何設計習慣。 在所有人都達成一致後,我們可以跳至安全討論環節。

在安全討論環節,我們發現:使用框架來系統處理不同的漏洞類很有效。 我們經常使用的方法之一是微軟的STRIDE模型,即欺騙、篡改、抵賴、信息披露、拒絕服務、特權提升,這是一種包含了可能在應用中發現的常見攻擊向量的記憶方法。 在查看總體系統時逐個檢查這些類,使得安全團隊能以整體方式查看正在分析的系統,並確保能涵蓋最常見的威脅。 談話深入,用STRIDE填滿提醒事項會佔據大半的會議時間,然後再確認系統的更多部分。

當發現潛在的安全漏洞或設計缺陷時,安全團隊會將它們與潛在的修復方案一併記錄下來,從而為工程團隊生成一張潛在變更的列表,留待會議後完成。 我們發現,隨著威脅建模成為整個GitHub更常見的做法,各個團隊都更習慣在開發系統的階段就讓安全團隊介入——這樣效果更好,有助於在敲鍵盤前,提前發現潛在的問題,確認大多的架構變更需求。 反過來,又有助於讓安全團隊通過安全設計原則,深入部署更好的防禦。

會議結束時,我們重新歷數關鍵的討論結果,包括團隊應當做出的發現及改進,並生成相應的追踪項目。 與會者都會收到一份摘要,並隨時可以就其提問,來更好地具體化要執行的項目。

我們從威脅建模中學到的東西

正如上文提到的,我们已经发现威胁建模的许多好处,正是这些好处推动了公司的安全意识文化。在我们的案例中,我们看到过三个显著的好处:

系統級的安全改善

坐下討論系統的簡單做法,為所有人討論底層系統提供了很好的機會。 團隊間的知識分享幫助所有人在這個環境中提高了對系統的了解。 這也有助於為在威脅模型審查期間所發現的問題制定減少漏洞的策略,從而改善了整個公司的安全狀況。

主動的設計指導

隨著威脅建模成熟起來,我們致力於“變動先行”,或者在開發階段提早著手,並在產品發行前建立會話機制。 安全團隊通常需要在問題發現時就做出回應。 但隨著公司調整進程,提早安排執行威脅建模,安全團隊有時可以從系統設計的角度,提供未來可能出現的漏洞,從而協助指導工程團隊。

增強安全團隊與工程團隊間的溝通

對於工程和安全團隊來說,這個好處帶來的轉變令人難以置信。 由於會讓安全團隊與工程團隊有規律的會面,威脅建模有助於在這些團隊間建立連接,從而使得兩個團隊的接觸更容易——彼此都是。

總結

再次重申,在GitHub我們包含了大量有助於提高安全建模的關鍵條目。 下面是我們執行進程的快速總結:

  • 將威脅建模進程合併到現有的開發生命週期進程中,並在可能時令其自動化;

  • 確保所有人做好準備;

  • 使用有定義的機制來系統化地涵蓋風險區域,比如STRIDE;

  • 會議結束時,總結好具體的執行項目;

  • 跟進。

通過跟進這些步驟,我們發現,針對正在開發的系統,我們可以提高其安全性,並主動與工程團隊合作(交付前),同時在參與軟件開發的團隊間建立起聯繫。

原文鏈接:

https://github.blog/2020-09-02-how-we-threat-model