一個人的攻防演練:聊聊企業安全策略

2019-11-11 560173人圍觀 ,發現 11 個不明物體 企業安全

寫在前面

首先交代下背景,本次演練防守方的客戶是一個金融企業,基礎安全做了近3年,基本上就要迎接高大上的深度探索階段,然后本次演練客戶不是主要目標,屬于大型目標下的小目標,也就是說供應鏈的一塊,演練的時間本來想說是一個月的,后續又是省護,大家都明白了,總之敏感時期,不是在演練,就是在演練的路上;之所以介紹這些就是想說,防守方屬于基礎安全扎實,整體安全成熟度屬于成長階段,同時并不是主要攻擊方,所以相應的我的壓力就會小很多,雖然期間出現了很多0day,也有很多掃描,嘗試攻擊,甚至有異常通信,但基本上都處理完了,可能有一些沒有發現的,這里也沒辦法說明,檢測能力并不能說100%發現問題,以上就是本次攻防演練的背景。

接下來可能要說的都是和安全策略相關,攻防演練期間我們采取了一個怎么樣的策略去進行防護,同時不影響業務,涉及策略的上層設計,策略的產生,策略的執行,策略的運營相關內容,因個人精力有限,就此拋磚引玉,共享盛世。

0×01 什么是策略?

策略宏觀上指的時根據形勢發展而制定的行動方針和斗爭方法;

在服務器中,安全策略(Policy)的概念:安全策略既一種整體的安全控制策略,如依據某些服務的設計基本的存取控制策略,也是一堆具體規則(rule)的組合,指定具體服務針對具體資源的存取權限;

安全策略就是指在某個安全區域內(一個安全區域,通常是指屬于某個組織的一系列處理和通信資源),用于所有與安全相關活動的一套規則。這些規則是由此安全區域中所設立的一個安全權力機構建立的,并由安全控制機構來描述、實施或實現的。

通俗一點就是針對資產(網絡,數據,權限,賬號等)限制訪問,使用,授權等安全規則。

所以安全策略也可以叫做安全規則,由于策略的使用面和使用層級不同,策略有很多種表現,我這里參考威脅情報,我把策略分成戰略層,戰術層,作戰(運營)層,為什么這么分層?便于對策略有不同級別的深入考慮,就個人分析發現分層不宜過多,此外要系統;

那么參考情報分層,我們可以得出:

戰略策略:用于引導整個信息安全,網絡安全的總體安全策略,主要用于我們用策略解決什么問題這一邏輯;

戰術策略:策略如何去解決安全問題,主要考慮策略如何進一步的解決問題,問題的難易程度,策略的深度,如何去實現戰略策略等等

作戰(運營)策略:策略在針對安全問題進行解決的真實情況,有沒有解決?解決了多少?存在什么隱患。如何優化策略?

所以我們要從三個點去考慮安全策略的生命周期,至少目前是如此。安全策略解決什么問題?安全策略如何解決問題?安全策略解決問題的效果如何?

1.1戰略策略

大多數時候我們遇到某個策略時,腦海中總會有一種似曾相識的感覺。隨著策略的展開,策略運營者會發現這難道不就是之前做過的類似的策略。曾幾何時,同樣的場景,不一樣的人或工具,結果需要不斷的調整策略,直到策略看起來完成全面的防護;我們不禁會想,為何沒有在最開始就制定了完整的策略,一個全面覆蓋的策略。盡管在策略的調整過程中可能做了一些小的優化,但對企業的安全沒有持續,穩定的影響,可能有新的緊急問題得優先處理,導致策略一直沒有很好的覆蓋或閉環。人們對戰略有一個誤解,導致它往往被忽視。這個誤解是沒有時間實施戰略。在日常的事件響應世界里發生了很多事情,有時候是每小時一次,許多人為了保持戰術水平而感到不知所措。戰略往往被視為“有更好”而不是“有需要”,只有在時間允許的情況下才會制定戰略,但時間很少允許。

戰略策略的名稱不僅來自其涵蓋的范圍,通常是對信息具有長期影響的高層次分析,而且也來自其受眾。戰略策略面向具有行動能力和決策權的決策者,因為這種情報應該形成向前推進的政策和策略。但是,這并不意味著領導是唯一可以從這些見解中獲益的群體。戰略對各級人員都極為有用,因為它可以幫助他們了解在處理各級問題時的周圍情況。理想的情況下,戰略可以幫助個人理解為什么要制定某些策略,或者為什么將重點放在某個特定的領域將有助于更有效地發揮個人角色的作用。John Heidenrich說道:“戰略并不是一個真正的計劃,而是一個推動計劃的邏輯。”

