三、維護漏洞管理計劃

要求6 ：開發(fā)并維護安全的系統(tǒng)和應(yīng)用程序

windows的各種升級以及補丁大家肯定很熟悉了，為了防止各種漏洞的攻擊微軟經(jīng)常要求我們更新，給系統(tǒng)打補丁。在我們的企業(yè)中，攻擊者經(jīng)常會使用我們的系統(tǒng)或者應(yīng)用程序出現(xiàn)的漏洞進行攻擊，所以我們要對我們的系統(tǒng)和應(yīng)用程序進行實時的關(guān)注和維護，在漏洞被發(fā)現(xiàn)的時候第一時間響應(yīng)。

6.1 制定相關(guān)流程，通過使用良好的外部信源獲取安全樓棟信息來識別安全漏洞，并未新發(fā)現(xiàn)的安全漏洞指定風(fēng)險等級（例如“高”、“中”或“低”）

6.1

對于我們正在使用的系統(tǒng)或者應(yīng)用程序我們必須時刻關(guān)注和他相關(guān)的漏洞的出現(xiàn)。我們得有一定的信息收集渠道在漏洞出現(xiàn)的第一時間獲取，并響應(yīng)。比如CVE，國內(nèi)的CNNVD或者國內(nèi)一些著名的安全公司。
我們在第一時間獲取這個漏洞情況的時候，第三方或者通報方肯定會有自己的風(fēng)險等級分析的方案并給出漏洞的風(fēng)險等級。我們詳細了解這個漏洞之后，根據(jù)自己公司的情況以及公司自己的風(fēng)險等級分析方案給出這個漏洞對于自己公司的風(fēng)險等級，然后根據(jù)風(fēng)險等級進行處理。
我們不是一次性就能掃描出所有的漏洞的，這個需要持續(xù)化的跟進，維護我們系統(tǒng)或應(yīng)用程序的安全。
同時在處理漏洞的時候應(yīng)該根據(jù)不同的風(fēng)險等級有不用的優(yōu)先級。對于被視為沒有影響或者風(fēng)險等級很低的漏洞，我們可能忽略，沒有采取措施，但是一定要有記錄，并持續(xù)對他進行風(fēng)險分析，保證業(yè)務(wù)或者其他變動導(dǎo)致漏洞風(fēng)險等級變高帶來的威脅可以被及時發(fā)現(xiàn)。

6.2 通過安裝供應(yīng)商提供的適用安全補丁，確保所有系統(tǒng)組件和軟件杜絕已知漏洞。在發(fā)布后一個月內(nèi)安裝關(guān)鍵補丁

6.2-1

6.2-2

在出現(xiàn)新的漏洞的時候我們及時安裝供應(yīng)商提供的補丁?？赡芤驗榇蜓a丁會對業(yè)務(wù)或者其他產(chǎn)生不必要的損失，但是我們必須協(xié)調(diào)好，在一定的時間內(nèi)安裝好供應(yīng)商提供的補丁。比如這里說的一個月內(nèi)安裝關(guān)鍵補丁。在沒有安裝的這段時間內(nèi)也要有相應(yīng)的應(yīng)對攻擊的策略，減少漏洞給我們帶來的損失。

6.3 遵照如下要求安全地開發(fā)內(nèi)部和外部軟件應(yīng)用程序

6.3

包括基于WEB的應(yīng)用程序管理訪問：
1、按照PCI DSS（例如安全驗證和記錄）
2、基于行業(yè)標(biāo)準(zhǔn)或最優(yōu)方法
3、信息安全并入整個軟件開發(fā)生命周期
這里從開發(fā)的角度直接從源頭上盡量杜絕漏洞的產(chǎn)生。開發(fā)安全的系統(tǒng)或者應(yīng)用程序，就得有安全的開發(fā)標(biāo)準(zhǔn)，代碼標(biāo)準(zhǔn)等。
我們需要制定安全開發(fā)的標(biāo)準(zhǔn)，在軟件或者應(yīng)用程序的整個開發(fā)周期考慮到漏洞的可能產(chǎn)生。比如php安全開發(fā)手冊，我們公司可能會有自己的標(biāo)準(zhǔn)，或者按照行業(yè)的標(biāo)準(zhǔn)或者按照PCI DSS的標(biāo)準(zhǔn)等。

