聊聊持续测试与安全

这是鼎叔的第一百零八篇原创文章。行业大牛和刚毕业的小白,都可以进来聊聊。

欢迎关注本公众号《敏捷测试转型》,星标收藏,大量原创思考文章陆续推出。本人新书《无测试组织-测试团队的敏捷转型》已出版(机械工业出版社),《无测试组织:测试团队的敏捷转型》(张鼎)【摘要 书评 试读】- 京东图书

鼎叔曾经花了一年多的时间组建了一个安全工程师团队,并系统化地学习了安全技术理论和实践方案,借着DevOpsSec的东风,聊聊测试(质量)与安全的关系,以及如何在持续测试中落实安全检测能力。

部分图片来自赖东方同学的分享。

测试(质量)与安全

从大的质量角度来定义,质量是包含功能,性能,安全,合规,兼容,易用性等多个维度的,所以安全类测试也是测试体系中的一个类型。

受限于安全意识和安全技术的专业门槛比较高,大多数测试工程师非常缺乏安全测试的能力,本质上,这类能力是可以刻意练习的。

先来理解一个问题,安全工程师和其他开发工程师有什么不同?

最大的区别,是对于引入风险的敏感度。安全工程师优先关注漏洞和被利用的可能性,而不是关注便利性。比如缓存的设计,业务开发用缓存来提高响应性能和用户满意度,安全工程师一看见“缓存”眼睛就亮了,眼里马上浮现出各种利用缓存的漏洞。

另外一个例子是对“客户端的不信任”,不盲目相信客户端的提交,对涉及权限的信息要有不可猜测性。比如有的用户可以通过遍历链接中的ID号,可以查看其他用户的交易记录。

专业的安全高手(白帽子)从大学开始就参加各种安全比赛(挖洞),并对各种最新的威胁漏洞和安全检测工具非常敏感。

优秀的测试工程师不也是应该这样么?——对于各种缺陷非常敏感,形成直觉。安全缺陷也是缺陷中的一类,优先级通常很高。

安全和其他测试一样,也很容易成为软件发布的瓶颈,团队经常为了达到安全标准,安排特定的评审和测试验收环节。

但如果安全流程严苛,安全技术人员人手不足,安全检测自动化水平低,整个业务的发布节奏都会被影响。

助力安全左移的DevOpsSec

敏捷团队经常强调质量内建,安全也同样要内建,内建的意思就是业务研发和安全团队责任共担。

关于安全内建和安全左移,微软有一套著名的SDL(应用安全开发生命周期)实践方案:

图片

如何快速内建,降低安全评审依赖,缩短交付周期?解法和持续测试是一样的,在DevOps闭环中赋予安全能力和安全工具,同时解决快速交付和信息安全的难题,即业界热门的DevOpsSec。

DevOps引入安全能力面对的通用挑战是:引入成本和工具误报,弱化安全设计带来的风险,以及如何真正做到快。

那什么是DevOpsSec的指导原则?

  • 安全左移

  • 默认安全

  • 运行时安全

  • 安全服务自动化/自助化

  • IaC-基础设施即代码,制品库安全等

  • 利用好CI/CD

  • 组织和文化建设。对于产研团队,最重要的就是意识和技术两方面的安全培训,相关内容可以看看下面。


工欲善其事,必先利其器。融合安全的持续交付必然离不开常见的持续集成安全工具,如:

  • 静态应用安全测试工具(SAST)

  • 第三方安全扫描工具

  • 动态安全测试(DAST)工具,模拟黑客的攻击行为

  • 交互式安全测试工具(IAST),通过在测试环境插桩或端口截流的分析方式。

  • 日志安全分析工具

  • 制品管理安全工具

信息安全自动化工具对于开发和运维工程师来说最好是“透明无感知”的,这样才能保证DevOps的敏捷。

类似鼎叔在持续测试提到的成熟度概念,DevOpsSec也是可以定义成熟度的,需要明确哪些指标纳入成熟度考核,并进行合理的分级。比如下面几个成熟度的参考维度:

  • 安全工具链的建设,集成和使用的情况

  • 团队敏捷工作方式和团队的组织架构情况

  • 人员的安全能力:知识经验和问题解决能力

  • 产品交付的质量数据和安全水平

安全团队在干什么

