實戰經驗分享：全國攻防演習的防守體系建設
近年來，多層級、不同規模的網絡安全實戰攻防演習已經成為檢驗各單位安全建設的重要手段，也是檢驗和完善網絡安全事件應急預案、提高應對突發網絡安全事件能力，加強網絡安全隊伍建設的重要支撐。如何建設切實有效的防守體系，是擺在廣大政企單位面前的一道難題，在建設防守體系的過程中，確定核心目標、獲得有力的組織保障、進行有效的安全排查與加固都顯得至關重要。
1確定防守目標
攻防演習開始前，需要提交參演方相關信息，比較關鍵的的是核心業務系統和蜜罐信息。
前幾年演習是有被攻擊“出局”這個說法的，核心系統被攻破基本就“出局”了。核心業務系統的選擇對結果有重要的影響，所以核心業務系統盡量選擇業務隔離內網的目標作為核心目標。不僅可以提升攻擊難度，也可以借助演習讓攻擊者對本單位進行一次徹徹底底的滲透測試。
在明確了核心業務系統后，后續的安全排查和加固工作，都要圍繞核心業務系統展開。具體排查和加固方式后面“3. 安全排查/加固”部分重點分享。
另外一個要報備的關鍵信息是蜜罐，如果沒有報備的蜜罐被入侵，不管是自建的還是采購的商業蜜罐，都會算做防守方失分，所以這點一定不能遺漏，尤其是具有高交互特性的蜜罐。蜜罐至少要提供蜜罐的URL、IP、端口、截圖。關于蜜罐的部署和利用，將在后面“3.4 反入侵能力增強”部分重點講，蜜罐在威脅感知、溯源反制和威脅情報的重要作用。
２組織保障
整個攻防演習期間組織保障非常關鍵，公司業務層面的重視程度會影響安全排查和加固的效率，間接影響效果。舉個最簡單的例子，安全團隊要梳理各域名資產責任人，需要與運維團隊配合，很多老舊的歷史資產無人維護，甚至需要找到對應的研發來確認資產所屬。如果研發和運維團隊認為演習只是安全團隊的事情，配合效率低下，這是很可怕的事情。
2.1 項目重要性
為了解決組織內各個團隊的配合問題，一定要將演習的優先級在大部門內提起來，這個各個公司可能都不太一樣，由于公司自上而下都比較重視攻防演習，所以其重點工作主要是制定演習方案。制定好演習方案后與產研、運維、運營等團隊達成一致，明確各團隊職責，確定演習接口人與安全團隊對接。
由于攻防演習本身的性質是針對基礎設施的，所以大部分安全部門接到演習任務基本都是“政治任務”，很少會有不重視演習的情況。安全部門要借這個機會盡可能的爭取資源、預算，不論整體安全能力如何，每年的攻防演習都是全員配合的重要任務，這是最容易提升安全能力的時候，日常推不動的工作，在演習的背景下，很多問題可以迎刃而解。
除了部門內部的協作外，還要考慮體系內是否有其它安全力量可以合作。比如部分生態公司、合作伙伴與本業務的網絡架構有耦合，這些也可能會成為攻擊者的突破口，需要對方也做好演習的相關準備，至少要做到攻擊情報互通。
2.2 項目啟動
在都已經明確各方職責，私下達成一致后，可以開一個項目啟動會。介紹演習的背景、規則、目標，以及演習的時間安排、人員安排、工作內容安排等。工作內容是最重要的部分，主要的思路可參考后面“3. 安全排查/加固部分”介紹。看到有人在論壇上抱怨演習備戰中各方不配合，內部甚至也在“摸魚”，其實核心原因就是大家的職責不明確，認為自己所做的事情可有可無。所以在啟動會上一定要明確這點，大任務分拆成小任務，小任務完不成，大任務也不會有好結果。
2.3 進度風險匯報
項目啟動會后，演習正式進入全面備戰階段。
演習備戰的大部分工作是安全自身要做的工作，比如Agent部署率、安全產品規則檢查等。當然也有很大一部分工作其實并不是安全團隊完成，比如業務接入統一認證系統、漏洞修復，可能更多的是研發需要工作，安全部門大多是推動工作，推動的痛苦相信甲乙方的同學應該都了解，如果推不動，對演習結果產生影響是誰都不想看到的，所以備戰期間定期進度review非常重要，默安這兩年都是秉承著“急事隨時匯報，階段性每周匯報”的思路。說起匯報，就要說一說，匯報給誰？答案是要匯報給兄弟團隊，匯報給產研、運維、運營，最重要的是匯報給大領導，因為要匯報的不僅僅是進度，還有需要決策的風險。如果只是匯報進度，周報就完全足夠了。
進度匯報的主要思路是圍繞“風險”進行匯報，首先是我們目前關注哪些風險？其次是哪些已知的風險落地有風險？比如互聯網邊界排查，ACL邊界開放過大是我們關注的風險，內部系統開放到外部的風險大家都懂，但是我們在排查中就發現有很多內部系統開放到一些未知的IP段，這些IP段看起來似乎也不是本業務的相關IP，但也無人認領。安全部門要不要封禁這些IP段？敢不敢封禁？如何封禁？每周的匯報會上就是要討論這些風險的如何處理。
３安全排查/加固
攻防演習防守的其實是企業資產，演習前的一切安全排查和加固都圍繞核心資產展開，以核心資產為中心，向外輻射到各個資產。資產包括物理資產、硬件資產、軟件資產等，另外人也是紅藍對抗中最容易造成突破口的資產。梳理資產的目的是為了明確網絡邊界，只有明確了網絡邊界和防守邊界，才能更好的制定策略。如何梳理全面企業資產將在“3.1 梳理資產”部分詳細介紹。
我們在落地過程中主要圍繞安全部門各小團隊的職責來劃分工作，讀者可以視各自的情況來定。我們主要分為生產網安全、物理安全、數據安全、反入侵這四個部分來構建防御體系。各個團隊可能會有部分職責重疊的地方，比如系統網絡和應用安全都會面臨弱口令等數據安全相關的權限問題，這很正常，在進度風險匯報中說清楚做了哪些，哪些還沒做，定清楚Owner即可。
為了保障安全排查的全面性，大部分工作都是正向自查和紅隊反查的方式進行。下面各章節會詳細介紹如何正反怎么配合進行。
3.1 梳理資產
首先資產主要分為硬件資產、軟件資產和人。軟件資產和人其實相對是比較好收集的，數字化能力相對比較高。硬件資產比較依賴IT和IDC相關部門的能力。不論以何種方式完成資產的梳理，哪怕是Excel來收集，這是一定要做的。
硬件資產主要包括機房設備、網絡設備、安全設備、辦公網區設備等，這類資產一般涉及到多支團隊，需要耗費大量人力投入去梳理。這里需要注意的外采設備的梳理，不論是外采的“盒子”還是私有化部署到服務器上的設備，都要收集到，比如VPN、APT威脅檢測設備等，這類設備如果出現漏洞被攻擊，比業務主機被拿下的風險還要大。
軟件資產主要包括域名、IP、機器、應用等，我們的業務全部上了XX云，XX云有完整的API接口可以實現資產的拉取。結合業務使用的云產品，通過XX云API接口可以基本可以實現云上資產的梳理。
· 域名資產：如果使用了XX云“云解析”產品，可通過DescribeDomains接口獲取所有域名，再通過DescribeDomainRecords接口獲取所有子域名。
· IP資產：由于我們的網絡架構問題，主要關注負載均衡SLB和彈性公網EIP，SLB可通過DescribeLoadBalancers接口獲取所有SLB實例，EIP可以通過DescribeEipAddresses接口獲取。
· 應用：XX云上所有ECS都裝了安騎士和態勢感知的Agent，可以很方便的取得完整機器列表和IP列表，甚至包括端口開放情況、中間件和版本情況。另外態勢感知也會基于中間件版本來匹配已公開漏洞，進行漏洞掃描。
還有一部分資產是“人”，梳理人的資產基本找HR就能拿到全集，梳理這部分數據是為了做后續的安全意識培訓和釣魚演練。
我們第一步花了大量的精力去梳理資產，最終得到了一張公司資產大圖，下一步我們要做一件更加痛苦的事情，明確資產責任人和安全責任人。
一般運維團隊會有CMDB系統協助我們完成很多資產的歸屬，但仍有一大部分需要人力推動去確認。如果這里的工作進展的極其痛苦，那么說明日常的安全流程建設，還是有很大的提升空間。如何提升我們在最后的“5.2運營機制優化”部分細聊。
完成資產梳理工作后，就可以正式進入安全自查階段了。當然，部分已知的安全問題是可以和資產梳理工作同步進行的。
3.2 生產網安全
生產網安全部分主要分為應用安全、系統網絡安全、數據和權限安全三大類。
3.2.1 應用安全
應用安全主要圍繞漏洞管理和安全方案展開，主要目標是保障生產和測試環境完成安全加固，通過紅隊滲透測試驗收。這里列幾個重點工作方向供大家參考：
- 漏洞修復
已知漏洞修復（含日常SDL檢出的漏洞、滲透測試發現的漏洞及其他漏洞）
- 封網和需求安全評審
演習期間要進行封網，演習期間原則上不允許上線新業務。應用安全團隊要積極與產研梳理演習期間要上線的業務，該業務改動較大，安全風險比較大的，建議推遲到演習后上線。
- 安全能力覆蓋率排查
如SDL卡點、白盒掃描、RASP、WAF、安全Agent等安全能力的覆蓋率，若未覆蓋全的需在演習前覆蓋完畢并做好安全檢查。
- 內部高風險系統安全排查
內部高風險系統進行重點安全評估，如運維系統、安全、客服系統。這類系統如果被入侵，通常具有較大權限，甚至可以直接控制線上所有資產。
- 社會工程學攻擊防范
因為演習的規則是允許一定程度的社會工程學攻擊的，比如釣魚郵件、客服系統的攻擊，都是比較高頻的攻擊手法。我們可以考慮在演習期間做一定程度的加固，比如禁止郵箱服務接受外域郵件、客服系統關閉文件上傳通道、客服系統超鏈接點開前二次確認等。
- 供應鏈攻擊防范
這里包含軟件供應鏈以及生態公司、合作伙伴等，軟件供應鏈主要是檢查系統耦合的一些第三方包/庫是否安全。對于在網絡上存在耦合的合作伙伴和生態公司一方面是要求對方做好加固和值守準備，另一方面是要做好切斷合作伙伴與本業務網絡通道的應急預案。
3.2.2 系統網絡安全
系統網絡主要圍繞網絡邊界、訪問控制、認證鑒權、主機安全展開，主要目標是確保生產環境、測試環境、預發環境以及辦公網的網絡安全，列幾個重點工作方向供大家參考：
- 網絡隔離排查
網絡隔離檢查主要兩方面，一是邊界對外開放情況的摸排，確保內部系統都正確設置了ACL且沒有開放過大的情況（比如將內部系統開放給某個大B段）。ACL排查的效果首先取決于3.1 梳理資產部分梳理的資產是否完整。二是內部網絡區域劃分檢查，不要出現“一張網”的情況，防止攻擊者突破邊界后可直接訪問到核心業務系統。
ACL排查主要分為兩類，一是域名對外開放的情況排查，二是主機對外開放的排查。我司的安全架構設計的比較嚴格，所有的主機（ECS）禁止配置彈性公網IP，所有對外開放必須通過SLB，我們通過拉取SLB資產的配置信息即可拿到全部的ACL策略。域名通過拉取WAF/SLB即可拿到所有的ACL策略。所以我們的主要工作都在檢查策略上。
檢查ACL策略可以先指定一些黑名單，比如對外開放設置為*的，必然需要與業務方確認進行更細力度的設置。設置為大B段的同理。黑名單可以篩掉一大部分異常的ACL規則，白名單的只能逐步與業務方確認。
- 主機/終端高危漏洞修復
這里主要關注服務器上可被利用的RCE漏洞，未授權漏洞，主要是為了防止黑客利用這些漏洞突破邊界，即便被突破，也可以增加橫向移動的攻擊成本。
如果企業有安裝安全Agent，大概率會有主機漏洞掃描的能力，XX云用戶可以使用態勢感知進行漏洞掃描，確定要修復的漏洞種類和機器，甚至可以一鍵修復。當然，修復是有穩定性影響的，需要和運維、研發定好策略，做好備份，按批次修復。
- 系統弱口令和未授權風險排查
對所有Web系統、安全設備、網絡設備進行未授權和弱口令檢測。這部分工作要根據梳理的資產寫一些小腳本，快速進行檢測，可通過主動掃描來做檢測，也可通過流量分析來做檢測，具體做法這里不細談。
- 辦公網網絡加固
這部分主要是確保終端EDR的部署率，確保安全規則設置無誤。可以根據各自的情況做一些相對嚴格的限制，比如封禁辦公網終端間除80，443端口以外的其它端口訪問、禁用USB讀寫（如有強需求建議專機專用）。另外辦公網也可以部署一些蜜罐來迷惑攻擊者。
辦公網的WIFI也可視情況進行加固，如無必要，可在演習期間關閉WIFI網絡。
辦公網的硬件設備也要注意清點，比如VPN、會議系統等。這類設備很容易對公網開放，且0day比較多，如無必要也可以考慮在演習期間關閉。
3.2.3 數據和權限安全
數據和權限安全團隊重點關注賬號權限、密鑰風險，列幾個重點方向供大家參考：
- 賬號權限收斂及密碼策略排查
賬號權限收斂首先根據梳理的資產明確具有賬號權限的核心B類系統，安全設備、網絡設備。權限收斂很大一部分工作是做閑置賬號的清理。如果公司沒有統一認證系統和權限管理系統，那么大概率會出現已離職人員賬號未清理、閑置賬號（一兩年都沒用）的情況，這些賬號無人使用，如果出現弱口令，被攻擊也無人感知，風險極大。密碼策略排查這里就不再細說。
- 密鑰治理
由于業務全部上云，各個云產品都有對應的AK/SK，密鑰風險的管控在云上尤為重要。主要是密鑰泄露風險，如果一個大權限AK被泄露，通過API基本可以控制云上所有資產。泄露的核心原因還是明文存儲，在代碼中明文存儲、在服務器上明文存儲、在腳本里明文存儲。治理思路首先是排查大權限AK，確認是否有開這么大權限的必要，如果確實有必要，是否可以縮小為只讀權限。排查明文存儲根據我們的工作場景，主要排查主機文件、OSS Bucket上的文件、Git倉庫文件，撰寫腳本批量排查這些地方是否有明文存儲AK的情況并進行整改。
另外一個方式是對AK做ACL限制，限制AK僅允許生產網的IP段訪問API，另外聽說XX云后續要做到AK限制到只有哪個VPC來訪問，這里給XX云點個贊，期待。AK限制ACL這件事推動比較難，在AK申請流程中增加限制可解決增量問題，存量未設置ACL的AK就需要日常去推進了。
密鑰治理我們更多的是在講限制，但問題肯定是沒法全部覆蓋的，所以需要有兜底的手段，我們是通過與反入侵團隊合作，調取AK調用記錄，定制監控，若AK被非生產網IP所調用，會實時告警。
3.3 物理安全
物理安全顧名思義，也有不少需要注意的點。
3.3.1 辦公區物理安全
辦公區物理安全主要是防止近源攻擊，WI-FI網絡、RFID門禁、暴露的有線網口、USB接口等都可能會成為近源攻擊的對象，比如我們當時就發現門口的打卡機連接的網線，可以直入辦公網。還有乙方老生常談的“撿U盤”、醫院的服務終端機沙盒bypass等。各位可根據實際情況進行對應的加固。
3.3.2 機房物理安全
默安機房也有對應的安全團隊，所以額外做了些限制和監控，托管的IDC可做的事情不多，這里不細說。
3.3.3 人員安全意識
人員安全意識比較關鍵，安全攻防核心其實是人的對抗。理解攻防演習通過社工攻擊人的情況太多了，所以一定要做全員安全意識培訓，不同工作性質的人群遇到的風險可能不近相同，比如客服是最容易被釣魚的，那就要對癥下藥，政策和安全意識教育兩手抓。
3.4 反入侵能力增強
聊起反入侵，其實很多公司可能沒有反入侵這支團隊，入侵檢測和應急響應的事情更多的是其它安全工程師兼著就做了，但反入侵這些事情，對攻防演習的效果有決定性的影響。
這里按照滲透測試、威脅情報、威脅感知、應急響應、溯源反制五個方面來詳細介紹。
3.4.1 滲透測試
其實常規的滲透測試可說的不多，每年我們在攻防演習前都會對業務進行全面的滲透測試。因為演習目標是“零”失分，所以滲透測試重點一般是模擬突破邊界。當然，在日常的滲透測試中也會做東西向滲透測試。
反向驗證，在滲透測試這個部分單獨說一下。我們安全團隊雖然大家做的事情都是為了提升安全能力，但還是分為了以安全加固為主的“正向團隊”和更偏攻防實戰的“反向團隊”。在演習前做的所有加固工作，反向團隊都會進行驗證。舉兩個例子，第一個是正向團隊為了確保安全防護效果排查了WAF的部署率，那反向團隊就會做反向掃描，看是否有遺漏？以及WAF規則是否都正確開啟？結果還真發現了由于XX云WAF大版本更新，IP加白/加黑配置方式變化，導致大版本更新后配置的ACL加白全部無效的情況。第二個是正向團隊推進業務接入統一認證系統，結果在反向驗證中發現統一認證系統接入SDK并不統一，各個業務放接入方式不一致，導致部分認證可被繞過。
說這么多是為了告訴大家，做安全加固還是要驗證，不能太相信“經驗”。
3.4.2 威脅情報
實戰攻防演習在演習期間，其實是“情報戰”。第一年參加演習的時候，感覺雷達就是黑的，不知道誰攻擊了我，也不知道現在演習到底什么情況，非常惶恐，這其實就是情報不到位導致的。另外在威脅感知、應急響應、溯源反制大量利用到威脅情報，所以第二部分重點講一下威脅情報的生產和消費。
- 威脅情報生產
我們建設了一個內部的威脅情報庫，主要包括IP、UMID、UID、姓名、威脅類型、威脅等級、情報可信度等字段。根據如下信息產出威脅情報：
- 歷史WAF、態勢感知、安騎士、云防火墻、自建告警攻擊記錄
- 實時沉淀安全告警信息
- 互聯網公開威脅情報收集
- 威脅情報蜜罐
- 三方安全廠商及威脅情報廠商合作
- 合作伙伴及生態公司威脅情報共享
上面列的這些威脅情報來源都比較好理解，歷史攻擊記錄都存在ODPS中，通過ODPS SQL就可以查詢出對應的信息并寫入到威脅情報庫。
某大型云廠商大部分云產品日志都存儲在日志服務SLS中，通過Blink或SLS自帶的數據加工功能即可篩選想要的實時告警寫入到威脅情報庫。
互聯網公開威脅情報就寫對應的爬蟲存入威脅情報庫即可，這里推薦一個免費開源的firehol威脅情報庫，firehol本身收集惡意IP是為了做防火墻規則的，當然也可以作為威脅情報來使用。firehol的缺點是只有IP和大致類別，沒有更詳細的字段。
威脅情報蜜罐這個顧名思義，甲方做的話成本比較高，要考慮投入產出比。建議了解下三方安全廠商和威脅情報廠商，另外默安科技的幻陣蜜罐目前用的廠商比較多，其實是能產出較多的威脅情報的，采購一波默安蜜罐，既能做威脅感知，又可以白嫖重保期間的威脅情報。
合作伙伴和生態公司威脅情報這個也很好理解，需要提前制定好威脅情報格式或者使用國際通用的STIX/TAXII格式，然后推動合作伙伴按照該格式共享威脅情報。當然，也可以在戰時人工同步。
- 威脅情報消費
當我們收集了足夠多的威脅情報后，只有在消費/利用了情報才會產生價值，否則就僅僅只是“威脅情報”。
情報消費消費主要分為三大場景：攔截、感知、響應。
攔截：高精準度的威脅情報，我們可以直接加入到防火墻規則攔截，比如firehol的威脅情報就分為很多種，有的是惡意郵件、有的是曾經是C2服務器，還有一類是目前沒有被分配的IP，這類IP正常情況是不可能有訪問行為的。大家可以根據自身業務情況，選擇可以攔截的情報進行主動攔截。
感知：我們所有業務都在XX云上，XX云提供了所有ECS的網絡連接日志，所以我們可以監測ECS外聯威脅情報惡意IP的情況，包括Web訪問日志可以過一遍威脅情報。部分無法直接攔截的情報，也可在內網網絡連接中進行檢測和告警。
響應：演習期間的告警量往往比平時高好幾倍，為了提高告警運營效率，我們將所有告警統一到一起，全部過一遍威脅情報，告警運營時可參考威脅情報的評級重點關注相關告警。
威脅情報消費部分這里只是簡單講了講思路，具體的做法在后面幾個小章節里面會細講。
3.4.3 威脅感知
威脅感知就像是攻防演習打仗時候的情報來源，像雷達一樣。威脅感知做的不好，雷達上就一片黑。我們威脅感知的basline是靠XX云WAF、威脅感知、安騎士等云安全產品支撐。
為了進一步提升威脅感知能力，我們在威脅情報、蜜罐、蜜餌、核心系統重保等方面也下了不少功夫。
- 蜜罐部署
我認為蜜罐有兩個重大意義，一是做威脅感知的兜底，二是溯源反制的利器（后面“3.4.5 溯源反制”里面重點講下如何利用蜜罐來做溯源）。大部分安全產品和自建的告警，其實是基于惡意行為的檢測，都是“黑名單”，如果沒有對某種威脅行為建模，就無法捕獲這類攻擊行為，所以蜜罐的部署和覆蓋策略就非常關鍵。
蜜罐的原理是模擬真實業務系統，投放誘餌吸引攻擊者攻擊，攻擊者攻擊后蜜罐產出告警，達到威脅感知的能力。
互聯網和內網面臨的攻擊手法大不同相同，所以我們在互聯網上部署高交互、高仿真的蜜罐，吸引攻擊者進行攻擊，在蜜罐上植入溯源代碼，獲取攻擊者的互聯網ID、設備指紋等信息。除了采購安全公司的蜜罐（比如默安科技的幻陣高級威脅狩獵與溯源系統），有條件的單位可以將自己的業務系統代碼拿出來，剝離掉所有功能，僅保留登錄功能，登錄功能使用SSO，這樣攻擊者在攻擊時一定會注冊業務系統賬號，可能就會留下注冊所需的郵箱、手機號、IP等信息，便于識別和溯源攻擊者。
- 擴大蜜罐感知面
互聯網蜜罐在部署上我們一般會選擇OA、VPN、MAIL等沙箱，那么互聯網蜜罐可以使用oa.xxxx.com、vpn.xxxx.com、sslvpn.xxxx.com、webmail.xxxx.com諸如此類的域名，但要注意的是一定要在演習前將該域名報備到蜜罐列表中，否則蜜罐被攻擊可能會導致失分。
內網蜜罐主要是為了發現攻擊者進入到內網的情況，所以部署的越廣越好，但內網假設有1000臺機器，我們不可能部署1000臺蜜罐，一般的思路是在每個網絡區中部署一套蜜罐，然后在該網絡區其它機器上部署流量轉發腳本，將業務不需要的端口流量轉發到內網蜜罐中。
- 誘餌投放
投放誘餌其實也是為了擴大蜜罐感知面，吸引攻擊者來進行攻擊。投放誘餌其實是順著攻擊者的思路來進行投放，攻擊者在做攻擊的第一步永遠是信息收集，那么攻擊者會收集哪里的信息？答案是：Github、百度文庫、百度網盤、企查查等等，紅隊信息收集手法很多，我們在這些必經之路上都可以設置誘餌，比如我們在Github上傳一些代碼，其中夾雜著蜜罐的URL，甚至放個假密碼上去。在百度文庫上上傳一個XX系統使用文檔，里面包含蜜罐的URL和默認賬號密碼。在百度網盤上傳個反制木馬，命名為“XXX單位VPN使用幫助”，諸如此類，可做的很多。不過這里想要起到更好的效果，可以先對本單位做一次互聯網風險暴露面的排查，看看重災區在哪，邊做排查清理，邊做誘餌的投放。在Github上投放誘餌也有一個小tips，如果我們按照正常流程上傳代碼，那么Github會顯示該項目是1秒前剛上傳，攻擊者又不傻，HW各個公司都在做安全意識培訓，怎么可能有研發蠢到在這個時間點上傳代碼到Github，所以我們可以通過修改系統時間，然后commit的方式，讓Github顯示這個代碼是X年前/X個月前上傳的代碼。像這樣的小tips非常非常多，就不在這里贅述了。
3.4.4 應急響應
3.4.4.1 完善感知和處置能力
攻攻防演習核心其實是攻擊和防守，防守上有兩個重點，一個是感知（發現攻擊），另一個是處置（阻斷攻擊）。首先在網絡層面，至少需要有全流量安全感知設備，可以配套用蜜罐來做兜底的威脅檢測。這里也可以做的比較細，比如從互聯網的攻擊可以用WAF來做感知和阻斷，辦公網的可以用EDR來做感知和阻斷，辦公網VLAN間用防火墻來做隔離，郵件安全用郵件網關，諸如此類，要保障幾乎所有外到內、內到內的路徑我們能發現攻擊，且能阻斷攻擊。
3.4.4.2 完善處置流程
感知和處置能力完成以后，還要考慮人為因素，應急響應流程應該由誰來發起，誰來審批，誰來執行處置動作。這類預案要提前設好，比如DMZ區的主機權限被控如何應急、隔離內網的主機被控如何應急、Web發現攻擊如何應急、如果流程上審批都通過了，技術人員按照哪種步驟進行應急。這都要提前寫好預案，至少有技術上的playbook。
3.4.4.3 應急演練
應急演練主要是兩個目的，一是驗證處置能力是否有效。二是驗證應急響應流程是否有效。
首先是驗證處置能力是否有效，比如：模擬黑客攻擊Web，看WAF是否能發現Web被攻擊，使用WAF進行攔截，驗證WAF攔截的有效性、時效性等。主機側和網絡側類似。
二是驗證應急響應流程是否有效。比如：發現某類攻擊，啟動應急響應流程，關鍵人是否敢審批？我們之前在突擊演練中就發現一些問題，當技術提交應急響應流程單以后，客戶需要層層向上報批，一直報到大領導，才敢審批，這個過程持續了將近30分鐘，應急響應的難度大大增加。這種情況就需要對流程進行優化。
４結 語
本文重點圍繞反入侵能力的增強建設，闡述了攻防演習中防守體系建設的思路，從演習前期的防守目標確立、團隊組織建設，到演習過程中的各項防守工作重點，內容涉及到資產梳理、生產網安全、物理安全等方面，并針對如何加強反入侵能力這一問題給出了多角度的思考，為廣大政企單位在攻防演習中的防守體系建設工作提供可參考經驗。
