从管理角度浅谈业务系统漏洞发现手段
前言
安全漏洞可以说是业务系统所有安全事件的源头，漏洞是一个宽泛概念，既包括安保、社工导致的意识流问题，也包含软硬件技术处理层面的缺陷问题，本文主要讨论系统上线运行后技术方向漏洞发现，一是不涉及系统上线或版本迭代前的检测发现手段，如代码审计、风评等，二是不涉及安保、员工意识等非技术问题。
漏洞发现是安全管理工作的前置必要条件，漏洞发现的全面性和及时性，很大程度上决定着整个漏洞治理和安全管理工作的质量，这应该是广大安全从业人员的共识，根据我浅薄的从业经验，漏洞发现途径大致可以分为人工资产匹配、漏洞扫描工具、渗透测试等三类，下面依次展开说明。
人工资产匹配
人工资产匹配方式指在不具备本文后两种发现手段执行条件的情况下，根据现有资产信息进行漏洞匹配（大多是根据版本进行，部分会涉及具体功能），主要适用于0day或已披露、爆发时间较短的漏洞，通常由软硬件厂商或监管机构、上级单位进行发布和通报，前者一般是单位自发排查处置，但后两种通告是强制任务，甚至部分紧要漏洞会要求限时反馈、上报受影响和处置情况，安全团队如不能根据已有资产信息快速做出判断，虽说部分企业的资产管理工作不是安全团队职能，但拉扯过程中可能或多或少会给高层留下工作不力的印象，甚至扣上推诿的帽子。
其实资产是漏洞发现的基础，漏洞扫描、渗透测试都是基于资产信息（URL、端口、IP、域名等）开展的，尤其是经历了快速增长期和漫长建设期的单位，资产管理工作往往或多或少都有欠缺，资产管理细细理顺讲来又可以写一篇文章，本文就不再展开了。
漏洞扫描工具
漏洞扫描工具五花八门，根据其来源属性可以分为开源的、国内外商用的（含号称国产自研的硬件盒子），根据其主要作用资产对象属性又可以分为主机扫描器、WEB应用扫描器等，根据其架构可以分为C/S、网络代理等，但究其根本大致可以划分为两种技术模式，猜测式匹配检测和POC式验证机制，各有优劣，大致特点如下：
1.误报的猜测式匹配检测
通过远程检测资产对象的网络服务和组件程序，收集返回的响应数据，根据漏洞库中的已知漏洞特征（版本、协议、响应特征等）进行模糊判断，满足组成条件则视为存在漏洞，但很多漏洞经过加固或修复后，其响应信息特征可能不会发生根本改变，这就产生了误报，我相信很多从业人士都因此挨过甲方、运维或者开发的怼。
猜测式匹配检测和上文提到的人工资产匹配有异曲同工之妙，都是在不具备脚本验证条件的情况下通过匹配版本进行的，不同之处有二，一是在于前者是根据厂商维护更新的工具半自动化进行的，通常虽更新时效不会太快，但技术成熟、漏洞信息全面，二是前者是判断维度不只有版本资产信息，还涉及协议、响应头等动态特征。
2.漏报的POC式验证检测
基于验证脚本的自动化过程，通过模拟已知漏洞利用手法（脚本）自动对资产对象进行仿真攻击（注意是仿真，不具有实际危害或实际危害可控），分析目标动态变化判断攻击是否成功，攻击成功则视为存在漏洞。POC式验证检测依赖验证脚本，历史已知漏洞不计其数，验证脚本覆盖不完全，会产生漏报。
3.误报漏报抉择建议
猜测式匹配检测的漏洞库全面，存在误报，POC式验证检测受限于验证脚本的覆盖面，存在漏报，误报和漏报貌似是两个极端。
（1）对于采买漏扫产品的单位：
好在近年来部分厂商意识到了问题，更新迭代的漏扫产品减少了对于版本对比等简单特征判断的依赖，结合POC机制，降低了误报率，虽然扫描速度相对较慢，但鱼和熊掌皆可兼得。
另外鉴于厂商脚本的更新时效不可控，建议采买支持自定义POC脚本的漏扫产品，以备不时之需，部分厂商产品虽号称支持POC功能，但为内置脚本库，不支持自定义。
（2）对于采买漏扫服务的单位：
明确要求服务单位使用基于POC、特征库的多款产品进行交叉验证，POC检测发现的漏洞直接交付给运维、开发等下一流程使用，基于猜测检测发现的漏洞要求乙方根据IP、端口、CVE号等进行筛重后扭转到下一流程。
渗透测试
1.定义介绍
通常来说渗透测试也包含漏洞扫描，但前者在目标上更倾向于取得权限或数据，偏重于纵向入侵，而非仅仅发现一些漏洞，发现、组合和利用漏洞是渗透测试关键手段，漏洞即可以是常见的高风险的已披露的安全问题，也可以是独有特殊的业务逻辑扭转处理上的错误（如薅羊毛）。
2.实践中存在的问题
在信息安全越来越重要的如今，各个互联网大厂要是没搞个众测平台，出门都不好意思打招呼的“众测”时代，渗透人员只要花时间在平台上磨，都可以获得一定的经济收益，特别是前几年，相关法律法规都尚未完善，漏洞披露平台授权没授权的一通乱炖，故此江湖上流传着很多靠挖洞发家致富、买车买房的传说，这些平台的注册用户大多是乙方专职的安全技术服务人员，趋利性催生了一种怪诞的现象“工作只是副业，上平台挖洞才是主业”，在各种渗透评估服务项目里也就草草应付了事，取得某些权限就交付报告完成渗透工作了，甚至把渗透测试做成了漏洞扫描结果验证。
3.可能的解决方案
（1）对于甲方单位：
市面上乙方服务商都有技术、态度均靠谱的高手，但这些高手成本很高，是相对稀缺资源，需要用到更有价值的地方，至少如果我是服务商的管理角色，遇到对服务内容要求不明确甚至完全不懂的客户，我想我是不会把这种高手长期放在这个项目上的，这无关道德和品质，甚至都无关于甲方的预算或项目大小，企业追求利益最大化、投入产出比是企业生存的核心任务，但如果甲方单位管理上对安全非常重视，技术上又能主导服务商的具体工作，对于服务商来说，在预算允许的情况下必须派出最高的高手来提供服务，保证交付质量，否则就有可能丢掉这个项目。
所以渗透测试或者说是所有安全服务项目的交付质量，固然与服务商能力有关联，但我个人认为也依赖于甲方团队对服务要求和验收标准的把控度，建议考虑根据系统实际情况约定具体预期目标，达成目标则完成服务，否则不成功，还可以引入多家服务商进行质量交叉对比。
（2）对于乙方服务商：
建立渗透测试标准作业流程，细化到采用什么工具，优先进行哪些风险的挖掘和利用，兜底固定住服务质量的下限，标准流程之外的风险挖掘作为加分项，不限制方式方法，给安全技术人员留有一定的空间，另外服务报告也可以统一进行质量审核后输出给客户，审核结果酌情纳入职称、奖金评价体系。