在許多情況下,戰略、戰術或作戰(運營)之間最重要的差異之一是建模過程。在戰術和作戰(運營)策略中,分析人員使用他們可用的模型來解決手頭的問題,無論該模型是專家策略還是人工智能策略。在戰略分析中,那些模型往往是第一次更新或開發。

記住,戰略策略并不是策略的具體計劃和細節,戰略策略只是一個推動計劃的策略邏輯;戰略級的策略我們需要關注目的性和邏輯性;

1.1.1目的性

演練的戰略策略我們一開始有2個的目的:

1.盡量不被攻破

2.不給上級供應鏈造成破壞,并且不墊底

后來我們的戰略策略改成了:

不墊底

那么我們的戰略就決定了我們在接下來的戰術層面和作戰(運營)層面不會過于嚴苛,比如禁止變更,不允許開放站點等行為,在某一程度上我們會容忍一定的策略放過和調整;此時的策略對業務會較為放松,這也是演練期間業務運行的策略,其實和平時的是一樣的;

1.1.2邏輯性

與其說是邏輯性,倒不如說是合理性,邏輯嚴謹讓人無法反駁,從某種角度而言,策略的出發點是符合邏輯的,比如我們要做一個針對上網使用遠程工具的策略,禁止使用遠程工具,這就是一個簡單的戰略策略,有著具體的目標和目的;關于策略實施會在戰術和作戰層面詳細說明;

總而言之就是:

戰略策略一定要存在目標和目的,要在戰術策略,作戰策略層面可以實施,符合一定的目的性和邏輯性;

1.2戰術策略

戰術策略主要關注受眾,策略方法;

戰術策略主要是面向你的用戶,也就是策略的受眾,以及如何制定策略,注意,此時的策略并沒有實施,可以理解為一個解決方案;拿前面提到的針對遠程工具訪問內網的行為,我們制定了以下的策略:

針對業務人員禁止使用任何的遠程訪問工具

針對一些非業務,非管理員的用戶我們禁止使用遠程訪問工具

針對網絡,服務器等基礎設施管理員我們允許在短時間內容提單申請下有限使用

針對遠程訪問工具,我們收集了anydesk,teamviewer,向日葵,RDP等

不同的受眾有著不同的需求,就拿限制遠程訪問的受眾來說,高層,業務人員,銷售,辦公基本上是不需要或者不允許可以遠程訪問,管理員在遠程處理應急事件是可能會使用到遠程訪問工具,但大多數是VPN,供應鏈基本上都是遠程訪問工具;

上面就是一個具體的戰術策略制定,但是實際上執行情況可能會和戰術策略不太一致,但是不能違背禁止使用遠程訪問工具的戰略策略;

1.3作戰(運營)策略

策略分層只是為了讓戰略級別的策略能夠更好的落地,大多數的策略其實只分兩層:戰略和戰術策略,大概就是專注制定什么策略,策略怎么執行?但實際上策略制定完戰術策略后,需要考慮策略的真實落地情況,需要對一些用戶反饋意見較大的策略結合安全要求和業務適當調整,這里的調整不是讓步,而是理解;

針對使用遠程訪問工具,我們進行了調整:

收集了更多的國內外的遠程訪問工具

允許了部分供應鏈授權情況下進行遠程排查

增加了新的可控的遠程訪問手段

以上就是一個針對遠程訪問控制的大致策略設計;

1.4攻防演練案例

既然是演練,這里提一下我們在演練期間做的策略情況,可能有的總結點沒寫,但大致差不多,和大家演練的思路基本上是一致的。

1.4.1演練戰略策略

減少所有的外部風險

關注內部潛在風險

1.4.2演練戰術策略

回收測試區域的應用;

回收不符合安全要求的應用;

關閉不必要的端口;

排查外部弱口令情況;

組織演練溝通小組;

關注內部流量;

關注內部郵件

關注終端,服務器安全告警

1.4.3演練作戰(運營)策略

(1)盤點所有外部開放資源,確定所有可以進入內網的途徑,包括應用服務,端口,登錄頁面,確定資源的開放情況,關閉情況

