漏洞和事件处理

发现安全问题

安全漏洞并不等同于安全事件，存在安全漏洞并不一定会被利用，安全漏洞只是一种客观存在的弱点，而安全事件是指已经发生了的，并且对企业造成了一定的影响和损失的事实，同时安全事件并不一定是由安全漏洞引起的。比如，由于人为的操作失误或者机房断电等原因，都可能造成一些安全事件。

很多公司和企业都有多种的web应用和服务，开放到互联网。一旦这些服务和应用开放到互联网，就会遭受到全球黑客的扫描和渗透攻击。这些安全问题就像屏蔽的定时炸弹一样，不清除的话，随时都有可能危害到企业的信息安全。而一旦web应用被攻陷之后，直入后门，服务器就会变成入侵者的前哨站，通过这些被入侵的服务器作为跳板。进一步的进行内网渗透，导致整个内网的沦陷。

在项目介入的初期，提前发现可能的安全问题，规避安全风险，永远是最经济的方法

我们可以从web使用的框架和语言的选型开始，比如常常爆发0day漏洞的stress two，就应该尽量避免使用密码的保存，应该是加盐后进行强哈希的方案。而且我们需要检查应用是否存在上传文件的风险等等

安全扫描

扫描器是安全人员武器库里最常见的兵器。就好比我们去医院看病，首先要进行化验一样。扫描器可以得到应用最基本的信息和漏洞相关的信息，扫描器可以分成开源的，也有商业的。同时，也有我们安全人员自己编写的特定的扫描工具，这些工具结合起来，可以帮助我们进行自动化的、周期性的常规扫描

除了扫描器之外，我们还需要人工安全测试作为补充，原因是自动化的扫描器存在一些不足。比如存储型的XSS漏洞触发点不定，所以我们很难用扫描器来发现。而一些越权型的漏洞扫描器很难捕捉到，而一些业务逻辑型的漏洞扫描器根本无法理解

入侵检测

入侵检测主要分成网络层的入侵检测和主机层的入侵检测。网络层的入侵检测是通过对网络流量进行分析，而检测到入侵行为，主机型的入侵检测则需要在主机上安装一个小程序，然后通过这个小程序来搜集文件、进程、日志等信息进行综合分析来检测入侵的行为。

只要有过攻击行为或者入侵行为，总会在日志中留下一些蛛丝马迹，通过对日志文件分析是发现安全问题一种非常常见的手段，一般可以通过可疑日志加人工分析、可疑日志加扫描器结合的方式来发现绝大部分的安全问题。同时结合最新的大数据和数据挖掘等新技术。可以挖掘更深层次的安全问题，同时捕获最新的漏洞和攻击方式。

建立SRC

借助外部的力量来弥补自身防御体系的不足，同时增加与安全圈子的互动。建立SRC是近年来各大互联网的一种新进的手段，通过社区化的运营发动白帽子来发现安全问题。做到了企业和白帽子的双赢。

与漏洞搜集平台合作

选择和漏洞平台合作是另外一种发现安全问题的途径，这种方法成本更低，但是相对于主动建立应急安全响应中心的方法，略显被动，这个需要各个公司根据自身的情况进行权衡，当然两者的结合是现在更加普遍的一种方式。

其他渠道

利用卧底和国家执法部门合作等方式进行补充，因为攻防本身是一个不对等的游戏，所以情报工作至关重要，知己知彼，方能百战不怠

随着互联网的发展，孕育了一个非常庞大的黑色产业链，我们只有了解黑色产业链的手段、最新动态使用的技术才能料敌先机，不至于被动挨打，卧底是一个长期而艰苦的任务，需要长期混迹于各个论坛群等。

漏洞处理

发现漏洞就像去看病时的诊断一样，而修复漏洞就像是我们需要开药方。

防御首先需要做的就是输入检查所有的安全问题的根源，其实是信任问题。所有的外部输入都属于不可信的范畴，除了常见的用户输入之外，还需要注意的是文件系统的输入，系统参数的输入、环境变量等其他不可控的输入。

进行输入检查的注意事项包括：

1.在服务端进行检查，因为客户端的检查很容易被绕过。数据的检查需要从类型，范围、长度等多个维度进行检查，减少被绕过的风险。这里我们以手机号为例，手机号首先是一个11位的数字。第二它是一个正数，不可能是负数，第三，它可能最小是从130开始，最大到189，最后在检查的时候，我们要尽量使用白名单，而非黑名单机制。除了对输入进行检查之外，还需要对输出进行清理。做输出清理的理由有很多，比如一些内部的错误信息和异常会暴露内部的实现细节。外部的恶意用户根据这些暴露的内容就可以推测出内部的实现。我们做好输出的清理，黑客不知道这些信息，其实他要猜测数据库名是非常难的。再比如，在对付XSS漏洞的时候，对于不需要输出富文本的地方，只需要进行HTML编码转译，就可以避免xss的漏洞，这也是输出清理的另外一个例子。

有些防御策略实施简单，但是效果非常明显，这就是针对性的防御。

针对性的防御是指针对某种特殊的漏洞或者某种特殊的场景设计的。例如，浏览器中的cookie有一个http only的属性，这个属性被标记之后js脚本就无法读取cookie的值。那么xss就无法获取该cookie，虽然这种防御手段不能从根本上杜绝xss漏洞本身，但是能够在一定程度上缓解xss漏洞给我们带来的危害。在sql注入漏洞当中，我们推荐统一使用预编译语句，如java中的prepared statement来对SQL注入进行防御。这也是针对性防御的一种。