6.3.1 為識別任何潛在的編碼漏洞（采用人工或自動流程），請在投入生產(chǎn)或向客戶發(fā)布前審核自定義代碼

6.3.1-1

6.3.1-2

在安全開發(fā)的過程中我們可能是有了已經(jīng)通過安全編碼審核的框架（或者之前已經(jīng)經(jīng)過審核的代碼），但是這里面根據(jù)不同的環(huán)境不同的需求我們會將代碼進行更改，這部分就屬于自定義代碼片段。
對于自定義代碼片段，雖然我們的開發(fā)人員按照安全的編碼標(biāo)準(zhǔn)去開發(fā)，但是難免也會有漏洞，所以在代碼項目發(fā)布或者交給客戶之前我們需要對其進行代碼審計，白盒測試。需要在除項目開發(fā)人員以外的有安全代碼審計經(jīng)驗的開發(fā)人員進行代碼審計，并修正。
我們在項目投入使用之后發(fā)現(xiàn)了編碼漏洞這個時候要修復(fù)付出的代價是很大的，所以一定要有上線前的代碼審計，最好也可以在測試環(huán)境上線并進行其他測試，比如黑盒測試。

6.4 系統(tǒng)組件的所有變更均須遵守變更控制流程和程序。

6.4

該流程必須包括如下內(nèi)容（6.4.1-6.4.6）。
對于系統(tǒng)組件的操作和更改我們必須有規(guī)定的流程和程序，并嚴格執(zhí)行。我們對系統(tǒng)組件的變更也要有一定的控制和記錄，防止系統(tǒng)組件變更帶來的安全隱患。第一眼看著這個要求，可能是翻譯也可能是自己的學(xué)識不夠所以不是很理解，所以我們先簡單的理解一下字面上的意思，我們詳細的看看6.4里面的具體流程都有哪些要求。

6.4.1 開發(fā)/測試環(huán)境獨立于生產(chǎn)環(huán)境，并借助訪問控制確保兩者分離

image.png

測試環(huán)境和線上環(huán)境的分離是十分重要的，直接將線上環(huán)境當(dāng)測試環(huán)境那如果一個不小心的操作很可能帶來巨大的經(jīng)濟損失。這讓我想起了前幾個禮拜很多ofo用戶都收到幾個test消息，一看就是開發(fā)人員在線上進行測試了，所幸沒有帶來其他的影響。
對于測試環(huán)境我們也要通過訪問控制將他與線上環(huán)境進行分離，因為我們的測試環(huán)境不斷地變更，產(chǎn)生漏洞的可能性是很大的，如果沒有將他和線上環(huán)境進行隔離的話，可能測試環(huán)境的漏洞直接給線上環(huán)境帶來嚴重的威脅。

6.4.2 開發(fā)/測試環(huán)境與生產(chǎn)環(huán)境中的職責(zé)分離

6.4.2

這個其實讓我聯(lián)想到了最小權(quán)限的原則，對于不同的用戶和場景我們只授予必要的權(quán)限，其他權(quán)限都默認禁止。對于測試環(huán)境和生產(chǎn)（線上）環(huán)境的職責(zé)和權(quán)限要分離。
比如開發(fā)者在測試環(huán)境可以有超管的權(quán)限，但是在生產(chǎn)環(huán)境就不一定，有可能只有用戶最低的權(quán)限。對生產(chǎn)環(huán)境只有管理線上的工作人員才有權(quán)限。如果ofo對開發(fā)和測試人員進行職責(zé)的分離，就不會出現(xiàn)之前提到的情況了，開發(fā)或測試人員就不會有在線上環(huán)境直接測試的權(quán)限了。

6.4.3 在測試或開發(fā)過程中不使用生產(chǎn)數(shù)據(jù)（真實的PAN）

6.4.3

