PCI-DSS(V3.2)學習筆記(二)

weixin_34148340發表於2018-10-20

一、建立和維護一個安全的網路和系統

要求2:不要使用供應商提供的預設系統密碼和其他安全引數

劃重點!劃重點!要點2可謂是直戳人心,我想這個不必細講大家都知道預設密碼或者弱密碼帶來的危害有多大!就說最近吧,烏克蘭軍方系統的123456密碼可是好好的給我上了一課,太真實了,且不細究這是預設密碼還是改成這麼簡單的,但是帶來的危害可想而知!
當我們在某個系統元件或者軟體中使用預設密碼的的時候,攻擊者可以很容易就通過網上或者產品提供商出獲取預設密碼進行攻擊。這個攻擊場景是十分十分常見的,博主在高校教育網中就見過無數次了,不論是校園網的平臺還是其他管理系統的平臺。預設密碼屢見不鮮,因此強烈建議不使用供應商提供的預設密碼。就算預設密碼是一個很複雜的密碼也必須更改!預設空密碼的就更不用說了。

2.1 始終更改供應商提供的預設值並於在網路中安裝系統之前刪除或禁用不必要的預設賬戶

(此要求適用於所有預設密碼。包括但不限於作業系統、提供安全服務的軟體、應用程式和系統賬戶、銷售點(POS)終端、支付應用程式、簡單網路管理協議(SNMP)社群字串等使用的預設密碼)。


6269327-dcfe6381554ed142.png
2.1

在我們使用了第三方提供的軟體、應用作業系統等時一定要在上線之前更改掉供應商提供的預設密碼,特別是預設空密碼的,一定要增加密碼,並且對於一些測試的賬號或者無作用的預設賬號一定要刪除!也說說預設賬號帶來的危害,之前rabbitmq就有預設的guest賬號登入,且有所有的操作許可權,還有很多的這樣的預設賬戶,我們需要在軟體或者應用正式使用之前就刪除這些不用的預設賬戶。

2.1.1 對於連線到持卡人資料環境或傳輸持卡人資料的無線環境,在安裝時更改所有無線供應商的預設值,包括但不限於預設的無線金鑰、密碼和SNMP社群字串

6269327-54d4d5f82b66c331.png
2.1.1

在要求1裡面我們曾經畫過持卡人資料的資料流圖和網路拓撲圖,我們已經清楚的瞭解到那些網路環境裡面會儲存或傳輸持卡人資料,對於這些網路環境我們需要重點關注。更改預設路由器或交換機的預設賬號,預設密碼。或者簡單網路管理協議(SNMP),若管理員配置不當執行預設團體名/弱口令訪問,將導致敏感資訊洩露。無線網路是很容易被嗅探竊取資訊的。比如校園網或者公司的辦公網,很容易被嗅探,學校內嗅探“借”校園網流量的也不少。

2.2 制定適合所有系統元件的配置標準。確保這些標準能解決所有已知的安全漏洞並與行業認可的系統強化標準一致

行業認可的系統強化標準來源包括但不限於:
1、網際網路安全中心(CIS)
2、國際標準化組織(ISO)
3、美國系統網路安全協會(SANS)
4、國家標準與技術研究所(NIST)


6269327-b3583c2e5cfac213.png
2.2

這裡其實就是讓我們參照權威機構釋出的標準來嚴格標準化我們的系統元件配置。我們主要看看2.2.d的詳細步驟,這裡具體講了標準化的主要程式和步驟,這裡前面也都說到了。談一談其中的一點,每臺伺服器僅執行一項主要功能買一房至不同安全級別的功能並存於同一臺伺服器上。
因為對於不同安全級別的伺服器我們採取的安全保護措施肯定是不同的,還是比如我們web server和資料伺服器在一臺伺服器上的話就很危險。
其他的主要就是按照CIS或者ISO啊之類根據我們環境的系統元件定製我們自己的標準,並嚴格執行,檢測。

2.2.1 每臺伺服器僅執行一項主要功能,以防需要不同安全級別的功能並存在同一臺伺服器上。

