业务SDL的上岸体历(二)

之前已经聊过在甲方团队做DevSecOps能力建设的零碎轨迹,但是针对项目级安全治理的关键细节,我们还不曾详述,那么接下来简单讲一讲。

安全合规评审

对于重要的基础系统或者服务,我们如何做好完整的评审闭环呢?

这里我们分三个阶段去达成这个目标:

信息采集阶段

  • 问卷和自查

首先,最了解系统的人肯定是相关开发人员和产品经理。那么整个企业或者整个业务线,拥有相似的研发习惯或者通病的话,批量进行问卷和自查能帮我们解决掉很多事情。

当然,很多人可能会说,这种东西业务方不一定会配合你去做,安全人员在大部分企业内的地位是相对低的。

好一点的可能是独立出来,直线向CTO汇报;次一点的挂在强势的运维总监下面,好赖能在平时做做事务推动。再次的话,就是那种一个人的安全部,除了怼二开/购置商业产品,还有日常和业务线撕逼外,其实存在感不是很大。

但是话又说回来,做不做是一回事,如何去达成是另一回事。

能用点手段,自上而下去推动自然是最好的。

  • 文档发掘

如果是规范完备的研发线,通常会存在相关的研发说明和产品文档。

我们做风险评估之前,也会从大量的信息中主动提取疑似脆弱点,作为后面评估的参考依据。

后面的工作中,我们能通过对比记录,更加快速的定位到风险点。

同时也能在一定程度上,避免在过长的评审时间跨度之后,产生不必要的风险遗漏。

主动评估阶段

在这个阶段,我们主要会对下面三个风险点进行分析。

  • 接入风险:

在使用某个系统的时候,可能系统本身是不具有高风险的。

但是由于业务方操作不当,或者配置失误,有可能会导致产生接入性风险。

所以这块儿的治理,一般是针对中台或者基础服务,需要提出规范制度进行管控。

  • 架构风险:

在架构设计之初,很多产品的安全评审是不足的。所以在架构设计中会出现潜在的风险。

在设计逻辑架构时,我们会考虑到数据流转和业务场景转换,在关键流程节点上往往需要制定审计策略。

在设计系统架构时,我们需要考虑到是否接入了安全能力组件或者安全服务中台;是否符合固有安全架构设定;是否符合冗余灾备法则。

在设计网络架构时,我们需要考虑是否进行了线上线下隔离;所在网络区域是否对外开放;如果接入了外网,是否接入了SSO+IAM+VPN;是否会留存重要的操作日志;是否能做流量安全审计。

  • 基础风险:

运行时系统评估:WEB层面主要针对OWASP TOP风险进行核查;系统本身层面会审计是否引用了不安全的第三方服务(组件);主机层面是否对基线(端口、配置、内核等)的进行了加固核查。

代码评估:分析代码中是否存在硬编码和配置风险;是否引用了不安全的第三方包;是否存在常见的漏洞;是否存在明显的逻辑链路失误。

数据评估:是否存在未脱敏数据的批量开放展示;是否存在敏感数据存储未加密,是否存在第三方数据不合规引用,是否接入了数据溯源和加密分发等措施。

自动化覆盖阶段

在完成风险评估后,我们需要有一套完整的风险验收的闭环。

在我们完成主动评估阶段的工作后,通过紧急程度分级进行修复推进。

而后,我们再结合基础CMDB的数据,借助自动化能力,进行定期巡检复核。

  • 接入风险覆盖:

可以通过注册依赖和代码层面,进行特征对比检查,校验是否存在接入失衡导致的风险。

  • 架构风险覆盖:

自动化核查供应链,实现第三方对接监测,枚举安全中台能力覆盖,枚举边界兜底措施覆盖等等。

  • 基础风险覆盖:

接入黑盒漏扫、基线、白盒规则,后期通过自动化观测,进行变更管控和风险复核。


基础能力兜底

对于整个企业、业务线、乃至具体到单个系统。除了本身固有的风险以外,我们更需要从宏观的架构出发,使用基础安全的能力进行兜底。

组件管理

首先,企业的研发线通常会引用开源组件,这批组件相对固定,所以维护起来有一定价值。

从安全的角度来讲,我们可以通过接入CMDB库来管理组件版本,引入对CVE官方或者开源组件官方的漏洞舆情感知,方便我们在紧急情况进行有序的版本推修。

当然,我们也可以通过脚手架的形式,把常用的组件进行打包,进行统一的版本升级管理。

其次,我们还可以对于常见的开源组件做二改加固,单独维护一套相对安全的组件版本。

能力引入集成

这个也是老生常谈了,对于安全能力的引入和集成,可以分为下面几个点去实施。

  • 安全组件:

如果我们拥有维护安全组件的能力,要么指望通过规范,推广让研发线做引入。要么就直接在流水线中进行默认集成,如果上线出现问题再做版本回退。

  • 黑白盒:

在流水线发布的时候,会自动化进行增量的黑白盒扫描,此时的优先级调度,建议排在队列前面。

然而这时候如果测出问题,并不建议直接阻断构建,因为我们一切的工作都是为了保障业务稳定性而服务的。

如果出现高危漏洞,可直接推送告警给安全人员,审核确认后可以跟研发人员沟通紧急修复。如果紧急程度不高,我们可通过邮件或者工单沟通好,徐徐图之。

  • IDE插件

在代码交付之前,业务方使用IDE安全插件,能很好的对代码做预修正。

常见的问题,能在自核验的过程中解除,减少其他环节的耗时。

  • 代理插件

在质量测试和开发中,一般会在本地PC进行调试,也会访问一些搭建好的新服务。

这时候如果本地agent(浏览器)设置了相关代理,将测试流量转发到安全中心。就能很好的对增量的服务和接口进行风险确认,及时防患于未然。

当然这个需要配置代理白名单,区分测试环境和线上环境,避免流量互串。

底层服务化

除了必要的安全检测能力,其他底层支撑能力也需要实现服务化。

很多企业目前的安全建设进度,其实还处在做二开或者怼商业产品的节点,不定时做做渗透和众测,但自身并没有精力把底层的安全能力树立起来做支撑。

因此,我们需要根据企业目前的情况进行分期建设,针对各个产品线进行安全缺失度评测和适度补全。

首先,我们需要强化底层的认证机制,借助内部的证书分发中台,将鉴权认证细粒度到业务方的IDC、服务、接口,尽可能实现非敏感区域全覆盖。

其次,需要实现存储能力的标准化,自适应调整敏感数据和文件的存储结构。将失衡的加密手段,以及错误的存储桶访问配置,实现无感知的安全强化加固。

此外,我们还需要对业务容器化的流程做融合,把相关能力嵌入到云管平台及配套体系中,在企业“云化”的发展中形成安全助力。