我們在測試環(huán)境測試一個系統(tǒng)或者應(yīng)用程序的時候和實際線上環(huán)境還是有差別的，因為我們沒有線上實際的用戶數(shù)據(jù)，所有為了完整的安全測試或其他測試來說我們可能需要自己生成這樣的數(shù)據(jù)。
一定確保在測試環(huán)境不用使用生產(chǎn)環(huán)境中用戶或者其他的真實數(shù)據(jù)（比如用戶身份信息或者管理員賬號密碼等），我們的測試樣本必須是自己生成的。因為開發(fā)測試的環(huán)境是經(jīng)常變動且不安全的，存在很多安全隱患可能會造成數(shù)據(jù)的泄露。

6.4.4 在機會系統(tǒng)/系統(tǒng)投入生產(chǎn)之前、刪除系統(tǒng)組件中的測試數(shù)據(jù)和賬號

6.4.4

在測試環(huán)境經(jīng)過一系列測試之后我們的系統(tǒng)或者應(yīng)用程序即將發(fā)布，但是因為我們測試系統(tǒng)時使用了很多我們自己編造的數(shù)據(jù)或者測試的賬號，在系統(tǒng)投入使用之前，我們需要將這些我們留下的測試痕跡清除，防止攻擊者利用我們留下的數(shù)據(jù)進行攻擊。
我們在測試環(huán)境測試的時候肯定會圖方便，留下一些不安全的隱患，比如弱密碼的test測試賬號等，如果沒有清除這些測試數(shù)據(jù)和賬號，攻擊者可能就會利用這些來了解我們的系統(tǒng)，發(fā)起攻擊。

6.4.5 變更控制程序包含（6.4.5.1-6.4.5.4）

6.4.5

對于軟件或者系統(tǒng)的變更我們必須要有一個控制他的程序，方案。因為我們軟件在更新或者打補丁的時候可能會對整個環(huán)境產(chǎn)生影響，或者產(chǎn)生一些很玄學(xué)的影響，所以我們在軟件變更的時候一定要有一個控制的方案，程序來控制和處理這個變更帶來的影響。具體這個變更控制程序的基本要求我們看一下6.4.5.1-6.4.5.4

6.4.5.1 影響記錄

6.4.5.1

對于每次軟件變更帶來的影響我們都需要進行記錄，這樣可以為下一次的變更有一個參照，更好的分析變更產(chǎn)生影響的原因，更好的制定對變更之后影響的解決方案。

6.4.5.2 被授權(quán)方的變更審批記錄

6.4.5.2

我們進行測試變更時，需要保證這個測試的樣本的變更是被授權(quán)的。比如說測試給一個軟件打補丁的影響的時候，我們需要確認這個補丁是供應(yīng)方官方發(fā)布的，并且這個補丁在供應(yīng)方以及有通過審核的詳細記錄了，我們才能進行安裝補丁的帶來的影響的測試。

6.4.5.3 功能測試，以確認該變更未對系統(tǒng)安全性造成不利影響

6.4.5.3

在對一個系統(tǒng)進行變更，比如升級之后，我們需要進行功能測試，就是對系統(tǒng)的各功能進行測試，確保系統(tǒng)變更之后還在我們的安全體系保障之內(nèi)，不會產(chǎn)生新的安全問題。
通過全面的測試我們要確認在變更之后這個系統(tǒng)仍讓受我們安全策略的保護。

6.4.5.4 取消程序

6.4.5.4

就算我們提前經(jīng)過變更測試，并記錄了測試帶來的影響。但是在實際的變更過程中還是有可能會有其他影響發(fā)生的，所以我們一定要確保這個變更有取消的程序，我們可以降級或者卸載補丁恢復(fù)到之前的環(huán)境。
環(huán)境問題有時候還是很玄學(xué)的，取消程序也是必不可少的挽回損失的關(guān)鍵一步。

6.4.6 完成重要變更后，須對所有新的或變更的系統(tǒng)和網(wǎng)絡(luò)實施所有相關(guān)的PCI DSS要求，并在適當(dāng)情況下更新文檔記錄

6.4.6

