关注我博客的朋友们可能知道,我有一个ASM的Side Project,经过一段时间的持续测试和验证之后,感觉到ASM的平台似乎存在一个无形的墙,这个墙看不见摸不着,但是确实存在,不管投入多少的精力去开发ASM平台,最终的结果都会碰到这个墙。
我的ASM平台接入了全球顶尖的扫描器(OWASP ZAP和AWVS),有全球顶尖的端口扫描工具,甚至还购买了全球顶尖的威胁情报数据以获取企业的外部暴露面,但是以Tesla为例,不管通过什么自动化程序尝试发现Tesla的风险,结果往往都不尽如人意。而对腾讯这种具有复杂业务的企业来说,虽然外部暴露面大,也发现了一些安全问题,但要想持续、稳定地发现企业的安全漏洞,则非常具有挑战。而面对一些信息资产数量本来就少的公司,ASM的表现则更为鸡肋。
算法的边界
很多人都看过三体这个小说,而其中提到的能够锁死人类科学的 “质子”给我留下了深刻的印象。无独有偶,吴军老师在一个讲关于Chatgpt是否能够替代人工智能的分享里也提到一个概念,叫做算法的边界,或者数学的边界。大意就是算法就是数学,而数学是有边界的。
关于数学的边界有完整的理论证明,但是证明的内容我没记住,感兴趣的朋友可以自行搜索一下,但其中有一个案例我觉得很形象,比如一个装载了自动驾驶算法的汽车,学会了怎么熟练的躲避障碍物和安全行驶,算法非常完美。但是如果遇到前面有一个大石头挡住了路,不管实验室的工程师怎么努力,算法怎么优化,汽车还是无法通过。如果是一个人类司机,则有可能直接下车把石头搬走,然后继续上路行驶。这就是算法的边界,很多问题是无法依靠算法解决的。
要怎么认识ASM算法的边界呢?可以从上面的自动驾驶算法中找到灵感,请君试看下图:
- 1 的部分表示算法能解决的范围,工程师们通过算法将能够解决这些问题,例如红绿灯停止和启动,路上躲避障碍物,或紧急避险等等。
- 2 的部分则属算法不能解决的范围,例如路上有块大石头挡住行车路线,再比如人类想要更舒适的座椅(这是算法所不能解决的,需要多个团队来共同合作)等等。
依次类比,ASM的算法也存在类似边界,如下:
作为一个产品负责人,我应该怎么定义这个ASM的边界呢?OWASP的应用程序验证标准给了我启发。
OWASP ASVS
OWASP ASVS(后简称ASVS),全称叫做 OWASP Application Security Verification Standard,也叫做OWASP应用安全验证标准,我在一篇关于BAS突破与攻击模拟的文章中提到过安全验证这个概念,OWASP组织针对应用安全验证这个细分领域,也有一套成熟的标准。
ASVS最新的正式版本是v4.0.3,发布于2021年。最新的5.0版本尚在草案阶段,本文以4.0.3版本为例,聊聊ASM的能力边界,或者DAST的能力边界问题。
ASVS v4版本中将应用安全分为三个等级,分别是:
根据我的理解大概的分类依据是:
Level 1 适用于低保证级别,可通过渗透测试验证。
Level 2 适用于包含敏感数据的应用程序(需要保护),是大多数应用程序的推荐级别。
Level 3 适用于最关键的应用程序:执行高价值交易、包含敏感医疗数据的应用程序,或任何需要最高级别信任的应用程序。
根据我的理解,一个大概的分类依据是:
L1 用来做渗透测试验证,用于保护无敏感数据的目标,做好之后可以防御脚本小子的攻击。
L2 则需要介入软件开发流程,用于保护有敏感数据的目标,做好之后可以用于防止定向攻击(红蓝对抗或白帽挖洞)。
L3 则需要引入纵深防御,用于保护企业最核心资产,做好之后用于防护高级攻击或者APT攻击。
那怎么样来做这个分类呢,ASVS v4版本一共有14个 verifcation,比如程序安全架构、安全验证、Session管理、访问控制等等,每个verification又有多个子项和checklist供应用评级。
以文件和资源检查项为例,分为6个检查项,共15个要求,如下图所示,针对文件上传一共定义了三个安全需求,细读之后可以发现
12.1.1 大文件测试归属于L1的需求,是DAST或者ASM可以自动检测到。
12.1.2 ZIP逻辑炸弹,被设定为L2的需求,原因是鼓励开发者做人工测试(成本更低覆盖率更高)
12.1.3 通过外部黑盒做就会十分棘手,而通过L2的要求(介入软件开发过程),通过人工白盒的方式则可以比较较低成本地完成。
当然这个分类并不绝对,L2和L3的部分需求也可以通过L1(自动化)的方式来做,但可能就类似于为一个自动驾驶的汽车机械臂去安装一个机械臂以解决路上被大石头堵到的问题,费力又不讨好。
猪猪侠说,做ASM产品的一个感受是:要去解决具体的问题。读完ASVS后,我的感触是ASM的定位或许可以是:0误报0漏报地解决企业中L1的问题。
对于L2和L3中的应用安全项,则可以问一下自己,是否可以通过L2和L3的思路,通过介入开发流程(SDL)或者纵深防御来解决/缓解?
最后
ASM的天花板低并不意味着不具备技术挑战性。例如怎么研发ASM的底座如DAST工具或者EXP扫描或者端口扫描程序,都需要富有经验的安全工程师进行持续投入。而在ASM的开发过程中,也会不断检验和打磨上述工具并促进企业的安全能力的提升。
行此文的目的旨在从一个更高的视角来看ASM的定位和它的能力边界。