顯示具有 軟體安全 標籤的文章。 顯示所有文章
顯示具有 軟體安全 標籤的文章。 顯示所有文章

2019年7月5日 星期五

安全軟體開發生命週期 (SSDLC)

SDLC and Security

The main phases of a software development life cycle are shown here with some specific security tasks.

Requirements gathering: (需求取得階段)
  1. Security risk assessmen
  2. Privacy risk assessment
  3. Risk-level acceptance
  4. Informational, functional, and behavioral requirements
軟體需求分析時應進行安全的評估,軟體的機密等級要求,例如涉及國家機密、營業秘密、金融交易、個人隱私資料等,應將軟體列為機密等級"高",如涉及組織內部使用但不可公開之型態機密等級可列為"中",一般可公開之型態機密等級可列為"普"。其次是完整性評估,資系統或資料若被竄改之影響性等級,而可用性評估,則是應考量系統若中斷服務的影響等級;此機密性、完整性、可用性均應評估其安全等級。

隱私安全評估,應考量各國有關個人隱私權的法令,如本國的個資保護法、歐盟的GDPR,同樣的也可區分為隱私要求為"高",隱私要求為"中",隱私要求為"普"

當經過風險評估後應決定該系統之風險等級,不同等級將區分出不同的開發規定,包含資料是否需要加密、遮罩,存取控制,操作行為模式等要求,以上這些都是需求分析時必須評估並做為設計階段的輸入項目。
Design:(設計階段)
  1. Attack surface analysis
  2. Threat modeling
攻擊分析主要在於識別如何減少系統被攻擊的因子
  • 程式碼(Code)的數量不宜過量
  • 減少程式人口(Entry points),並限制未經授權的連線
  • 最小權限原則
  • 無須使用的通訊服務不應開放
威脅建模流程分為 6 個步驟︰ 
  • 識別資產:識別出哪些才是系統必須保護的重要資產。 
  • 建立架構概觀:利用簡單的圖表來記錄應用程式的整體架構,包含子系統、信任邊界和資料流。 
  • 分解應用程式:將應用程式進行架構分解,包含基礎網路和基礎架構設計,目的在於為應用程式建立一個安全配置文件。這份文件的目的就是在應用程式設計、實 作及部署時能夠發現弱點。
  • 識別威脅:留意攻擊者的目標以及應用程式的潛在漏洞,找出可能影響應用程式的威脅。 
  • 記錄威脅:將識別出的威脅使用威脅的屬性定義和一般常見的威脅樣板記錄下來。 
  • 評估威脅:評估所面臨的威脅,針對嚴重程度進行排序,並且優先處理優先權最高的。
Development:(開發階段)
  1. Automated CASE tools
  2. Static analysis
軟體開發時,應避免產生脆弱點導致系統之漏洞,CWE組織針對常見的軟體錯誤提出分析報告,如下表所示
Rank
Score
ID
Name
[1]
93.8
Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
[2]
83.3
Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
[3]
79.0
Buffer Copy without Checking Size of Input ('Classic Buffer Overflow')
[4]
77.7
Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
[5]
76.9
Missing Authentication for Critical Function
[6]
76.8
Missing Authorization
[7]
75.0
Use of Hard-coded Credentials
[8]
75.0
Missing Encryption of Sensitive Data
[9]
74.0
Unrestricted Upload of File with Dangerous Type
[10]
73.8
Reliance on Untrusted Inputs in a Security Decision
[11]
73.1
Execution with Unnecessary Privileges
[12]
70.1
Cross-Site Request Forgery (CSRF)
[13]
69.3
Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
[14]
68.5
Download of Code Without Integrity Check
[15]
67.8
Incorrect Authorization
[16]
66.0
Inclusion of Functionality from Untrusted Control Sphere
[17]
65.5
Incorrect Permission Assignment for Critical Resource
[18]
64.6
Use of Potentially Dangerous Function
[19]
64.1
Use of a Broken or Risky Cryptographic Algorithm
[20]
62.4
Incorrect Calculation of Buffer Size
[21]
61.5
Improper Restriction of Excessive Authentication Attempts
[22]
61.1
URL Redirection to Untrusted Site ('Open Redirect')
[23]
61.0
Uncontrolled Format String
[24]
60.3
Integer Overflow or Wraparound
[25]
59.9
Use of a One-Way Hash without a Salt

Top 25 Most Dangerous Software Errors

