“A9 Team 甲方攻防团队，成员来自某证券、微步、青藤、长亭、安全狗等公司。成员能力涉及安全运营、威胁情报、攻防对抗、渗透测试、数据安全、安全产品开发等领域，持续分享安全运营和攻防的思考和实践。”
为了全面了解外网资产的安全状况，我们在2022年启动了一项众测工作。自2022年7月份在三家平台发布以来，我们经历了护网、重保等重要活动，并于2023年3月份圆满结束。为了更好地准备下一次众测项目，我们特此进行详细的复盘。
（1）大概摸清外网整体安全状况；
（2）避免因外部漏洞对公司声誉造成影响从而导致监管处罚。
（3）查看安全安全检测的整体概况，漏检率如何（是骡是马，拿出来遛遛）
![【A9】众测项目痛点复盘优化]( "【A9】众测项目痛点复盘优化")
我们知道，漏洞是不断变化的，而业务也十分复杂。因此，即使有严格的系统上线流程和专业的渗透测试人员，也无法挖掘出所有漏洞，也无法通过一次上线检测发现所有问题。
通常情况下，一个系统在正式上线或重大变更前，会经历一系列软件提测。如果条件允许，可能会在SecOpsDev模式下发布版本。最后，在完成待渗透提测的系统后，进行手工渗透测试。按照完整的checklist清单，逐一检查可能出现的漏洞点，及时发现并修复漏洞，以确保上线系统能够稳健、安全地运行。
![【A9】众测项目痛点复盘优化]( "【A9】众测项目痛点复盘优化")
内部明明有了安全检测流程和每周红蓝对抗活动，为什么还需要众测呢？
从这两点的角度来看正常的渗透测试模式和红蓝对抗模式所求的目的不同，就会导致不同结果，渗透测试更像是大家去做全身体检的时候，尽可能的发现自身所有的问题，证明漏洞危害即可；而红蓝对抗更类似于大家熟知的木桶理论，只要我找到你的最薄弱点，突破系统的限制，拿到系统权限，维持权限，进而拿到更多的主机权限。
![【A9】众测项目痛点复盘优化]( "【A9】众测项目痛点复盘优化")
但是以上的手段也只是内部的，做的再好，也有点“闭门造车”的嫌疑，手段还是不够完备。真正的强大和自信，是愿意让更多的人提出自身的漏洞问题，也针对即使自己看起来很安全的业务系统，毕竟灯下黑的事迹在业界并不少见，”众“的力量也远远大于个体（不同的白帽师傅专研的方向不同，能提供更为全面的检测。），这就是市面上各大厂商需要采取这种较为流行的众测模式的原因。
依据国家发布的金融行业标准：《金融网络安全-网络安全众测实施指南》标准号，JR/T 0214-2021 来看，众测项目的实施具体会细分为几个主体：众测需求方（金融企业）、众测组织方（提供众测服务的企业）、众测测试方（白帽师傅）、众测审计方（项目实施过程中审计人员）；细分三个阶段：项目准备阶段、项目进行阶段、项目收尾阶段。大致的流程图如下：
![【A9】众测项目痛点复盘优化]( "【A9】众测项目痛点复盘优化")
![【A9】众测项目痛点复盘优化]( "【A9】众测项目痛点复盘优化")
![【A9】众测项目痛点复盘优化]( "【A9】众测项目痛点复盘优化")
对于以上的流程图，可能读者有以下的疑惑，为啥需要审计方，其实审计方的作用是对安全众测过程进行管控、监控、审计和评价的组织。根据和同行朋友的一些沟通，这块往往做的还不够好，没有独立出来，往往这个角色被需求方和组织方给分割了。
在此次众测过程中，首先需要对外招标，根据招标的结果提前准备好众测收录的范围，以及漏洞定级结果等参考。在今年的众测服务过程中，我们总共遇到以下几个印象较深的坑点（没经验导致）：
（1）漏洞接受与反馈的问题。
22年的众测不同21年以前，中标的众测组织方有三家，这就需要考虑漏洞接收的公平性，同一个漏洞（同一个漏洞只收录第一个提交者），谁的漏洞确认谁的问题，这就是需要倒逼我们去考虑漏洞统一接收口问题以及后续漏洞审核定级反馈问题。当时我们采用通过收发邮件的形式去接收漏洞，以邮件的时间为准，去评定同一个的漏洞谁先确认收录，这个做法解决了漏洞公平性的问题，但是没解决反馈的问题。
![【A9】众测项目痛点复盘优化]( "【A9】众测项目痛点复盘优化")
我们知道有些漏洞是讲究时效的，对于我们而言有些漏洞需要尽快修复，对于白帽师傅而言，可能越快审核越有动力去挖掘漏洞，但是通过邮件反馈漏洞，对于漏洞定级需求方和测试方有歧义，通过来回的沟通邮件，效率不高。
这就需要改进这种反馈的做法，这就需要三方都能看到联络的平台，于是参考了组织方的意见，漏洞的收录还是通过邮件来确定，组织方先初审漏洞，并通过邮件列举通过的漏洞列表，我们后续再去各自众测平台再去复审，有问题直接在平台沟通，三方都能看到，处理意见，也更快达成共识。避免一份报告来回编写与收发邮件。也解决了后续项目收尾的坑点。
![【A9】众测项目痛点复盘优化]( "【A9】众测项目痛点复盘优化")
（2）测试方动作规范的问题。
按照上述所说，因为审计方未能独立出来，有些监控可能无法得知，有众测需求的用户，可能也有以下的担忧：“测试人员的行为不可见、不可控、不可审计、不可溯源，一旦在安全众测事中或事后发生安全事件，缺少对事件的定位和溯源条件。” 害怕测试方借着众测方便的旗子，做着与众测无关，损害需求方的事宜，毕竟防人之心不可无，特别是对于安全这个行业来说。
所赖安全运营工作有大领导的支持、翔哥的实际指导和诸位同事共同努力，还算做的不错。在众测的时候，还曾检测出在非工作时间段，有白帽师傅私自探测漏洞的情况，详情可见：啥？白帽子进来了。。。
当然对于这种日志留痕，探测漏洞流量走众测厂家的出口，其实各大众测平台都有，但是在与协调日志和众测厂家沟通配合，组织方中，漏洞盒子平台的相关人员还是挺不错的。
![【A9】众测项目痛点复盘优化]( "【A9】众测项目痛点复盘优化")
（3）项目结项漏洞数据相关问题。
当项目结项时，需要统计漏洞相关的数据，因为有三家众测服务组织方，所以导致数据比较散乱，而与组织方核对的时候，发现双方记得同一个漏洞，却是不同的名字，导致核对产生了不必要的工作，如果一开始按照在众测平台审核各自漏洞，需求方和组织方都能在平台按照条件筛选本次项目收录漏洞的情况，避免了后期结项，关于漏洞数据比较痛苦核对的问题。
以上三点，是我这边认为在此次项目中比较大的坑点。
砍柴不误磨刀工，本文章是对22年众测工作的复盘，希望下次众测工作能做的更好，期待需求方、组织方、测试方三方能为共赢这个目标，精力合作。
https://www.cfstc.org/standards_bzgk/details/?id=1909&columnName=%E5%B7%B2%E5%8F%91%E5%B8%83%E9%87%91%E8%9E%8D%E6%A0%87%E5%87%86&nature=2
原文始发于微信公众号（A9 Team）：【A9】众测项目痛点复盘优化
免责声明:文章中涉及的程序(方法)可能带有攻击性，仅供安全研究与教学之用，读者将其信息做其他用途，由读者承担全部法律及连带责任，本站不承担任何法律及连带责任；如有问题可邮件联系(建议使用企业邮箱或有效邮箱,避免邮件被拦截，联系方式见首页)，望知悉。
点赞
https://cn-sec.com/archives/1763244.html
复制链接
复制链接
-
左青龙
- 微信扫一扫
-
-
右白虎
- 微信扫一扫
-
评论