使安全成為軟體開發必要部分

Taien內部資安講座 II 使安全成為軟體開發必要部分

2013.01.16 @ Hiiir Inc.

Taien Wang<[email protected]>

英屬維京群島商時間軸科技股份有限公司新創事業部

大綱

• 使安全成為軟體開發必要部分

• 風險管理框架

• 七個接觸點

– 程式碼審核

– 體系結構風險分析

– 滲透測試

– 基於風險的安全測試

– 濫用案例

– 安全需求

– 安全操作

• 實際導入經驗

軟體安全 - 向左移動

• 問題越早解決越好

Building Security In 使安全成為軟體開發必要部分

• 微軟

– Security System Development Life Cycle, SSDLC

• Gray McGraw

– 軟體安全接觸點

– Software Security: Building Security In

Security System Development Life Cycle

0200400600800

CVE

軟體安全的三個基石

• 應用風險管理

– 風險管理框架(Risk Management Framework, RMF)

• 軟體安全的接觸點

– 微軟可信賴計算計畫(Mircosoft Trustworthy Computing Initiative)

– Gray McGraw接觸點: 程式碼審核, 體系結構風險分析, 滲透測試, 基於風險的安全測試, 濫

用案例, 安全需求和安全操作

• 知識

– 軟體安全知識: 原則, 方針, 規則, 弱點, 攻擊程序, 攻擊模式和歷史風險

– 知識類: 說明性知識, 診斷性知識和歷史知識

軟體安全接觸點(Touchpoint)

BSI有誰在用

• 美國國土安全部-國家網路安全處(NCSD)

• 美國國家標準與技術研究所(NIST)

• 國際標準化組織(ISO)

• 電氣電子工程師協會(IEEE)

誰該實行軟體安全

• 開發人員都要有資安的素養

– 建立一個軟體安全小組

– 不要在安全人員中培養軟體安全人員

– 從軟體人員中培養軟體安全人員

• Bill Gate, "Trustworthy computing", 2002

– 發給微軟員工的備忘錄

軟體安全在學術界情況

學校

University of California at Davis

University of Virginia

Johns Hopkins University

Princeton University

Purdue University

Rice University

University of California at Berkeley

Stanford University

Naval Postgraduate School

University of Idaho

Iowa State University

George Washington University

United States Military Academy at West Point

課程

Introduction to Computer Security

Computer and Information Security

Computer Security: An Intrusion Detection Approach

Foundations of Computer and Information Security

Computer Incident Detection and Response

Cryptography and Data Security

Penetration Analysis

Advanced Topics in Security

風險管理框架

• 理解商業環境

• 確定商業和技術風險

• 綜合考慮和確定風險級別

• 定義降低風險的策略

• 實施修復並驗證它們的正確性

七個接觸點

1. 程式碼審核

2. 體系結構風險分析

3. 滲透測試

4. 基於風險的安全測試

5. 濫用案例

6. 安全需求

7. 安全操作

1. 程式碼審核(1/3)

• 早期程式碼審核

– grep, find

– 詞彙分析

– 相關產品

• ITS4, Flawfinder, RATS

• 現在程式碼審核

– 抽象語法樹(AST)

– 相關產品

• 阿碼科技: CodeSecure

– http://www.armorize.com/codesecure/

• HP Fortify SCA

– 2010年8月17日, HP宣布收購Fortify Software

– http://www8.hp.com/us/en/software-solutions/software.html?compURI=1338812/

• IBM: IBM Security AppScan Source

– IBM收購Ounce Labs

– http://www-01.ibm.com/software/rational/products/appscan/source/

1. 程式碼審核(2/3)

1. 程式碼審核(3/3)

• 靜態程式碼分析流程

2. 體系結構風險分析(1/6) 簡介

• 風險分析

– 在軟體開發生命週期的某個特殊階段中確定風險和對風險評鑑的活動

• 風險管理

– 描述進行大量不連續的風險分析操作, 在整個開發過程中追蹤風險以及降低風險的策略性活動

• 術語

– 資產 Asset

– 風險 Risk

• 風險 = 發生機率 * 影響

– 威脅 Threat

– 弱點 Vulnerability

– 對策或者安全對策 Countermeasures and Safeguards

– 影響 Impact

• 可以從兩方面來分析：系統與法律

– 發生機率 Probability

2. 體系結構風險分析(2/6) 舉例

• 被SQL Injetcion攻擊的風險

– 一個系統要被成功的SQL Injetcion攻擊, 可能要具備以下兩個條件

• 必須要有惡意駭客或自動化的SQL攻擊

• 系統沒有做好SQL Injetcion字串淨化

– 如此才會產生被入侵的狀況

• 在此例中, 惡意駭客或自動化的SQL攻擊是外來的威脅，而系統沒

有做好SQL Injetcion字串淨化，則是自身的弱點

• 當其中一個要件不成立之時，都可能不會產生被入侵或攻擊之風險