(2)確定安全防護能力:確定所有安全設備的運行情況,安全設備規則庫,病毒庫,情報庫,甚至系統庫;

(3)監控外部威脅情報:0day,1day,Nday為主的攻擊情報

(4)聯合行業進行防護:同步相關攻擊情報,對攻擊IP進行封禁

(5)記錄所有的攻擊防護措施,避免過度防護導致業務運行異常

簡而言之就是:

(1)暴露面最小化

最小的暴露面,確定的攻擊路徑

(2)安全能力持續更新

保持最新的防護策略和規則,通常包括檢測規則和阻斷規則,這里有IPS,IDS,FW,天眼

(3)及時響應和相應的響應組織

及時響應演練期間發現的漏洞和情報,同時有相關的管理員配合,實現快速響應,同時提前制定好相應的響應流程

(4)備注和登記

一般而言,很難在演練結束的一瞬間完成整個安全能力的升級,當一些無法進行實時整改的,需要進行登記備注,然后關聯立項,同時部分策略實施后可能對業務會造成一定的影響,記錄便于恢復

這里還得提下規則庫,也屬于戰術策略的一部分,但由于可以進行優化的屬性,也可以看成作戰運營策略

0×02 策略設計

2.1需求產生策略

策略產生有很多,但最常見的就是兩種,甚至可以說就是一種,那就是需求驅動策略,安全需求驅動安全策略的產生;還有一種時約定俗成的基線,你需要這么做;

我們的安全策略的目的是解決一些安全風險和安全問題,那么安全風險和安全問題經常會產生一些相應的安全需求,我們需要怎樣的安全解決辦法?比如我們擔心賬號會被爆破,我們就用限制失敗次數和驗證碼的策略去限制爆破。我們擔心用戶會獲取過多的權限,我們默認是最基礎的權限策略,再要使用我們就通過申請審批來授權。我們擔心掃描器的結果不好,所以我們要求用2-3種掃描器進行漏洞評估,同時我們要求掃描時使用最新的策略。等等,我們需要什么樣的安全風險解決辦法,我們就在此基礎產生一定的安全需求,安全需求導向安全策略,安全策略總是有效的?不見得,后續我們在來聊一聊。

需求又從哪里獲取?

需求一般有三個來源:

1.上司:一般是技術負責人對于安全有一定要求產生的安全需求,這一類是實現波動性較大的,有的需求可以實現,有的不一定,但大部分你都會盡力去滿足,同時對上級的策略需要從多訪問理解,比如業務,安全,基礎設施等,一般都是戰略級別的策略。

2.用戶需求:此類需求又具體分內部用戶和外部用戶,比如你的內部用戶要求你臨時開放teamviewer權限,但你的安全策略限制了他的訪問,此時你會臨時在上網管理上開放,又或者你的內部用戶覺得在上班時間寬帶限速了,但下班時間以后也限速不合理,此時你就通過流控開放了18點之后的流量限制。外部用戶的需求一般和產品相關,比如登陸需要驗證碼,客戶覺得每次登陸都要驗證碼,體驗很不好,然后就進行了反饋,然后應用覺得可以關閉,但又擔心被爆破,此時你引入登陸設備,地址,時間段等風控手段,然后密碼錯誤的前三次關閉了驗證碼,這一整套策略的調整都是來源于每次登陸都要驗證碼的反饋,用戶此時滿意的提交下一個反饋。

3.事件驅動:其實有一些安全策略的產生是被迫的,也是應該要具備的,比如外網開放3389,有一天服務器因為外網開放3389被cve-2019-0708等類似漏洞拿下了,甚至弱口令爆破,我們的策略就變成了:禁止開放3389端口,事件驅動安全需求,安全策略是很痛苦的,或許我們需要一個默認安全策略。

此時,在這里不得不提一個產品解決安全問題思路,那就是默認策略。

我們常聽說Elasticsearch,mongodb數據泄露,通常是因為默認密碼沒有修改,倘若我們創建應用后強制修改成不同于默認密碼的強口令,此類事件會少很多,同樣一些防病毒默認是開始更新和同步,一些ips,waf,ti,ids產品配置好代理默認更新策略,默認關閉共享,默認關閉高危端口,等等,默認策略能夠避免人力所不能及的那部分策略的失效或者未生效。

其實標準和合規可以極大的驅動出策略的產生,關于標準和合規此處不做贅述。

2.2策略設計原則

