摘要：前言之前的一個人安全部的大師傅把我們拉在了一起，然后逐漸發現群里大師傅們也發了建設經驗文章。月入職，一家具有支付牌照的互聯網金融公司，網絡運維部下。

之前的一個人安全部的77大師傅把我們拉在了一起，然后逐漸發現群里大師傅們也發了建設經驗文章。好吧，這么懶得我也分享下自己的經驗，也就當對這2年多來的甲方經驗的總結。感謝群里的小伙伴們，感謝安全圈的各路大牛們和小伙伴們的幫助，更感謝朝夕相處的同事們的幫助。

首先，把要說的重點總結下，時間就是金錢，剩下的都是廢話圍繞這些去說的。（PS。本文所說的甲方安全，全部指一個或者兩三個普通人的小團隊，非大佬團隊，非互聯網航母企業）

安全一定要由上往下去推動

不制定獎懲措施的制度是很難推行落地的

外部機構的檢查遠遠比自己找出來的問題更有影響力

作為甲方安全，你要以主人翁的角度去思考和推動，不要把開發看成敵人

不要任何事都自己造輪子，在現有的基礎上加以改造

不要一直做救火隊員，要推行有利于安全的流程

把安全做得有聲音，最好有產出物（P神總結的）

好了，開始廢話了

之所以把一個人加引號，是因為在甲方做安全，真的不能靠一個人來做，而是需要周圍一切可以借助的資源去做，才能夠做起來，否則很多事情舉步難行，到頭來樹敵萬千，工作也無法順利進行。

接下來是我做過的事情時間點

2015年一套合規各類檢查的管理體系，熟悉基礎架構、初步了解業務。

2016年救火的一年，發現問題修復問題，同時規范流程（基礎建設）

2017年把一些開源項目加入到環境中，彌補某些方面空缺（逐漸完善）

今年618買了本書，《互聯網企業安全高級指南》，神級的甲方建設指導的書，覆蓋很全面，思路很清晰。

?三張表

組織架構圖

產品和負責人對應表

全網拓撲、邏輯架構、物理圖、各系統間調用關系、數據關系流等

后面還有各類技術介紹，講的很全面。

很慶幸自己沒有走彎路，大體方向還對，不幸的是都是摸索的去做，會耽誤時間，有些客觀因素不能實現，比如團隊。。。

8月入職，一家具有支付牌照的互聯網金融公司，網絡運維部下。正好趕上支付牌照的認證，互金企業的監管機構太多了，等級保護，PCI DSS，ADSS，中金認證，人民銀行……

于是，為了應對檢測，先把現有制度熟悉了一遍，長遠考慮，打算重新搞一套符合各位大爺的制度，在原有不熟悉的制度上改造不如重新做。

管理制度制定的思路是依據 ISO27001 建立框架，分級制定“制度流程–操作手冊–記錄”。結合等級保護（許多人說等保只是應付，其實等保結合了各種標準，形成了一個安全基本要求，挺全面的）、ITIL（流程上可參考）、BS25999（業務連續性可參考）、NIST SP800-53 和ISO27005（風險評估可參考），管理專業人士請教育，畢竟我也不太懂…

因為金融業的合規要求很多，僅僅27001的覆蓋面是不夠的，因此結合多一些完全覆蓋各類合規檢測。

其實我國的GB系列標準，已經引進了多個ISO標準，而且全中文看著很方便。下面是推薦參考的內容，完全足夠。

? ISO/IEC 27001:2013信息技術 安全技術 信息安全管理體系要求
? ISO/IEC 27002:2013信息技術 安全技術 信息安全控制實用規則
? GB/T 22239-2008 信息安全技術 信息系統安全等級保護基本要求
? JR/T 0122-2014 非金融機構支付業務設施技術要求
? GB/T 20271-2006 信息安全技術 信息系統通用安全技術要求
? GB/T 18336-2008 信息技術 安全技術 信息技術安全性評估準則
? GB/T 20984-2007 信息安全技術 信息安全風險評估規范
? GB/T 20269-2006 信息安全技術 信息系統安全管理要求
? GB/T 27910-2011 金融服務 信息安全指南
? GA/T 708-2007 信息安全技術 信息系統安全等級保護體系框架
? ISO 22301：2012 公共安全-業務連續性管理體系-要求
? GB/T 20988—2007 信息安全技術-信息系統災難恢復規范
? GB/Z 20985-2007 信息技術 安全技術 信息安全事件管理指南
? GB/Z 20986-2007 信息安全技術 信息安全事件分類分級指南
? GB/T 24363-2009 信息安全技術 信息安全應急響應計劃規范

制度的制定并不僅僅是應對檢查，最終還是要落實，所以制度的細節一定要切合公司自身情況，盡量簡單易于執行。雖然落實比較難，但流程的東西一定要落實，比如系統上線、變更要規范其安全標準化。一般安全是掛在運維下……就算不是也要和運維打好關系，把基礎安全這層打牢，可以在運維推行部分流程，前面提到的4級文件形式，做過的事情要記錄，記錄盡量電子化，便于查閱，一是檢查的時候真的有，沒必要再造假了 – -！二是記錄也可便于事后的總結、追溯，有一天會幫助到你的。等大家適應了流程，再一點點細化、增加，如果一口氣推下去所有制度，很難落實。不想要一口吃成胖子，有了部分框架標準和流程，對于安全很重要了，你不會再浪費時間去查看對外開放端口、之前的struts漏洞新上的系統是否存在等等。

