闭环处理企业安全脆弱性

引言：企业的信息安全管理是一项管理与技术结合的工作，着重侧重其中一方最后往往收效甚微，因此在安全脆弱性管理这样的工作中也要充分考虑管理层面的可落地性，并逐步思考完善系统化的管理方法。

随着企业信息化程度的提升，大中型企业拥有大量的IT系统，企业关键的信息资产也正是分布在这其中。来自企业外部的攻击日新月异，深入企业内部逐步入侵核心资产的攻击模式越来越多。企业信息安全的防护逐渐向两个分支发展：一支紧盯攻击者、跟踪其行动路线、推理其使用工具、确定攻击动机，是对攻击者的研究；一支着重内部安全风险的检测、加固、防御，是对防御者的研究。而本文将要探讨的就是后者，如何能将企业内部的安全风险快速准确的检测出来并且闭环处理。

当前，检测安全脆弱性的系统及工具都日趋成熟，其细分产品类型也非常庞大，安全管理人员在使用这些检测工具时，面临了如下问题：检测结果在各个工具中导致展示维度各不相同；脆弱性无法统一展示：脆弱性整改工作繁琐：整改工作的整个流程没有系统支持：不断产生的问题和不及时的响应导致管理错乱。

解决方案

要解决当前脆弱性管控工作中的问题，要完成以下要点：

1.统一展示入口、统一下发工作、统一处理入口；

2.企业组织的各个结点上的各个检查专题都可以随意组合；

3.要展示安全脆弱性“现状”，即“当前”存在的“问题列表”；

4.任务结果实时更新表要含有所有任务结果的信息，且需要去重的、实时更新过的，展示内容需要筛选；

5.统一检查任务的管理。避免“重复”检查；

6.检查结果要简洁明了,避免一些复杂的检查状态带来的结果混淆；

7.结果是衡量脆弱性的唯一标准,不会因检查项的问题去撤销对问题设备的判断，也不会因为现网实际整改困难，而取消整改提示。

系统设计

1.整体流程设计

为实现解决方案中描述的方法，需要对系统做整体上的流程设计，分析关键的参与人员、闭环处理过程中的数据流向。

系统化过程中的关键环节：

总负责的管理者启动或者一般管理者启动任务检查；

角色鉴权，判断检查的数据权限和岗位权限适用的检查范围；

在众多的检查任务中，选择本次所要进行的检查专题；

将检查结果按设备更新到实时更新表中，这样保证了在任务完成一部分的情况下，仍有效输出检查结果，并且使用户时刻都能看到最新的脆弱性结果；

将结果按照组织结构进行分发；

生成更为详细的脆弱性明细表；

安全接口人查看自己组织下的安全问题，进行线下整改；

在整改过程中随时可自定义任务进行“复查”；

整改报告作为设备脆弱性结果的一部分更新到实时更新表中；

汇总所有检查任务结果呈现给安全管理负责人。

分析结果变更历史对比检查结果，得出整改工作的成效。

2.工作角色

安全管理员：具有各专项能力（基线配置、弱口令、防火墙策略、URPF、系统漏洞、内网Web漏洞、外网Web漏洞）自查、复查和统一检查权限；查看各专项能力的问题明细、问题出现次数、整改情况等权限；查询权限内系统未连通设备明细、设备问题明细和问题汇总权限；按“开始时间与结束时间”、“检查的组织范围”、“检查类型”条件增删改快照和查询快照组织系统的问题整改情况。

安全接口人：各专项能力（基线配置、弱口令、防火墙策略、URPF、系统漏洞、内外网Web漏洞）自查、复查和统一检查权限；查看各专项能力的问题明细、整改情况等和进行整改情况报备权限；查询权限内系统未连通设备明细、设备的问题明细和问题汇总权限。

3.综合调度

连通率、基线、弱口令、防火墙策略核查、URPF、系统漏扫等任务的统一自动调度包括了执行顺序、执行优先级、各组件内部任务的自动协调。任务的状态应集中展示在综合调度上，任务是否启动、启动后执行中的任务状态、中断行为的展示。

