當安全性左移還不夠時

讓我們開門見山地說：威脅建模是一個持續循環的過程。它以明確的目標開始，然後是分析和採取相對應的處置行動，然後再重複這一個過程。威脅建模並不是萬靈藥──它並不能解決你的所有安全問題。威脅建模也不是一個指向網站或是程式碼儲存庫的雷達，一鍵生成可供勾選的項目清單列表。如果你讓團隊中適當的人員參加，則威脅建模是一個合乎邏輯推導且充滿智慧的過程。它會將設計考量和執行步驟進行充分討論，並使其更為清晰與完整。這些過程都需要團隊成員一同付出工作時間與專業知識來參與。

威脅建模的第一條規則可能是古老的格言「垃圾進，垃圾出」（garbage in, garbage out）。如果你將威脅建模作為團隊工具箱的一部分，並讓每個人都以積極的方式參與其中，你將獲得很多好處；反之，如果你並沒有充分理解威脅建模的強處與弱項，或並沒有全心全意的投入其中，只把它當成一個「檢查項目表」，那這個過程就只是一個浪費時間的行為。

為什麼需要威脅建模

了解你的系統中可能出現的問題以及你可以透過做些什麼來增加你對所交付內容的信任，這才能讓你可以自由地專注於系統的其他方面。這就是威脅建模需求背後的真正原因。

相同地，正確理解你不需要威脅建模的原因，也是很重要的事情。威脅建模並不能解決你所有的安全問題；它也不會立即將你的團隊轉變為安全專家。最重要的是，你不需要透過使用它來符合什麼安全規範。如果執行安全性實踐措施只是為了在符合規範的檢查表中打勾，那比什麼都沒做更令人沮喪。

責怪開發人員不知道一些基本且重要的資安知識是不公平的。況且市場上的訓練機構，主要專注於交付商業導向的目標給開發人員，例如系統合規性，藉此滿足訓練機構的培訓目標及其他各種指標，在如何傳達有效、實用的安全內容給開發團隊並協助他們轉化成知識和實務操作方面，我們其實還有很大的進步空間。

安全專家的任務之一是促進開發者社群的資訊安全教育發展。這包括如何開發出安全的系統，以及開發完成後如何評估程式碼和系統的安全性。為了達成這個目標，使用一些昂貴的資安工具往往可以補足公司或組織內尚未發展的資訊安全專業量能，但是使用工具的作法也會對使用者大幅地隱藏工具背後的專業知識。如果開發團隊成員能更了解工具背後的偵測方法，而不僅僅只是使用它，那麼團隊將獲益匪淺。以下是只會使用但卻沒有深入了解背後原理的例子：

●簡單又有效的掃瞄器和靜態程式碼分析工具往往號稱採用人工智慧、機器學習、污染分析、攻擊樹以及某種神祕力量，但卻無法始終如一地產生相同的結果，或者給出的誤報比實際有用的答案還多。更甚者，分析工具往往希望等整個系統準備好了再執行掃描，此一做法與現代的持續整合/持續開發（CI/CD）軟體開發方法相悖。

●顧問諮詢服務通常是被請求時才參與執行安全業務，往往都是忽然地出現，執行補救措施或教育訓練，然後便揚長而去。這在我們眼中就像海鷗一樣，牠們猛然地撲了過來，在你們身上拉了坨屎，再拍拍屁股走人，留下開發團隊自行處理後果。太過於依賴即時的安全顧問會帶來不利的長遠影響，因為資訊安全顧問並不是團隊成員，或許也並非公司的一員，顧問的利益與團隊目標無關，因此他們不會注重自己工作成果的長期影響。

身為安全專家的我們也在組織內給開發人員製造了一種錯誤的期望值，例如以下的例子：

●一個組織可以透過購買行為來獲得它的安全性態勢。如果組織在資訊安全工具上投入足夠的資金，那麼它將解決所有的安全問題。

●每一季必修30分鐘資安訓練課程就足以讓開發團隊學習到公司對他們的期望目標，同時也能通過公司的稽核標準。且基於這些一流的訓練內容，開發團隊採用訓練內容中的工具也一定會保持警覺，並驗證團隊是否確實地遵循安全守則完成工作。