(例如web伺服器、資料庫伺服器和DNS伺服器均應在單獨的伺服器上執行)


6269327-e47dadfc33faed9e.png
2.2.1

好吧,前面剛剛說到,這裡的2.2.1就是說這一點,看來我還是抓住了重點的。這裡來說說,如果兩個安全級別不同的功能在一個伺服器上,如果我們使用高安全級別的話可能會對低安全級別的功能產生影響,如果使用低安全級別的整個伺服器的安全有沒有達到標準,沒有得到保障。很多運維工程師對待這樣的伺服器往往會捨棄安全換取便利,使用低安全標準,這樣帶來了很大的伺服器被攻擊的隱患,同時我們也確保如果一個服務被攻擊後不會導致其他的服務快速淪陷。
舉個例子來說,我們如果把兩種不同的動物圈養在一個柵欄裡面,我們首先不知道兩個動物會不會相互影響,就算不會相互影響,我們設計柵欄的時候也是很困難的,柵欄低了,長得高的動物可以逃跑,柵欄高了,長得低的動物無法時刻被圈養者關注著。

2.2.2 僅啟用系統功能所需的必要服務、協議、守護程式等

6269327-ea7cf1fae7ff3137.png
2.2.2

這和1.3.1有一點相似,1.3.1是禁止向不安全的協議,服務埠,輸入流量,這裡是不啟用那些非必要的服務、協議埠。前者是從防火牆角度,這裡直接是從伺服器,源頭解決安全隱患。就算有存在不安全的的服務、協議、埠,但是又是必須的,這就得必須確認通過公司的安全標準。

2.2.3 針對任何被視為不安全的必要服務、協議或守護程式實施附加安全功能

6269327-b38550ebcea858fc.png
2.23

這個在上面也提到了,如果一個不安全的協議、服務、埠是一個業務的必須條件,那我們就得實施自己的安全策略將解決協議或服務的不安全性,自己新增策略確保安全,同時也要有記錄!

2.2.4 配置系統引數,以防濫用

6269327-ad4dffbc04b79be3.png
2.2.4

這個應該是針對那些具體系統或應用來說的,我們要根據具體系統的安全引數來配置。比如mysql的安全配置,一個資料庫一個賬號,root只允許本機登入等。

2.2.5 刪除所有非必要功能,例如指令碼、驅動程式、特性、子系統、檔案系統和不必要的Web伺服器

6269327-fbc105675d6d9e35.png
2.2.5

對於一個安全體系較為完整的公司來說,每一個正在使用的系統,服務等都會有相應的記錄和負責人員,如果一些系統廢棄了,更換了,在整理完資料之後我們有必要刪除那些非必要的指令碼或者系統等。之前給某個公司做授權的滲透測試時,發現公司一個老域名上有一個已經廢棄的web服務,準備幾個月後更新,這幾個月一直處於無人監管的狀態,在這裡就有一大堆的sql注入,身份驗證繞過漏洞。所以對於廢棄服務,或者不必要的指令碼,驅動我們一定要定時檢測,清理,就算暫時不用也要進行安全隔離。

2.3 使用強效加密法對所有非控制檯管理訪問進行加密

6269327-5890c40988016d6a.png
2.3-1

6269327-606bcdb59b866d52.png
2.3-2

這裡也是很重要的一點,就是說我們如果不是在管理臺登入的管理系統,在其他地方登陸,比如我們ssh登入到某臺伺服器,或者http訪問某個管理後臺,所有的遠端訪問的時候我們就必須對我們的訪問進行強效的加密演算法進行加密!不然很容易就被竊取密碼。當然前提我們也得保證加密演算法或者協議的安全性,比如當時heartbleed的漏洞。

2.4 保留一份PCI DSS範圍內系統元件的清單

6269327-4c4d55aa66338515.png
2.4

這個就是自己制定一份清單,這個清單就是包括所有在PCI DSS這個標準下的系統元件,如果出問題我們可以縮小範圍。以及防止我們以防某個重要系統元件是否受到安全的保障。

2.5 確保已記錄、正在使用且所有相關方瞭解用於管理供應商預設設定及其他安全引數的安全政策和操作程式

