前言
之前的一個人安全部的77大師傅把我們拉在了一起，然后逐漸發(fā)現(xiàn)群里大師傅們也發(fā)了建設(shè)經(jīng)驗文章。好吧，這么懶得我也分享下自己的經(jīng)驗，也就當對這2年多來的甲方經(jīng)驗的總結(jié)。感謝群里的小伙伴們，感謝安全圈的各路大牛們和小伙伴們的幫助，更感謝朝夕相處的同事們的幫助。
一、概述
首先，把要說的重點總結(jié)下，時間就是金錢，剩下的都是廢話圍繞這些去說的。（PS。本文所說的甲方安全，全部指一個或者兩三個普通人的小團隊，非大佬團隊，非互聯(lián)網(wǎng)航母企業(yè)）
安全一定要由上往下去推動
不制定獎懲措施的制度是很難推行落地的
外部機構(gòu)的檢查遠遠比自己找出來的問題更有影響力
作為甲方安全，你要以主人翁的角度去思考和推動，不要把開發(fā)看成敵人
不要任何事都自己造輪子，在現(xiàn)有的基礎(chǔ)上加以改造
不要一直做救火隊員，要推行有利于安全的流程
把安全做得有聲音，最好有產(chǎn)出物（P神總結(jié)的）
好了，開始廢話了。
之所以把一個人加引號，是因為在甲方做安全，真的不能靠一個人來做，而是需要周圍一切可以借助的資源去做，才能夠做起來，否則很多事情舉步難行，到頭來樹敵萬千，工作也無法順利進行。
接下來是我做過的事情時間點
2015年一套合規(guī)各類檢查的管理體系，熟悉基礎(chǔ)架構(gòu)、初步了解業(yè)務(wù)。
2016年救火的一年，發(fā)現(xiàn)問題修復問題，同時規(guī)范流程（基礎(chǔ)建設(shè)）
2017年把一些開源項目加入到環(huán)境中，彌補某些方面空缺（逐漸完善）
今年618買了本書，《互聯(lián)網(wǎng)企業(yè)安全高級指南》，神級的甲方建設(shè)指導的書，覆蓋很全面，思路很清晰。
三張表，1組織架構(gòu)圖，2產(chǎn)品和負責人對應(yīng)表，3全網(wǎng)拓撲、邏輯架構(gòu)、物理圖、各系統(tǒng)間調(diào)用關(guān)系、數(shù)據(jù)關(guān)系流等，后面還有各類技術(shù)介紹，講的很全面。
很慶幸自己沒有走彎路，大體方向還對，不幸的是都是摸索的去做，會耽誤時間，有些客觀因素不能實現(xiàn)，比如團隊。。。
二、2015
8月入職，一家具有支付牌照的互聯(lián)網(wǎng)金融公司，網(wǎng)絡(luò)運維部下。正好趕上支付牌照的認證，互金企業(yè)的監(jiān)管機構(gòu)太多了，等級保護，PCI DSS，ADSS，中金認證，人民銀行……
于是，為了應(yīng)對檢測，先把現(xiàn)有制度熟悉了一遍，長遠考慮，打算重新搞一套符合各位大爺?shù)闹贫�，在原有不熟悉的制度上改造不如重新做�?/div>
管理制度制定的思路是依據(jù)ISO27001建立框架，分級制定“制度流程–操作手冊–記錄”。結(jié)合等級保護（許多人說等保只是應(yīng)付，其實等保結(jié)合了各種標準，形成了一個安全基本要求，挺全面的）、ITIL（流程上可參考）、BS25999（業(yè)務(wù)連續(xù)性可參考）、NIST SP800-53 和ISO27005（風險評估可參考），管理專業(yè)人士請教育，畢竟我也不太懂…
因為金融業(yè)的合規(guī)要求很多，僅僅27001的覆蓋面是不夠的，因此結(jié)合多一些完全覆蓋各類合規(guī)檢測。
其實我國的GB系列標準，已經(jīng)引進了多個ISO標準，而且全中文看著很方便。下面是推薦參考的內(nèi)容，完全足夠。
ISO/IEC 27001：2013信息技術(shù) 安全技術(shù) 信息安全管理體系要求
ISO/IEC 27002：2013信息技術(shù) 安全技術(shù) 信息安全控制實用規(guī)則
GB/T 22239-2008 信息安全技術(shù) 信息系統(tǒng)安全等級保護基本要求
JR/T 0122-2014 非金融機構(gòu)支付業(yè)務(wù)設(shè)施技術(shù)要求
GB/T 20271-2006 信息安全技術(shù) 信息系統(tǒng)通用安全技術(shù)要求
GB/T 18336-2008 信息技術(shù) 安全技術(shù) 信息技術(shù)安全性評估準則
GB/T 20984-2007 信息安全技術(shù) 信息安全風險評估規(guī)范
GB/T 20269-2006 信息安全技術(shù) 信息系統(tǒng)安全管理要求
GB/T 27910-2011 金融服務(wù) 信息安全指南
GA/T 708-2007 信息安全技術(shù) 信息系統(tǒng)安全等級保護體系框架
ISO 22301：2012 公共安全-業(yè)務(wù)連續(xù)性管理體系-要求
GB/T 20988—2007 信息安全技術(shù)-信息系統(tǒng)災(zāi)難恢復規(guī)范
GB/Z 20985-2007 信息技術(shù) 安全技術(shù) 信息安全事件管理指南
GB/Z 20986-2007 信息安全技術(shù) 信息安全事件分類分級指南
GB/T 24363-2009 信息安全技術(shù) 信息安全應(yīng)急響應(yīng)計劃規(guī)范
制度的制定并不僅僅是應(yīng)對檢查，最終還是要落實，所以制度的細節(jié)一定要切合公司自身情況，盡量簡單易于執(zhí)行。雖然落實比較難，但流程的東西一定要落實，比如系統(tǒng)上線、變更要規(guī)范其安全標準化。一般安全是掛在運維下……就算不是也要和運維打好關(guān)系，把基礎(chǔ)安全這層打牢，可以在運維推行部分流程，前面提到的4級文件形式，做過的事情要記錄，記錄盡量電子化，便于查閱，一是檢查的時候真的有，沒必要再造假了 – -！二是記錄也可便于事后的總結(jié)、追溯，有一天會幫助到你的。等大家適應(yīng)了流程，再一點點細化、增加，如果一口氣推下去所有制度，很難落實。不想要一口吃成胖子，有了部分框架標準和流程，對于安全很重要了，你不會再浪費時間去查看對外開放端口、之前的struts漏洞新上的系統(tǒng)是否存在等等。
安全一定要由上往下去推動
不制定獎懲措施的制度是很難推行落地的
這是兩條制度落地的關(guān)鍵，說多了都是淚，自己體會吧。最理想的狀態(tài)是形成PDCA閉環(huán)，不斷完善改進。
ps，互金企業(yè)更重視結(jié)果的記錄，因此在做類似系統(tǒng)變更、補丁修復這樣的操作時候要有記錄，無論紙質(zhì)或者電子的。
三、2016
這一年公司業(yè)務(wù)發(fā)展迅速，上線的系統(tǒng)也多了，起初還有時間挖挖漏洞，后來就是疲于上線掃描、定期掃描、漏洞修復，然而可怕的是同樣的漏洞會再次出現(xiàn)，開發(fā)小伙伴們忙于進度是不會太注意安全的，立場不同。還好當時的CTO重視安全，運維領(lǐng)導極其重視安全，對于新公開的高危漏洞，群發(fā)郵件后，都會把各個技術(shù)負責人召集起來開會，自己評估是否影響并確定整改期限，領(lǐng)導的強勢會有助于工作的進行。
這一年與某大互聯(lián)網(wǎng)公司合作，簽了安全服務(wù)，包括培訓、滲透、抗D等等。他們挖出來的漏洞會被更重視（同類型問題自己找出來不會很受重視 > <）。所以啊安全開發(fā)、上線安全檢測流程是必要存在的。
外部機構(gòu)的檢查遠遠比自己找出來的問題更有影響力
除了救火，其實另一半的工作是把基礎(chǔ)安全做好，不要想一口氣做好所有，一步一步來，讓大家有個“溫水煮青蛙”的過程，漸漸的都會適應(yīng)。
個人感覺初期建設(shè)流程2個步驟足夠了：
1.發(fā)現(xiàn)目前不足
2.針對不足加以完善
不要任何事都自己造輪子，在現(xiàn)有的基礎(chǔ)上加以改造
具體工作如下
網(wǎng)絡(luò)方面：
1.確認開放端口，nmap或masscan掃下，然后和防火墻策略對照下。只提供必要服務(wù)的端口，SSH這樣的堅決不對外提供。
2.交換機路由器基線配置，比如snmp配置不能用public
3.網(wǎng)段的重新劃分，訪問控制策略的重新制定（起初提過但改動太大，后來外部滲透服務(wù)，拿到內(nèi)網(wǎng)權(quán)限后堅決整改，事件驅(qū)動）。根據(jù)重要性劃分網(wǎng)段，網(wǎng)段間嚴格訪問策略（通過路由或ACL都行，目的達到即可），可做部分mac綁定，比如網(wǎng)關(guān)、重要網(wǎng)段，辦公區(qū)wifi只允許連接互聯(lián)網(wǎng)。
4.堡壘機，所有設(shè)備、服務(wù)器均通過堡壘機訪問
5.IPS和WAF設(shè)備的規(guī)則優(yōu)化，每周的攻擊日志分析
系統(tǒng)方面：
其實運維團隊基本都會有自己的一套標準，包括自動化部署、監(jiān)控、日志收集等。因此要做的就是熟悉現(xiàn)有方法，加以完善。
如果在沒有任何監(jiān)控、安全措施的環(huán)境下，可以自己搭建一套SIEM，但是拿我們的環(huán)境來說，目前已經(jīng)有了nagios、cacti監(jiān)控網(wǎng)絡(luò)、性能、進程，服務(wù)器文件完整性檢測、puppet配置同步，定制的加固過的系統(tǒng)鏡像，時間同步、日志收集措施，我覺得覆蓋面已經(jīng)足夠了，不如在現(xiàn)有基礎(chǔ)上進行優(yōu)化。
歡迎大佬指教還欠缺哪些方面。
實現(xiàn)安全目標的方式有很多種，只要達到目的，最切合企業(yè)自身利益便好。
數(shù)據(jù)庫真心不太懂，而且我們有oracle、mysql、SQLserver、mongoDB，核查下安全基線關(guān)注下漏洞動態(tài)…比如啟動數(shù)據(jù)庫的賬號權(quán)限，數(shù)據(jù)庫內(nèi)的默認賬號，生產(chǎn)庫賬號限制，訪問權(quán)限限制。數(shù)據(jù)庫審計我見到的基本沒人開的，影響效率。但是對于數(shù)據(jù)安全，互金企業(yè)對其要求極高，數(shù)據(jù)的存儲、加密、傳輸、備份恢復都有嚴格要求，按照監(jiān)管機構(gòu)的要求去做就好了╮(╯▽╰)╭
ps，作為互金企業(yè)，對災(zāi)備切換極其重視，因此每年的災(zāi)備演練要確實去做。
應(yīng)用安全，其實本質(zhì)還是要提高代碼安全，請了外部培訓、外部滲透測試，也沒有搞好這方面，這也是甲方安全的一個痛點。其實人與人之間的交流都一樣的，與開發(fā)交流，要用“咱們”，不要挑開發(fā)的問題，要說成那些討厭的人會不正常的去輸入內(nèi)容，繞過web界面直接修改數(shù)據(jù)包等等，原則上是找共同利益點，多贊美，人性所在啊。換個角度去想，作為開發(fā)任務(wù)挺緊的，實現(xiàn)功能、趕進度、改bug，突然來了個人和我說你的代碼不安全，這樣不行，WTF，你丫哪根蔥你來寫啊。所以互相理解吧。
1. 作為甲方安全，你要以主人翁的角度去思考和推動，不要把開發(fā)看成敵人
題目是帶引號的一個人，因此我們要借助可以利用的各種資源去做安全。比如DDOS防御，我們是把服務(wù)器托管到IDC機房，對于DDOS防御肯定要借助外部力量，機房的流量清洗以及安全公司提供的抗D服務(wù)。再比如我們自己的DNS服務(wù)器，每天很多的攻擊流量，于是采用外部的DNS服務(wù)，自己不再做DNS解析。
把自己無法做到的事情和非關(guān)鍵業(yè)務(wù)又浪費精力資源的事情，轉(zhuǎn)交給專業(yè)的外部服務(wù)團隊，性價比更高。
2. 作為甲方安全，其實起初在技術(shù)深度上下功夫，并不能給整體企業(yè)安全帶來太多顯著提升，反而流程上安全優(yōu)化會有顯著提升。先做緯度，再做深度。
比如你的開發(fā)同學將源碼傳到git上公開…
不要一直做救火隊員，要推行有利于安全的流程
于是在頻頻救火的過程中，即使領(lǐng)導再重視，你依舊處于救火中。流程制定好，處理事情有條理，整體的企業(yè)安全會有顯著提高。
最關(guān)心的流程我覺得就是安全事件，那么安全事件發(fā)生后第一時間得知，就需要一個監(jiān)控匯上報過程，包括技術(shù)上的監(jiān)控系統(tǒng)，非技術(shù)層面的運營人員發(fā)現(xiàn)系統(tǒng)故障。向誰上報，上報哪些內(nèi)容，如何處理，由誰處理，處理優(yōu)先級，處理方法，總結(jié)積累。
從這個流程可以看到，我們需要業(yè)務(wù)連續(xù)性分析（處理優(yōu)先級），應(yīng)急手冊（處理方法），可能這些東西太虛，但起碼你要了解自己公司的哪些業(yè)務(wù)重要，遇到不同安全事件如何處理，需要外部資源聯(lián)系誰。
每一年可以集中對這些事件進行分析總結(jié)，然后根據(jù)結(jié)果進一步優(yōu)化代碼也好，架構(gòu)也好，進一步提升安全能力。
總之，我覺得重要的2個流程：
1.安全事件處理流程
2.系統(tǒng)上下線流程（資產(chǎn)信息變更、基線確認、安全測試等，最有效的把系統(tǒng)安全提升到及格分數(shù)）
這一年還確定了安全預(yù)警流程、漏洞修復流程以及下圖中運維相關(guān)的流程。
制定流程要切合實際，便于落地執(zhí)行，精簡。至于是否完全合理，在今后的工作中逐漸微調(diào)，總之先有一個流程先讓大家適應(yīng)。其次，要把權(quán)限責任分散出去，流程可以是自己制定或者和同事一起，但至于流程的執(zhí)行負責人分開管理，讓大家知道誰負責哪些，該有什么流程，既起到了規(guī)范作用，又減少了出現(xiàn)坑的機率了。
四、2017
這一年，日常的安全日志分析、漏洞預(yù)警、季度掃描、上線測試、漏洞修復、安全事件處理、合規(guī)檢查已經(jīng)輕車熟路了，再在原有基礎(chǔ)上優(yōu)化流程，就可以騰出來時間搞些開源的東西。當年做計劃的時候?qū)懥送{感知，那時候概念很火，后來給了自己一個大嘴巴，沒有大數(shù)據(jù)根本搞不了這玩意。
目前環(huán)境中，沒有源代碼掃描、日志分析系統(tǒng)，ips和waf都是商業(yè)化產(chǎn)品，有時發(fā)現(xiàn)一些細節(jié)問題無法定制化，資產(chǎn)的管理系統(tǒng)是人工錄入，存在延遲更新、失誤導致的錯誤數(shù)據(jù)風險。于是應(yīng)用了下面這些開源項目
1.巡風掃描，感覺最好用的是資產(chǎn)管理，可以查看哪些IP開放了什么端口，開放了某端口有哪些IP…可以比我們的監(jiān)控系統(tǒng)更簡單更全面搜索（畢竟服務(wù)器多了人為操作難免會有遺漏加監(jiān)控等等），還可以自己嘗試寫寫漏洞檢測腳本。
2.Nginx-lua-waf，很實用，基于openresty，可以自己寫規(guī)則防御某些有針對性的攻擊，然而總是與時代慢了一步，AI聯(lián)動waf的時代已經(jīng)來臨了，尤其兜哥出了AI安全三部曲以后…
3.Yasca，源代碼掃描，幾年前的東西了，支持Java， C/C++， HTML， JavaScript， ASP， ColdFusion， PHP， COBOL， .NET…支持挺多的還免費…而且集成了PMD，JLint等很多常用源代碼檢測工具，建議在git下載，版本較新。如果是PHP大神還可以定制更改。
4.ELK，日志分析，后來公司買了套類似產(chǎn)品…然后我就不再花費精力研究這個了。
推薦些常用的吧，小伙伴們都說好的，很多我都沒用過。
網(wǎng)絡(luò)入侵檢測snort的時代過去了，現(xiàn)在基本用suricata。主機入侵檢測ossec。Siem產(chǎn)品ossim，跳板機jumpserver，蜜罐t-pot、Awesome Honeypots。
還有個安全思維導圖大全：https：//github.com/SecWiki/sec-chart？files=1
當基礎(chǔ)安全做好，緯度夠了，接下來就是要做深度的事情了。
安全開發(fā)知識庫：對應(yīng)各類威脅，不斷積累的一個代碼庫。
蜜罐系統(tǒng)：知己知彼，百戰(zhàn)不殆。
AI：先看書學習吧 > <
業(yè)務(wù)安全：互金行業(yè)對業(yè)務(wù)的功能要求蠻多的，而作為互金企業(yè)，風控是一個重點工作，我不清楚大的互聯(lián)網(wǎng)公司風控和業(yè)務(wù)安全是如何歸屬，但是業(yè)務(wù)安全做得好，防止企業(yè)利益受損，是看的見的收益。
五、總結(jié)
產(chǎn)出物這個問題，很多人總要搭建一個烏云知識庫，一個XSS平臺等等，我心想有哪個公司的開發(fā)會有時間去玩他，烏云知識庫網(wǎng)上有，公司資源緊張我沒必要再搞了。現(xiàn)在我終于清楚為什么要搭建了。
把安全做得有聲音，最好有產(chǎn)出物（P神總結(jié)的）
甲方安全的痛點，在于話語權(quán)，公司是以業(yè)務(wù)為重，安全只是個輔助。因此前面提到的從根本上提高代碼安全，推行制度落地流程，都是一個長期的緩慢工作。大的互聯(lián)網(wǎng)公司安全都很強勢，安全不達標系統(tǒng)不能上線，漏洞未按時修復直接影響績效考核，但有能力做到流程化的基礎(chǔ)安全后，才有精力去做業(yè)務(wù)安全，總之感覺路還很長……
核心關(guān)注：拓步ERP系統(tǒng)平臺是覆蓋了眾多的業(yè)務(wù)領(lǐng)域、行業(yè)應(yīng)用，蘊涵了豐富的ERP管理思想，集成了ERP軟件業(yè)務(wù)管理理念，功能涉及供應(yīng)鏈、成本、制造、CRM、HR等眾多業(yè)務(wù)領(lǐng)域的管理，全面涵蓋了企業(yè)關(guān)注ERP管理系統(tǒng)的核心領(lǐng)域，是眾多中小企業(yè)信息化建設(shè)首選的ERP管理軟件信賴品牌。
轉(zhuǎn)載請注明出處：拓步ERP資訊網(wǎng)http://www.ezxoed.cn/
本文轉(zhuǎn)自：e-works制造業(yè)信息化門戶網(wǎng)
本文來源于互聯(lián)網(wǎng)，拓步ERP資訊網(wǎng)本著傳播知識、有益學習和研究的目的進行的轉(zhuǎn)載，為網(wǎng)友免費提供，并盡力標明作者與出處，如有著作權(quán)人或出版方提出異議，本站將立即刪除。如果您對文章轉(zhuǎn)載有任何疑問請告之我們，以便我們及時糾正。聯(lián)系方式：QQ：10877846 Tel：0755-26405298。（請勿發(fā)郵件，由于垃圾郵件眾多，有可能會被當作垃圾郵件處理掉，同時現(xiàn)在很用郵件處理事務(wù)了，郵件處理時效期為3天，如急件請直接QQ聯(lián)系。）
相關(guān)文章
