安全體系與企業安全

時間 2019-11-17

標籤安全體系企業欄目系統安全简体版

原文原文鏈接

1節 SDL介紹

擴展閱讀：html

安全開發流程（SDL）學習概述 http://www.cnblogs.com/whoami101/p/9914862.htmlgit

SDL：https://www.microsoft.com/en-us/SDL/process/training.aspxgithub

SDL軟件安全設計初窺： https://xz.aliyun.com/t/226正則表達式

SDL的全稱是Security Development Lifecycle，翻譯成中文就是安全開發生命週期，也有人稱之爲安全開發流程，其實就是一個東西。數據庫

SDL最先是有微軟提出的，是一種專一於軟件開發的安全保障流程，幫助開發人員構建更安全的軟件和解決安全合規要求的同時下降開發成本的軟件開發過程。爲實現保護最終用戶爲目標，它在軟件開發流程的各個階段引入安全和隱私問題的活動。微軟自2004年以來將其做爲公司範圍內的強制性政策，它可以從根源有效地解決安全漏洞問題。windows

擴展閱讀：安全

安全開發流程（SDL）學習概述 http://www.cnblogs.com/whoami101/p/9914862.html網絡

SDL： https://www.microsoft.com/en-us/SDL/process/training.aspx數據結構

SDL軟件安全設計初窺： https://xz.aliyun.com/t/226架構

圖片太大，後臺沒法上傳，請打開石墨連接查看https://shimo.im/docs/gOzSUgU0Zj4NWHzX/ 《11-1 SDL介紹—學習資料》

這是整個SDL的過程，分爲7個階段，分別爲：

一、安全培訓

這個其實也好理解，是安全開發生命週期的首要要求，經過給軟件開發的同窗進行安全培訓，掌握基礎的安全和隱私知識，瞭解相關安全背景，有利於創建你們對安全的理解和後續流程的開展。

二、需求

需求主要包含有創建安全需求、建立質量門/bug欄、實施安全和隱私風險評估三個部分。

儘早肯定安全和隱私需求有助於更容易的識別關鍵里程碑和可交付內容，最小化對計劃和日程的干擾；在這過程須要指派安全專家、定義應用程序的最低安全和隱私標準、部署安全漏洞/問題跟蹤系統。在開始階段設定最低的安全標準和質量要求有助於開發團隊理解安全問題和風險，這樣使得開發團隊能夠在開發過程當中識別並修復安全風險，以及貫徹這一標準。

而質量門或者bug欄的建立，主要是爲了定義安全漏洞閾值。

而最後的評估部分主要是幫助團隊肯定項目的哪些部分在發佈以前須要進行威脅建模和安全涉及審查，並肯定對應的影響等級。

通俗的理解，就是要明確安全需求，而且儘量早的肯定安全需求，目的是避免中途插入安全需求致使開發的計劃日程變動，也讓開發人員內心有個底；同時須要設定必定閾值和標準，如怎麼肯定安全漏洞等級，創建安全問題反饋機制；最後就是評估項目安全現狀，以及創建威脅模型。

三、設計

設計主要分爲創建設計需求、分析和減少攻擊面、使用威脅模型。

在產品設計初期就要考慮安全需求，分析可能的攻擊面並進行修復和減小攻擊面，好比進行訪問限制、應用最小權限原則等；最後的話，有方法的應用威脅模型，能夠更有效的肯定安全漏洞和威脅風險，創建對應措施。

此次再次強調的了在前期肯定安全需求，都是一個目的，避免安全需求對正常開發流程的影響。其實安全和開發或者運維便捷一直都存在衝突點，爲了更安全增長相關的機制和審查流程，天然而然就阻擾正常的開發流程，因此相關流程推進應該考慮儘量的在前期考慮安全需求，避免中途的干擾操做。

四、實施

實施主要也包含三部分，分別是使用指定工具、棄用不安全函數、進行靜態分析。

發佈指定的工具和相關安全檢查，好比使用編譯器的告警信息能夠有助於進行自動化低成本的安全實踐，並按期更新工具。分析並避免使用不安全的函數，能夠減小潛在的安全缺陷，好比一些頭文件等。同時能夠經過靜態分析源碼，有助於發現問題並確保相關代碼的開發遵循了安全編碼規範。