網頁類型的系統是目前的主流,且曝露於網際網路高風險環境中,因此Open Web Application Security Project 組織,定義出重要的網路應用系統10大安全風險,如下表所示
A1:2017-Injection
Injection flaws, such as SQL, NoSQL, OS, and LDAP injection, occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization
A2:2017-Broken
Authentication
Application functions related to authentication and session management are often implemented incorrectly, allowing attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users’ identities temporarily or permanently.
A3:2017- Sensitive Data Exposure
Many web applications and APIs do not properly protect sensitive data, such as financial, healthcare, and PII. Attackers may steal or modify such weakly  rotected data to conduct credit card fraud, identity theft, or other crimes. Sensitive data may be compromised without extra protection, such as encryption at rest or in transit, and requires special precautions when exchanged with the browser.
A4:2017-XML External Entities (XXE)
Many older or poorly configured XML processors evaluate external entity references within XML documents. External entities can be used to disclose internal files using the file URI handler, internal file shares, internal port scanning, remote code execution, and denial of service attacks.
A5:2017-Broken Access Control
Restrictions on what authenticated users are allowed to do are often not properly enforced. Attackers can exploit these flaws to access unauthorized functionality and/or data, such as access other users' accounts, view sensitive files, modify other users’ data, change access rights, etc.
A6:2017-Security Misconfiguration
Security misconfiguration is the most commonly seen issue. This is commonly a result of insecure default configurations, incomplete or ad hoc configurations, open cloud storage, misconfigured HTTP headers, and verbose error messages containing sensitive information. Not only must all operating systems, frameworks, libraries, and applications be securely configured, but they must be patched and upgraded in a timely fashion.
A7:2017- Cross-Site Scripting (XSS)
XSS flaws occur whenever an application includes untrusted data in a new web page without proper validation or escaping, or updates an existing web page with user-supplied data using a browser API that can create HTML or JavaScript. XSS allows attackers to execute scripts in the victim’s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites.
A9:2017-Using Components with Known Vulnerabilities
Components, such as libraries, frameworks, and other software modules, run with the same privileges as the application. If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover. Applications and APIs using components with known vulnerabilities may undermine application defenses and enable various attacks and impacts.
A10:2017- Insufficient Logging & Monitoring
Insufficient logging and monitoring, coupled with missing or ineffective integration with incident response, allows attackers to further attack systems, maintain persistence, pivot to more systems, and tamper, extract, or destroy data. Most breach studies show time to detect a breach is over 200 days, typically detected by external parties rather than internal processes or monitoring.

OWASP Top 10

Testing/validation:(測試階段)
  1. Dynamic analysis
  2. Fuzzing
  3. Manual testing
  4. Unit, integration, acceptance, and regression testing
軟體開發完成後進入測試階段,除了功能性測試外,亦須安全性測試,安全測試主要以弱點檢測、原碼檢測、滲透測試三類為主,經過安全性檢測後以達到系統安全狀態。

https://pentestmag.com/

Release/maintenance:(發佈上線階段)
  1. Final security review
上線前應檢視相關文件,如系統規格文件、系統操作說明、功能與安全測試報告、上線程序等,後續維護方式等。


2019年7月2日 星期二

弱點管理之虛擬修補技術

在資安管理中,無論任何資訊系統都會面臨到永無止境的安全性更新及弱點修補的作業,運氣好的話,簡單幾個步驟就可修補漏洞,但常常會有多種情況,無法完成修補;如組織仍使用原廠已停止支援的作業系統,又如應用系統架構在一套老舊的作業平台導致無法修補,為了安全性修補可能需要全面更版應用系統,產生昂貴的開發經費,系統管理者也常因為擔心應用系統因更新後有狀況,所以會有些空窗期(評估觀察期;因系統無法停機需等候),在這些尚未修補漏洞的期間,或許就是惡意行為(駭客、惡意程式)作怪的時間,基於此,資安業者也研發出一些解決方案,防範於未然。

在威脅出現之前幹掉它! IBM開發最新虛擬修補漏洞技術

國際商業機器公司(IBM)的研究人員最近設計了一種新技術,可以在發現安全漏洞之前就進行虛擬修補。他們日前在一個國際研討會上展示了這一技術。
據該項目的首席研究員非迪·考普提稱,工程師們為尋找流行軟體中的安全漏洞而不斷研究解決方案,他們清楚地知道,在應用程序中找到所有漏洞是不可能的,這在實際上以及理論上都是如此。這就意味著,需要不斷向系統部署安全補丁。
但在應用程序上部署安全修補程序是一項繁瑣且耗時的任務,需要執行一系列步驟,包括識別應用程序的易受攻擊版本、管理該漏洞、交付修補程序、部署修補程序,然後重新啟動應用程序。通常,補丁要在很長時間內才能部署,因此應用程序在發現漏洞後的一段時間內仍然容易受到攻擊。為了顯著加快這一過程,IBM研究人員推出了虛擬補丁。
團隊成員利用機器學習技術來解決問題。他們在給定的應用程序上運行各種測試工具來生成數據,然後使用這些數據來訓練模型。他們先為應用程序創建了數百萬個樣本,然後確定輸入的分類標簽:良性、錯誤或惡意,最終他們訓練模型來預測一個新樣本究竟是良性的還是惡意的。

