你驻足于春色中,于那独一无二的春色之中.
拥有强大的扫描能力和全面的漏洞规则就能干好企业漏扫吗？那怕是要被业务喷死了。
漏洞自动化发掘一直是业内热衷于研究的技术之一，大到BAT，小到个人白帽，都有自己的一套漏扫工具。谈到漏洞扫描，一方面被提到最多的是扫描器技术理念如何先进，使用了分布可扩展的扫描节点，拥有了JS渲染的爬虫能力，底层的网络协议做了优化，能够对程序执行进行埋点等等。另一方面是规则覆盖如何准确，拥有插件式的扫描模块添加，针对规则能够做特定的payload变异，能够fuzz收集目标特征辅助扫描等等。
但是真正在企业的安全管理运营中，你会发现扫描器绝不仅仅是开发几个功能，架设起服务器就开扫这么简单。当业务方的一封封投诉邮件发到你的邮箱时，就不得不把顾及业务方感受的扫描器运营提到议程中来。
从漏洞发现、资产探测的角度来说，我们是尽可能希望扫描速度够快，恨不得一天轮训一遍所有的企业资产，但过快的扫描速度同时也会给业务方带来困扰，即便是在业务方能够准确识别自己人的扫描器特征前提下，依然会遇到一些问题。
扫描器要真正产生作用，往往是需要扫描量的保证的，之所以用自动化技术，其实就是希望能够和外部的漏洞发现打一个时间差和覆盖差，但站在业务诉求角度，我们希望扫描器是对业务无感知的，尤其希望避免半夜三更，业务被应用告警信息惊醒后，拉一堆人在一起排查原因这种情况。有时候会以自己不扫外部也会扫这样的说法来回应，但其实仔细一想，内部扫描器对业务的了解是更深层次的，所以这种干扰规模也不是外部扫描器可以对比的。
漏洞内审用的扫描规则都是经过严密推敲的，往往都是通过带外手段证明漏洞存在，但其实考虑再周到，遇到很多特殊的业务实现场景时，也难免会有疏漏。比如腾讯安全博客里曾经提到的因为延时注入而导致数据库挂起的事件，从内审的角度来说，基于时间的注入探测对于内部扫描器来说具有更加统一的判断模式和不会向业务插入脏数据的优势，但即便如此，也会有影响业务的时候。
类似的场景还有很多，比如为了不对业务进行修改，内部扫描器往往在权限上会比较克制，但如果遇到压根就没做权限控制的业务接口，扫描器就难免会对数据造成影响。还有由于业务的代码异常处理机制不完善，导致扫描器频繁出发应用的异常，潜在影响了应用的可用性等等。
想想你执行启动的扫描器，即便是精心构造了扫描规则，依然随时都有可能让业务瘫痪，这个时候还能睡的安稳吗 :)
对于扫描器来说，它只管按照既定的逻辑对提供的目标列表进行发包，在这种情况下就会出现同一个目标一扫再扫，同一个漏洞短时间内重复上报等问题。
这个其实就涉及如何管理企业资产和让扫描器知道扫描目标历史状态的问题。从企业资产的角度来说，要能够感知不同业务的应用变化，对于没有发生变化的资产，在规则稳定的前提下，不需要重复触发扫描。而从扫描器状态记录的角度来说，需要和漏洞上报管理系统相结合，对于已经上报但未修复完成的资产进行状态记录，以此来指导扫描器的扫描行为。
以上只是从三个角度切入来说明扫描器日常运营的重要性，如何在扫描器漏洞发现与日常运营之间找到一个平衡点很重要，从这个角度出发，不是说扫描器一味的发现很多漏洞就是好的，这后面可能带来的是业务正常运行的隐患和高昂的后期维护成本。
从扫描运营体系出发，这里抛砖引玉提出一些漏扫运营思路：
关注扫描技术、漏洞规则的同时，漏扫运营也是企业安全建设避不开的话题。谈到运营，就往往不只是纯粹的技术，这时就需要我们更多的考虑人在其中的作用以及从整体出发管理的作用了。