一個好的策略應該是在所有的受眾下都可以接受并且是符合安全需求,業務需求的安全策略,能夠促進生產和安全能力提升;

最小化原則

一個好的策略應該是至少符合最小化,有效,可優化的,為什么這么說?

好的策略不應該過于龐大,應該是精簡而且恰到好處的,比如你擔心Web收到攻擊,所以你把WAF防護級別調到了最高,結果業務無法運行,實際上中級的防護級別加上定制化的策略修改就能夠滿足Web防護的功能,輔以web滲透和漏洞評估,網站監測就可以完成Web的基本防護

有效原則

策略最重要的其實是有效,任何的策略設計完之后如果無法起到預計的效果,都不是一個好的策略,比如在白名單防護策略中,由于白名單不詳細,導致白名單之外的正常業務無法運行,此時應該取消白名單,先用黑名單過濾,然后再完善白名單后進行策略實施;

自適應原則

好的策略應該是可持續,并符合自適應安全自身和業務安全要求不斷完善的,就拿限制遠程訪問工具的使用,很有可能出現新的遠程訪問工具,此時就應該將它添加的禁用名單,不然策略的本身就在失效中;

2.3如何設計一個好的策略

策略的好壞最終是看策略的實現,其目的和作用,如果你設計了一個策略,結果對業務造成了影響,那么這個策略從某種程度而言,雖然防護住了業務系統,但是影響了業務的運行水平,甚至影響業務連續性,這就得不償失,一個較好的策略可以從以下幾個方面考慮:

1.思考設計的策略是否可行?

好的策略是可以用于實現其策略的目的,并且落于實地;也就是說,首先策略能夠定位到人或者資產,能夠通過策略控制來實現策略的執行;其次策略是可以執行并不會影響業務和系統,策略的可行性從其他角度就是切合策略的受眾的可用性;既能夠實現策略最初的目的,又能夠保護業務運行不受較大影響,安全策略最終的服務對象大多是業務和內部需求下的用戶,此時要考慮業務運行和用戶體驗;同時要確定策略的受眾,策略所執行的層面到底時在哪些用戶或者設備資產,如果一個策略執行后無法在資產中進行定位,那么這個策略基本時無法運行的,管理策略也是如此;

2.策略是否可維護?是否可閉環?

策略實施之后可調整,可運營,可閉環,具備持續性,可維護性,如果策略在基礎設施,技術發展的沖擊下不復存在,此時策略應該取消,替換成針對新技術,新架構下的新戰略策略下戰術策略,作戰策略

可閉環,相比可維護,閉環更難以實現,畢竟一個好的策略應該滿足不但優化,并且能夠符合業務驅動下的安全需求和受眾,做到千人千面,反饋顯得極為重要,好的反饋流程反饋渠道可以讓策略落地的更加有效,這里建議將反饋渠道放在責任人和安全人員之間,最好有相應的討論渠道,不斷的快速獲取反饋和優化;

3.受眾是否樂意遵守策略并參與優化?

好的策略應盡可能的滿足受眾的心理期望并實現安全控制;

如果一個策略本身被大多數人抵觸,并且短期無法看到策略執行后的效果,此時應該思考策略是否需要調整,或者策略是否應該設計并執行,真正充滿人文關懷的策略是隨風潛入夜,潤物細無聲的,所以策略設計尤為重要,并且在流程上需要足夠的支持和適配;當然如果遇到適當的抵觸,但是總體效果不錯的策略可以適當的調整,以滿足幾乎所有受眾的體驗要求;

這里提一下漏洞修復策略:我對于安全是主戰派,就是強調安全是需要測試并且充滿主動的,所以我初期執行的漏洞修復策略是每月定期更新,并且強制推送,但是現在辦公網絡很多用戶都不會進行日常的辦公電腦維護,補丁安裝過程充滿了各種的問題和反饋,后續我將策略調整為高危漏洞或在野利用的漏洞強制推送,非高危且無在野利用的漏洞直接延期一月推送,并且對推送的時間做了調整,業務終端,也是反饋最多的終端在一個月基礎再延期一周進行推送,前期基礎設施,營銷體系先推送,整個策略調整后反對的聲音減少了一些,但漏洞管理依然會有一些抵觸;

2.4策略生命周期

整個策略從產生到終止分成4個階段:策略產生,策略使用,策略運營,策略終止

策略產生:策略經過戰略策略設計,戰術策略設計后產生的具體策略清單

