在甲方做业务SDL的几年,在落地方面也做了不少努力。一是得看着业务高P的脸色,二是得假装硬气的扮猪吃老虎,一路走来可谓是一把辛酸泪。
闲话不多扯,我们团队在SDL方向,针对公司现状进行威胁建模,进行了多个维度的治理。
在本文笔者会根据过往的治理工作,在业务建设从0到1进行剖析,给大家落地经验的参考。
基础审计运营
在安全建设初期,我们会着重针对事前、事中、事后为基准,进行SDL基础能力补全优化。
事前审计
在事前的维度,我们会以域名和服务Key为单位,对前后端的资产进行梳理,嵌入SOC进行运营管理,并进行安全审计流程闭环。
在项目上线前,我们会对提测前的代码进行人工Review,进行安全合规的风险评估。
对于安全检查大致包括:
- OWASP TOP 10
- OWASP API Security TOP 10
- 常见的逻辑漏洞
此外,我们还会根据研发同学的习惯,制定相关核查制度,进行重点检查,提升检察效率。
对于数据合规会重点检查:
- 数据接口是否脱敏
- 数据存储是否加密
- 传输是否加密
- 数据关联性是否解耦
还有部分没有全部例举出来,会严格的按照合规白皮书的标准来实施。
在审计完毕后,会在SOC平台进行数据留存,发工单向业务同学督促修复。
如果出现了延期,系统工单会进行逐级递进,通知其上级,直到业务方响应闭环为止。
虽然这些制度可能比较难推行,但确实是非常有必要的,这需要自上而下的认可才能完成。
只有把代码安全的指标,像代码质量考核那样,加入业务研发同学的KPI之中,才能真正引起大家对安全的重视。
事中监督
在每个项目的大型迭代时,我们也会进行人工安全审计。
除了针对迭代出现的安全问题以外,主要还会检查部分误添加的线上测试数据,以及研发同学无意中进行的硬编码、弱口令配置、敏感数据打印等等。
由于当时工具比较原始,除了借助半自动化的代码审计工具(如IDE、Fortify)以外,也会读取第三方设备收集入库的日志,自行写脚本筛选核查。
当然这些工作,后面也逐步被接入CICD流水线的自动化平台所替代。
事后管控
在各个系统正常运营期间,我们需要做的是借助各种安全入侵防护产品(自研or商采),譬如IDS、WAF、RASP之类的进行纵深体系检测,再借助风控与法务部门的力量,对出现的风险事件进行溯源和应急响应。
为啥这里说的是纵深检测而不是纵深防御,其实是早期在使用安全产品的时候,更多的需要去借助人工去复核,没有很好的进行产品联动。
当然大家可能觉得是因为没有采购同一家产品,造成了兼容性缺失的问题,才会导致工作量指数级别上升。
其实笔者觉得这块儿的工作,无论是厂商本身来做,还是依靠团队人工对信息流进行补齐,都是相对次要的。
更关键的点在于,是我们需要优化好安全运营规则,让更严重的事务和更优先的级别,及早的被我们感知到并进行应急处理,而不是淹没在海量告警和镭射动态展示大盘之中。
自动化能力建设
在这个阶段,我们投入了更多的精力去建设团队的安全自动化能力,以求解放人力去搞研究工作。
在此期间,我们针对性的对缺失的安全能力,对标业内互联网企业的标杆进行剖析,发现主要有几个点是亟待改善的。
黑盒安全能力
我们利用线下测试环境和镜像流量,重点建设了主被动扫描器(DAST),其中包含黑盒漏扫和基线核查平台;同时,也针对交互式扫描(IAST)能力进行强化,对代码执行进行污点插桩和编号,监控系统的输出和落地执行结果,方便向源头进行追溯。
白盒安全能力
针对白盒扫描(SAST),我们接入了多个扫描引擎。除了质量CICD流水线平台自带了安全插件进行优化外,还对商业化的白盒安全产品进行了外采接入;除此之外,自研的引擎里,还加入了针对Git平台的关键词和配置、组件版本依赖检查(支持分支),保障在接入流水线后,能尽可能完整的覆盖到所有代码的检查。
数据合规检查
针对这块儿,我们着重对数据库里存储敏感数据字段进行核查,也结合XIDS对流量里包含的敏感数据进行了监控。
同时,我们还结合DLP监管的记录,以及对明暗水印机制的设计,对数据外泄事件起到了一定的防控作用。
安全SDK治理
每个公司的技术栈是不同的,所以针对内部应用最多的技术栈代码,针对性的开发安全SDK也显得比较重要。
除了本身对研发团队提出安全编码制度以外,我们还对研发团队提供了安全SDK,也提供了IDE安全检查插件,通过微侵入式的方法,在一定程度上保障了代码的安全。
当然,这样产出的代码,可能在交付给第三方合作厂商时,会单独进行脱敏分支开发,在一定程度上会提升成本。但考虑到这方面的业务量不多,还是合算的。
风险链路治理
在SDL建设到了这个阶段,我们已经有了一定的安全自动化能力,那么如何去实现突破呢?
在梳理业务链路中的风险后,我们开始针对威胁进行建模,从体系架构上自上而下进行治理。
其中,我们重点关注了IPDRR和STRIDE模型,并辅以DREAD模型进行威胁评级,针对原有安全能力的缺失进行优化联动,也对现有的安全风险点进行收敛治理。
从不同的业务场景,以及不同的数据流程,分别对风险定制了削减措施,分配人力形成项目组,推进治理优化工作。
具体的风险链路大盘,这里由于内容敏感不方便直接发出来,我们就简单谈谈重点项目的建设工作。
资产库的收敛
在原先的工作中,我们自己的资产库更多的会去依赖于运维部门的注册信息,然后我们内部通过扫描器进行的资产补充。
后来发现这样做有个问题,我们在针对细粒度的资产标签,譬如新增端口、机器所属域、服务类型列表、迭代接口等等,无法及时的掌控,这样对我们的纵深体系的监测是不利的。
所以在我们着重进行了这方面能力的补充,通过被动监控流量,以及主动对代码AST树进行梳理的方式,对复杂的调用进行网状关系绘制,以及对标签关联的资产进行聚类。
这样,在出现问题后,我们也能很快的进行阻断和溯源定位。
内部巡检
针对内部的一些通用型漏洞,由于信息关联度问题,我们在原来的工作中没有很好的进行横向打通。
在不断加强内部对于0day、1day的识别能力后,我们能更好的去识别入侵事件。
在后面的SOC运营平台的建设工作中,会针对漏洞元素进行细粒度的手动标签,也支持了自动化识别,加强了针对资产的测试环境和边界环境,及时进行横向巡检,将风险扼杀于摇篮之中。
边界治理
在针对诸多风险进行治理时,必不可少的需要考虑到对边界安全进行收敛。
在这方面的工作中,我们可以考虑做以下的工作:
- 针对出入的流量进行重点核查
- 对开放的外网服务进行一键式深度防护
- 启用备份机制,随时对出现漏洞升级故障的边界服务进行替换
- 对边界资产进行即时扫描防控
- 自动化核查应该把边界的优先级提升到最高
我们前面对于资产库的优化工作,也是能为边界安全的治理提供效能的。
接口人制度
我们原来的业务方接口人,都是资产定位到项目组为止。
这样的话,很难在具体风险发生时,最快速度联系到个体接洽解决,在推进修复的过程中也很容易扯皮。
所以后来我们采用了业务方接口注册制度,让业务方主动去做项目归属个体和人员backup的填写,并且结合内部的人力资源存留的注册信息,定期向业务方确认项目变动情况。
总之,我们需要保障在项目存活的安全生命周期中,实现人员响应可控、权限周期可控、人员备用可控。
第三方合作建设
在第三方合作体系的建设过程中,我们也参照业内的情况,做了不少工作。
在这方面的治理上,虽然有不少标准可以参考,但并没有统一的方案。
其中需要治理的内容有:
- 第三方合作商的业务
- 第三方SDK的引入核查
- 第三方流量接入时的监控前置
- 第三方账号监控的核查
这些东西太多,只能稍微例举几项。真正想要做好,需要对各业务线的情况进行深入了解,结合企业自身的情况进行定制。
同时,这也是外部审计公司很难在短时间内给出完整方案的,需要内部的安全人员去做更多的探索。
后面的话,针对这块儿可能会单独提出来跟大家聊聊,讨论下有哪些通用的解决方案。
指标订立和回归
在针对SDL实现流程化管理,对治理成果进行验收时,我们需要重点注意的是,得对前期订立的指标做验证回归。
这些无论是在安全工作的KPI中体现,还是向业务方进行成果透明化展示,都是有意义的。
这里举例几个方面,给大家参考下指标订立的原则:
风险收敛
我们针对需要重要防控的项目,在风险收敛比例和收敛耗时方面,是需要订立一定的指标的。
如果在这期间发生了安全风险引起的资损事件,会侧重考核我们是否做出了合适的应对措施,针对资损事件进行弥补和挽回。
漏洞回归
对于漏洞指标订立,我们会针对高危漏洞的数量、漏洞类型趋势进行统计。
其中,会区分外部SRC提交和内部发现情况,从不同维度进行趋势计算。
同时,我们针对黑白盒自动化漏扫的召回率和精确率,也会做同期的月度、季度、年度对比。
最终,我们也会添加插件数、服务数、接口数等作为变量,从综合层面去判定成果,避免在判定权重方面发生缺失。
服务健康
这个有点类似于QA的质量考核指标,如果一个服务经常出现代码风险,经常出现漏洞,通常这个服务的健康评分会比较低。
这个是针对业务方的,也是对我们治理结果的的反馈之一。
对于服务安全,我们订立了几个指标,譬如漏洞修复率、安全产品接入率、漏洞反复率、风险发生率、鉴权接入率等等。
最后,通过单个服务乃至业务线作为基准元素,我们也会反过来对比考核各个业务线安全的质量,从而在更高的维度评价业务安全的产出。
结语
上面的一些总结,是从业务安全早期治理内容来讲的,涉及的内容相对简单。
后面的续篇,会继续对单方向的重点进一步剖析,以及针对具体实施细节进行描述。