安全一定要由上往下去推動
不制定獎懲措施的制度是很難推行落地的

這是兩條制度落地的關鍵，說多了都是淚，自己體會吧。最理想的狀態是形成PDCA閉環，不斷完善改進。

ps，互金企業更重視結果的記錄，因此在做類似系統變更、補丁修復這樣的操作時候要有記錄，無論紙質或者電子的。

這一年公司業務發展迅速，上線的系統也多了，起初還有時間挖挖漏洞，后來就是疲于上線掃描、定期掃描、漏洞修復，然而可怕的是同樣的漏洞會再次出現，開發小伙伴們忙于進度是不會太注意安全的，立場不同。還好當時的CTO重視安全，運維領導極其重視安全，對于新公開的高危漏洞，群發郵件后，都會把各個技術負責人召集起來開會，自己評估是否影響并確定整改期限，領導的強勢會有助于工作的進行。

這一年與某大互聯網公司合作，簽了安全服務，包括培訓、滲透、抗D等等。他們挖出來的漏洞會被更重視（同類型問題自己找出來不會很受重視 > <）。所以啊安全開發、上線安全檢測流程是必要存在的。

外部機構的檢查遠遠比自己找出來的問題更有影響力

除了救火，其實另一半的工作是把基礎安全做好，不要想一口氣做好所有，一步一步來，讓大家有個“溫水煮青蛙”的過程，漸漸的都會適應。

個人感覺初期建設流程2個步驟足夠了：

發現目前不足

針對不足加以完善

不要任何事都自己造輪子，在現有的基礎上加以改造

具體工作如下：

確認開放端口，nmap或masscan掃下，然后和防火墻策略對照下。只提供必要服務的端口，SSH這樣的堅決不對外提供。
交換機路由器基線配置，比如snmp配置不能用public
網段的重新劃分，訪問控制策略的重新制定（起初提過但改動太大，后來外部滲透服務，拿到內網權限后堅決整改，事件驅動）。根據重要性劃分網段，網段間嚴格訪問策略（通過路由或ACL都行，目的達到即可），可做部分mac綁定，比如網關、重要網段，辦公區wifi只允許連接互聯網。
堡壘機，所有設備、服務器均通過堡壘機訪問
IPS和WAF設備的規則優化，每周的攻擊日志分析

其實運維團隊基本都會有自己的一套標準，包括自動化部署、監控、日志收集等。因此要做的就是熟悉現有方法，加以完善。

如果在沒有任何監控、安全措施的環境下，可以自己搭建一套SIEM，但是拿我們的環境來說，目前已經有了nagios、cacti監控網絡、性能、進程，服務器文件完整性檢測、puppet配置同步，定制的加固過的系統鏡像，時間同步、日志收集措施，我覺得覆蓋面已經足夠了，不如在現有基礎上進行優化。

歡迎大佬指教還欠缺哪些方面。

實現安全目標的方式有很多種，只要達到目的，最切合企業自身利益便好。

數據庫真心不太懂，而且我們有oracle、mysql、SQLserver、mongoDB，核查下安全基線關注下漏洞動態…比如啟動數據庫的賬號權限，數據庫內的默認賬號，生產庫賬號限制，訪問權限限制。數據庫審計我見到的基本沒人開的，影響效率。但是對于數據安全，互金企業對其要求極高，數據的存儲、加密、傳輸、備份恢復都有嚴格要求，按照監管機構的要求去做就好了╮(╯▽╰)╭

ps，作為互金企業，對災備切換極其重視，因此每年的災備演練要確實去做。

應用安全，其實本質還是要提高代碼安全，請了外部培訓、外部滲透測試，也沒有搞好這方面，這也是甲方安全的一個痛點。其實人與人之間的交流都一樣的，與開發交流，要用“咱們”，不要挑開發的問題，要說成那些討厭的人會不正常的去輸入內容，繞過web界面直接修改數據包等等，原則上是找共同利益點，多贊美，人性所在啊。換個角度去想，作為開發任務挺緊的，實現功能、趕進度、改bug，突然來了個人和我說你的代碼不安全，這樣不行，WTF，你丫哪根蔥你來寫啊。所以互相理解吧。

1.作為甲方安全，你要以主人翁的角度去思考和推動，不要把開發看成敵人

題目是帶引號的一個人，因此我們要借助可以利用的各種資源去做安全。比如DDOS防御，我們是把服務器托管到IDC機房，對于DDOS防御肯定要借助外部力量，機房的流量清洗以及安全公司提供的抗D服務。再比如我們自己的DNS服務器，每天很多的攻擊流量，于是采用外部的DNS服務，自己不再做DNS解析。

把自己無法做到的事情和非關鍵業務又浪費精力資源的事情，轉交給專業的外部服務團隊，性價比更高。