這裏重點就是經過指定的工具進行檢查，靜態分析發現問題，同時棄用非安全函數避免引入問題。

五、驗證

驗證包含有動態分析、模糊測試、攻擊面檢查。

經過動態分析在軟件運行時進行監控以發現內存損壞、用戶特權訪問等安全問題；同時經過格式錯誤或者隨機數據的測試方式故意致使程序失敗進行測試，一樣能夠發現安全問題；最後就是在代碼完成後，再次檢查攻擊面，能夠確保程序或者系統設計已經進行了攻擊面分析和修復。

經過動態分析、模糊測試、攻擊面面檢查三個維度再次驗證項目安全狀況。

六、發佈

建立事故應急方案、最後的安全評估、發佈與存檔。

事故應急方案就不用說了，包含肯定緊急聯繫人，這是相當重要的；而後進行一個最終評估，包含說審覈以前定義的質量門/bug欄的的狀況等；以及歸檔全部的代碼、規範等相關文件。

七、響應

執行事件響應計劃，經過執行事先制定的事件響應計劃有助於最大限度幫助客戶免受安全或隱私漏洞的影響。

這就是SDL的7個階段，每一個階段對應開發過程的不一樣階段，核心思想就是將安全集成在開發的每一個階段，也就是咱們常說的需求分析、設計、編碼、測試和維護，每一個部分都增長了對應的安全活動，以求在安全開發過程當中就將可能的安全風險降到最低。

其核心設計原則有六點：

Attack Surface Reduction：攻擊面最小化
Basic Privacy: 基本隱私
Least Privilege: 權限最小化
Secure Defaults: 默認安全
Defense in Depth：縱深防護
Threat Modeling：威脅建模

2 威脅情報與企業安全

擴展閱讀：

The Pyramid of Pain： http://detect-respond.blogspot.com/2013/03/the-pyramid-of-pain.html

STIX： https://stixproject.github.io/

CybOX： https://cyboxproject.github.io/

TAXII： https://taxiiproject.github.io/

一、威脅情報建設標準參考

STIX - Structured Threat Information eXpression

TAXII - Trusted Automated eXchange of Indicator Information

CybOX - Cyber Observable eXpression

MAEC - Malware Attribute Enumeration and Characterization

OpenIOC - Open sourced schema from Mandiant

IODEF - Incident Object Description Exchange Format

CIF - Collective Intelligence Framework

IDXWG - Incident Data eXchange Working Group

二、STIX標準要點淺析

主要可適用在如下四類場景

一、威脅分析。威脅的判斷、分析、調查、保留記錄等使用。

二、威脅特徵分類。將威脅特徵進行分類，以人工方式或自動化工具。

三、威脅及安全事件應急處理：安全事件的防範、偵測、處理、總結等，在安全事件處置過程當中能夠有很好的借鑑，之前作事件處理沒有這麼詳盡的信息。

四、威脅情報分享。用標準化的框架進行描述與分享。

三、TAXII標準要點淺析

服務規範：定義了TAXII的服務類型、TAXII情報類型以及情報交流格式

消息規範：採用XML格式

協議規範：肯定了HTTP/HTTPS做爲TAXII傳送的協議。從安全角度考慮可採用https協議傳輸。查詢格式規範：定義了缺省的查詢格式和處理規則。

3 態勢感知與監控預警

一、態勢感知產品

1.1 明鑑網絡安全態勢感知通報預警平臺

1.2 360 態勢感知與安全運營平臺

二、對態勢感知的理解

（1）態勢感知是瞭解當前的狀態，包括狀態識別與確認（攻擊發現），以及對態勢感知所需信息來源和素材的質量評價。

（2）態勢理解則包括瞭解攻擊的影響、攻擊者（對手）的行爲和當前態勢發生的緣由及方式。簡單可歸納爲：損害評估、行爲分析（攻擊行爲的趨勢與意圖分析）和因果分析（包括溯源分析和取證分析）。

（3）態勢預測則是對態勢發展狀況的預測評估，主要包括態勢演化（態勢跟蹤）和影響評估（情境推演）

三、在線態勢感知平臺

一、全景網絡安全防護系統

http://guanjia.qq.com/system/preloader.html

二、網絡安全威脅信息共享平臺

https://share.anva.org.cn/index

三、騰訊位置大數據