6269327-4c1107760e1624cb.png
2.5

對那些使用了供應商預設設定以及其他安全引數的安全政策的操作都有記錄。且實時更新。比如我們一個郵件服務,我們哪些使用了供應商預設的,要有確認檢測並記錄,為了達到安全標準我們做了哪些安全引數的調整,這些也要記錄。

2.6 共享託管服務商必須保護每個實體的託管環境和持卡人資料。

這些提供商必須符合附錄A1中詳述的具體要求:《針對供應商託管服務提供商的PCI DSS附加要求》中詳述的具體要求。


6269327-91ea7e610e9e6644.png
2.6

這是針對伺服器,託管環境提供商對客戶伺服器的保護的要求。主要在附錄A1中,雖然不是針對公司的,但是我們也得知道服務商能為我們做到什麼樣的抱回。我們具體看看這四個要求。

附錄A1:針對共享託管服務提供商的PCI DSS附加要求

6269327-3a32422ef5e84141.png
A1

託管服務提供商必須保護每個實體的託管環境和資料。舉個例子,比如我們公司尋找一個資料中心託管服務商,需要考慮很多問題,除了網路上的保護,還有物理上的,比如我們會找一個不會發生地震這種天災的,離公司近的託管服務商。PCI DSS特地對託管服務商也有很多要求,這是在確保公司內部做好之後,第三方的提供商也有足夠的安全保護策略。這個也方便我們在尋找託管服務提供商的時候大概有一個標準,而不是聽對方的盲目吹牛。

A1.1 確保每個實體僅執行可訪問自身持法人資料環境的流程

6269327-1bfe54792edeb9c1.png
A1.1

就是共享託管服務提供商必須保證每個客戶只能訪問和執行自己的伺服器,或者說資料環境。具體一點就是我每一個實體(商戶,客戶)都有自己特定的賬戶,而不是共享的一個。就是做好許可權的劃分,特定客戶自己的只能操作和訪問他自己的,對其他實體都沒有許可權。

A1.2 每個實體的訪問許可權和特權僅限其自身的持卡人資料環境

6269327-b062bdd5081e272e.png
A1.2

同樣是許可權的問題,每個實體都只有自己的檔案和目錄的許可權,沒有其他使用者的檔案或資料夾的任何許可權,也沒有對任何系統檔案的任何許可權。系統檔案這些應該掌握在託管服務提供商手上。同時對伺服器上不同的資源均已分配好和有限制,不會造成其他漏洞被利用。

A1.3 確保日誌記錄和檢查記錄已啟用、對於每個實體的持卡人資料環境唯一且符合PCI DSS要求10

6269327-f9d05410317b2274.png
A1.3

這裡是保證託管服務提供商對指定客戶有指定的日誌記錄,同時確保日誌記錄處於活動狀態。且可供客戶檢視。這樣客戶自己就可以通過日誌檢視操作和登入等資訊。

A1.4 啟用相關流程,確保在任何託管商戶或伺服器提供商受到威脅時提供及時的取證調查

6269327-1a23f9fb9b95dde7.png
A1.4

這個就根據字面上就可以理解的。服務商得有相關書面政策,如果服務提供商出現問題,服務提供商是可以被取證調查的。如果我們的資料等在服務提供商那裡出現問題,我們可以根據他們之前的書面政策,對服務商進行取證調查。

總結

要求2大概到這裡就結束了。要求2:不要使用供應商提供的預設系統密碼和其他安全引數
很重要的一點,雖然看起來只有一句話,但是細看下來裡面的內容還是不少的。最後還是告誡相關從業者,不要圖自己的方便,而使用了預設提供商提供的這些預設配置,他們並不用為你的安全負責,但你自己要!很多時候不得不使用,也得有一定的安全策略保證其符合PCI DSS的標準!
後面也看了看附錄A中對託管服務提供商的一些要求,這些也為大家提供了意見,這個也是必須要了解的,起碼能知道他們能為我們做到什麼地步,更多的還是要看到他們做不到或者不能做的地方,我們自己需要去補充。

相關文章