回忆一下,鼎叔在组建安全团队期间具体做过哪几件事。

  • 安全渗透测试。给公司的数据资产做深度检查。入职的第一位安全工程师,就在第一周发现了后台数据库的一个重大漏洞,导出了所有员工的登录账号密码并暴力破解,让技术部门吃了一惊。渗透测试怎么展开,可以看看这张思维导图

  • 图片

    图片

  • 安全自动化扫描能力,和前面提到的DevOps工具链的聚合。发布了多端产品(H5官网,App端,后端等)的扫描安全问题分析报告。

  • 业务安全,分为业务架构的安全评审,以及用户可疑操作行为的风控等两大类工作。

  • 图片

  • 对于APP羊毛党用户,我们能够从登录地点,登录IP,登录频率,登录时间,交易操作频次,以及第三方登录方式等信息,判断其对业务带来的风险。我们甚至为此建设了异常登录规则库。

  • 安全团队可以把需求安全评审的关注点做成checklist,具体考虑这些维度:信息安全资产的机密性,完整性和可用性;针对安全控制设计与变更,基础设施的变更,合规性的变更,给出具体的控制评审清单。

  • 对GitHub上的公司敏感代码泄露进行监控,落实管理办法。

  • 给公司员工赋能安全能力和安全意识。安全是质量的一个维度,这句话类似“培养员工的质量能力和质量意识”,让全员重视安全,远比一个小团队辛苦救火要好。

安全赋能-意识

安全防范体系的四部曲:让坏人进不来,看不到,改不了,赖不掉。

鼎叔曾经花了四个月的时间(每天一个小时),看完了CISSP考试教程的内容,里面提到了十大安全设计原则,可以用来避免90%的安全问题:

  • 简单易懂

  • 最小特权

  • 故障安全化-即使发生故障,也能安全处理业务

  • 保护最薄弱环节

  • 纵深防御。多层次地防御攻击

  • 隔离原则

  • 总体调节

  • 默认不信任

  • 保护隐私。包括脱敏和加密,明确禁止的数据不要采集

  • 公开设计才是安全的设计。

一张很有趣的图片,开着这辆车去街上溜达一圈,就可能入侵各个摄像头网络的数据库:

图片

为了提升员工安全意识,安全团队会联合IT做一些安全演练,最常见的就是发钓鱼软件,看看哪些人会上当。

对于灰产羊毛党最喜欢的大规模自动化恶意操作,如撸羊毛和撞库,也有不少的图片资料,提升员工的直观感受。

图片

图片

安全赋能-技术能力

安全技术能力主要包括这么几大类:

  • Web安全漏洞挖掘能力

    图片

  • APP安全漏洞挖掘

  • 隐私合规能力

  • 安全编码能力。最突出的是输入输出参数处理不当产生的漏洞。大公司都会搞一个安全编码规范,注意:如果安全人员做的规范不太考虑编码语言,不考虑开发人员的视角,会给开发人员带来较多的负面体验。

  • 框架安全,安全函数库和安全组件。直接提供一系列的安全函数,或者内置了安全特性的组件,对开发人员的帮助会更有效。

  • 源代码安全管理。代码安全管理允许开发人员协作处理并跟踪更改。源代码属于公司的敏感数据,对其访问控制也需要遵循最小权限原则。

  • 编译环境和开发环境安全。第三方提供的构建依赖包等,可能会成为安全隐患的源头。如2015年的XcodeGhost事件,受影响的用户数量超过了一亿。

  • 构建基本的自动化攻防能力。一旦树大招风,被黑产盯上还是很要命的,基本能力需要日常演练。

  • 图片

  • 数据安全,本质上是保障存储,传输,使用的安全。传输要看签名完整性,使用上要看操作和日记记录。

图片

安全团队的新挑战

自动化时代的低代码平台在前些年挺火,但是对于DevOps公司很难深度使用,低代码平台始终不能缓解自动化焦虑,长期看也不能提高效率,开发团队也不愿意接手低代码遗产。

对于当前普遍上云和微服务的业务而言,面临更多具体的新安全挑战:

  • 对于云和微服务,攻击面小很多,边界不清晰,审计困难。

  • 容器的安全技术和以往不同,要考虑资产的销毁,兼容性等新风险。

  • 云原生的安全也有所不同,它包括代码安全,镜像安全,编排系统安全,容器运行时安全。这四种安全分别对应着代码,容器,集群和云这四个层级。

结语

安全团队投入的成本很高,不要指望100%的安全,安全工作的本质就是尽可能降低风险,积极攻防实践,尽量借助自动化机制快速验证,并对一线工程师赋能。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值