https://heat.qq.com/

四、360流量監控平臺

http://scan.netlab.360.com/#/dashboard

四、態勢感知的應用價值

一、應對關鍵性威脅：快速發現失陷主機；全面的Web安全保障。

二、提高分析研判能力：分析研判保障事件正確響應處置、逐步完善防護架構；依賴外部威脅情報和本地的流量日誌進行有效的分析研判。

三、信息與情報共享：實現本行業、本領域的網絡安全監測預警和信息通報；研判分析和情報共享是預警、預測的基礎。

四、履行行業監管職責：邊界流量探針、雲監控和外部情報監測等優選檢測手段，實現對行業的監管。

4 漏洞生命週期與漏洞的披露

擴展閱讀

漏洞披露究竟怎麼作更」合適「？看看美國相關部門怎麼看 https://www.freebuf.com/articles/neopoints/123847.html

專家 | 黃道麗：網絡安全漏洞披露規則及其體系設計 https://blog.csdn.net/kevin_bobolkevin/article/details/79408610

谷歌披露Windows關鍵漏洞惹怒微軟因只給了10天反應期 http://tech.qq.com/a/20161101/040313.htm

一、安全漏洞生命週期

安全漏洞指信息系統中存在的缺陷或不適當的配置，它們可以使攻擊者在未受權狀況下訪問或破壞系統，致使信息系統面臨安全風險。利用安全漏洞來形成入侵或破壞效果的程序就稱爲滲透代碼(Exploit)，或者漏洞利用代碼。

圍繞着安全漏洞生命週期所進行的攻防技術，一直是安全社區永恆的話題，而一個典型的安全路東生命週期包括以下7部分：

1、安全漏洞研究與挖掘

由高技術水平的黑客與滲透測試師開展，主要利用源代碼審覈(白盒測試)、逆向工程(灰盒測試)、Fuzz測試(黑盒測試)等方法，挖掘目標系統中存有的可被利用的安全漏洞。

2、滲透代碼開發與測試

在安全漏洞挖掘的同時，黑客會開發概念驗證性的滲透攻擊代碼(POC)，用於驗證找到的安全漏洞是否確實存在，並確認其是否可被利用。

3、安全漏洞和滲透代碼在封閉團隊中流傳

在發現安全漏洞並給出滲透攻擊代碼後，負責任的「白帽子」們採起的處理策略是首先通知廠商進行修補，而在廠商給出補丁後再進行公佈；而「黑帽子」與「灰帽子」通常在封閉小規模團隊中進行祕密地共享，以充分地利用這些安全漏洞和滲透攻擊代碼所帶來的攻擊價值。

4、安全漏洞和滲透代碼開始擴散

因爲各類緣由，在封閉團隊中祕密共享的安全漏洞和滲透代碼最終會被披露出來，在互聯網上得以公佈，「黑帽子」會快速對其進行掌握和應用，並在安全社區中快速擴散。

5、惡意程序出現並開始傳播

「黑帽子」將在掌握安全漏洞和滲透代碼基礎上，進一步開發更易使用、更具自動化傳播能力的惡意程序，並經過黑客社區社會組織結構和互聯網進行傳播。在此過程當中(或以前或以後)，廠商完成補丁程序開發和測試，並進行發佈。

6、滲透代碼/惡意程序大規模傳播並危害互聯網

廠商發佈補丁程序和安全警報將進一步地讓整個黑客社區瞭解出現新的安全漏洞和相應的滲透代碼、惡意程序，更多的「黑帽子」將從互聯網或社區關係網得到並使用這些惡意程序，對互聯網的危害也在這個階段達到頂峯。

7、滲透攻擊代碼/攻擊工具/惡意程序逐漸消亡

在廠商補丁程序、安全公司提供的檢測和移除機制獲得普遍應用後，相應的滲透代碼、惡意程序將被「黑帽子」逐漸拋棄，從而慢慢消亡。

安全漏洞生命週期以下圖所示：

在安全漏洞生命週期內，從安全漏洞被發現到廠商發佈補丁程序用於修補該漏洞以前，安全社區廣泛稱爲"0day"。在這段時間，黑客們攻擊存有該安全漏洞的目標能夠達到百分之百的成功率，同時也能夠躲避檢測，在「0day」的安全漏洞和對應的滲透代碼對於黑客社區具備很高的價值，挖掘「0day」安全漏洞並給出滲透代碼也成爲高水平黑客的追求目標。

