• SAMM 資訊安全軟體成熟度模型 – 驗證面

    SAAM Overview

    資訊安全驗證面分為三個子項目

    Verification = Design Review + Code Review + Security Testing

     

    這部分的驗證與測試多半與Quality Assurance部門比較有關

    Design Review (DR)

    DR 1 : 指出潛在被攻擊的點  + 分析資訊安全需求與設計的關係 

    DR 2 : 檢查資訊安全機制 + Design Review 結合到軟體開發過程中

    DR 3: 針對敏感性的資料描繪出 data flow + 對於 design review 訂定出合格的標準

    針對軟體的設計與架構進行評估。在架構上檢視是否會有潛在的資訊安全風險。

     

    Code Review (CR)

    針對程式碼進行評估驗證,就筆者公司為例,我們會依造不同語言程式碼,

    用相對應的工具進行自動化程式掃描,

    自動化程式掃描會根據程式弱點資料庫指出程式的弱點與需要改進的地方

    CR1: Code review 檢核表  + 高風險的程式法做 code review

    (Code Review checklist 應該要包含哪些要素呢? 這裡舉OWASP CheatSheet 為例,該 CheatSheet 提供一些建議,例如如何避免 SQL/XSS Injection等.

    https://www.owasp.org/index.php/OWASP_Cheat_Sheet_Series)

    CR2: 善用自動化分析工具 + 將程式碼分析整合到軟體開發流程中

    自動化程式碼分析工具有很多,例如 Klocwork 或是 IBM AppScan等。

    CR3: 針對應用程式進一步做相關分析 + 建立起產品出貨的品質標準

    例如,有些公司會就定義透過自動化分析工具的掃描結果,每千行必須低於 2 個瑕疵。

    Security Testing (ST)

    ST1: 針對資訊安全需求設計測試個案 + 進行滲透式測試

    ST2: 運用自動化測試工具 + 資訊安全測試至軟體流程中

    ST3: 針對應用程式進行資訊安全自動化測試 + 建立資訊安全測試的出貨標準

    這部分大部分由 QA執行,透過測試個案、各種工具的自動化、半自動化測試,

    並針對資訊安全品質訂出出貨標準,哪一些測試個案一定要通過才能夠出貨。

    Tags: , , , , ,

  •  

    microsoft Security model

     

     Microsoft Security model in SDLC

    微軟在軟體開發週期也定義每個過程所需要的資訊安全任務

    從教育訓練 >  軟體需求 > 設計 > 建置 > 驗收 > 上線 > 回應

    以研究開發部的團隊來說,成員不外乎是 QA/RD,比較會接觸到的是訓練、需求、設計、建置與驗收

    針對 IT Network Operation Team ,就會接觸到”上線”之後定期不斷地追蹤資訊安全等問題

    對於客戶技術支援部說 “Response “就很重要,當有事件發生時,如何對客戶溝通並採取適當的行動。

     

    SAMM 模型的差異

    這個模型大致的實際內容與 SAMM 模型類似,只是分類的方式有些不同

    SAMM 的分類主要以功能別來區分為四大類。資訊安全管理 (CSO) >  開發 (RD) > 驗證 (QA) > 上線佈署 (IT operation)

    Microsoft Security model in SDLC則是以軟體開發週期來說明每個環節應該要注意的項目。

     

    不論每一個政策與規範,最後都需要持續不斷的執行。才會有所效果。

    如果公司目前沒有或是預計導入一些資訊安全流程在軟體開發過程中,不防可以參考這幾個模型 方法。

     

    Tags: , , , , , ,

  • SAMM Construction

    資訊安全  – 開發面

    延續 SAMM (Software Assurance Maturity Model ),專案開發需要注意哪些項目呢?

    開發的過程主要參予的人員不外乎為研發團隊 (project managers, RD/QA)

    根據 SAMM 的建議,開發的過程中,在資訊安全的部分,主要有下列三個方向可以考慮:

    1. Threat Assessment (TA)  風險評估

    2. Security Requirements (SR) 資訊安全需求

    3. Secure Architecture (SA) 資訊安全架構

     

    接這讓我們分別看這三個方向,有哪一些具體的工作要執行

    1. Threat Assessment (TA)  風險評估

    每個軟體系統在執行時,潛在所可能帶來的風險為何?

    例如:該系統在做密碼傳輸時,是否有加密? 是否有被中途截取或是修改的可能性?

    TA 又分為三個階段

    • TA 1: 建立適當的威脅模型 (例如:登入的功能,潛在的威脅有密碼明文傳送、密碼cookie被盜用等..) + 建立駭客攻擊的模型
    • TA2: 建立潛在可能被濫用的模型 + 將威脅的類型案權重計算
    • TA3: 評估第三方工具使用的安全威脅 + 威脅模型與資訊安全控制

    以筆者公司為例,我們會針對每個產品所使用的 library,

    去檢查是否有已知的 CVE (Common Vulnerability Exploit),

    如果有重大的CVE,就必須要針對該 lib做更新

     

    2. Security Requirements (SR) 資訊安全需求

    這點指的是軟體的功能應該如何達到資訊安全的需求

    例如:密碼的複雜度,至少為8個字元。其中必須包含英文與數字等。

    • SR1: 從功能面定義資訊安全需求(例如密碼強度) + 評估資訊安全準則的需求 (例如:電子商務網站就必須符合PCI規範)
    • SR2: 建立控制的機制 + 針對已知的風險建立資訊安全需求(例如:敏感性資料一律用HTTPS/SSL加密的方式傳輸)
    • SR3: 將資訊安全規範導入至上下游供應商 + 資訊安全稽核

    由於有些公司的軟體或是開發工作為外包,所以就必須將這樣的資訊安全需求列入考量

    相關的資訊安全稽核也應該包含軟體需求分析的階段。

    例如:密碼的強度的規範、資料的加密傳輸、權限的管理、非法字元的檢查等。

     

    3. Secure Architecture (SA) 資訊安全架構

    整體的資訊安全架構,

    例如:帳號密法的驗證,都透過 Active Directory 整合方式進行。

    例如:資料的傳輸都是透過 SSL / HTTS 等

     

    Tags: , , , , , , , ,