企业内部安全漏洞修复流程的建立与思考（其四）

今天的聊的主要是漏洞修复的测试和发版以及业务测试和流程优化部分，在企业内部修复的过程中，这两点应该是在整个漏洞修复生命周期中占比最长的流程，一方面是因为在很多企业中，这些涉及到其他部门，跨部门之间的沟通和协调较难，其次就是具体的漏洞修复涉及到生产变更的要求，这方面就需要遵守具体流程去做。（不否认有紧急发版或临时性的方式处理，笔者这里不算在日常工作中）

4.漏洞修复测试及发版

在漏洞修复过程中，很多时候并不是像渗透测试人员想的那样，有了漏洞打补丁即可，或者是修改参数就行，要考虑具体的业务方向（自建使用的可以稍微粗暴点），针对系统的重要程度（等保、社会影响、业务重要程度等）的修复测试和流程可能都有不同（看单位具体情况），所以需要安全人员在修复的过程中针对这些系统、业务有个清晰的认知，安全不能只聚焦于发现脆弱性方面，很多时候要了解具体的业务功能、场景，针对现有的实际情况针对性的进行防护和流程优化。

4.1漏洞测试

针对漏洞修复，经常性是非安全人员进行修复，大部分为开发人员或运维人员进行版本升级、补丁包更新、配置变更等，由于涉及到跨部门工作，需要额外的时间去验证其他部门的人是否针对下发的漏洞修复成功（并非是不信任修复人员的工作，而是为了进行工作闭环的需要）。

针对漏洞测试主要有如下测试方面：

1.技术性验证测试：即通过技术手段（应用扫描或者漏洞扫描）验证相关漏洞是否修复。

2.兼容性验证：验证逻辑漏洞（例如：业务数据篡改、条件竞争类漏洞）是否修复，是否影响业务功能。

3.多次验证：系统的上线遵循测试环境、生产上线前环境、生产环境，针对漏洞，需要及时跟进不同环境下的修复情况。（一般来说环境应该保持一致，但是具体实施起来存在困难，需要根据现有单位的情况进行适配）

4.2 修复版本上线后的性能监控

系统/版本上线后，由于有具体的业务承载，需要针对变更后的相关组件、应用、服务器、系统进行性能的监控，如zabbix、promethus，对CPU、内存、业务响应时间等进行监控，验证更新后的是否存在异常；同时还需关注具体的业务日志，是否存在报错、乱码的情况。

4.3注意事项

在漏洞修复及测试的注意事项其实不多，主要就是

1.在测试环境、准生产环境、生产环境接入验证时，需要及时和相关负责部门沟通，开通相关网络规则（和漏洞发现一致），针对可能引入数据的测试要慎重，必要的时候针对引入的数据进行删除操作。

2.针对性能监控，重点放在具体的业务高峰期以及版本更新后的24小时，针对上述说的应用、服务器、系统进行监控，若出现问题，按照应急预案或者相关生产管理办法及时处理（必要时上报监管机构或者上级单位）

5.业务测试和流程优化

其实漏洞测试和业务测试是交替进行，但是为做好职责工作的区分，进行分开。

5.1 业务测试

针对修复的漏洞，相关业务部门需要对修复完的相关系统进行业务可用性的验证，部分涉及到无法验证的系统，联系相关接入机构帮忙以具体实际业务的形式进行验证（生产环境且系统重要程度较高），其中主要关注这几点：

1.相关测试大纲来源：业务测试需要相关的测试大纲，按照大纲流程去进行测试（部门单位有具体的自动化测试脚本，但这里还是点出），这个时候，针对修复的具体漏洞，需要开发部门给出业务测试大纲，按照大纲流程进行修复。【很多安全工作者觉得没必要，只要这个功能点修复即可，但是在系统中，存在多个应用调用某个功能点/接口，针对这种，需要谨慎，确保业务正常运行】

2.测试、验证发版的排期是否符合安全部门的需求：这个主要是针对重保、护网、严重/高危漏洞的修复流程，这里不做细节上的阐述，按照相关流程去做，安全/开发/业务/运维的领导有具体需求时可以组会讨论，得出方案，不做一言堂。

3.对业务无感知的测试业务部门是否愿意接受额外的测试工作量：针对跨部门协调，由于漏洞的发版针对业务部门的测试排期来说，属于额外的工作计划，针对某些漏洞修复，系统无感知的情况下，业务部门是否愿意进行测试，发版是否能够跳过业务验证这块去发版，需要根据单位内部的制度、流程处理，这里不做太多的建议。

5.2 设备测防护措施是否生效

应用代码层面无法修复或者修复存在困难的情况下，需要在外部进行兜底时，要验证相关安全策略是否可以针对漏洞进行防护，且防护是否生效。

例如短信轰炸漏洞，通过waf调节访问策略，进行防护；或者多因素认证，验证认证通过UKEY、软（硬）件证书是否正常做认证等。

原文始发于微信公众号（云下信安）：企业内部安全漏洞修复流程的建立与思考（其四）