博主是塗鴉安全部門最早期成員之一，雖然不是安全負責人，卻也有幸參與和見證了塗鴉安全體系從無到有的建設歷程。本文是博主關於甲方安全體系建設歷程的思考，分爲三部分：
一、安全體系建設v1.0—快速治理
二、安全體系建設v2.0—系統化建設
三、安全體系建設v3.0—全面完善
附：安全制度管理
同時，對於甲方安全體系建設，我還寫了附屬的兩篇實踐博文：
甲方基礎安全運營平臺建設實踐
SDL安全與企業辦公安全落地實踐
一、安全體系建設v1.0—快速治理
很多互聯網公司的業務發展通常先於安全團隊建設，在業務發展到一定規模、出現安全事故時才考慮在安全方面進行投入，但此時已經是企業信息安全環境狀況很差的時候，安全作爲業務的基本屬性，已經嚴重滯後於業務的快速發展。
此時可能出現的安全問題有：企業內網出現衆多弱口令和未打安全補丁的系統，線上業務有大量常見的安全漏洞，員工安全意識薄弱，數據泄露嚴重……
對於這時候的企業所面臨的安全風險，需要救火式的快速切入解決，先從容易的、成本小的、效果明顯的地方入手。
1.1 選擇合適的安全負責人
安全團隊早期一般爲1-3人，因此，安全負責人知識面的廣度就極爲重要。負責人應當熟悉安全技術和安全運營，以及安全管理和安全合規。安全負責人需要帶領安全團隊開展包括安全研發（基於開源二次開發）、滲透測試、安全加固、應急響應、安全審計、安全培訓、安全合規、安全管理、安全運營等工作。
1.2 識別主要的安全風險
快速治理階段的主要目標是利用20%的資源解決80%的安全風險，所以第一步是識別主要的安全風險。互聯網公司的特點是業務技術以web和移動應用APP爲主（有的還涉及到桌面軟件、雲服務、IoT硬件等），業務迭代快，人員變動較大，公司管理較爲鬆散。互聯網企業的安全風險大多來自線上業務，同時企業內部也隨時面臨風險。
1、在線業務
在線業務的風險主要包括web安全風險、業務自身的安全風險、移動應用安全風險。
2、企業內部
來自企業內部的安全風險主要包括員工的安全風險、口令的安全風險、釣魚攻擊和社會工程學的安全風險、安全合規風險。除了這些安全風險，還有很多其他的安全風險，例如業務中的DDoS，未打安全補丁的設備和工具，包括路由器、打印機、個人電腦、BYOD設備（自帶設備）等。
1.3 實施快速消減
以兩手都要抓，兩手都要硬的原則，一手抓安全技術和安全運營，一手抓安全管理和安全合規。雙管齊下快速消減安全問題。
解決web安全風險可採取的處理方式按優先級排序依次爲：
1、全站清理webshell後門，購買或採用開源WAF快速解決常見web安全問題；
2、使用動態應用安全測試、靜態應用安全測試、交互式應用安全測試產品，對web業務進行黑盒掃描、白盒掃描和人工滲透測試，解決線上主要漏洞；
3、部署RASP（運行時應用自保護）時應當使用自保護產品對web進行自免疫保護，比如使用Prevoty、OpenRASP等；
4、提供安全代碼過濾庫和安全編碼培訓，提升代碼等安全質量。
解決來自業務的安全風險可採取的處理方式按優先級排序依次爲：
1、初期針對業務特點，選擇合適的第三方風控安全產品；
2、人員到位後，可以從接入層（查詢引擎、規則引擎、模型引擎）、處理層、數據層這三方面構建自有的安全風控平臺。
解決移動應用安全風險可採取的處理方式按優先級排序依次爲：
1、採用商業方案（免費/付費）對APP進行漏洞掃描和安全加固來解決常見的安全問題；
2、安全團隊中熟悉移動應用安全技術的成員對移動應用進行深入的人工安全測試；
3、提供基礎移動安全組件和安全編碼培訓、安全編碼規範。
解決來自員工的安全風險可採取的處理方式按優先級排序依次爲：
1、部署可統一管理的EDR安全產品，在生產環境中統一使用堡壘機進行遠程審計管理，採用數據庫管理系統審計進行數據庫訪問；
2、員工入職時進行安全培訓，在入職前對重點員工進行背景調查，制定員工信息安全行爲規範並進行考試，在員工離職時需要告知其安全須知，並進行安全審計；
3、對企業重點業務團隊建立隔離受控網絡，統一訪問互聯網的代理服務器，確保包括HTTPS在內的網絡流量可審計；
4、建立基於機器學習的用戶異常行爲發現系統，如Splunk產品中的UEBA模塊。
解決口令安全風險可採取的處理方式按優先級排序依次爲：
1、通過弱口令掃描器（Hydra/Medusa）檢測公司員工賬號和內網（SSH、MySQL、RDP、web後臺等）所有涉及密碼的系統服務，並責令修改密碼以快速解決弱口令隱患；
2、建設基於OpenLDAP的統一單點登錄系統，並使用基於TOTP方案的動態口令雙因素認證或RSA Key，若使用Wi-Fi技術，則可以通過Radius協議實現雙因素認證；
3、建立更加嚴格的基於Fido U2F認證協議的實體安全密鑰登錄系統和BeyondCorp賬戶安全體系。
解決來自釣魚攻擊和社會工程學的安全風險可採取的處理方式按優先級排序依次爲：
1、對員工進行相關安全意識培訓，並不定期組織相關演練測試以驗證培訓效果，加強辦公場地物理安全管控，避免使用第三方通信軟件建立工作羣；
2、強化對釣魚攻擊和利用社會工程學進行攻擊的技術監控（如終端安全監控），若要查看高風險文件則可利用沙箱技術進行隔離訪問，對於瀏覽網頁的高風險操作可以使用遠程安全瀏覽產品；
3、加強BYOD設備的安全管理。
解決安全合規認證可採取的處理方式按優先級排序依次爲：
1、閱讀官方安全合規文檔，瞭解安全合規需求；
2、列出安全合規需要的文檔清單，撰寫安全合規文檔；
3、判斷哪些要求公司已經做到了，哪些還沒做到，對於沒有做到的制定實施計劃方案；
4、以外規對內規，內規對檢查，檢查對整改，整改對考覈的原則，推進落地；
5、通過合規認證，拿到合規證書。
二、安全體系建設v2.0—系統化建設
經過第一階段救火式的快速治理後，企業中存在的大部分隱患基本被解除，所以第二階段可以系統的完善企業安全架構，將“安全融於體系”的安全理念落地。
2.1 依據ISMS建立安全管理體系
ISMS具體是由ISO 27001-ISO 27013系列標準組成的，其中尤其以ISO 27001最爲業界熟知。ISO 27001主要規定了信息安全管理體系的要求，主要是對一些概念的介紹和概述，一般用於認證。ISO 27002是對應ISO 27001的詳細實踐，該標準涉及14個領域，113個控制措施。
ISMS提供了一個大而全的指導性要求框架，其可以爲互聯網企業安全團隊帶來的幫助有：
1、提供了一個全面的安全視圖，避免安全覆蓋面不足帶來的死角；
2、可以給高管一個可交代的信息安全實施依據，方便安全策略的推行；
3、獲取ISO 27001認證後，可以提高公司知名度與信任度，使客戶對企業充滿信心。
ISMS是具體依據PDCA循環原則建立：
P即Plan（計劃）。制定與風險管理和信息安全改進相關的政策、ISMS目標、流程和程序，以提供符合組織全球政策和目標的結果；
D即Do（實施）。實施和利用ISMS政策對流程和程序進行控制；
C即Check（檢查）。在檢查過程中對流程進行相應的評估，並在適當的情況下根據政策、目標和實踐經驗衡量流程的績效，之後將結果報告給管理層進行審覈。
A即Act（行動）。根據ISMS內部審覈和管理評審的結果或其他相關信息，採取糾正和預防措施，不斷改進上述系統。
安全管理體系具體可以依照ISO 27001的14個控制領域開展，通過對ISMS提供對檢查表格，一項一項完成相應的模塊並打鉤，等勾選的差不多了，安全管理體系自然也就建立好了。
安全管理類對工作雖然繁雜，但萬變不離其宗，要先把合規要求和規章制度等規則喫透，然後發現本企業在執行方面的風險和短板，最後完成整改和化解風險。
2.2 基於BSIMM構建安全工程的能力
1、BSIMM介紹
BSIMM是衡量軟件是否安全的標尺，可以通過BSIMM標準來實施自身安全開發建設，BSIMM具體由三大部分組成：
1、軟件安全框架（SSF）：支撐BSIMM的基礎結構由劃分爲4個領域的12項實踐模塊組成；
2、軟件安全小組（SSG）：負責實施和推動軟件安全工作的內部工作小組；
3、軟件安全計劃（SSI）：一項涵蓋整個組織機構的項目，用於以協調一致的方式來灌輸、評估、管理並演進軟件安全活動。
軟件安全框架的4個領域12項實踐模塊：
| 治理 | 情報 | SSDL觸點 | 部署 |
|---|---|---|---|
| 戰略和指標（SM） | 攻擊模型（TM） | 架構分析（AA） | 滲透測試（PT） |
| 合規性和政策（CP） | 安全功能和設計（SFD） | 代碼審計（CR） | 軟件環境（SE） |
| 培訓（T） | 標準和要求（SR） | 安全測試（ST） | 配置和安全漏洞管理（CMVM） |
治理：用於協助組織、管理和評估軟件安全計劃的實踐，人員培養也屬於治理領域的核心實踐。
情報：用於在企業中彙集企業知識以開展軟件安全活動的實踐，前瞻性的安全指導和威脅建模都屬於該領域。
SSDL觸點：分析和保障與特定軟件開發工作及流程相關的實踐。
部署：與傳統的網絡安全及軟件維護組織機構打交道的實踐，軟件配置、維護和其他環境問題對軟件安全有直接影響。
2、安全工程能力建設中常見問題的解決辦法
問題1：業務上線時間緊、壓力大，安全漏洞修復佔用時間過多而影響業務上線進度
爲避免安全工作成爲開發瓶頸，安全測試技術應儘量和現有系統相結合。比如，在IDE上直接集成SpotBugs插件，開發人員在編譯時就能被提示要修改漏洞代碼；在管理第三方組件漏洞時將BlackDuck與Maven倉庫相結合，業務人員不需要介入就可以解決Java庫的安全問題；在提交代碼到GitLab時，加入Gitrob自動掃描密鑰、密碼等敏感信息泄露問題；將Facebook Infer集成在CI平臺（如Jenkins）上，形成掃描集羣以自動檢測代碼漏洞，並編寫Python腳本將漏洞信息發到JIRA上提醒研發人員修復，跟蹤漏洞修復進度。
問題2：安全漏洞方面的誤報太多
任何自動化安全測試系統在剛上線時都可能存在誤報問題，針對這類問題可以設計誤報反饋功能，成立專職安全小組提供安全技術支持，並使其參與到不斷優化檢測規則的工作中來，經過幾輪迭代之後基本都可以解決誤報問題。
問題3：公司對員工工作無量化指標，部分研發團隊成員的責任心不夠，對於漏洞修復持無所謂態度，從而留下大量安全隱患
建立漏洞修復相關的流程制度，將代碼質量與KPI掛鉤，對因違反流程制度而造成安全隱患的員工按出現的漏洞等級進行處罰。結合質量保障團隊定期發送項目質量報告，最終將安全漏洞數據彙總到代碼質量管理平臺。將漏洞修復放入KPI指標，以促進開發人員修復安全漏洞的積極性。
問題4：安全方案和要求通常會阻礙業務發展
安全團隊在設計安全方案和要求時，不應該以安全團隊省時省事、少承擔責任爲出發點，這樣會阻礙業務發展、降低效率。一套安全方案和要求，應當是能夠在降低甚至不降低業務發展的情況下還能保障安全，這樣的方案和要求才能受到業務團隊和開發運維團隊的歡迎。
3、構建普適的安全技術架構
網絡層：
在NTA網絡流量分析方面有AOL開源的Moloch和redborder等，在欺騙防禦方面有Thinkst的OpenCanary和Canarytokens
主機層：
開源產品有Facebook的Osquery
應用層：
開源產品有百度的OpenRASP
身份和訪問權限管理：
開源的產品有gluu
數據安全與隱私：
細粒度權限管理的開源產品有Apache Ranger，大數據安全與性能分析的開源產品有Apache Eagle，開源的密鑰管理系統有Vault
安全運營：
開源的產品有Mozilla開源的SIEM平臺MozDef
三、安全體系建設v3.0—全面完善
經過第二階段的系統安全建設後，企業已經基本形成了完整的安全體系，因此，第三階段的安全體系建設工作主要是對其進行全面完善。
3.1 強化安全文化建設
如何建設企業安全文化？安全應該納入企業的價值觀中與業績一起考覈。如果企業文化是貼在牆上的，也不知道怎麼考覈，那麼企業文化所起到的作用就不大。只有建立好企業安全文化，公司纔不至於因人員變動而導致安全價值觀逐漸稀釋。
3.2 完善安全韌性架構
安全韌性架構主要實現4中能力：
1、預料能力，保持對入侵的知情準備狀態；
2、承受能力，即使被入侵仍然可以繼續執行基本任務或業務職能；
3、恢復能力，在入侵期間和之後恢復任務或業務功能；
4、適應能力，修改任務或業務功能的支持能力，以預測技術、運營、威脅環境中的變化。
附：安全制度管理
制度一般以條文形式展示，名稱通常冠以政策、規定、辦法、規程、細則、指引等；制度可以通過制度補丁的方式進行調整、補充和完善，制度補丁可以採取條文或非條文的形式展示，一般以修訂通知、補充通知、加強管理通知等標題體現。
1. 制度體系
制度體系應遵循架構合理、層級清晰、覆蓋全面的原則，制度體系一般包括三級：
1、政策級制度，是指用於規範業務條線行使經營管理職責基本事項的制度，名稱一般使用制度、規定、政策、章程等。
2、辦法級制度，是指用於規範業務條線的工作方法和具體內容的制度，名稱一般使用管理辦法、管理規程等。
3、規程級制度，用於規範具體的作業內容，名稱一般使用操作規程、操作細則、實施細則、指引等。
2. 制度的起草
在起草制度的過程中，應開展調查研究，廣泛徵求制度執行部門人員、部門內部相關人員的意見，以論證制度的必要性、有效性、合理性和可操作性。徵求意見可採取發送徵求意見郵件、召開制度討論會議等方式進行。
制度內容一般包括：總則（含目的依據、適用範圍、管理原則、職責分工、定義等）、管理流程、監督檢查及處罰規則、附則（含制定細則要求、解釋部門、施行日期、作廢聲明等）。
3. 制度的評審
制度評審主要包括以下內容：
1、是否符合法律、規則、準則和監管要求；
2、是否與本公司有關制度協調一致、接口清晰；
3、是否影響本公司制度整體架構的合理性和清晰性；
4、制度描述的流程是否清晰並具有可操作性；
5、是否符合本公司制度的規範性要求；
6、評審人員可以對其認爲的其他制度問題提出評審意見。
4. 制度的發佈
經評審、審覈或審議通過的制度以全員通告的形式發佈，爲便於制度維護和管理，發佈的制度原則上應一文號對應一項制度。主辦部門應合理確定制度的施行日期，並在制度中明確。建議直接明確施行日期，而不是“自本文發佈之日起施行”。
5. 制度的維護
制度的維護包括制度的後續評估和制度改進。制度的後續評估是指主辦部門對制度實際管理效果進行的自我評估，旨在發現制度存在的問題，評估是否需要對制度進行整改。後續評估包括以下內容：
1、是否存在合規性、有效性、可操作性和規範性等制度問題；
2、制度間是否存在重複、衝突；
3、是否存在制度缺失和管理盲點；
4、對制度進行梳理，摸清制度補丁情況，評估實施整合的可行性和必要性。
對執行層面反映意見較多的制度，主辦部門應及時進行後續評估。同時，主辦部門應及時收集和整理制度信息，提高制度後續評估的效率和質量。制度信息包括：外部政策的變化，基層操作人員的反饋，業務檢查發現的管理漏洞，外部或同行案件反映的管理漏洞，內部組織架構、管理和業務流程調整等。
制度改進是指根據制度後續評估結果和業務管理需要，主辦部門實施的制度新增、換版、修訂、補充以及整合工作。在實施制度改進工作前，主辦部門要評估制度改進的成本，兼顧制度的穩定性和執行的方便性，選擇發佈制度補丁、增加新制度、換版等方式對制度實施改進。對於制度存在較多補丁的，主辦部門應結合部門制度架構的安排，對制度實施整合。
6. 制度的日常管理
制度應明確解釋部門，原則上由制度主辦部門負責解釋，特殊情況下應明確各部門解釋的範圍。低層級制度與高層級制度規定相牴觸時，以高層級制度規定爲準，但制度解釋部門另有正式批覆或回覆的除外。