奇安信的漏洞管理实践 本⽂8846字   阅读约需 25分钟 随着攻击向量扩⼤和漏洞增加，漏洞管理成为安全解决⽅案的最前沿，成为⻛险管理的重要组成。安 全团队⾯临两难：安全漏洞数量激增、⽆处不在，安全预算却在减少和安全⼈才持续短缺，修补每年 发现的惊⼈安全漏洞简直遥不可及的任务，简单的发现和修复模式已经难以为继。 奇安信经过多年总结与实践，针对已知漏洞和未知漏洞⻛险管理，形成了⾃⼰的完善的体系。 ⼀、背景介绍 安全漏洞⼀直被视作攻击企业的⼊⼝，以各种形式存在于企业信息资产的⽅⽅⾯⾯，稍有不慎，安全 防线就可能被击破。 通过从组建漏洞管理团队、在现有⼤流程中设计漏洞管理流程、增加漏洞发现⽅法、建⽴漏洞管理闭 环流程、形成漏洞复盘机制、构建漏洞评价体系、推动漏洞发现转向漏洞预防等 7 个⽅⾯，对企业的 安全漏洞进⾏全⾯、深度的治理。 ⼆、管理实践 2.1 漏洞管理团队 漏洞涉及的范围⼴泛，故管理难度也⾮常⼤。通过建⽴专项⼯作组、部⻔ BP 制度、安全团队内部分 ⼯等式，为漏洞管理提供最有⼒的⽀撑。武鑫 2023-08-24 19:09发表于北京 原创 ⻁符智库 2. 1.1 集团级管理团队 专项⼯作组：⽆论是建⽴虚拟或实体的⼯作组，都应该⾃上⽽下，需要包括产品、开发、测试、运 维、安全等不同⻆⾊的⼈员。各企业中相关岗位可能已经有⼀定的组织，那么在建设专项⼯作组时优 先考虑将其纳⼊或联系其主要成员加⼊，如下图所示的研发委员会、安全委员会等。明确该岗位的⼯ 作⽬标与⼯作职责，⽐如，研发需要对⾃⼰所写程序的安全质量负责，主动学习安全⼈员提供的开发 安全规范、进⾏开发安全考试、在编码时安装安全 IDE 插件进⾏安全检查、编码完成后触发静态代码 安全扫描⼯具进⾏安全检测、针对安全检测结果联动安全⼈员进⾏漏洞确认与修复、在运营阶段若是 发现产品编码相关漏洞需要及时响应与修复。 · 部⻔BP 制度：建⽴部⻔的安全接⼝⼈，负责对接安全⼈员上传和下达消息、在本部⻔落地相关安 全要求。建⽴的机制依旧是从上往下，通过专项⼯作组发通知给各部⻔的负责⼈，由负责⼈亲⾃指定 并声明该部分⼯作的重要性，争取对接⼝⼈有⼀定的考核权，让安全⼯作正式成为接⼝⼈职责的⼀部 分。前期可对接⼝⼈的配合情况和⼯作质量进⾏排名、正向反馈，最终需要落实到绩效考核上。安全 接⼝⼈需要对部⻔内部的产品、研发、测试⼈员进⾏联动、驱动，承接部⻔漏洞的管理职责。 2.1.2 部⻔级管理团队 为了保证各项安全活动有效落地，安全团队内部可根据安全活动不同的⽅向设置团队，包括安全防 护、安全运营和产品安全团队，内部的漏洞管理⼯作也主要是由这三个团队负责。 · 在安全防护团队中，设置专岗⼈员进⾏资产信息收集与识别、最新漏洞跟进分析、编写 POC 、执⾏ 漏洞扫描等⼯作； · 在安全运营团队中，安全运营⼈员通过⽇常安全设备的告警，发现漏洞并提交漏洞⼯单； · 在产品安全团队中，负责产品上线前的安全测试及 SRC 运营，通过引⼊⽩盒测试、⿊盒测试和灰盒 测试等⽅法发现并推动漏洞修复。2.2 漏洞管理嵌⼊流程 漏洞频现，发现的⽅式也⽐较多。但如何才能持久、⾼效、有效地发现并管理漏洞呢？在经过⻓期实 践之后，总结出以下两点漏洞管理⽅式，最核⼼的思想就是 “ 嵌⼊现有的⼀切流程 ” 中。 2.2.1 漏洞管理融⼊开发流程 为进⼀步提升产品与信息系统的⾃身安全能⼒，防⽌产品与信息系统带严重、⾼危和中危漏洞上线， 有效减⼩集团信息安全事件发⽣的概率。在产品发布节点上设置了安全卡点，未经过安全提测或安全 提测结果不达标的产线，将被禁⽌发布上线。同时由于安全⼈员有限，将部分安全测试能⼒融⼊到产 品中，交由产线来完成，以此保障该措施能够落地。基于开发流程的安全测试流程，如下：最开始的节点始于产线，在完成⾃主安全测试并漏洞修复后，可进⾏安全提测；产线提交安全提测⼯ 单后，进⼊排队待测试状态；安全测试⼈员分配到安全提测⼯单后，进⼊测试中状态；安全测试完成 后，由产线进⾏漏洞修复，提测⼯单状态为修复中；漏洞修复完毕并经过安全测试⼈员验证，提测⼯ 单状态为安全测试通过。 2.2.2 漏洞管理联动资产管理流程 ⽆论是漏洞的发现，亦或是漏洞的修复，均需要明确存在漏洞的资产归属情况，故资产管理是漏洞管 理的另⼀个基础。基于资产（操作系统 / 应⽤ / 组件）进⾏漏洞扫描，可以提升扫描效率、降低⽹络流 量；基于资产（重要级别 / ⽹络位置）进⾏漏洞修复判断，可以提⾼必修的漏洞修复率；基于资产 （使⽤⼈/ 运维负责⼈ / 安全负责⼈）进⾏漏洞修复推动，可以提⾼整体的漏洞修复率。以下为漏洞运 营平台结构图，清晰的展示了与资产管理的紧密联系。 2.3 漏洞发现⽅法2.3.1 漏洞预警监测 通过从安全媒介、软件官⽹、国内外漏洞平台、社交软件等途径，实时获取漏洞情报信息、漏洞利⽤ 信息等，结合公司的信息资产对内进⾏预警。对于银⾏、证券、运营商等⾏业，还会收到来⾃上级监 管单位的漏洞预警通知。常⻅的漏洞监测情报包括 CNVD 、 CNNVD 、 CVE Details 、 CVE 等漏洞平 台；可以是 Freebuf 、安全脉搏等安全媒体；还可以是微信朋友圈、推特等社交软件。 对漏洞情报的处理，是接收到漏洞情报后应⽴即开展的⼯作，也是对安全⼈员对⾃身资产熟悉情况、 对新漏洞理解的考验。通常若漏洞有 CVSS 评分，则可以直接关注 7.0 分及以上的漏洞，进⼀步还需 要结合以下⼏个维度进⾏综合评估。 漏洞利⽤危害程度：漏洞被利⽤后造成的直接危害； 漏洞利⽤难易程度：有⽆公开 POC 、 EXP ，是否需要登录等； 受漏洞影响资产的属性：资产所在⽹络位置（公⽹或内⽹）、资产重要程度（重要系统或⼀般 系统）； 监管或上级单位发⽂通知的漏洞（⾮普适）； 漏洞修复成本和对业务的影响。 2.3.2 ⽇常漏洞扫描 定期使⽤扫描器对资产进⾏主机漏洞和 Web 漏洞扫描，是较为常⻅发现线上系统安全漏洞的⽅式之 ⼀。扫描频率和扫描规则决定漏洞的发现能⼒，扫描频率原则上在能覆盖所有资产的基础上越频繁越 好，扫描规则需要根据漏洞情报或⼚商及时更新。在常⻅的漏洞⼯具中，⽆论是系统还是 Web 层 ⾯，⼀般都⽀持登录扫描，但以此带来影响业务的⻛险也随之增⼤，特别是实时性要求很⾼的业务系 统对扫描⽐较敏感，所以在进⾏扫描前需要注意以下事项。 · 扫描器地址加⽩：扫描器的地址加⽩包含两层意思，⼀是在⼀些特殊的⽹段或业务系统放⾏扫描请 求，实现覆盖率全局覆盖；另⼀⽅⾯是在安全防护设备上添加⽩名单，防⽌被安全设备拦截导致扫描 ⽆果，同时也减少扫描时产⽣的⼤量告警，避免给安全运营带来巨⼤的⼯作量、已知的扫描告警淹没 掉有真正攻击的有价值的告警。 · 设置扫描时间窗⼝：从扫描类型（系统 /Web 漏洞）和扫描⽬标（内⽹ / 外⽹系统）进⾏区分，设置 每天扫描开始和结束的时间，每⽉ / 每季度的扫描频率，在制定的时间内进⾏扫描⼯作。 · 扫描前通知业务⽅：将制定的扫描任务与计划在开始前，同步到业务⽅并获得其统⼀，可以提⾼扫 描时出现线上故障的处置效率。另外有⼀些业务系统也会反馈不能扫描，需要添加扫描的⽩名单。 · 留意加⽩业务系统：针对扫描加⽩的业务系统，可以通过进⼀步确定扫描作业开始时间、加⼤扫描 周期、扫描⼀⽐⼀的测试 / 预发环境、根据系统架构等基础信息进⾏精细化扫描等多种⽅式来发现漏 洞，防⽌因为加⽩⽽导致的扫描盲点。· 多款扫描器交叉扫描：不同扫描器的规则（能⼒）不⼀致，对漏洞的检出能⼒也有所差异。从⿊客 攻击、上级单位扫描检查等⻆度出发，需要将常⻅的扫描器加⼊到扫描武器库中，实现漏洞在被⼈发 现之前先发现，掌握⼀定主动权。 · 对扫描器的操作进⾏审计：由于在⽹络和防护层⾯都对扫描器开放，扫描器上已知漏洞也属于公司 的重要资产信息，需要对扫描器的登录、登出、扫描任务制定等关键操作进⾏审计，做到事后可取证 追溯。 2.3.3 产品安全提测 业务上线前进⾏安全测试，基本已经成为拥有安全⼈员的企业必做安全⼯作之⼀，也是漏洞发现的主 要来源。通过建⽴安全提测流程，设置业务上线卡点和安全质量要求，促使业务上线前都来进⾏安全 测试并进⾏漏洞修复。 下⾯介绍⼏种常⻅的安全测试模式，不同企业⼀般都是有⼀种或⼏种搭配组合。 · ⿊盒主动漏扫：这应该是最常⻅的发现漏洞⽅式，也常常作为安全测试中的安全基线，使⽤⼯具通 过爬⾍获取待检测系统的 API ，加载各类 payload 进⾏漏洞扫描，包括主机漏洞扫描和 Web 漏洞扫 描。主机漏洞扫描器基本都是商⽤的，⽐如 Nessus 、绿盟 RSAS 等； Web 漏洞主动式扫描⼯具种类 较多，包括⽿熟能详的 AWVS 、 w3af 、 Nikto 、 OWASP_ZAP 等，⼤多都可通过开源⽅式获得。⿊盒 主动漏扫能发现常⻅的漏洞，但是在覆盖⾯⽅⾯存在⼀定的不⾜，就 Web 漏扫⽽⾔，针对单个链接 的孤岛因为爬⾍找不到路径、使⽤防重放⼀次失效 token 的⻚⾯等，通常会检测不到。 · ⿊盒被动漏扫：相对于主动⽅式的漏洞扫描⽽⾔，被动漏扫最⼤的区别就是获取的 URL 来源不同， ⼀般包括通过流量提取和⽇志解析。在功能测试时或者线上环境产⽣的流量中，提取待测系统的 URL、去重、加载 payload 、重放进⾏安全测试，从⽽覆盖到⽤户能接触到的所有系统功能。⾄于⼯ 具⽅⾯，以商业和⼤型互联⽹公司⾃研两种形态为主；另外也出现⼀些社区版的产品，⽐如 xray ； 半⾃动化的⼯具 Burpsuite + ⾃研漏洞插件进⾏漏洞扫描。 · ⽩盒安全测试：在安全测试领域，静态代码扫描通