參考連接：https://blog.csdn.net/henni_719/article/details/77947938

5 安全自動化協議SCAP

擴展閱讀：

SCAP官方頁面： https://csrc.nist.gov/projects/security-content-automation-protocol/

一、SCAP中文社區

SCAP中文社區是一個開放的安全資訊聚合與利用平臺，其使命是促進SCAP系列標準在中國的採納與應用。當前的社區中集成了SCAP框架協議中的CVE、OVAL、CPE等3種網絡安全相關標準數據庫。用戶能夠方便地使用本站對CVE漏洞庫、OVAL漏洞檢查語言以及CPE平臺列表進行查詢。

截止如今，SCAP中文社區主要收錄了近6萬條CVE數據（2002年以來），以及14000餘條OVAL數據。並提供了有史以來最爲詳細的CVE中文解釋以和OVAL的斷定邏輯表達式的解析。SCAP中文社區在深刻分析大量數據的基礎上，完成了CVE與OVAL之間的映射：即若是一個CVE漏洞存在相應的OVAL漏洞檢查技術細節，那麼在在兩個數據之間會有直接的連接，點擊相關連接可以相互跳轉（如CVE-2013-0095)，這爲漏洞分析人員的工做提供了極大的方便。此外，社區還完成了與CNNVD完整庫的映射，經過CVE能夠很方便地查看相關的中國國家信息安全漏洞庫資源。

CVE數據庫：http://cve.scap.org.cn

能夠經過關鍵字、廠商和軟件名稱對CVE數據進行檢索分析：http://cve.scap.org.cn/

OVAL數據庫：http://oval.scap.org.cn

二、OVAL

OVAL由MITRE公司開發，是一種用來定義檢查項、脆弱點等技術細節的一種描述語言。OVAL一樣使用標準的XML格式組織其內容。它提供了足夠的靈活性，能夠用於分析Windows、Linux、Unix以及各類嵌入式操做系統的系統狀態、漏洞、配置、補丁等狀況，並且還能用於描述測試報告。OVAL可以清晰地對與安全相關的檢查點做出描述，而且這種描述是機器可讀的，可以直接應用到自動化的安全掃描中。OVAL的核心是「公開」（Open），這就意味着任何人均可覺得OVAL的發展做出本身的貢獻，共享知識和經驗，避免重複勞動。實際上XCCDF設計的目標是可以支持與多種基礎配置檢查技術交互。其中推薦的，默認的檢查技術是MITRE公司的OVAL。在實際的SCAP應用中，XCCDF和OVAL每每是成對出現，XCCDF定義檢查單，而OVAL定義每一個檢查項的具體實施細節。

OVAL以XML格式描述，包含以下幾種XML格式（Schema）：OVAL定義格式（OVAL Definition Schema），OVAL系統特性格式（OVAL System Characteristics Schema）與OVAL結果格式（OVAL Result Schema）。OVAL系統特性格式用於描述系統信息快照，該快照可用於和OVAL定義文件進行匹配以得出評估結果，OVAL結果格式用於描述評估結果。

在三種OVAL格式中，OVAL定義格式佔有較爲重要的位置，OVAL定義格式提供了一種機器可讀的對系統進行安全評估的操做指南，它可用來描述系統的配置信息、分析系統的安全狀態、報告評估結果等。典型的OVAL定義格式的XML文檔由定義（Definition）、測試（Test）、對象（Object）、狀態（State）和變量（Variable）等要素構成，其結構比較簡單，主要是將各個要素以枚舉的方式列出，如圖1所示。

6 SCAP的應用與示例

擴展閱讀：

分值計算的示例能夠參考: https://www.first.org/cvss/examples https://www.first.org/cvss/specification-document

心臟出血漏洞：

https://nvd.nist.gov/vuln/detail/CVE-2014-0160

CVSS 3.0計算器： https://www.first.org/cvss/calculator/3.0

CWE樹狀圖： https://nvd.nist.gov/vuln/categories/cwe-layout

利用SCAP有效進行主機安全管

理： https://www.edu.cn/info/fei/wang_luo/an_quan_ji_shu/201303/t20130306_912136.shtml