策略使用:策略落地,開始對相應的受眾進行約束的過程

策略運營:策略開始作戰(運營)的階段,主要目的在于調整和優化策略,查缺補漏

策略終止:策略隨著技術架構變化調整后不再適用,經過評審后進行終止

基于策略簡單的設計了一個策略鉆石模型(參考事件鉆石模型):

該原子為“策略”,策略是最小單位,一個完整的策略應該有至少四個要素:目的,受眾,技術和管理;策略的基本元素比較簡單,主要有時間戳和執行結果,時間戳包括啟用時間,調整時間,終止時間。

目的

目的就是策略產生的基本目的,也就是策略的產生是用于解決什么問題的?為什么要制定這個策略,目的是決定策略的歸屬和方向,只有明確目的的策略才能具備效力,目的最好體現的層是戰略層策略;所以換句話而言,戰略層的策略應該是專注解決特定類型的問題,一般是業務和安全自身需求;

受眾

受眾即策略最終落地去實施和使用的人群,也就是最終評價策略好壞的一環,受眾的反饋有助于策略生命周期的延續,良好的策略反饋可以促進策略的優化和調整,不斷的促進安全和業務需求下的策略的落地和改善

技術

主要是設計策略過程中使用的各類技術,涉及開發,網絡,存儲,數據庫,桌面運維,郵服,中間件,安全技術等,相當于等保2.0中的技術部分;

管理

管理即通過流程,制度進行限定受眾執行,達到彌補技術措施無法實現的手段,比如人員管理,外包管理,策略修訂管理,業務上線下線管理,網絡安全管理,權限管理,供應鏈管理等等;管理策略多來源ISO27000,監管單位要求,等保2.0等

0×03 策略的使用

策略的使用其實沒有什么訣竅,大多說都是采取觸發式的辦法去使用策略,比如上線要安全評估,漏洞,基線,滲透,防護,甚至代碼審計,只有有載體出現,策略才能生效,而難度主要在于策略的賦能,所以有幾個建議:

建立策略庫->插入流程->收集意見->定期更新和維護

1.建立策略庫:把策略當重要資產一樣進行收集和統計,然后保持更新

2.插入流程/引用策略:包括安全流程,處置安全問題,安全事件的流程,包括應用開發流程,業務上線流程,員工入職離職流程,資源申請歸還,等等,在你的ITSM里面盡情,合理的展現

3.收集意見、反饋:開放策略收集和反饋渠道,很大一部分的策略沒有變化或者沒有優化大多是因為聽不到外界聲音,策略的創建和維護者在自娛自樂

4.定期更新和評估:沒有永遠不變的策略,只有相對完善的策略,不斷的評估策略有效性,完整性,可用性,嚴謹性。

總結下就是2種方式使用策略:

(1)變更,流程觸發策略使用:當有變更或者有措施將要執行的時候,插入策略評估,進行策略的評估,判斷受眾的行為是否滿足已生效要求的策略,同時關注潛在目的,需求,風險下的策略,尤其是那些還沒有實施的策略,這部分內容是策略運營的主要目的和核心;

(2)基線庫定制規范策略:對于策略進行封裝,讓“出場”的設置資產,業務流程就符合基本安全,滿足安全基線,從而達到策略規范,這里要注意的就是定期對策略進行檢測和更新,基線是需要定制并不斷的優化的;其深度,其廣度應該覆蓋所有的資產范圍,業務流程范圍;

0×04 策略運營

策略運營,現在大多數的安全都喜歡帶上運營二字,策略也是,運營就是對策略整個產生,使用,結束的生命周期下進行優化的過程,同時參考三同步,并讓策略持續擁有動能!

策略運營我把它分成策略檢測,策略更新,策略備份與維護,策略評估四大塊,簡單的理解就是策略的后續生命活動特征。

4.1策略檢測

策略下發或者受眾執行后不一定百分百的生效,甚至有的策略可能會進行規避,臨時的也好,長期的也罷,我們都需要一系列措施進行策略的檢驗和修復,常見的策略檢測手段有定期策略檢查,策略更新,策略備份與維護,策略評估,基線檢查,代碼審計等;

4.1.1策略檢查

策略巡檢即對業務流程,基礎設施資產等資源下發的策略進行人工巡檢,常見的策略巡檢方式有風險評估和等保檢查,安全設備評估,基線評估,代碼審計等;通過風險評估,等保檢查對資源進行排查,確認是否符合安全策略紅線要求;