2. 作為甲方安全，其實起初在技術深度上下功夫，并不能給整體企業安全帶來太多顯著提升，反而流程上安全優化會有顯著提升。先做緯度，再做深度。

比如你的開發同學將源碼傳到git上公開…

不要一直做救火隊員，要推行有利于安全的流程

于是在頻頻救火的過程中，即使領導再重視，你依舊處于救火中。流程制定好，處理事情有條理，整體的企業安全會有顯著提高。

最關心的流程我覺得就是安全事件，那么安全事件發生后第一時間得知，就需要一個監控匯上報過程，包括技術上的監控系統，非技術層面的運營人員發現系統故障。向誰上報，上報哪些內容，如何處理，由誰處理，處理優先級，處理方法，總結積累。

從這個流程可以看到，我們需要業務連續性分析（處理優先級），應急手冊（處理方法），可能這些東西太虛，但起碼你要了解自己公司的哪些業務重要，遇到不同安全事件如何處理，需要外部資源聯系誰。

每一年可以集中對這些事件進行分析總結，然后根據結果進一步優化代碼也好，架構也好，進一步提升安全能力。

總之，我覺得重要的2個流程：

安全事件處理流程
系統上下線流程（資產信息變更、基線確認、安全測試等，最有效的把系統安全提升到及格分數）

這一年還確定了安全預警流程、漏洞修復流程以及下圖中運維相關的流程。

制定流程要切合實際，便于落地執行，精簡。至于是否完全合理，在今后的工作中逐漸微調，總之先有一個流程先讓大家適應。其次，要把權限責任分散出去，流程可以是自己制定或者和同事一起，但至于流程的執行負責人分開管理，讓大家知道誰負責哪些，該有什么流程，既起到了規范作用，又減少了出現坑的機率了。

這一年，日常的安全日志分析、漏洞預警、季度掃描、上線測試、漏洞修復、安全事件處理、合規檢查已經輕車熟路了，再在原有基礎上優化流程，就可以騰出來時間搞些開源的東西。當年做計劃的時候寫了威脅感知，那時候概念很火，后來給了自己一個大嘴巴，沒有大數據根本搞不了這玩意。

目前環境中，沒有源代碼掃描、日志分析系統，ips和waf都是商業化產品，有時發現一些細節問題無法定制化，資產的管理系統是人工錄入，存在延遲更新、失誤導致的錯誤數據風險。于是應用了下面這些開源項目

巡風掃描，感覺最好用的是資產管理，可以查看哪些IP開放了什么端口，開放了某端口有哪些IP…可以比我們的監控系統更簡單更全面搜索（畢竟服務器多了人為操作難免會有遺漏加監控等等），還可以自己嘗試寫寫漏洞檢測腳本。

Nginx-lua-waf，很實用，基于openresty，可以自己寫規則防御某些有針對性的攻擊，然而總是與時代慢了一步，AI聯動waf的時代已經來臨了，尤其兜哥出了AI安全三部曲以后…

Yasca，源代碼掃描，幾年前的東西了，支持Java, C/C++, HTML, JavaScript, ASP, ColdFusion, PHP, COBOL, .NET…支持挺多的還免費…而且集成了PMD，JLint等很多常用源代碼檢測工具，建議在git下載，版本較新。如果是PHP大神還可以定制更改。

ELK，日志分析，后來公司買了套類似產品…然后我就不再花費精力研究這個了。

推薦些常用的吧，小伙伴們都說好的，很多我都沒用過。

網絡入侵檢測snort的時代過去了，現在基本用suricata。主機入侵檢測ossec。Siem產品ossim，跳板機jumpserver，蜜罐t-pot、Awesome Honeypots。

還有個安全思維導圖大全：
https://github.com/SecWiki/se...

當基礎安全做好，緯度夠了，接下來就是要做深度的事情了。

安全開發知識庫：對應各類威脅，不斷積累的一個代碼庫。
蜜罐系統：知己知彼，百戰不殆。
AI：先看書學習吧 > <
業務安全：互金行業對業務的功能要求蠻多的，而作為互金企業，風控是一個重點工作，我不清楚大的互聯網公司風控和業務安全是如何歸屬，但是業務安全做得好，防止企業利益受損，是看的見的收益。

產出物這個問題，很多人總要搭建一個烏云知識庫，一個XSS平臺等等，我心想有哪個公司的開發會有時間去玩他，烏云知識庫網上有，公司資源緊張我沒必要再搞了。現在我終于清楚為什么要搭建了。

把安全做得有聲音，最好有產出物（P神總結的）

甲方安全的痛點，在于話語權，公司是以業務為重，安全只是個輔助。因此前面提到的從根本上提高代碼安全，推行制度落地流程，都是一個長期的緩慢工作。大的互聯網公司安全都很強勢，安全不達標系統不能上線，漏洞未按時修復直接影響績效考核，但有能力做到流程化的基礎安全后，才有精力去做業務安全，總之感覺路還很長……

煩請各位大佬指點，灰常感謝。新年快樂～

*本文作者：pur0，
來源：http://www.freebuf.com/articl...