最近（自2019年年中以來）資訊安全產業已經慢慢地接受安全性左移的概念。想像一下你要從左到右進行閱讀，而這個流程的起點在左端。當我們說左移的時候，意思是不論團隊使用什麼樣的開發方法，我們希望將安全實踐措施盡可能地移動到開發工作流程中的起點去執行。這樣做可讓潛在的資安事件發生並儘早得到處理。此外，與設計密切相關的資訊安全考量應該在系統的開發生命週期中儘早參與，例如威脅建模。如果你們團隊尚未採取這樣的措施，那麼現在應該即刻實踐。

隨著軟體開發流程日益進步與變化，傳統上由左至右的開發週期的線性程度變得愈來愈低，使得安全性左移可能無法滿足系統中的所有安全需求。相反地，安全性左移在社群發展中日漸重要，在一個資訊系統開始考量其安全性之前，資訊安全社群需要被視為個體並進一步左移走進開發人員和設計師的日常工作。在這個出發點之上，我們將需要專注於培訓開發團隊做出安全的選擇，並帶來安全開發能力，從而在更基本的層面上避免威脅。

依照資訊安全產業的整體培訓工作成果，我們預期看到資訊安全被落實在開發流程上的安全性左移，並在實作階段上以容易理解的語意和以邏輯化的程式碼所表達。但是如果前述的訓練失敗了呢？我們有哪些可能的糾正措施來糾正失敗的假設？

讓我們從另一個角度來看，然後將各個部分連接成對這個情境的連貫回應。在討論安全策略時，有些人會以「在餐桌上的位置」來比喻安全資源的分配與優先處理事項。安全團隊和主管都希望「涉及的利益相關者」在「正在進行的討論」中為安全保留「一席之地」。好處是可以讓利益相關者釐清他們的需求，再從資源蛋糕中分得一杯羹。但是還有一個重要的資源沒有計算進來，那就是開發人員的時間和專注力。

來看看網頁開發人員的例子，如果一個網頁開發工程師在早餐前學了LAMP技術棧，那這個技術知識可能在午餐過後就變得過時了，因為此時整個資訊產業已經遷移到MEAN技術棧。然後MEAN技術棧或許在下午茶時間又被另一個閃亮的新技術給取代，直到MEAN技術棧本身進化成另一個新玩意兒，並重新加入這個輪迴。也難怪網路上有許多迷因圖談論工程師永遠有學不完的東西，並且那些學到的專業知識通常都很快就過時。然而，不論這些技術存活時間多久，它們每一個的確都帶來新的安全挑戰以及與安全相關的習慣用法和機制。當然不免俗地，每一個技術棧也擁有自己的安全遵守規範，而開發者們必須理解和整合這些使用習慣，以便有效地保護他們正在開發的系統。

如果網站不能關閉，而且網站的日常維運工作與開發人員學習新工具是在同一個時間進行，那又怎能期望網站安全性可以共享開發人員的時間與專注力，期待獲得比預期更多的收穫呢？

這就是十字軍東征的開始──正如Richard Feynman告訴我們的那樣：「教授原則，而不是公式。」在本書中，我們將專注於原則，以幫助你理解和思考哪種威脅建模較適合你的用途、它如何在你的特定使用案例中提供幫助，以及你如何才能最好地將它應用到你的專案和團隊之中。（本文摘錄整理自《威脅建模》導論，碁峰資訊提供）

圖片來源_碁峰資訊

 書名  威脅建模：開發團隊的實務指南（Threat Modeling）

Izar Tarandach, Matthew J. Coles／著

簡誌宏／譯

碁峰資訊出版

定價：680元

 作者簡介 

圖片來源_Amazon

Izar Tarandach

Izar Tarandach曾是橋水公司(Bridgewater Associates)的資深資安架構師，在加入橋水公司之前，他亦曾在歐特克公司(Autodesk)負責產品安全架構。

圖片來源_Horangi

Matthew J. Coles

Matthew J. Coles在博士公司(Bose)負責產品資安專案以及擔任產品安全架構師，在加入博士公司之前，他在易安信公司(EMC)的類比產品團隊任職資安架構師。