0x1本周话题
话题：大家单位里漏洞是怎么去管理的，包括漏洞发现、评估评级、处置跟踪这些，工作职责会被分解到各个单元还是由安全部门一把抓？
A1：我们是安全部门一把抓，只是修复的时候安全部门出具修复方法，相关人员去修复。
A2：只有漏洞修复由业务方去做，安全会发安全工单跟踪整个漏洞处置流转流程。如果是外部漏洞，会有一个漏洞费用分摊，会分摊到业务方。
A3：安全负责。首先制度定好等级、扫描频率、修复时长要求，平时除了定期漏扫，监管每个月还有缺陷发文一样要跟进。发现漏洞后提内部流程，定好修复责任人，跟踪进度。流程内置了修复时效要求，到期前也会提醒。
A4：漏洞发现：安全部负责安全评估和测试、漏洞扫描、漏洞情报发现的漏洞，各部门负责定期从厂商处获取漏洞和补丁信息。
漏洞评估评级：安全部，确认漏洞等级，指定漏洞修复部门。
漏洞处置：安全部给建议，各部门负责制定具体实施方案、完成修复，如果不能完成方案，可以和安全部协商。
修复验证：安全部对漏洞修复结果进行验证。
闭环跟踪：根据漏洞修复SLA跟进漏洞修复情况，并对延期漏洞进行通报或扣除相关部门KPI。
A5：可以看看历史群周报和分享，有较多实践经验可以借鉴：
开源组件漏洞可利用性分析的落地实践与经验之谈 | 总第208周 漏洞修复&安全左移探讨：如何解决互联网系统上线不能有高危漏洞的问题？安全与测试、研发合作有哪些矛盾？如何解决？ | 总第176周 |
Q：请问漏洞修复SLA是发布的管理制度吗？我看到有扫描的动作，咱这边会有多源的扫描数据整合吗？如何排除误报呢？我们现在缺少一个平台化的工具，修复情况很难去跟进。当然内部有IT流程平台还有OA和ITSM，但是我觉得不是很适用，主要是闭环方面做不起来，一份漏洞报告涉及多个漏洞，OA里没办法落实修复率等情况。还有就是我们OA比较古老，功能上有不少缺陷。
A5：我们直接用内部的ITSM平台，嵌入进去安全工单流，这样大家用起来更方便，平时提策略单、申请机器单，直接在一个平台搞定。业务方在修复漏洞之后，去ITSM关单。如果未修复就reopen，让他们再次修复。
A6：我们目前是专门漏扫系统、EDR发现、监管发文、外部信息等等，都算。给IT定下年度KPI指标，问题就不大了。
A7：流程能提醒对应处理节点，就能闭环，安全发起，最后有一个节点是安全验证确认。需求管理，研发管理系统，就用在漏洞管理也挺好，管漏洞就是管bug。像CMDB，ITIL这些平台也可以分发。
A8：现在看来我还是得在ITSM上多做做工作。也不只是管bug吧，得看是哪个阶段的漏洞，实质上都是管的流程。
A9：对呀，ITSM业务方都用，这不是很棒嘛，使用起来更适应一些。还需要发布对应的漏洞管理流程的制度，都知晓且遵守。其实不一定是漏洞管理系统，只要能做到闭环，还有针对每条漏洞的跟踪和总体漏洞的修复情况汇总，这几方面做到了我觉得就还好了。
A10：流程可以用公司现有的流程来闭环。安全闭环管理漏洞如果没有系统支持可以建议用以下两种方式低成本的管起来，都是免费的工具: 1.飞书的多维度表格；2.钉钉的多维度表格。我们现在就是用这种方式，可以触发到每个责任人，还可以定期提醒。
A11：我们也是用ITSM跟踪的，由安全团队负责定期扫描和渗透测试，发现漏洞，然后发起ITSM的漏洞修复流程，由安全负责人确认，部门领导确认，然后分配给对应系统的开发负责人，开发负责人修复后，由安全人员确认修复，关闭工单，形成闭环。
A12：这样我还是要继续研究一下ITSM，尽量在这个平台里转起来，我们的工作流是全流转于内网环境的……
Q：那你们内部IM用什么呢？是自研的还是哪个的私有化部署？
A13：我们有一套自己的平台，部署在内网的。也是商业版软件，感觉挺弱的。
A14：IT用什么流程就与什么流程结合，修漏洞是IT或者业务开发部门的事情，要与他们的流程整合。我们也是在项目管理平台上对接了流程。