(1)風險評估:對信息資產(即某事件或事物所具有的信息集)所面臨的威脅、存在的弱點、造成的影響,以及三者綜合作用所帶來風險的可能性的評估。作為風險管理的基礎,風險評估是組織確定信息安全需求的一個重要途徑,屬于組織信息安全管理體系策劃的過程。關于策略風險評估主要關注著策略對于風險控制的有效性,對資產面臨的威脅,存在的弱點進行規避的措施是否有效,如果策略無效應該采取什么措施去規避是重中之重;

(2)等保檢查:又叫等級保護,即對信息和信息載體按照重要性等級分級別進行保護的一種工作;那么就很容易理解策略對于資源的風險控制和保護要求,不同級別的系統所采取的的策略應該是不一樣的;

(3)安全設備評估:這里指的是安全防護能力的評估,當你部署了各種安全設備的時候,并對設備進行了啟用和防護,應該考慮安全防護,檢測,阻攔,響應相關設備的能力是否存在缺失并進行及時的發現和更新,這里就需要對于各種設備有一定的理解和掌握,并能夠自定義的優化相關設備,從而實現策略巡檢,優化調整

(4)基線評估:基線評估其實就是對各種資源的基線情況進行檢查和確認,這里主要準備的資源就是資產清單和資產對應的基線腳本和結果報表等

(5)代碼審計:檢查源代碼源代碼/3969)中的安全缺陷,檢查程序源代碼是否存在安全隱患,或者有編碼不規范的地方,通過自動化工具或者人工審查的方式,對程序源代碼逐條進行檢查和分析,發現這些源代碼缺陷引發的安全漏洞,并提供代碼修訂措施和建議。

(6)其他:其他可以對于策略進行檢測的任何方式,包括但不僅限于風險評估,等保檢查,安全設備評估,基線評估,代碼審計,比如訪談確認業務流程和相關策略執行情況,手段并不是唯一的,專注檢測出策略狀態的目的。

4.2策略更新

策略更新部分是僅次于策略產生的重要部分,該環節的策略運營決定了策略的生存周期和使用效果。

策略更新包括策略變更和策略調整

策略變更:策略變更涉及策略的調整的流程,就是如何對策略調整進行規范化,不能肆意的調整策略從而導致策略影響業務

策略調整:指的是具體的策略調整的動作,可以是縮小范圍,擴大范圍,增加力度,減輕力度等涉及策略具體操作的行為。

4.3策略備份與維護

一般策略的修復就是為了解決策略下發不徹底,下發后執行不徹底,策略執行存在Bug等情況;

常見的策略備份是通過設備已有的備份功能直接進行備份,然后將備份包進行定期的維護,存儲充足的情況基本上不考慮清理歷史策略;

維護:當策略因為實施過程中產生較大影響和事件時,需要對策略進行停用維護,或者策略不生效,出現了異常(不滿足策略當初設定的狀態),需要對策略進行分析和糾正的過程。也可以是將某一節點某一時刻的策略恢復到上一個正常的節點;

4.4策略評估

策略維護主要考慮策略的備份和高可用性,不會由于設備綁定策略等原因,從而由于設備宕機甚至設備淘汰之后部分優化策略無法使用,策略維護主要考慮策略的備份和還原,策略評估主要考慮策略的優劣,通常通過以下幾個問題來評估策略:

1.策略用來干什么?策略達成了目標么?

2.策略是否過于嚴格或者過于疏松?

3.策略是否可以跳過?

4.策略實施數據是否有存儲和記錄?

總而言之,一個好的策略就是有一個/多個明確的目標,追求簡約,同時又不可繞過,最后能夠定期的回顧和復盤。

0×05策略庫系統

經過上面對策略的探討,現在對策略進行一個基本的設計,此處只是一個Demo,僅供參考:

現在對上面的的模塊進行更進一步的分析:

對于一些不怎么出現的模塊,功能做一些自己的說明,通用的就不做說明了,比如賬號認證模塊

策略庫管理:對于策略的記錄,調整進行管理,主要是增加,刪除,修改策略,策略庫涉及基線策略,代碼安全策略,其他業務,應用,流程,管理策略要求;

策略檢測:主要是對于策略檢測的操作進行管理和記錄,和策略庫分開管理;主要檢測方式有基線檢測,代碼掃描,業務邏輯檢測等

