安全架构--1--关于甲方安全体系建设历程的思考

博主是涂鸦安全部门最早期成员之一，虽然不是安全负责人，却也有幸参与和见证了涂鸦安全体系从无到有的建设历程。本文是博主关于甲方安全体系建设历程的思考，分为三部分：

一、安全体系建设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. 制度的日常管理

制度应明确解释部门，原则上由制度主办部门负责解释，特殊情况下应明确各部门解释的范围。低层级制度与高层级制度规定相抵触时，以高层级制度规定为准，但制度解释部门另有正式批复或回复的除外。