「一我的」的互金企業安全建設總結

前言

以前的一我的安所有的77大師傅把咱們拉在了一塊兒，而後逐漸發現羣裏大師傅們也發了建設經驗文章。好吧，這麼懶得我也分享下本身的經驗，也就當對這2年多來的甲方經驗的總結。感謝羣裏的小夥伴們，感謝安全圈的各路大牛們和小夥伴們的幫助，更感謝朝夕相處的同事們的幫助。

概述

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

• 安全必定要由上往下去推進
• 不制定獎懲措施的制度是很難推行落地的
• 外部機構的檢查遠遠比本身找出來的問題更有影響力
• 做爲甲方安全，你要以主人翁的角度去思考和推進，不要把開發當作敵人
• 不要任何事都本身造輪子，在現有的基礎上加以改造
• 不要一直作救火隊員，要推行有利於安全的流程
• 把安全作得有聲音，最好有產出物（P神總結的）

好了，開始廢話了

之因此把一我的加引號，是由於在甲方作安全，真的不能靠一我的來作，而是須要周圍一切能夠藉助的資源去作，纔可以作起來，不然不少事情舉步難行，到頭來樹敵萬千，工做也沒法順利進行。

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

• 2015年一套合規各種檢查的管理體系，熟悉基礎架構、初步瞭解業務。
• 2016年救火的一年，發現問題修復問題，同時規範流程（基礎建設）
• 2017年把一些開源項目加入到環境中，彌補某些方面空缺（逐漸完善）

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

☞三張表

1. 組織架構圖
2. 產品和負責人對應表
3. 全網拓撲、邏輯架構、物理圖、各系統間調用關係、數據關係流等

後面還有各種技術介紹，講的很全面。

很慶幸本身沒有走彎路，大致方向還對，不幸的是都是摸索的去作，會耽誤時間，有些客觀因素不能實現，好比團隊。。。

2015

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，互金企業更重視結果的記錄，所以在作相似系統變動、補丁修復這樣的操做時候要有記錄，不管紙質或者電子的。

2016

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

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

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

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

我的感受初期建設流程2個步驟足夠了：

1. 發現目前不足
2. 針對不足加以完善

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

具體工做以下：

1網絡方面

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

2系統方面

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

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

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

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

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

ps，做爲互金企業，對災備切換極其重視，所以每一年的災備演練要確實去作。

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

1.做爲甲方安全，你要以主人翁的角度去思考和推進，不要把開發當作敵人

題目是帶引號的一我的，所以咱們要藉助能夠利用的各類資源去作安全。好比DDOS防護，咱們是把服務器託管到IDC機房，對於DDOS防護確定要藉助外部力量，機房的流量清洗以及安全公司提供的抗D服務。再好比咱們本身的DNS服務器，天天不少的攻擊流量，因而採用外部的DNS服務，本身再也不作DNS解析。

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

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

好比你的開發同窗將源碼傳到git上公開…

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

因而在頻頻救火的過程當中，即便領導再重視，你依舊處於救火中。流程制定好，處理事情有條理，總體的企業安全會有顯著提升。

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

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

每年能夠集中對這些事件進行分析總結，而後根據結果進一步優化代碼也好，架構也好，進一步提高安全能力。

總之，我以爲重要的2個流程：

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

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

制定流程要切合實際，便於落地執行，精簡。至因而否徹底合理，在從此的工做中逐漸微調，總之先有一個流程先讓你們適應。其次，要把權限責任分散出去，流程能夠是本身制定或者和同事一塊兒，但至於流程的執行負責人分開管理，讓你們知道誰負責哪些，該有什麼流程，既起到了規範做用，又減小了出現坑的機率了。

2017

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

目前環境中，沒有源代碼掃描、日誌分析系統，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...