2. 體系結構風險分析(3/6) 風險分析方法原型

• 盡可能地學習關於分析對象的知識

– 閱讀和理解範圍, 體系結構檔案以及其他的設計素材

– 與一組人員一起研究對象和討論解決方案

– 確定系統邊界和資料敏感度/危險程度

– 實際使用軟體

– 研究程式碼和其他軟體工程

• 確定威脅,並得出關於攻擊源的共識

– 討論軟體周圍環境的安全問題

– 對產品的工作方式展開辯論, 並確定存在異議或者含糊的方面

– 確定可能的弱點, 有時可使用工具或常見的弱點清單

– 分析攻擊程式, 並開始討論可能的修改方法

– 理解當前的和規劃的安全計畫

• 確定受到發生危害的可能性

– 分析利用弱點進行的攻擊

– 平衡控制威脅的數量, 並確定發生危害的可能性

• 進行影響分析

– 確定對資產和商業目標的影響

– 考慮對安全狀態的影響

2. 體系結構風險分析(4/6) 風險分析方法

• 基本步驟

– 攻擊抵抗力分析

– 不確定性分析

– 弱點分析

2. 體系結構風險分析(5/6) 對風險評鑑

• 開發降低風險的策略

– 推薦降低風險的對策

– 報告所發現的內容

• 仔細地描述主要和次要的風險, 注意他們造成的影響

– 提供一些基本資訊, 以說明如何使用降低風險的有限資源

2. 體系結構風險分析(6/6)

• 舉例

3. 滲透測試

• 開發環節的最後檢查而非最為安全狀態的最先檢查

• 幾乎所有滲透測試方法都依賴黑帽而非白帽

• 黑帽

– 破壞方法(destructivealtivity), 攻擊與破解程式相關方法

• 白帽

– 建設方法(constorutiveactivity) 設計與防禦功能相關的方法

• PTES:Penetration Testing Execution Standard

– 前期交互階段 Pre-engagement Interactions

– 情報蒐集階段 Intelligence Gathering

– 威脅建模階段 Threat Modeling

– 漏洞分析階段 Vulnerability Analysis

– 滲透攻擊階段 Exploitation

– 後滲透攻擊階段 Post Exploitation

– 報告階段 Reporting

http://www.pentest-standard.org/index.php/Main_Page

4. 基於風險的安全測試(1/2)

• 為了管理安全風險

– 創建安全濫用/誤用案例(以及安全特性和功能)

– 列舉標準化的安全需求

– 執行體系結構的風險分析

– 制定基於風險的安全測試計畫

– 執行靜態分析工具

– 進行安全測試

– 在最終環境中進行滲透測試

– 在安全被破壞後進行清理

4. 基於風險的安全測試(2/2)

• 安全測試兩種不同方法

• 功能性安全測試

– 測試安全機制以保證正確地實現了他們的功能

• 對抗性安全測試

– 執行通過理解和模擬攻擊者的方法而設計的基於風險的安全測試

5. 濫用案例(1/2)

• 常見攻擊模式

• OWASP Testing Guide 3.0

– 設定管理(Configuration Management Testing)

– 資訊收集(Information Gathering)

– 驗證(Authentication Testing)

– 連線管理(Session Management)

– 授權測試(Authorization Testing)

– 商業邏輯測試(Business logic testing)

– 資料驗證測試(Data Validation Testing)

– Web Services

– AJAX

• 主動提供客戶安全保障SLA

– 正確地實現安全特性(考慮加密和存取控制)

– 查找已知的安全瑕疵並確認他們不再存在

– 通過預先商定的第三方確認和驗證測試

– 使用程式法分析工具

5. 濫用案例(2/2)

• 濫用案例開發

• Abuse Case Development

6. 安全需求

• 資通安全三大基本目標

– 機密性 Confidentiality

– 完整性 Integrity

– 可用性 Availability

7. 安全操作

• 需求: 濫用案例

• 設計: 商業風險分析

• 測試計畫: 安全測試

• 實現: 程式碼審核

• 系統測試: 滲透測試

• 實際部屬系統: 安全的配置與操作

實際導入的經驗

• 每一次的改善過程

– 止血

– 收穫最容易得到的成果

– 打基礎

– 建立核心競爭力

– 開發獨特之處

– 擴展有用的能力

工商時間: 企業可實際套用方法

• 評測與規劃: 建立Code Style與統一防禦架構

• 建造與試用: 實際導入Code Style並修繕指導方針

• 宣傳與改善: 持續修改架構之安全, 可用與效率等, 創建Hiiir獨特開發架構

參考資料

• Gary McGraw, "Software Security: Building Security In", 2006

• Microsoft, "Simplified Implementation of the Microsoft SDL",

2010

• Michael Howard and David LeBlanc, "Writing Secure Code,

Second Edition", 2003

• Common Vulnerabilities and Exposures

• PTES: Penetration Testing Execution Standard