目前安全測試通常都存在以下問題:數據庫
目前的狀態:安全
基於以上兩點須要一套完整的,連貫的方法指導安全及業務特性的安全測試設計,TM(ThreatModeling,威脅建模)安全測試設計方法應運而生。網絡
威脅建模的本質:儘管一般咱們沒法證實給定的設計是安全的,但咱們能夠從本身的錯誤中汲取教訓並避免犯一樣的錯誤。測試
TM主要的理論、實踐來源是微軟的STRIDE威脅建模方法論,它從6個維度來考察系統設計時存在的來自外部威脅的風險點。網站
首先須要知道什麼樣的設計是「安全的」,安全設計原則:編碼
設計 | 安全原則 |
---|---|
開放設計 | 假設攻擊者具備源代碼和規格。 |
故障安全預設值 | 出故障時自動關閉,無單點故障。 |
最低權限 | 只分配所需的權限。 |
機制經濟性 | 保持簡單、易懂的特性。 |
分離權限 | 不容許根據單一條件執行操做。 |
整體調節 | 每次檢查全部內容。 |
最低公用機制 | 注意保護共享資源。 |
心理可接受性 | 他們將使用它嗎? |
更進一步,設計完的系統應具備哪些安全相關的屬性?加密
安全屬性 | 詳細 |
---|---|
機密性 | 數據只應限具備權限的人員訪問。 |
完整性 | 數據和系統資源只限適當的人員以適當的方式進行更改。 |
可用性 | 系統在須要時一切就緒,能夠正常操做。 |
身份驗證 | 創建用戶身份(或者接受匿名用戶)。 |
受權 | 明確容許或拒絕用戶訪問資源。 |
承認 | 用戶沒法在執行某操做後否定執行了此操做。 |
STRIDE是這6個維度的單詞的首字母的縮寫;這6個維度分別爲:設計
下圖對這六項信息各自進行了距離:日誌
屬性 | 威脅 | 定義 | 例子 |
---|---|---|---|
認證 | Spoofing(假冒) | 冒充某人或某物 | 假冒billg、microsoft.com或ntdll.dll |
完整性 | Tampering(篡改) | 修改數據和代碼 | 修改一個DLL,或一個局域網的封包 |
不可抵賴性 | Repudiation(否定) | 宣稱未作過某個行爲 | 「我沒有發送email」 「我沒有修改文件」 「我確定沒有訪問那個網站」 |
機密性 | Information Disclosure(信息泄露) | 暴露信息給未經受權的訪問者 | 容許某人閱讀Windows源代碼;將客戶列表發佈在網站上 |
可用性 | Denial of Service(拒絕服務) | 使對服務對用戶拒絕訪問或降級 | 發送數據包使目標系統CPU滿負荷或發送惡意代碼使目標服務崩潰 |
受權 | Elevation of Privlege(權限提高) | 未經受權獲取權限 | 遠程用戶執行任意代碼,普通用戶能夠執行管理員私有的系統指令 |
不少安全從業者所接受的安全認知每每是進入一家企業後,拿到一份名爲應用開發安全標準的文檔,裏面描述了訪問控制、輸入驗證、編碼過濾、認證鑑權、加密、日誌等各類要求,長此以往就變成了一種慣性思惟,實際上之因此要這麼作是由於在系統設計的某個環節存在STRIDE中的一種或幾種風險,因此在那個設計關注點上要加入對應的安全措施,並非在全部的地方都要套用所有的或千篇一概的安全措施。不然就會變成另一種結果:「過分的安全設計」。orm
威脅建模的成果跟工做者自身的知識也有很大的關係,有攻防經驗的人比較容易判斷威脅的來源和利用場景,若是缺乏這方面的認知,可能會發現處處是風險,有些風險的利用場景不多或利用條件很是苛刻,若是一味地強調風險削減措施也會變成有點紙上談兵的味道,雖然從安全的角度沒有錯,但從產品交付的總體視角看,安全仍是作過頭了。
STIRDE如何使用?首先咱們須要畫出數據流關係圖(DFD),以圖形的方式表示系統。數據流關係圖由數據流、數據存儲、進程和交互方四個元素標準符號組成。
- 數據流表示經過網絡鏈接、命名管道、消息隊列、RPC 通道等移動的數據。
- 數據存儲表示文本、文件、關係型數據庫、非結構化數據等。
- 進程指的是計算機運行的計算或程序。
而後咱們根據實際狀況另外增長了一個元素,即信任邊界。
添加信任邊界後,對每個節點元素和過程進行分析判斷是否存在上述6種威脅,並制定對應的風險緩解措施。
整體上看,STRIDE是一個不錯的參考視角,即使有豐富攻防經驗的人也不能保證本身在面對複雜系統的安全設計時考慮是全面的,而STRIDE則有助於風險識別的覆蓋面。