我們前面說到要保證變更之后系統(tǒng)或應(yīng)用程序仍在我們的安全策略保護之內(nèi)，這里同時要求我們變更后，受變更影響的系統(tǒng)或者網(wǎng)絡(luò)我們必須重新驗證，并保證其仍然符合PCI DSS的要求。
比如重置新系統(tǒng)的默認密碼，刪除新系統(tǒng)的默認賬號，以及新的網(wǎng)絡(luò)圖等等。這是很關(guān)鍵的要求，這樣才能保證我們所有的重要系統(tǒng)或者網(wǎng)絡(luò)在PCI DSS的要求內(nèi)，不會出現(xiàn)重要的系統(tǒng)或網(wǎng)絡(luò)沒有受到安全保護。
這就相當(dāng)于寫了一個死循環(huán)，開始是我在PCI DSS的標(biāo)準(zhǔn)內(nèi)，因為系統(tǒng)或者程序的變更，發(fā)生了變化，在繼續(xù)按照PCI DSS的標(biāo)準(zhǔn)重新規(guī)范我們的新系統(tǒng)。這樣就保證我們的系統(tǒng)或網(wǎng)絡(luò)始終在PCI DSS的標(biāo)準(zhǔn)范圍內(nèi)。

6.5 按照以下方式處理軟件流程中常見的編碼漏洞

6.5-1

6.5-2

方式：
1、至少每年對開發(fā)人員進行一次最新安全編碼技術(shù)方面的培訓(xùn)，包括如何避免常見的編碼漏洞
2、根據(jù)安全編碼指南開發(fā)應(yīng)用程序
上面都說了在開發(fā)過程中清理排除編碼漏洞，但是總會有漏網(wǎng)之魚，我們也要有萬全之策，如果出現(xiàn)了編碼漏洞我們也得有應(yīng)對策略。
我們要有適當(dāng)?shù)牧鞒瘫ＷC開發(fā)過程中避免編碼漏洞的產(chǎn)生（定期安全編碼培訓(xùn)，安全編碼指南），以及漏洞產(chǎn)生之后的應(yīng)對措施。對于編碼漏洞我們盡力做到最好，如果有不足的地方我們也要有彌補的方法，這里的6.5.1-6.5.10是我們至少要能應(yīng)對的編碼漏洞，都是一些著名的高危漏洞。

6.5.1 注入攻擊

6.5.1

特別是SQL注入，同時還需考慮OS命令注入、LDAP、Xpath等其他注入攻擊。
我們關(guān)注OWASP top ten就會發(fā)現(xiàn)歷年來，注入蟬聯(lián)榜首已經(jīng)很多年了，灰產(chǎn)內(nèi)利用注入批量攻擊的工具更是數(shù)不勝數(shù)。由此可見注入帶來的危害有多大，范圍有多廣；我們安全開發(fā)人員也得有多重視。
有過經(jīng)驗的安全從業(yè)者都知道，數(shù)據(jù)與代碼分離的原則是解決注入漏洞的關(guān)鍵。所有的注入類型的漏洞都是因為服務(wù)器將用戶輸入的數(shù)據(jù)當(dāng)成代碼執(zhí)行了，混淆了數(shù)據(jù)和代碼的邊界。
對于用戶的輸入我們都認為是數(shù)據(jù)，杜絕他變成代碼并執(zhí)行時解決注入問題的關(guān)鍵。所以要合理處理，驗證用戶的輸入，確保其不會變成代碼執(zhí)行?；蛘呃脜?shù)化查詢。
同時我們也要確保輸入的驗證不會影響用戶的體驗，要合理的處理用戶的輸入數(shù)據(jù)。

6.5.2 緩沖區(qū)溢出

6.5.2

其實緩沖區(qū)溢出和注入的原理差不多，都是因為服務(wù)器將數(shù)據(jù)當(dāng)做代碼來執(zhí)行了。程序在?；蛘叨阎?，將用戶數(shù)據(jù)當(dāng)做代碼執(zhí)行，混淆了數(shù)據(jù)和代碼的邊界。
對于緩沖區(qū)溢出的問題，我們可以通過驗證緩沖區(qū)邊界，截取輸入字符串來解決。
簡單的說在進程地址中有數(shù)據(jù)段和代碼段，因為數(shù)據(jù)段受空間大小的限制，當(dāng)我們輸入的數(shù)據(jù)超過這個數(shù)據(jù)段的空間時，數(shù)據(jù)就會被擠到下面的代碼段，并當(dāng)成代碼執(zhí)行。
詳細的緩沖區(qū)溢出可以上網(wǎng)看看各種原理分析。