WAF是web应用安全防火墙的简称，是目前比较流行的web安全漏洞防御方法。很多乙方安全公司都提供了WAF服务。WAF的原理是对每一个web请求进行规则检查。从而匹配可能的web攻击，并且进行拦截。WAF好处是对于爆发的新漏洞，可以及时的打一个虚拟补丁，为后面的修复，争取上线的时间，同时waf的规则需要专业的维护，而且也可能会成为一个性能的瓶颈。所以，是否使用waf还需要根据业务场景进行综合的一个考量。

实现对任何外部的不可信输入进行一个检查，其次是对内部输出的各种进行一个综合的清理，再次是对某些特定类型的漏洞进行一些针对性的防御，最后是统一部署waf进行维护，这个成本相对较高。有条件的可以使用。除了积极的防御之外，安全漏洞的修复也是非常重要的一部分工作，这样才能避免被攻击者利用。漏洞修复需要一个强大的知识库进行支撑。对于各种漏洞的原理，防护方法都需要在知识库中体现。并且根据应用的特点和场景进行定制，安全团队对于漏洞不能只是粗暴的来一句，对用户的输入进行过滤就完事了，安全团队的价值就在于根据业务的不同而提供可落地的、可操作的解决方案，并且结合公司的开发情况、框架、语言等进行定制。

漏洞的修复有一个修复周期的概念，对于不同类型、不同危害程度的漏洞，需要定制不同的修复周期。比如严重漏洞，一般要求在24小时之内必须修复漏洞，漏洞修复时间这一块在企业内部和白帽子之间存在一些误会，白帽子往往仅仅从技术角度上去考虑一个漏洞，觉得修复一个漏洞，或者升级一下某个库是分分钟的事情，而在实际企业中，这个过程往往很复杂，比如进行升级的时候，需要评估升级可能带来的其他影响，而漏洞的攻防是跟时间的赛跑，所以在修复之前，安全团队需要密切关注漏洞的发展情况。

监控应用的安全，保证在修复期间内的安全性，通过waf打一个虚拟补丁，可以为后面的修复和升级争取很多的时间。

在技术团队对漏洞进行修复之后，安全团队还必须对漏洞的修复进行复查，保证漏洞修复的全面性和完整性。对于业务方和开发方而言，对安全的理解往往会有一些偏差，往往会对漏洞的修复采取头痛医头，脚痛医脚的方法，所以安全团队必须做好double check。并且充分和业务方、开发方进行一个沟通，才能保证修复的完整。

实现针对各种漏洞需要建立一个安全漏洞的知识库。这个知识库就像一个图书馆，对于新人可以学习，对于团队可以沉淀，对于工作可以参考；其次要对漏洞进行分级和分类处理，对不同危害程度的漏洞定制不同的修复周期，并且严格执行，必要时需要获得管理层的支持，安全团队在修复期间要保证应用的安全，最后安全团队要对修复方案的完整性和漏洞进行复查。保证修复是全面的

即使我们做到了上面的漏洞发现、漏洞处理，但根据墨菲定律，安全事件还是一定会发生的，这个是迟早的事情

事件处理

事件不等于漏洞，漏洞是一种客观存在，可能会被利用，也可能不会造成任何危害。而事件是已经发生的，并且对公司造成了一定危害的事实，当发生安全事件时，需要注意重大事件是否会引起一个公关危机，事件的处理要及时的归档，比如通过xss漏洞造成的蠕虫事件，事先需要切断源头，避免扩大范围。

要处理安全事件，就需要对安全事件进行分类。

1、入侵事件，例如通过命令注入的漏洞来入侵服务器
2、攻击事件，例如ddos攻击而导致服务不可用
3、信息泄露事件，用户的用户信息如用户名密码被泄露

安全事件分级

分级的目标主要是分清事件的轻重缓急。这里我们也给出了一个参考的分级标准，就是分成高中低三级，分级不宜太多，也不宜太少。最终还是要根据公司的自己情况来决定。

这里我们再说明一下一个事件的分级不是一成不变的，可能会随着时间和调查事态的发展进行升级或者降级。比如一个普通的入侵事件，在调查的过程当中发现，黑客已经通过一台普通的服务器渗透进内网，并且控制了财务系统，那么事件就必须得到升级。

建立一个安全事件应急响应流程也是非常重要的事情，这样每当发生安全事件的时候，安全团队就可以有章可循。可以按照既定的流程召集相关人员进行处理。

每当发生安全事件时，需要有一个事先确定的步骤，这个确认步骤需要有产品方、安全方，一起判定事件的真实性和分级，必要的时候还需要运维、公安、法务、人力等相关部门的介入。在对事件进行定性和分级之后，需要对事件进行一个上报的动作。这个动作非常的关键，处理安全事件可能需要很多资源的支持，只有获得了高层的支持，才能获得足够的资源来进行处理。根据事件的不同分级，会通知到不同级别的人员，比如普通的安全事件，可能需要通知到总监一级，但是重大的安全事件就需要通知到VP甚至是CEO。

在建立流程中非常重要的一部分是建立安全应急响应小组，并且确定相关人员的联系方式和后备人员。这样不至于在事件发生之后完全找不到人来处理。一般来说，至少需要产品方、安全方共同参与，并且指定相应的事件应急响应方案。对外需要配合公关法务提供产品数据支持和技术支持，同时对事件影响的服务器，数据资源等调用。灾备资源进行恢复，保留原来的受影响服务器数据和现场环境。事件处理过程需要详细的记录进行归档，针对导致事件的问题进行分析和列出可实施的改进方案和后续的动作。针对事件本身的处理遇到的问题和情况进行复盘，列出可实施的改进方案。

安全事件应急响应流程：事件确认、事件汇报、事件处理、归档和复盘，每个步骤都需要进行一系列的动作