执行任务过程中，任务下发人若因系统占用或发现错误情况可能需要终止综合任务，此时各模块产生的报告和结果文件已完成的部分需要更新和记录。插入任务则需要系统后台设置好各模块的执行优先级，对当前正执行的任务采取挂起操作。

综合调度任务涉及到各个脆弱性系统模块的整合，下发后执行过程中必然存在任务执行异常，异常需要任务下发人通过各种异常信息提示联系到能够处理的人。那么调度系统一方面要提供异常情况的预判能力，另一方面提供异常处理的建议，类似于资源连通性测试时产生网络不通、资源未接入等情况的错误信息提示。

模板自适应，当使用任务模板时，系统对模板中选定的设备所在的组织结构进行实时查询，对比模板，若发现新增或已下线设备的情况，直接更新为实时的资源列表，若此前模板并未覆盖全部资源而是个别资源的话，应提示所选资源发生变动，同时更新为最新情况。

4.整改流程

综合检查完成后，生成的检查结果应分发给各安全接口人，让其参与整改，并反馈整改完成项与未完成项，未完成项需填写误报和无法整改的备注。整改三种状态：已整改、无法整改、误报。

检查结果的生成过程中，按照组织结构维度进行组装。

在报告按照组织结构输出后，还需要对应到组织的安全接口人，用以在安全接口人登录后在其待办中显示。待办中需有详实的待整改设备列表，清楚展示设备存在哪几类问题、每类问题个数、问题的详细信息等。

因检查结果实时更新，对专项检查来说整改率是项考察组织侧日常安全工作开展的重要指标，但整改周期长时，对组织的评价很难通过历史时间判断其整改的最终效果。当前漏洞数里有专项检查后官方发布的新漏洞或因系统配置导致新增的漏洞，因此：整改率“必须是“一个比较过的结果，而非单纯的数字计算，例如1月0个漏洞，2月 A、B、C、D4个漏洞，3月 5日查看时B、C、D、E4个漏洞，那么2月整改率是25%。关于误报，是参与到整改率的计算中，被认为是”已处理的“、”非遗留的“项，在计算时分子和分母中都有”误报项“参与计算。

对安全接口人来说，收到检查结果后，应按结果对权限下设备进行整改，整改完成后报送一个“整改完成”的结果即可，但整改过程中会遇到两种情况误报和无法整改，如遇需添加整改备注。误报：由于检查项或检查方式不适用于检查设备，造成的检查结果错误。无法整改：因设备处关键系统，不允许宕机等原因无法完成漏洞修补的情况。组织安全接口人会根据实际情况在报送整改时，追加误报和无法整改两种情况的备注。整改备注包括正常整改内容的备注、误报情况、无法整改等三方面内容，执行一次任务后，之后的复查结果（界面展示和报告）上会一直标识整改备注（误报和无法整改）。

5.综合呈现

检查结果包含多种检查的报告整合，且需要按照不同维度展现并预置其可查看的权限，功能相对复杂因此作为单独模块表述。

系统中的这张汇总表处于动态加载状态，一旦有某项任务执行导致了结果的变动，此表都需要更新。

为支持后续的分析、展示、标识乃至未来的评分，检查结果都需要进行统一的标准化处理以满足变更、扩展、关系对应等要求。

展示内容需按照“任务”作为基本线条来展示，“任务”表示了用户对某个例行或专项检查的计划，任务是由“开始时间与结束时间”、“检查的组织范围”、“检查专题的范围”三个要素构成。

综合调度检查后，输出的内容庞杂，应提供简便易读的最终输出物报表和视图。

通过多次检查后，会出现某些组织在某项指标上一直存在问题，例如系统资源上存在漏洞，经过3次检查漏洞依然存在，这除了误报和无法整改还可能由于安全接口人消极处理导致，因此对此类问题应输出相应的展示及报表。展示内容包括了该问题被检查出的历史任务列表、整改备注、整改后消除不达标项的时间。

总结

该方法从实际工作场景出发，将工作入口、工作成果做统一的处理，最终令脆弱性处理工作符合使用习惯和工作需要。这种基于工作场景的创新具有创新意义。

按照本文提供的方法进行脆弱性管理将使脆弱性管理工作得心应手，符合参与各方的工作需求和使用体验，告别繁琐复杂、令人疑惑的管理流程和呈现结果。