6.5.4 非安全加密存儲

6.5.3

使用了容易破解的加密方法加密存儲數(shù)據(jù)或者甚至沒有加密就存儲數(shù)據(jù)，攻擊者就很容易便可以得到數(shù)據(jù)的明文。
我們可以使用強效的加密算法加密我們數(shù)據(jù)或者很多其他強效的加密手段。

6.5.4 非安全通信

6.5.4

同樣，我們使用費非安全信道進行通信也是極其危險的，對于非安全的通信我們得有加密的手段來保證其是安全的。比如使用https等。

6.5.5 不正確的錯誤處理

6.5.5

這一點很多公司的安全上都沒有注意到。我感覺注意是兩個方面，一個是對于代碼上的錯誤沒有進行正確的處理導(dǎo)致敏感信息泄露，比如我們訪問一些網(wǎng)站的錯誤請求時會有報錯提示，這里可能會泄露網(wǎng)站的物理路徑等信息。
第二個就是業(yè)務(wù)方面了，比如用戶登錄的時候，對于錯誤的登錄請求時，服務(wù)器對密碼錯誤和用戶名錯誤進行了自以為貼心的區(qū)別處理，用戶名存在，密碼錯誤就提示：“密碼錯誤”，用戶名和密碼都不對就提示：“用戶名錯誤”，雖然提高了一些用戶體驗，但是帶來的更多還是安全隱患。攻擊者可以根據(jù)這不同的提示爆破用戶的密碼。

6.5.6 漏洞識別流程中確認的所有“高風(fēng)險”漏洞

6.5.6

還有很多其他的漏洞，有一些可能其他方威脅分析為低的對于我們所處的公司實際為高風(fēng)險，所以我們在前面說過公司要自己根據(jù)不同情況分析漏洞的風(fēng)險等級，然后進行處理。我們對這“高風(fēng)險”的漏洞也要有應(yīng)對的措施。確保發(fā)現(xiàn)這樣的漏洞后能及時相應(yīng)，最大化減少損失。

6.5.7 跨站腳本

6.5.7

6.5.1到6.5.6都是適用所有的應(yīng)用程序來說，6.5.7到6.5.10則是適用于網(wǎng)絡(luò)應(yīng)用程序和應(yīng)用程序的接口。
XSS就是利用“HTML注入”的方式，給網(wǎng)頁嵌入了惡意腳本，從而在用戶瀏覽網(wǎng)頁的時候，執(zhí)行惡意腳本進行攻擊。
但是其實XSS的場景很復(fù)雜，很難解決，場景不同我們的處理方式也不同。這里說道對參數(shù)在應(yīng)用前進行驗證，是否合法以及利用上下文相關(guān)的轉(zhuǎn)義。
涉及到用戶輸入的數(shù)據(jù)被當(dāng)做代碼執(zhí)行的情況，都是混淆的數(shù)據(jù)和代碼的邊界，最重要的方法就是輸入的檢測。

6.5.8 不正確的訪問控制

6.5.8

例如不安全的直接對象引用、未能限制網(wǎng)址訪問、目錄遍歷和未能限制用戶的功能訪問。
損壞的訪問控制在OWASP 2017中排在了第五的位置，甚至超過了第七的XSS。
不正確的訪問控制十分的危險，沒有一個完善的訪問控制機制，攻擊者可以輕松的偽造成某些用戶進行訪問?；蛘咂渌脑L問控制缺失，導(dǎo)致url上顯示了具體的文件名，導(dǎo)致用戶可以未授權(quán)的更改文件名進行訪問。
這里包括很多情況，但是最主要的就是訪問控制機制的不完善，導(dǎo)致攻擊者可以在未授權(quán)的情況訪問不該被訪問的敏感內(nèi)容（如數(shù)據(jù)，文件等）。博主校園網(wǎng)內(nèi)部的財務(wù)系統(tǒng)就曾出現(xiàn)了類似的的問題，因為使用的是校園統(tǒng)一認證，用學(xué)生的身份經(jīng)過統(tǒng)一認證之后，跳轉(zhuǎn)的時候更改訪問的id就可以用不同的學(xué)生或教師身份登錄。這就是典型的訪問控制機制的缺失，不完善。
我們要根據(jù)具體出現(xiàn)的情況進行漏洞的修復(fù)，比如這里提到的正確的驗證用戶的身份，確保不會被偽造，以及對未授權(quán)的功能不允許用戶訪問，還有不想用戶暴力內(nèi)部對象引用也很重要，攻擊者就更難構(gòu)造這樣的偽造訪問。

