发现漏洞之后该怎么办？

jack

作为安全行业的甲方（如互联网企业），经常会收到外部报告的漏洞或者发现安全事件，比如SQL注入、XSS、逻辑漏洞、APP缺陷等等。那么，收到漏洞报告之后，应该如何处理，才能最大程度的降低风险呢？


在互联网企业，一般都建设有安全应急响应中心（SRC），负责跟外部白帽子或第三方漏洞报告平台接口，协调处理报告过来的漏洞。处理的流程，通常叫做安全应急响应流程。接下来简要描述一下这个流程。
问题定位/事件调查

SRC收到漏洞报告之后，首先要在承诺的时间范围内尽快召集对应产品的开发、测试、运维等相关人员（这个过程可通过即时通讯系统拉群讨论），对问题进行分析、确认、定位，得出漏洞产生的原因。
如果是安全事件，就需要分析入侵路径、所利用的漏洞，对整个入侵事件进行还原。
在实行ITSM（IT服务管理）的企业，需要在ITSM平台上创建一个事件，启动事件处理流程。
应急措施

采取措施降低风险，措施通常分为应急措施和根本措施两种。
应急措施是以以快速降低风险、保障业务为目标，不寻求彻底解决；而根本措施是以从根本上降低风险为目标，按照最佳实践进行改进，通常需要一个较长的时间段。
在定位到原因之后，就需要采取应急措施。
比如针对SQL注入等常见Web高危漏洞，应急措施可以采取对用户提交的参数进行转义或过滤、审视调整WAF拦截策略等。
针对弱口令的场景，责令相关人员按照口令强度标准修改口令。
风险定级与奖励

给报告漏洞的白帽子发放奖励，是互联网行业的通行做法（当然，白帽子也只能点到为止，不能有利用发现的漏洞进行进一步入侵、窃取数据等行为）。
根据漏洞的危害（可能造成的损失）、风险定级标准对漏洞进行定级，然后发放奖励。
根本措施

上述应急措施虽已实施，但执行的措施往往不是最佳实践的做法，需要从根本上改进。比如针对SQL注入漏洞采取了过滤或WAF阻断的应急措施，但这种措施并非最佳，需要修改为预编译（绑定变量）的机制，彻底将指令和数据分开，从根本上消除SQL注入风险。这个会纳入版本升级计划，执行周期相对较长。
如果所采取的应急措施就是根本措施，则跳过该环节。
针对严重的安全事件，还需要根据分析的结果（攻击路径、利用的漏洞等）执行关键路径切断，或者在关键路径上执行网络监控（运维及数据库端口、弱口令连接）以便第一时间发现风险。如果事件是由于员工的安全意识薄弱所导致，比如感染钓鱼邮件中带木马的附件，还需要进一步执行员工安全意识教育（宣传）。


上述内容都是针对产品上线后的风险、漏洞报告或事件。
接下来看看上线前在SDL执行过程中的风险处置。


SDL与上线前的风险处置

如果是在SDL执行过程中，安全人员发现了产品中的风险（或与标准规范的冲突项），该如何处理呢？
通常来说，针对风险的处置措施包括：
降低风险（至业务可以接受的水平之内）；
分担风险（部分转嫁风险，如购买保险）；
接受风险（保留风险，但需要额外的决策）


针对高危风险，通常应该改进后才能放行（首选）；
如果业务紧急（或强势），至少应有应急规避措施（通过安全配置或额外的访问控制）以及版本更新计划（在新版本中消除已知高危风险）；


俗话说，没有绝对的安全。
如果是已经采取了一定安全措施，但无法从根本上修复，也没有可行的规避措施的高危风险（比如补卡攻击盗窃网银），可以购买保险以转嫁风险。

如果上述措施都没有，除非安全方面非常强势，那就需要请业务好好决策一下了，如果业务决定自担风险，那就由它去吧~
安全上的改进有时也是需要付出代价的。
针对中等或低危风险，依据公司安全策略（比如需要什么岗位的角色来决策或确认）进行处置。这个策略文件通常被称之为风险评估与处置办法，是安全管理类文件的组成部分。