策略下發:這里主要考慮策略庫系統可以實現的任務發布和無法實現下發的任務,可以調用的任務直接通過策略庫系統進行下發,無法下發的通過調用接口或者手動策略調整的方式實現,所以策略下發由自動下發,手動下發,手動排查策略3中方式;

資產管理:策略庫的資產主要由策略檢查中的資產,CMDB API導入的資產,其他手動導入資產進行管理,資產的緯度就是策略和策略檢查結果,檢查結果為不符合/總檢查項這樣展示;可以通過nmap,masscan來進行資產發現;

工單系統:用于管理從ITIL中提交的策略檢測的服務單和變更單,涉及策略的檢測,調整為主,同時對工單的創建,執行,結束進行同步和監控

任務系統:定時檢測任務和手動檢測任務,主要是對于工單系統記錄的內容進行操作記錄,運行的檢測腳本,執行情況進行跟進,對任務進行取消等

通知系統:對于一些策略評估項進行及時通知,對于一些結果進行手動通知

日志:策略庫管理日志,策略檢測日志,任務管理日志,工單系統日志,通知日志,資產更新日志等;

以上僅為demo,僅供參考;

總結

聊了那么多,你咋不放一些策略出來?

仔細想想,是沒有安全策略還是安全策略沒法實施。配置基線,病毒庫,補丁更新,規則庫,安全編碼和SDL,上線,下線,大部分的企業都有涉及,但效果都一般,要么太厚重沒辦法落地,要么太淺顯沒有效果,很大一部分的安全策略需求都是來自于基礎的安全需求和業務成長需要關注的安全能力,這一塊會成為基礎安全建設成熟度的一部分,并不是沒有策略,而是沒有用好策略。

最后說說演練,其實剛開始演練的時候我是不打算封IP的,因為這并沒有什么價值和安全能力提升,就和當初政企等保一樣,走個過場,然后應用和基礎設施依舊千瘡百孔,所以我對于惡意IP都是永久封禁和持續關注,后續再次高頻率出現就開展溯源分析。以致于后面演練的頻率從每小時一次分析告警到每天2次分析,演練期間是5*8值守,效果還行;

但從某種結果而言,HW給長期以等保為基線的企業帶來了新的安全思維,新的安全理念,不再是單純的報告和評分,而是攻防對抗下的博弈,也促進了很多甲乙方和安全從業人員對紅藍對抗的關注,所以我們都笑著說這是演習,對于企業來說,開放的端口和應用更清晰了,權限和內網架構,流量也更加的可見,風險管理也變得更加有效,這也是一件好事,就這次演練而言,做了很多,也深有感受,細細思量,最終得出一個結論:演練常態化是安全能力的持續正常迭代,這不能犧牲大量的用戶體驗來實現,有的直接關閉了外部郵箱訪問,有的邊緣業務全部關閉,意義不大,除非業務直接整體下線,那么新的業務如何開展?當然,像不做防護的郵箱,同時不遵循安全合規下的整改的邊緣業務關閉和回收也不是不可以;

總的來說,只有具有防護,檢測,阻攔,響應基本安全能力的企業才具有演練常態化的趨勢,但不能忽略策略和流程的力量。安全其實應該是一種能力和屬性,就像武器附魔一樣,給業務增加殺傷力,但如果因為過度附魔而導致業務奔潰,業務使用的限制大幅度提高,原來平民武器到后來需要神一樣的體質才能使用,那就得不償失了,合適的才是最好的;

接下來個人會重點關注安全建設框架和模型,“一次性”的安全建設不能保證業務的持續安全,為了讓安全更好的賦能,安全策略,安全建設應該更多的關注目的,業務需求驅動安全目的,戰略目的驅動策略和建設;

策略就是為了控制風險,這里對于其他部分的內容,如風險控制,業務安全,風險庫等內容不做過多的描述,會在后續的文章中聊聊自己的看法,也歡迎大家一起交流和分享;

*本文原創作者:LinuxSelf,本文屬于FreeBuf原創獎勵計劃,未經許可禁止轉載

相關推薦
發表評論

已有 11 條評論

取消
Loading...
LinuxSelf

欲窮千里目 https://anyeduke.github.io/Enterprise-Security-Skill/

3 文章數 77 評論數 0 關注者

特別推薦

推薦關注

活動預告

填寫個人信息

姓名
電話
郵箱
公司
行業
職位
css.php 什么app能玩二人麻将