6.5.9 跨站請求偽造（CSRF）

6.5.9

跨站請求偽造也是典型的高危漏洞之一。簡而言之就是攻擊者盜用用戶的身份并發(fā)送惡意請求。我們竊取了用戶的會話令牌，也就是到瀏覽器的Cookies。比如說我們誘使目標(biāo)訪問淘寶，使他淘寶用戶的session cookies有效，然后實施csrf，讓他訪問一個購買商品的鏈接或者其他我們想要的動作對應(yīng)的鏈接。
這就是因為我們會話管理和驗證失效了，應(yīng)對措施這里有不暴露會話id以及添加超時和輪換id等等。還有一些比如驗證碼手段，強制用戶和應(yīng)用進行交互才能完成請求。

6.6 對于面向公眾的網(wǎng)絡(luò)應(yīng)用程序，應(yīng)不斷解決新的威脅和漏洞，并通過一下任一方法確保這些應(yīng)用程序不會受到攻擊

6.6

1、利用手動或自動應(yīng)用程序漏洞安全評估工具或方法審核面向公眾網(wǎng)絡(luò)應(yīng)用程序，至少每年一次并在有任何變更后進行
2、在面向公眾的web應(yīng)用程序前安裝可檢查和防范網(wǎng)頁式攻擊的自動化技術(shù)解決方案（例如web應(yīng)用程序防火墻），泳衣不斷檢查所有流量
說一句，企業(yè)的src還是挺有必要的。對于面向公眾的網(wǎng)絡(luò)應(yīng)用，就是對外提供服務(wù)的那些網(wǎng)絡(luò)應(yīng)用，我們要持續(xù)不斷地解決新的威脅和漏洞。既然對外開放，就會面臨不斷地攻擊，我們要通過一定的手段，確保他不受這些攻擊的威脅。我們可以通過上面說的兩個方法。
一個是定期手動或者自動對這個網(wǎng)絡(luò)應(yīng)用進行漏洞安全評估。我們需要定期執(zhí)行，但是在某些情況發(fā)生導(dǎo)致系統(tǒng)環(huán)境產(chǎn)生變化我們也都進行檢測評估，并在發(fā)現(xiàn)漏洞后及時修復(fù)，記錄并重新評估。
二是在這個網(wǎng)絡(luò)應(yīng)用和外部網(wǎng)絡(luò)之間增加加一個防止攻擊的自動化解決方案，比如web防火墻，安全狗之類的。在使用之后我們也得確保我們的防火墻處于工作狀態(tài)以及有詳細的抵御攻擊的日志。

6.7 確保已記錄、正在使用且所有相關(guān)方了解用于開發(fā)和維護安全系統(tǒng)和應(yīng)用程序的安全政策和錯做程序

6.7

確保我們開發(fā)并維護安全的系統(tǒng)和應(yīng)用程序的措施被詳細記錄，并且相關(guān)人員以及學(xué)習(xí)并嚴格遵守。落實到每個人。

總結(jié)

第三個區(qū)域維護漏洞管理計劃也就結(jié)束了?；仡^看看，主要就是有實時更新的殺毒軟件和開發(fā)并維護安全的系統(tǒng)和網(wǎng)絡(luò)應(yīng)用程序流程。這個區(qū)域主要就是對漏洞產(chǎn)生時候我們最快修補漏洞，最大化減少漏洞對我們產(chǎn)生的不利影響。我們雖然可以盡全力把防御體系做到最好，但是不可能杜絕漏洞的而產(chǎn)生，所有做好對漏洞的及時響應(yīng)也是企業(yè)安全中的一個重要環(huán)節(jié)。