安全是个“无底洞”，没有一个企业的安全负责人会说自己的系统是百分百安全的，安全也不是特别好衡量和量化，尤其是定量地评估出谁比谁做得好、好多少。有时候也会反思，或者说迷茫，“上了那么多防护手段、到底能不能经得起对抗？”，“安全自研产品做了半年、用了半年、然后有一天它被废弃掉了”，“SDL喊了好几年了，怎么就运营不下去呢？”，“业务主动过来寻求支撑，可是我们手里没有核武器。”......
本文将介绍宜信安全建设不同阶段的思路和成果，每个阶段遇到的挑战、踩过的坑，以及收获的心得和体会，分享宜信内部安全产品的发展，探索企业安全建设路径。
一、背景
2013年，公司正式开始进行安全建设，投入资源成立专门的安全团队、搭建基础安全设施。宜信公司的安全建设自开始至今大致可分为三个阶段：
2013年-2016年处于V1阶段。V1阶段主要实现了：基础的安全环境（如防火墙、区域隔离、主机IDS、网络IDS、网络准入、防病毒等等）；在上市前后通过合规检查工作逐步建立和完善了公司的信息安全制度，通过了等保三级、ISO27001认证；在2016年建立了自己的安全应急响应中心。
2016-2018年处于V2阶段。V2阶段的主要成果是完善了安全技术，提高了安全工作覆盖的范围；参与了部分业务安全相关的工作（账号安全、反爬虫、短信接口***、人机识别等）；确定了SDL的相关流程（没有特意去实施，只是使用了其中一两个方法）；开发了漏洞扫描、GitHub监控等一些安全工具。
当前处于V3阶段，未来应该还会持续1-2年左右的时间。在这个阶段，我们开始追求构建更加贴合企业长期发展、在某个点更专注更深入的安全能力，比如安全运营的能力、数据安全的能力。
二、几年前的状态
上图是之前总结的行业里信息安全所处的状态和发展情况，以及截止2016年我们在安全上完成的一些项目。那个阶段在网络边界、IT等方面的工作，打下了比较扎实的基础，包括网络准入、终端DLP、防病毒等已经实施完成。在基础安全尤其是终端安全效果尤为显著，保证了内网、办公网处于一个相对安全的环境，不用天天紧急应对***、勒索病毒、甚至APT这类安全事件，可以释放更多的精力去做更有意义的事情。
三、SDL实践
3.1 SDL流程
本阶段我们重点参考、借鉴了唯品会安全团队分享的SDL流程，挑选了适用我们现状的几个重点环节，包括培训、安全编码规范等，在公司进行推广。重要的项目安全也会参与安全需求评审，与业务、产品、技术等团队建立了很好的合作关系。
值得一提的是，在企业，与安全的合作可以分为两种：一种属于“免责甩锅型”、一种属于“合作共赢型”。两种类型，遇到涉及安全的事情，表面上都会找到安全，但内在的动机却是大相径庭。第一种更多的是为了免责，事情我通报你了、问题我抛给你了，甚至为什么要找安全、找安全解决什么需求问题都不知道也不关心，剩下的都与我无关了，出了问题，安全来背锅；第二种更多的是为了寻求安全的协作，我知道可能会有哪些安全风险、我有特别关注的业务上的安全需求，我需要和安全一起配合解决产品的安全问题，确保上线后系统、业务的安全性，两个团队相互促进和提升。
两种类型在合作方式、日常互动、最终的安全效果上截然不同。造成这种局面可能有多种原因，包括：非安全人员的综合能力和素质、安全培训的有效性、安全团队的专业性和影响力（安全是否真的帮别人解决过痛点、双方是否一起扛过枪）。
3.2 SDL案例
上面两张图展示的是我们做得比较好的地方，称之为SDL或DevSecOps都可以，是自动化嵌入到发布过程的，重点解决了第三方组件的安全问题，既可以快速在发布过的软件制品里检索出包含的第三方组件，也可以定义规则直接在构建过程中对包含存在严重漏洞的组件直接阻断。这部分工作可以完全实现自动化，支持Maven、Gradle、Docker等，并且不会影响持续交付的能力。统一的资产管理、代码库、软件仓库、CICD平台实施起来会更加便捷，维护成本也最低，当然这离不开DevOps团队的能力支持。
3.3 SDL威胁建模
今年我们也尝试了SDL威胁建模，设计了适合我们的建模规则，包括重点关注的数据安全需求、审计需求等。这部分工作目前还在小规模试点、探索阶段，从流程到工具都还有很多要解决和优化的事情，等到实际成熟，我们再考虑投入更多的安全测试、安全服务人员在公司大范围推广。
3.4 SDL白盒扫描
在白盒代码审计方面，我们也投入了少量的资源进行尝试，封装了代码审计平台，核心依赖于Sonarqube和Findbugs Security，也支持自己编写规则，实现了触发扫描、上传源码扫描等方式，自动提交漏洞。但是这部分最大的消耗还是对规则的运营、对误报的消除等，目前也没有找到更优的解决办法，听到比较多的思路也是简化规则，初期“宁可漏报，不要误报”。目前主要的使用方式：安全人员临时任务需要上传源码进行扫描、对一些接入的项目每周扫描发送检测报告。
3.5 SDL被动扫描
SDL的另外一个尝试是在被动扫描，基于流沙平台收集的测试环境流量进行回放。大致的思路之前很多人都分享过，通过替换cookie、request-param重点用于测试发现未授权访问、垂直越权、水平越权等安全问题。难点也是优化规则、整理收集公司业务的共性（比如错误页提示等）。之前利用这个扫描发现过几个高危的问题，投入产出比还是挺高的。但是想做到较高的扫描准确率、提高自动化程度、达到可持续运营的效果，要投入的人力就比较大了。具体看团队的取舍吧，最近也看到一些国内外利用AI来提高安全测试效率、甚至替换人来进行手工安全测试的项目，不评判短期内是否能很好的落地，但是认同一句话“人是会疲劳的，但是机器却不会”。
3.6 SDL漏洞管理
漏洞管理主要依赖于洞察平台，包括应用资产系统的管理、漏洞生命周期的管理、安全知识库的管理。洞察平台在去年进行了开源，用户比我们预期的要多，从社区微信群平时的交流咨询来看，使用者多是1-5人的安全团队，并且有互联网、制造、物流等多个行业。每次有人加我们微信寻求洞察平台部署配置以及功能使用上的帮助时，虽然占用了我们一些工作的时间来解答或者解决问题（我们会检讨软件质量问题），但还是很开心能够真正帮助到安全同行。
这件事也让我有些反思：
其一很多企业在安全上的投入有限，的确需要好的开源解决方案；
其二产品落地需要一些乙方的思维，产品有时候需要做减法，大而全未必是每个人都需要的，而且好用的前提是好部署好配置。
洞察×××ight开源地址：https://github.com/creditease-sec/×××ight
四、洞察2.0
今年我们将开源洞察的2.0版本。
第一会优化之前的交互、功能、业务逻辑等提高易用性；
第二完善漏洞运营的数据，加强报表功能来关注整体的安全状况；
第三也是最大的更新，合并了SRC前、后台的功能，让企业可以自定义地来建立自己的安全应急响应中心，并且统一了各个来源的漏洞管理。
上图展示的是原型图，目前正在开发的过程中，有需要的安全同行们可以期待一下。
五、流沙平台
另外一个最近一年听到比较多的各甲方团队在讨论的就是SOC和SIEM，有商业化的安全大数据产品、也有类似Splunk这样的平台（Splunk Enterprise Security）、还有基于ELK的开源方案。我们选择的是第三种，当前阶段比较好地实现了数据的采集、存储，以及一些不是非常复杂的计算。
数据来来自交换机的流量镜像、日志文件、各安全设备的syslog等。架构师设计实现了一套预处理程序，进行数据的接入配置、过滤、格式化、组装、打标、脱敏等，核心代码部分用go来编写，来提升处理性能。
上图是整个“流沙”平台的架构，以及硬件资源、数据量、写入速度等；有了数据，在应用场景，目前实现了包括资产发现、弱口令检测、信息泄漏发现等等，基于简单的规则就可以实现，不需要非常复杂的计算。
具体参考：流沙：宜信安全数据平台实践
5.1 流沙应用：内控
基于流沙安全大数据平台，如何满足更复杂的安全分析、关联分析场景，也是我们后续要重点开发的。
上图是之前做的用于满足内控的一个上层应用，同事也在QCon上分享过，实时收集公司内部业务系统的登录、查询操作、办公网员工的上网行为（自定义规则）、DNS、GitLab、WiKi、DLP告警等。
第一满足审计业务运营系统的操作行为，比如谁在什么时候访问过哪些敏感数据，做记录用于追溯；
第二进行分析，比如某个人的操作异于该岗位的其他人员，聚类定位高危人员，做重点关注。
上图是我们整理的关于用户资产的信息。
六、自研的WAF产品
逐步替换商业化的WAF产品，
- 具备传统WEB安全防御能力
- 具备CC***防护能力
- 具备爬虫防护能力
- 具备信息泄露防护能力
- 具备数据分析识别异常流量能力
6.1 宜人盾
重点说一下我们自研的WAF产品：宜人盾，前后大概花了一年半左右的时间，迭代了3个大版本，投入了8名安全团队的人员负责系统设计、开发、防护规则收集，1名运维同事负责安装包制作和部署工作，2名测试工程师协助进行压力测试。
我们之前采用的是商业化WAF设备，Gartner象限里排第一的，这几年采购了有10台左右。产品本身很好，大家使用的比较熟练也比较稳定，但也存在一些不足：
- 第一，产品对传统基于规则的恶意请求的防护强、但对爬虫这种有时间窗口上下文的访问防护比较弱、并且开启这部分功能会损耗整体的硬件性能；
- 第二，需要以硬件的形式串入到网络中，遇到实施新的业务、新的网络区域时，就需要上架新的设备，实施周期长；
- 第三，水平扩展的能力不是很强，单点遇到瓶颈时只能选择扩容或者拆分流量，动静很大。
综上，我们还是选择在有商业化产品的前提下，自研了宜人盾，符合SDS软件定义安全的趋势（感谢公司和领导的大力支持）。宜人盾基于OpenResty扩展，分为网关、大数据分析平台、运营后台管理端三大部分，所有配置通过Redis共享读取。宜人盾具备WEB防护、CC防护、黑名单防护、语义识别防护、敏感数据防护、AI防护。产品设计和开发按照商业化产品标准：精选100多条基础规则、可添加自定义规则、规则黑白名单等均分全局与域名、并且每个域名的每项防护开关都可独立开启、报表分析和每个拦截事件的查询均按域名区分，在产品易用性和交互上做了打磨。
平台特点
- 软件定义、水平扩展
- 快速接入
当前进度及运营情况
- 持续迭代一年半左右
- 目前已经全线接入宜人贷
- 压力测试峰值流量：5000qps（2C8G）
宜人盾目前已经全线接入了宜人贷，因为属于网关产品，对性能和稳定性要求比较高，所以前期在2名测试同事的支持下做了很多的压力测试。2C8G的虚拟机上运行宜人盾，QPS在5000左右，可以满足我们的要求。同时，我们对每项服务（MQ、Flink、计数服务、Redis、完整穿行等）都进行了监控，在运营后台里专门设置了查看系统状态的功能，可以看到每个宜人盾节点的域名接入状态、以及节点是有错误告警。在每条防护事件的查询上，我们也做了比较多的优化，确保在拦截比较多的情况下仍可以快速进行查询。
利用机器学习识别高低频爬虫
- 序列化访问的URL
- 按时间形成访问路线
- 用图提取出环的循环次数
- 聚类找出异常的IP、SID
识别传统规则不易发现的CC***、爬虫行为，也是宜人盾重点要实现的目标。除了UA、IP黑名单、基于IP\SID的单一接口访问频率的判断，我们也加入了算法来识别这类异常访问。
举例说一下我们使用的“路径聚类模型”，这部分在宜人盾的数据分析平台实现：定期提取上一时间段的访问、序列化访问的URL、形成访问路径、用图提取出环（循环，单独一个点也是环）次数、聚类找出异常的IP和SID。
比如上图标记的，第一个IP访问[2835]这个URL是86次，第二个IP则是访问[2821，2832，2827]是14次，然后另一个循环36次。这里说明一下，路径是根据时间排序的，不根据Referer，图计算用的类库NetworkX，感兴趣的可以了解下。上线后，我们发现过爬取财经文章的、还有刷签到的刷新手标的薅羊毛行为，达到了我们的预期。
七、目前在做的事
以上就是我们这两年在做的一些事情，以及我自己的一些体会：
- 项目制有利于安全开发的迭代，明确了产出和目标效率能提高不少；
- 坏计划好过没有计划，在计划的过程中，比如头脑风暴大家可以贡献更多的创新、思路，计划还要关注一下风险点，比如可以持续投入多久、会不会面临项目被叫停的风险，核心的人员是不是稳定、选用的架构或者开发语言是不是团队擅长的诸如此类，避免出现烂尾工程。
- 在安全产品层面，更多乙方的产品越来越贴合甲方的实际需求，落地效果也越来越好，细分的产品都能找到比较合适的解决方案，除了少数大厂，有些东西要不要自研得再三考虑，需要结合短期中期长期的各种变化，尽量贴合企业的长期发展需求。
- 在安全服务、***对抗、SDL等贴近传统安全的方面，很多公司都还有很多可以实践和优化的地方，近期也能看到大家对这方面的讨论比较多，比如ATT&CK Matrix，比如滴滴持续对SDL的建设。
今年，我们也重点设置了几个项目，除了上面说的洞察2.0，更多的是为了贡献开源社区。内部还有2个比较重要的项目。
第一个项目，代号“超级扫描器”，用各种手段（包括内部工单、CMDB、搜索引擎、CMS指纹等）来发现外部资产，实现GitLab、暗网、负面舆情的监控，以及提高安全测试效率、辅助SDL推广的重任，复用了之前开发的分布式安全服务编排服务“须弥”以及爬虫服务。“像***一样发现资产、深入集成到SDL中”是项目建立的初衷。
第二个项目，代号“安全感知”，是对流沙、内控审计及办公网安全系统的重新整合和扩展。数据安全越来越多地被单独提起，成为安全的核心问题之一。《数据安全法》已经进入立法阶段，不论从安全建设、合规、还是企业的战略发展，很多走在行业前列的企业已经在向以“数据为中心的安全策略”转变。所以这个项目的重点就是围绕数据安全来开展的，在应用层关注数据的使用，打通安全可用的各种信息，方便的配置关联关系，每一类业务系统或场景设置自己的检测模型，可以把它当作一个智能审计的产品。当然，这个只是整个数据安全治理的一角，数据安全策略、数据安全委员会、数据分类分级、操作流程、奖惩制度、传统数据库脱敏、数据防泄漏、数据文件摆渡、数据地图、大数据安全等放在一起，才组成了数据安全的完整板块，要做的事情很多、也很复杂。
作者：王哲
首发：宜信安全应急响应中心
原文地址：https://blog.51cto.com/14159827/2408895