一、OVAL學習筆記

定義」是最重要的構成元素，它會引用一個或多個「測試」，根據「測試」的結果綜合斷定總體的結果，「測試」使用「對象」和「狀態」與系統交互並得出檢查結果，「狀態」可使用固定值或引用「變量」中的值。OVAL各組成要素之間的邏輯關係以下圖。在下圖中，Definition1包含兩個「測試」Test1和Test2，假設其斷定標準爲AND的邏輯關係，那麼若是兩個Test均爲True，整個Definition1結果爲True。舉例來講，若是Test1測試結果爲True，Test2測試結果爲False，根據Definition1中的斷定條件Test1=True AND Test2=True，整個Definition的測試結果爲False。

OVAL定義

「定義」（Definition）用於描述如何對某一特定安全問題進行檢查，一般一個OVAL文檔中包含多個「定義」。主要有四類定義，分別是漏洞（Vulnerability）：描述如何根據系統狀態斷定系統中是否存在某個特定漏洞；補丁（Patch）：與漏洞定義相似，但它更關注如何斷定系統中是否安裝了某個特定補丁；軟件（Inventory）：描述如何對系統中是否安裝了某個特定的軟件進行斷定；合規（Compliance）：描述如何對系統是否知足某個特定的配置要求進行斷定。表1是一個OVAL定義的示例數據。

OVAL測試

「測試」（Test）經過定義一組OVAL對象（Object）和OVAL狀態（State）執行，OVAL 測試的數據結構如表2所示，而圖2則較爲清晰地表達了OVAL測試中OVAL對象與OVAL狀態是如何相互配合執行測試。

OVAL對象

「對象」（Object）用來描述測試主體，因爲測試主體類別衆多（如註冊表、組策略、文件、軟件包等），所以Object的類型也不少，且每種類型的數據結構各不相同。下面是一個passworkpolicy_object的定義，能夠看出系統策略類的OVAL對象只須要指明一個id便可被解釋器識別：

<passwordpolicy_object id="oval:gov.nist.usgcb.windowsseven:obj:27" version="2"/>

下面是一個registry_object的定義，能夠看到註冊表類OVAL對象須要指明註冊表Hive、註冊表鍵和註冊表項的名稱：

<registry_object id="oval:gov.nist.usgcb.winseven:obj:16" version="2">

<hive>HKEY_LOCAL_MACHINE</hive>

<key>SOFTWARE\Policies\Microsoft\PCHealth\ErrorReporting\DW</key>

<name>DWAllowHeadless</name>

</registry_object>

OVAL狀態

「狀態」（State）用來描述測試主體的參考狀態值，同OVAL對象相似，State也分爲多種類型，每種類型的數據結構不相同，下面是一個passwordpolicy_state的定義：

<passwordpolicy_state id="oval:gov.nist.usgcb.winseven:ste:33" version="2">

<min_passwd_len operation="greater than or equal" datatype="int" var_ref="oval:gov.nist.usgcb.winseven:var:22"/>

</passwordpolicy_state>

能夠在Value中使用正則表達式以更好的完成字符串匹配工做。下面是一個registry_state的定義，用來識別註冊表中獲取的值能與字符串「Windows 7」相匹配。

<registry_state id="oval:org.mitre.oval:ste:5027" version="4" comment="Matches with Windows 7">

^[a-zA-Z0-9\s]*[Ww][Ii][Nn][Dd][Oo][Ww][Ss] 7[a-zA-Z0-9\s]*$

</value></registry_state>

能夠看出，OVAL狀態中可使用var_ref引用一個OVAL變量表示OVAL狀態的值，或者直接將值寫入到value節點中。

OVAL變量

「變量」（Variable）定義了執行測試時State所需的值，其有三種類型：常量（constant_variable）、本地變量（local_variable）和外部變量（external_variable）。常量定義一個不能在運行時改變的值，本地變量定義在OVAL中直接使用的值，而外部變量一般用於將XCCDF的Value值傳遞到OVAL中。下面是一個外部變量的定義：

<external_variable comment="Minimum Password Length is greater than or equal to the prescribed value" datatype="int" id="oval:gov.nist.usgcb.winseven:var:22" version="2"></external_variable>

注：以上大多轉自破殼筆記學習資料，歡迎你們前來報名學習