研究人員根據他們之前生成的數據訓練了模型。該模型結合了卷積神經網絡(CNN)和遞歸神經網絡(RNN),在預測威脅發生之前的漏洞方面,取得了顯著成果——在評估中,他們的模型成功地在威脅之前檢測到LibXML2和LibTIFF漏洞,準確率分別為91.3%和93.7%。
在未來,這一技術可以幫助開發人員在實際暴露之前更快、更有效地修補軟體漏洞。研究人員還計劃繼續探索,以發掘其修補更廣泛漏洞的有效性。

資安趨勢部落格在漏洞遭受攻擊前加以修補
https://blog.trendmicro.com.tw/?p=57893#more-57893

解決方案:
https://www.trendmicro.com/zh_tw/business/products/hybrid-cloud.html
https://www.trendmicro.com/zh_tw/business/products/hybrid-cloud/security-data-center-virtualization.html
https://www.ibm.com/tw-zh/marketplace/real-time-threat-identification

2012年7月16日 星期一

Risk Management Case Study

軟體安全的風險管理架構(可參閱軟體安全簡介),了解業務內容->辨識商業風險->辨識技術風險->風險綜合分析->降低風險的策略,此篇的範例,主要是簡述整個階段的過程。主要針對商業風險與技術風險簡單列出幾項,並說明其影響性及可能性等程度,及減緩風險的對策擬定

風險分析管理範例

2012年7月5日 星期四

軟體安全簡介

軟體安全的心智圖,主要分為三大支柱,風險管理,7Touchpoint,相關知識,而所有均發展於軟體開發週期中(SDLC)。以下簡略說明三大支柱

一.風險管理:是軟體安全的核心要項,而風險分析亦是風險管理框架的中心,依據下圖所示,風險分析在一開始的業務需求和架構設計階段就開始實施,而後面再出現一次是測試階段,也就是依據之前所風險分析之結果進行測試。風險管理框架是一個循環的流程,如下圖右上所示:
  • Step1.從一開始的對於客戶需求的詳細了解
    Step2辨識此業務需求上會有哪些風險,例如購物網站上交易的安全風險
    Step3辨識技術上的風險,例如Buffer Overflow,SQL injection等
    Step4是將前兩的階段所辨識出來的風險做綜合與等級上的區分整理
    Step5是決定降低風險的策略
    Step6執行處置風險的策略
    Step7確認風險處置是有效的
這是風險管理的步驟,而每個步驟亦有其各項措施不再此述,

二.Touchpoints:其中有七項分布在六個開發步驟(SDLC),如下圖左上所示,(每項上面所標示的數字表示其重要程度,不表示順序)
  1. 從客戶需求階段需要的重點
    • Abuse Case:惡意使用的案例分析避免遭受惡意操弄
    • Security Requirment:客戶系統的安全要求了解
    • Risk Analysis:從商業上進行分析,引用風險管理的步驟,了解有哪些風險
  2. 軟體架構與設計
    • Risk Analysis:從技術上進行分析,引用風險管理的步驟,了解有哪些風險
  3. 擬定測試計畫
    • Risk-based Security Text:依據風險分析的結果擬定測試計畫
  4. 程式開發
    • Code Review:利用工具進行原始碼檢測,如RATS,ITS4都是檢測工具,找出是否有不當的程式邏輯會造成bug
  5. 系統測試
    • Risk Analysis:依據分險分析結果和測試計畫進行測試
    • Penetration Text:對系統進行滲透測試,看是否有漏洞,通常會委由專人進行
  6. 回饋報告
    • Penetration Text:對系統進行滲透測試,看是否有漏洞,通常會委由專人進行
    • Security Operations:系統作業的安全
三.知識 :是支持整個軟體安全所需的基礎,分為三種類別七種類型的知識,如下圖右下所示
  1. 規則類
    • Princlpies:安全的原則,模型等
    • Guidelines:安全的指引
    • Rules:安全的規則,標準等
  2. 特徵類
    • Attack Patterns:攻擊的形式
    • Vulnerabilities:應用系統,作業平台等弱點
    • Exploites:可被攻擊利用的
  3. 歷史類
    •  Historical:過去的攻擊事件,漏洞,弱點等歷史資料


  資訊安全管理重要流程 資訊安全管理包含眾多工作,組織中有多少資訊系統,資訊設備,提供哪些資訊服務,自行開發或是委外開發時之系統之安全性,如何確保服務的正常運作及機敏資料的安全,當有資安事件時,是否有適當人員來處置與緊急應變,要如何監控資訊環境,這些工作需要有系統的規劃,每項工...