俗话说，安全是“三分技术，七分管理”。安全对于企业来说，结果才是最重要的。安全方案设计完成后，即使看起来再美好，也需要经受实践的检验。在“我的安全世界观”一章中曾经提到，安全是一个持续的过程。而“安全运营”的目的，就是把这个“持续的过程”执行起来。健康的企业安全，需要依靠“安全运营”来保持新陈代谢，保持活力。
互联网公司如何规划自己的安全蓝图呢？从战略层面上来说，Aberdeen Group提到了三句话：Find and Fix，Defend and Defer，Secure at the Source。
一个安全评估的过程，就是一个“Find andFix”的过程。通过漏洞扫描、渗透测试、代码审计等方式，可以发现系统中已知的安全问题；然后再通过设计安全方案，实施安全方案，最终解决这些问题。
而像入侵检测系统、Web应用防火墙，反DDOS设备等则是一些防御性的工作，这也是保证安全必不可少的一个部分。它们能防范问题于未然，或者当安全事件发生后，快速地响应和处理问题。这些防御性的工作，是一个“Defend and De-fer”的过程。
最后“Secure at the Source”指的则是“安全开发流程（SDL）”，它能从源头降低安全风险，提高产品的安全质量。
这三者的关系是互补的，当SDL出现差错时，可以通过周期性的扫描、安全评估等工作将问题及时解决；而入侵检测、WAF等系统，则可以在安全事件发生后的第一时间进行响应，并有助于事后定损。如果三者只剩其一，都可能使得公司的安全体系出现短板，出现可乘之机。
安全运营贯穿在整个体系之中。安全运营需要让端口扫描、漏洞扫描、代码白盒扫描等发现问题的方式变成一种周期性的任务。
因为安全是一个持续的过程（在“我的安全世界观”一章中已经强调过这个观点），我们永远无法保证在下一刻网络管理员是否会因为工作疏忽而把SSH端口开放到Internet，或者是某个小项目又逃过了安全检查私自发布上线了。这些管理上的疏忽随时都有可能打破之前辛辛苦苦建立起来的安全防线。假设管理工作和流程是不可靠的，就需要通过安全运营不断地去发现问题，周期性地做安全健康检查，才能让我们放心。这个工作，则是安全运营需要做的“Find”的工作。“Fix”的工作分为两种：一种是例行的扫描任务发现了漏洞，需要及时修补；另一种则是在安全事件发生时，或者是0day漏洞被公布时，需要进行紧急响应。这些工作需要建立制度和流程，并有专门的人对此负责。
SDL的工作也可以看成是安全运营的一部分，但由于其与软件工程结合紧密，独立出来也无不可。
在安全运营的过程中，必然会与各种安全产品、安全工具打交道。有的安全产品是商业产品，有的则是开源工具，甚至安全团队还需要自主研发一些安全工具，这些安全产品都会产生大量的日志，这些日志对于安全运营来说是非常有价值的。通过事件之间的关联，可以全面地分析出企业的安全现状，并对未来的安全趋势做出一些预警，为决策提供参考意见。
将各种安全日志、安全事件关联起来的系统我们称之为SOC（Security Operation Center）。建立SOC可以算是安全运营的一个重要目标。
建立漏洞修补流程，是在“Fix”阶段要做的第一件事情。当公司规模不大时，沟通成本较低，可以通过口口相传的方式快速解决问题；但当公司规模大了以后，沟通成本随之上升，相应的漏洞修补速度会降低，而只靠沟通还可能会出现一些错漏，所以建立一个“漏洞修补流程”以保证漏洞修补的进度和质量是非常有必要的。
最常见的问题是漏洞报告给开发团队后，迟迟未能得到反馈，一拖再拖。这是因为安全漏洞对于开发团队的现有开发计划来说，是一种意外。但这种问题不难解决，因为开发团队一般都会建立bug管理的平台，比如bugtracker等，只需要将安全漏洞作为bug提交到bugtracker中，就会成为开发团队的一个例行修补bug的工作，会按照计划完成。目前许多大的开源项目也是如此处理安全漏洞的，在bug中会定义类型为security，同时还定义了bug的紧急程度。
一个bugtracker的截图
除此之外，常见的问题还有漏洞修补得不彻底，补丁发布后，被发现漏洞仍然可以利用，这种情况时有发生。通常造成此问题的原因是，补丁的实现方案与代码未经安全部门检查，有时候也有可能是处理问题的安全工程师未能理解漏洞的本质，因此导致修补方案存在缺陷。
因此在制定补丁的方案时，首先应该由安全工程师对漏洞进行分析，然后再和开发团队一起制定技术方案，并由安全工程师review补丁的代码，最后才能发布上线。
对于“安全运营”的工作来说，建立漏洞修补流程，意味着需要完成这几件事情：（A）建立类似bugtracker的漏洞跟踪机制，并为漏洞的紧急程度选择优先级；（B）建立漏洞分析机制，并与程序员一起制定修补方案，同时review补丁的代码实现；（C）对曾经出现的漏洞进行归档，并定期统计漏洞修补情况。
对存在过的漏洞进行归档，是公司安全经验的一种积累。历年来曾经出现过的漏洞，是公司成长的宝贵财富。对漏洞数量、漏洞类型、产生原因进行统计，也可以从全局的角度看到系统的短板在什么地方，为决策提供依据。
安全监控与报警，是“Defend and Defer”的一种有效手段。
对于互联网公司来说，由于其业务的高度连续性，所以监控网络、系统、应用的健康程度是一件非常重要的事情。监控能使公司在发生任何异常时第一时间就做出反应。下图为一个开源的监控系统Nagios。
其实网站的安全性也是需要监控的。安全监控的主要目的，是探测网站或网站的用户是否被攻击，是否发生了DDOS，从而可以做出反应。
安全监控与安全扫描又是什么关系呢？是否有了安全扫描就可以不用安全监控了呢？
理论上说，如果一切都是完美的，所有漏洞都可以通过扫描器发现的话，那么可以不需要安全监控。但现实是扫描器难以覆盖到所有漏洞，有时候由于扫描器规则或一些其他的问题，还可能导致漏报。因此安全监控是对网站安全的有力补充。安全监控就像是一双眼睛，能够时刻捕捉到发生的异常情况。
常见的安全监控产品有IDS（入侵检测系统）、IPS（入侵防御系统）、DDOS监控设备等。在IDS这个大家族中，Web应用防火墙（简称WAF）又是近年来兴起的一种产品。相对于传统的IDS来说，WAF专注于应用层攻击的检测和防御。
IDS、WAF等设备一般的布署方式是串联或并联在网络出口处，对网站的所有流量进行监控。在开源的软件中，也有一些优秀的IDS，比如Mod-Security就是一个非常成熟的WAF。
ModSecurity是Apache的一个Module，它能获取到所有访问Apache Httpd Server的请求，并根据自己的规则对这些请求进行匹配，以检测哪些请求存在攻击行为。ModSecurity的架构图
ModSecurity的规则几乎囊括了所有的Web攻击行为，其核心规则由社区的安全专家维护。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129…… SecRule REQUEST_COOKIES| REQUEST_COOKIES_NAMES|REQUEST_FILENAME| ARGS_NAMES|ARGS|XML:/* "\bonkeydown\b\W*?\=" \ "phase:2,rev:'2.2.2',capture,t:none,t:htmlEnt ityDecode,t:compressWhiteSpace,t:lo wercase,ctl:auditLogParts= +E,block,msg:'Cross-site Scripting (XSS) Attack',id:'958410',tag:'WEB_ATTACK/ XSS',tag:'WASCTC/WASC-8',tag:'WASCTC/ WASC-22',tag :'OWASP_TOP_10/A2',tag:'OWASP_AppSensor/ IE1',tag:'PCI/6.5.1',logdata:'%{TX.0}',severi ty:'2',setvar:'tx.msg= %{rule.msg}',setvar:tx.xss_score=+ %{tx.critical_anomaly_score}, setvar:tx.anomaly_score=+ %{tx.critical_anomaly_score},setvar:tx. %{rule.id}-WEB_ATTACK /XSS-%{matched_var_name}=%{tx.0}" SecRule REQUEST_COOKIES| REQUEST_COOKIES_NAMES|REQUEST_FILENAME| ARGS_NAMES|ARGS|XML:/* "\bonmousemove\b\W*?\=" \ "phase:2,rev:'2.2.2',capture,t:none,t:htmlEnt ityDecode,t:compressWhiteSpace,t:lo wercase,ctl:auditLogParts= +E,block,msg:'Cross-site Scripting (XSS) Attack',id:'958415',tag:'WEB_ATTACK/ XSS',tag:'WASCTC/WASC-8',tag:'WASCTC/ WASC-22',tag :'OWASP_TOP_10/A2',tag:'OWASP_AppSensor/ IE1',tag:'PCI/6.5.1',logdata:'%{TX.0}',severi ty:'2',setvar:'tx.msg= %{rule.msg}',setvar:tx.xss_score=+ %{tx.critical_anomaly_score}, setvar:tx.anomaly_score=+ %{tx.critical_anomaly_score},setvar:tx. %{rule.id}-WEB_ATTACK /XSS-%{matched_var_name}=%{tx.0}" SecRule REQUEST_COOKIES| REQUEST_COOKIES_NAMES|REQUEST_FILENAME| ARGS_NAMES|ARGS|XML:/* "\blivescript:" \ "phase:2,rev:'2.2.2',capture,t:none,t:htmlEnt ityDecode,t:compressWhiteSpace,t:lo wercase,ctl:auditLogParts= +E,block,msg:'Cross-site Scripting (XSS) Attack',id:'958022',tag:'WEB_ATTACK/ XSS',tag:'WASCTC/WASC-8',tag:'WASCTC/ WASC-22',tag :'OWASP_TOP_10/A2',tag:'OWASP_AppSensor/ IE1',tag:'PCI/6.5.1',logdata:'%{TX.0}',severi ty:'2',setvar:'tx.msg= %{rule.msg}',setvar:tx.xss_score=+ %{tx.critical_anomaly_score}, setvar:tx.anomaly_score=+ %{tx.critical_anomaly_score},setvar:tx. %{rule.id}-WEB_ATTACK /XSS-%{matched_var_name}=%{tx.0}" ……
另一个同样著名的开源WAF是PHPIDS。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31PHPIDS是为PHP应用设计的一套入侵检测系统，它与应用代码的结合更为紧密，需要修改应用代码才能使用它。通过如下方式可以加载PH-PIDS。 require_once 'IDS/Init.php'; $request = array( 'REQUEST' => $_REQUEST, 'GET' => $_GET, 'POST' => $_POST, 'COOKIE' => $_COOKIE ); $init = IDS_Init::init('IDS/Config/ Config.ini'); $ids = new IDS_Monitor($request, $init); $result = $ids->run(); if (!$result->isEmpty()) { // Take a look at the result object echo $result; }
PHPIDS的规则也非常完整，它是以正则的方式写在XML文件中的，比如以下规则：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93…… <filter> <id>15</id> <rule><![CDATA[([^*:\s\w,.\/?+-]\s*)?(?<![a- z]\s)(?<![a-z\/_@\-\|])(\s*return\s*)?(?: create(?:element|attribute|textnode)|[a- z]+events?|setattribute|getelement\w+|appendc hild|createrange|createcontextualfragment| removenode|parentnode|decodeuricomponent|\w ettimeout|option|useragent)(?(1)[^\w%"]|(?: \s*[^@\s\w%",.+\-]))]]></rule> <description>Detects JavaScript DOM/ miscellaneous properties and methods</description> <tags> <tag>xss</tag> <tag>csrf</tag> <tag>id</tag> <tag>rfe</tag> </tags> <impact>6</impact> </filter> <filter> <id>16</id> <rule><![CDATA[([^*\s\w,.\/?+-]\s*)?(?<![a- mo-z]\s)(?<![a-z\/_@])(\s*return\s*)?(?:al ert|inputbox|showmodaldialog|showhelp| infinity|isnan|isnull|iterator|msgbox| executegl obal|expression|prompt|write(?:ln)?|confirm| dialog|urn|(?:un)?eval|exec|execscript|to string|status|execute|window|unescape| navigate|jquery|getscript|extend|prototype)(? (1 )[^\w%"]|(?:\s*[^@\s\w%",.:\/+\-]))]]></rule> <description>Detects possible includes and typical script methods</ description> <tags> <tag>xss</tag> <tag>csrf</tag> <tag>id</tag> <tag>rfe</tag> </tags> <impact>5</impact> </filter> ……
但是在实际使用IDS产品时，需要根据具体情况调整规则，避免误报。规则的优化是一个相对较长的过程，需要经过实践的检验。因此IDS在很多时候仅仅是报警，而不会由程序直接处理报告的攻击。人工处理报警，会带来运营成本的提升。
除了部署入侵检测产品外，在应用中也可以实现代码级的安全监控功能。比如在实施CSRF方案时，采取的办法是对比用户提交表单中的token与当前用户Session中的token是否一致。当比对失败时，可以由应用记录下当前请求的IP地址、时间、URL、用户名等相关信息。这些安全日志汇总后，可以酌情发出安全警报。
在应用代码中输出安全日志，需要执行IO的写操作，对性能会有一些影响。在设计方案时，要考虑到这种写日志的动作是否会频繁发生。在正常情况下，应用也会频繁地执行写日志的动作，那么这个日志并不适合启用。安全日志也属于机密信息，应该实时地保存到远程服务器。
正如前文所述，安全监控的目的是为了在最快的时间内做出反应，因此报警机制必不可少。
入侵检测系统或其他安全监控产品的规则被触发时，根据攻击的严重程度，最终会产生“事件”（Event）或“报警”（Alert），报警是一种主动通知管理员的提醒方式。
常见的报警方式有三种。
（1）邮件报警
这是成本最低的报警方式，建立一个SMTP服务器就可以发送报警邮件。当一个监控到的事件发生时，可以调用邮件API发出邮件报警。但是邮件报警的实时性较差，邮件从发出到接收到存在一定的时间差，且邮件服务器可能会被队列堵塞，导致邮件延时或者丢邮件。
但邮件报警的好处是，报警内容可以描写得丰富翔实。
（2）IM报警
通过调用一些IM的API，可以实现IM报警。如果公司没有自己的IM软件，也可以采用一些开源的IM。IM报警相对邮件报警来说实时性要好一些，但IM报警的内容长度有限，难以像邮件报警的内容一样丰富。
（3）短信报警
随着手机的普及，短信报警也成为越来越重要的一种报警方式。短信报警需要架设短信网关，或者采用互联网上提供的一些短信发送服务。
短信报警的实时性最好，无论管理员在何时何地都能收到报警。但短信报警的局限之处是单条短信能容纳的内容较少，因此短信报警内容一般都短小精悍。
监控与报警都建立后，就可以开始着手制定“紧急响应流程”了。紧急响应流程是在发生紧急安全事件时，需要启动的一个用于快速处理事件的流程。很多时候由于缺乏紧急响应流程，或者紧急响应流程执行不到位，使得一些本来可以快速平息的安全事件，最终造成巨大的损失。
建立紧急响应流程，首先要建立“紧急响应小组”，这个小组全权负责对紧急安全事件的处理、资源协调工作。小组成员需要包括：
技术负责人
产品负责人
最了解技术架构的资深开发工程师
资深网络工程师
资深系统运维工程师
资深DBA
资深安全专家
监控工程师
公司公关
这个小组的主要工作是在第一时间弄清楚问题产生的原因，并协调相关的资源进行处理。因此小组的成员可能随时扩大。
小组成员中包含公司公关，是因为遇到一些影响较大的安全事件时，需要公关发对外的新闻稿。由于公关一般不太了解技术，因此公司公关对外发的新闻稿需要参考安全专家的意见，以免出现言辞不当的情况。
当安全事件发生时，首先应该通知到安全专家，并由安全专家召集紧急响应小组，处理相关问题。在处理安全问题时，有两个需要注意的地方。
一是需要保护安全事件的现场。从以往的经验看，很多时候由于缺乏安全专家的指导，安全事件的现场往往被工程师破坏，这对后续分析入侵行为以及定损带来了困难。
当入侵事件发生时，首先不要慌张，应该先弄清楚入侵者的所有行为都有哪些，然后评估入侵事件所造成的损失。比较合理的做法是先将被入侵的机器下线，在线下进行分析。
二是以最快的速度处理完问题。紧急响应流程启动后，就是与时间争分夺秒，因此务必在最短的时间内找到对应的人，并制定出相应的计划，很多流程能省则省。这也是为何需要让技术负责人、产品负责人，以及各个领域的资深工程师加入的原因。紧急响应小组的成员，一定要是最了解公司业务和架构的人，这样才能快速定位和解决问题。
紧急响应流程建立以后，可以适当地进行一两次演习，以保证流程的有效性。这些，都是安全运营需要做的工作。
本章介绍了安全运营的一些方法。
公司安全的发展蓝图可以分为“Find andFix”、“Defend and Defer”、“Secure at the Source”三个方向，每一个方向的最终结果都需要由“安全运营”来保证。
安全运营实施的好坏，将决定公司安全是否能健康地发展。只有把安全运营起来，在变化中对抗攻击，才能真正让安全成为一个持续的过程，才能走在正确的道路上。
讨论范围限定在互联网公司，是为了避免和一些安全公司打口水战。我一向认为互联网公司的安全做到极致后，是不太需要购买安全软件或解决方案的，因为一个大的互联网公司发展到一定程度后，其规模和复杂程度决定了世界上没有哪一家安全公司能够提供这样的解决方案，一切都得自力更生。当然这句话也不是绝对的，一些非关键领域或者基础安全领域还是需要安全厂商的支持，比如防火墙设备、桌面安全设备、防DDOS设备等。
但我今天要说的是互联网公司安全的方向。我的命题是：我们今天做了什么，做得够不够，接下来我们还需要做些什么？
在过去的很长时间内，无论是漏洞挖掘者还是安全专家们，都在致力于研究各种各样的漏洞，以此为代表的是OWASP每隔几年就会公布的Top10威胁List。所以在很长一段时间内，互联网公司的安全专家们，包括安全厂商的产品专家们，都在致力于做一件事情：不管是产品还是方案，尽可能地消灭这些漏洞。
因此，我把互联网公司安全的第一个目标，定义为：让工程师写出的每一行代码都是安全的！
这第一个目标应该理解为互联网公司的产品安全。一个以产品（包括网站、在线服务等，在互联网公司里在线服务也被称为产品）驱动的公司，要做安全，第一件事情必然是要保证核心业务的健康发展。为了达到这个目标，微软有了SDL，基于对软件工程的改造，SDL可以帮助工程师编写出安全的代码。微软的SDL达成了“让微软的工程师写出的大部分代码都是安全的”这一目标。所以我认为SDL是伟大的创造，它在无限接近终极目标。
在这个SDL中，我们就有很多东西需要去完善，也促进了相当多的衍生技术研究和技术产品。比如代码安全扫描工具的研究，仅此一项，就涉及语法分析、词法分析、数据关联、统计学等诸多问题；再比如fuzzing，则涉及各类协议或文件格式、统计学、数据处理、调试与回溯、可重用的测试环境建设等诸多复杂问题。把每一项做精，都不是件容易的事情。
所以SDL是一项需要长期坚持和不断完善的工作。但是光有这个还无法100%保证不会出现安全问题，于是我定义了互联网公司安全的第二个目标：让所有已知的、未知的攻击，都能在第一时间发现，并迅速报警和追踪。
这第二个目标也挺宏伟的，涉及许多IDS、IPS、蜜罐方面的研究，但光有现有的这些技术，还是远远无法完成这个目标的，因为现在已有的商业的、开源的IDS及IPS都存在着种种局限性，而互联网公司的海量数据和复杂需求，也对这些现有产品提出了严峻的挑战。只有借助大规模超强的计算能力，实施有效的数据挖掘和数据关联工作，或者建立更加立体化的模型，才能逐渐逼近这一目标。
这个目标也是需要无限逼近去完成的一个宏伟目标。我目前在公司做的部分事情，就是在向着这个目标努力，所以无法在这里详谈、深谈。
光前面两个目标，就不知道需要投入多少人力、时间来努力，但我还有点不满足，所以我定义了第三个目标：让安全成为公司的核心竞争力，深入到每一个产品的特性中，能够更好地引导用户使用互联网的习惯。
在一开始，我们使用电脑时，是不需要安装任何杀毒软件的。但是到了今天，如果一个普通用户新买了电脑，却没有安装任何的杀毒软件或者桌面保护软件，那么大家都会担心他会不会中病毒或木马。这种需求和市场，就完全是病毒和杀毒软件厂商培养和熏陶出来的。所以在今天，很多电脑生产商甚至在电脑出厂时就会预装一个杀毒软件。
前两天我去超市，看到乐事的薯片捆绑销售一盒小的番茄酱。我马上想到了肯德基和麦当劳，我不知道在它们之前是否还有别的速食品是把薯条和番茄酱配在一起销售的，但是我认为肯德基和麦当劳改变了人们吃薯条的习惯：是要蘸着番茄酱吃的。所以乐事的薯片捆绑销售番茄酱，也可以看做是被肯德基做出来的需求和市场。
所以，我认为做互联网公司安全需要达成的一个目标是让安全成为深深植入产品骨髓的一个功能和特性，引导用户使用互联网的习惯，把这个需求和市场做出来。这更是一件需要长期投入和坚持的事情。
我还有最后一个目标：能够观测到整个互联网安全趋势的变化，对未来一段时间内的风险做出预警。
这个预警的目标也是我们部门当初草创时的目标之一，我至今还没有很好的头绪来想这些问题。但是这个目标反而是今天列举的这些目标中最容易达到的一个，因为已经有公司在做了，而且比较成功。比如McAfee和赛门铁克每隔一段时间都会有互联网威胁报告，国外一些组织比如SANS等也有类似的报告。腾讯这几年一直在做挂马检测方面的工作，所以他们也能在一定程度上预警挂马方面的趋势。
由于有前人的榜样，再借助大规模的客户端或者是强力搜索引擎的海量数据，要做这件事情的路线和方法还是非常清晰的，只是要想做好，还得花上很多的时间和精力。
安全技术一直是依附于技术发展的，不光是技术发展开辟了新的需要安全的领域，技术发展也能给安全技术带来更多的想象空间。
比如10年前，甚至是5年前，可能我们都不需要去想手机是否需要安全这件事情。但是在今天，手机安全已经成为刻不容缓的一个战场，比如前两天报道的在澳洲传播的iPhone蠕虫，这些已经是实实在在的威胁。
而手机安全反过来也促进了一些新的安全技术，比如手机认证能够起到与客户端证书类似的作用，甚至比客户端证书更进一步，因为手机不是装在电脑上的，而是放在用户的裤兜里的。类似的还有随着计算能力的提升，已经能够处理更大规模的数据，从而使得安全分析会有一些新的发展和变化，这些都是在过去不敢想象的。
在互联网公司做安全一定要有想象力，同时需要紧密关注其他技术领域的发展，这样就不会止步于几种漏洞的研究，而会发现有非常多的有趣的事情正等着去做，这是一个非常宏伟的蓝图。
Copyright ©2010-2022 比特日记 All Rights Reserved.