0%

Notes-论安全漏洞响应机制扩展—JSRC-3

如何看待待企业的安全工作建设

安全响应中心不仅仅是接报漏洞,还需要帮助内部提升安全质量,分为两方面:被动、主动。

被动方面:

比如说进行针对性的培训,加强规范。 需要明确的是,安全团队是在帮助业务部门防范风险;

主动方面:

应该是我们增加的那些检测机制,例如在上线流程,或waf中增加策略,可以直接进行自动化检测。

漏洞的处理是一个方面,对于内部的项目上线筛查可能比后续更重要,通过需求评审, 架构评审,安全评审等来筛选项目是否够上线的条件。

上线前充分筛查,上线后出现问题,基本都可控。

现状是,还会发现一些在野资产。都不知道什么时候就上线了。

另外,上线流程过程中可以开发一些黑盒、白盒扫描工具,提供给开发人员,让开发人员去自查,如果有问题再找安全部门,这样开发人员也会对安全越来越了解。只要解决开发部门的自我驱动,所有问题都迎刃而解。

让开发人员自查,这个难度有点大


安全响应机制整个流程的结束点?

白帽子提交漏洞,企业应该按照白帽子提供的方法结合自己的业务去查是否还有类似的问题,白帽子的漏洞提交只是事件处理的开始。处理完相同类型的漏洞,才能算是结束。

举一反三, 一个地方有问题,那么其他地方出现同样问题的概率很大。


跨部门协作配合修复漏洞的问题:

有些漏洞不一定能及时修复,但这不会影响我们对漏洞的评级。

在企业中,越大的企业越会出现漏洞修复推进困难的情况。

漏洞的修复情况,看这几个因素:

  1. 具体的漏洞
  2. 这个漏洞会影响的业务
  3. 业务方的配合程度
  4. 有没有合适贴切的解决方案

“提升安全能力”不在应急止损的关注范围内,可以包括在后续安全建设中。 跨部门修复方面主要分 “产品线重视自觉寻求帮助”“上级推动” 两类。

定制漏洞修复事件dead line,如果不修,逐级上报。

还可制定不同级别漏洞对应不同修复时间的要求, 严格执行考核。 超期系统自动邮件抄处理人的上一级领导, 时间越长,抄送级别越高,直到超送到技术副总裁。


一个业务部门如果多次出现同类型问题, 有相应的响应机制么?

需要看是什么类型问题,是工作态度问题还是技术能力不够,如果是前者要找他们leader去沟通,如果是后者,安全部门需要组织交流培训,提升业务部门的安全意识和技术能力。


安全应急响应机制:

建立安全接口人,协助产品线培养免疫力。

阶梯性的做安全培训,后续让产品线他们自己重视培训,提升安全意识与能力。


refs: