编者按:
第一部分 安全架构
第一章 企业信息安全建设简介
企业信息安全越来越受到关注,但企业信息安全的本质和原则是什么?该怎么做?趋势如何?我们从更接近实战的角度进行探讨。
1.1 安全的本质
在企业做信息安全会遇到很多困惑,企业信息安全到底应该怎么做?管理、技术、流程和人员哪个更重要?安全团队和安全人才该怎么建设、培养和激励?笔者带着这些问题。
与各种安全圈内各种安全人士交流过,笔者发现长期以来一直困扰的问题与信息安全的本质有关,或者说,需要了解信息安全问题的本质是什么?
互联网本来是安全的,自从有了“研究安全”的人,就变得不安全了。比如SQL注入攻击, 自从1999年首次出现后就成为互联网应用安全的头号大敌,SQL注入攻击的本质是把用户输入的数据当作代码执行,而开发人员设计用户输入的功能时,本意只是提供一个用户交互功能,根据用户的输入返回动态页面结果,以便提供更好的用户体验。这个好的出发点,很不幸被恶意的人滥用了。再比如,钓鱼网站目前已成为很多金融企业的首要安全威胁,而在2011年以前,很多金融企业的安全人员甚至都没有考虑过这个问题。时至今日,他们仍会觉得很无辜,因为企业的网站并没有任何安全漏洞,是钓鱼网站的“狡猾”和用户的“傻”,才让攻击者有机可乘。
1.2 安全原则
1.3 安全世界观
对于信息安全人员来说,最重要的是建立“安全世界观”,即解决安全问题的思路,以及看待安全问题的角度和高度,而不是具体掌握了多少漏洞,拿下了多少权限,或者发现了多少风险。不同的企业、不同的安全人员,一定会有不同的安全世界观。笔者的安全世界观是:信息安全就是博弈和对抗,是一场人与人之间的战争。交战双方所争夺的是对信息资产的控制权,谁能够在博弈和对抗中牢牢地把控住各类信息资产的控制权,谁就取得了胜利。
1.4 正确处理几个关系
企业信息安全建设过程中,需要正确处理以下几种关系:
科学与技术
科学讲究严谨,艺术讲究美感。安全既是一门科学,也是一门艺术。
安全的科学性,体现在无论是安全体系还是具体安全措施,其落地都是严谨和严肃的。在企业安全建设中,有的开发和运维同事觉得在内网就安全了,已经拒敌于门外了,从而放松了安全要求,但实际中攻击者通过一些边缘攻击进入内网,从而进一步渗透入内部服务器的案例比比皆是。因此必须全面、整体、综合性地考虑安全,并且认真、踏实、谨慎地落地实施。
安全的艺术性,体现在安全工作的权变,不是所有情况都适用同样的安全要求,需要不断地权衡利弊,选择当前情况下的最优。比如,服务器安全基线根据所处安全域的不同有不同的基线标准,漏洞跟踪处理时,安全部门通过补偿措施降低风险,从而允许一些业务系统带病上线,这都是权变的体现。
管理与技术
安全管理与安全技术孰轻孰重?有的企业拼命搞ISO27001安全体系,发布各种安全制度政策,实施各种安全流程控制,做各种安全审计和检查,搞得民怨沸腾,往往效果也不好。从事漏洞挖掘和攻防的人会觉得搞安全管理的人太虚,这也不会,那也不会,每天就是搞体系制度流程,能挡住我一个0day吗?会挖洞和写PoC吗?反过来,安全管理的人会觉得漏洞挖掘和攻防都是具体的工作,没有良好的组织架构、制度流程、意识培训等安全治理体系,“人”这个最重要的要素,可能会让所有的安全技术防范措施形同虚设,甚至毁于一旦。
其实,安全管理和安全技术更像是灯芯与灯油的关系,谁也离不开谁。管理和技术,必须“两手抓、两手都要硬”。
首先,从安全管理的角度看,安全政策和流程如果没有技术和自动化手段保障,无法有效落地,而脱离安全技术的安全政策和流程也有可能失效,例如,管理10台和10000台服务器,用同样的安全政策和流程肯定是行不通的。
其次,从安全技术的角度看,没有管理的辅助,可能会变成“为了技术而技术”的“自嗨”,例如,在企业安全建设中,困难不在技术上,至少技术不是最重要的点,而是需要不断地去说服并影响开发运维和业务部门的同事,如果技术人员能跳出技术思维,站在更高层面去思考安全问题解决方案,安全人员的境界就提高了好几层。
业务与安全
这个话题非常有意思。刚工作时,我认为安全是为业务服务的,但安全会一定程度地阻碍业务发展。随着认识加深,我的认知发生了一些变化—安全是为业务服务的,安全更是业务的属性之一,不安全或没有安全考虑的业务就像不合格的产品一样,终究是要被市场淘汰的。
本质上,安全是一项服务,安全服务是安全团队提供给用户和客户的一种服务类别。如果在设计安全方案和安全要求时没有最大化这种服务的价值,那么在充分竞争的情况下,安全团队也是要被市场淘汰的。我经常问自己和团队,如果公司不是只有我们一支安全团队,我们安全团队在公司范围内不是垄断的,而是其他安全团队也提供安全服务,在共同竞争的情况下,我们提供的安全服务还能被用户认可买单吗?只要答案为“否”,就说明安全团队还有提升的空间。
传统观念认为,安全总是这也不能做、那也要控制,安全就是拖业务的后腿,安全总是降低业务发展效率,在企业中安全往往也被做成了这个样子。造成这种现状,企业安全主管首先要反思。这是因为安全团队设计安全方案和要求时,不是以业务和服务为出发点,而是以安全团队省时省事、尽量少承担责任为出发点。后者设计出的安全方案当然是阻碍业务发展、降低效率。但如果一套安全方案和要求,能够在降低甚至不降低业务发展的情况下还能保障安全,业务团队和开发运维当然是欢迎的,毕竟谁都不愿意冒着巨大的风险强行上线新的业务。
如果安全团队能和业务、开发运维一起剖析,站在对方立场设计方案和执行要求,用户从心里一定是会认可安全团队和安全服务的。很多企业的实践证明,坚持安全服务的做法,会让安全团队之路走得更为顺畅。
甲方与乙方
乙方是指给企业(甲方)提供安全产品和服务的一方,包括安全产品原厂、代理商、集成商和外包公司等。甲方和乙方的关系也可理解为灯芯和灯油的关系,谁离开谁都会失败。有好的灯芯和灯油,也会有差的灯芯和灯油,关键在于各守本分,各尽其责。
企业中较为常见的场景是,乙方老板说,贵公司是我们的大客户,我们一定会服务好。乙方销售则在旁边配合,我们的产品和服务是最好的,用我们的绝对不会有问题。但一旦甲方稍微追问一句,贵公司打算怎么服务好我们?你们的产品和服务相比竞争对手好在哪里?你们了解我们的实际问题和需求吗?基本上90%的乙方就接不上话了。更有甚者,个别老板和销售的回答令人啼笑皆非,我们的产品和服务就是最好的,不用你们会后悔的。有风度的甲方此时往往还需要心情平静地答复,你们的产品和服务我都了解了,挺不错的,希望有机会合作。但内心简直是崩溃的。
另一方面,也听到较多的乙方抱怨甲方,主管啥也不懂,就知道不能出事,出事背锅;安全人员啥也不会,只知道指挥我们干活,把我们工程师不当人用。乙方眼里90%的甲方都是这个印象。
笔者无意为任何一方辩护,包括作为甲方的自己。因为甲乙双方都是站在自己的立场处理问题,无可厚非。但甲方和乙方都需要检讨:
甲方,应该对自己承担的职责负责,不管用什么方法,结果是必须搞定安全问题,但要能识别什么是能搞定的方案,以及哪些是方案中靠谱一员的乙方。和乙方的关系挺简单,如果乙方能为甲方创造安全价值,那给乙方匹配等量的安全回报,继续长期合作;否则对不起,多听一秒都是浪费生命。
乙方,应该是对自己的承诺负责,要了解你的客户,不是签单成功就万事大吉。合同落地才是刚刚开始,在甲方的辨识能力和社会口碑传播效应越来越强的今天,做一锤子买卖只能让自己的路越走越窄。谁都不傻,不是吗?
1.5 安全趋势
未来已来,如果只着眼于当下的安全,很可能疲于奔命,被超越或抛弃。因此,必须看到安全的趋势方能提早布局,确保立于不败之地。
安全度量
安全度量是指如何衡量企业安全的效果。做安全的人遇到的最大挑战就是讲不清楚安全的价值。安全这个东西很微妙,不像业务可以用销售额和用户数来衡量,也不像运维可以用可用性指标(比如故障数)来衡量,也不像研发可以用bug数、项目完成率、扩展性、专利等来衡量。安全往往是事件性的,很可能你什么都不做,但一年都不出问题;也可能你花了很大力气,花了很多钱,却还是问题频出。所以我们很难用单一的事件性指标来衡量数据安全做得好还是不好。
企业做安全,最终还是要对结果负责,对于安全效果,有两个最关键的核心指标:一个是漏洞数,一个是安全事件数。这两个关键安全指标,却没有一个安全厂商愿意承诺,他们通常都只愿意承诺卖出设备的功能效果,或者服务的响应时间。由于漏洞数涉及企业发现能力,每年第三方漏洞报告平台(如补天或CNCERT)上,漏洞数量排前十的大多是互联网公司,但不能因此认为互联网公司安全能力靠后,相反,由于互联网公司面临安全威胁且自身发现能力(各种SRC虽然是白帽提交的安全漏洞,但可以理解为自身发现能力提高导致)较强,所以发现的漏洞数量靠前。很多没有爆出安全漏洞的企业不是因为做得有多好,而是自身发现能力不够。
在这种情况下,有必要把漏洞数分成两类:一类是通过众测与SRC获得的外部上报漏洞数量,一类是通过自身安全防护和检测发现的安全漏洞数量。某些金融机构已引入专业的蓝军团队进行攻防,检测红军安全防护和安全检测能力,将是未来安全度量的发展趋势。
安全事件数的情况和漏洞数大体相同,不同点是,安全事件数没有第三方报告平台,数据主要来自于监管通报等被动暴露以及主动发现,数据统计要更难一些。
历史问题免疫
运维管理目前事实上的标准是ISO20000服务管理体系,这套体系也称为ITIL运维流程管理,ITIL众多流程中有个核心流程—问题管理。问题管理有个有意思的做法,通过问题管理的思维模式,对企业所有曾经出现过的历史故障进行举一反三的持续改进,从而实现对历史故障免疫。
既然安全性要当作可用性来运维,那么安全管理也应该能做到对历史问题免疫,而这也应该成为安全未来趋势之一。笔者理解历史问题免疫有两个含义:一是对企业曾经出过的安全漏洞和安全事件做举一反三的彻底整改,从人、技术、流程、资源四个维度分析问题产生根源,查找差距,并建立机制进行防护,从而根本上解决已出现的安全问题,实现历史安全问题免疫。二是对已部署的安全措施的有效性做100%确认,比如已经部署了防病毒客户端,那么就一定要关注防病毒客户端安装率、正常率两个指标,这两个指标能做到99.99%的应该算执行力和安全有效性不错的企业了。类似的指标也同样应该在已部署的安全措施中得到确认。严格来说,历史问题免疫这一点其实不能算安全趋势,而应该是常识,在各种安全概念层出不穷的今天,希望越来越多的甲乙方能回归常识。
安全成为属性
越来越多的企业重视信息安全,这种重视可能是主动的,但仍然被动居多。不管怎样,今天的安全人员面对的安全环境越来越恶化,但得到的资源和支持却比任何时候都多,这一点体现在:安全将成为各类系统甚至人才的关键属性之一。举个例子,十年前,很少看到系统需求阶段就会有安全需求,测试阶段有安全测试,开发人员需要接受专业的安全编码开发规范培训。十年后,这些都很常见了,甚至是标配(默认)。对安全知识和技能的掌握也从单纯安全人员必备变成了开发人员的必备技能,实际上,安全意识和安全开发能力较强的开发人员,薪酬水平和发展空间已高于技能单一的程序员。程序员在用代码改变世界的同时,也有义务更好地保护世界。安全将成为越来越多的需求品,成为非专业安全人员的一种标配属性,这将是安全发展趋势之一。
安全人才缺口增大
1.6 小结
理事服务 | 会员服务
请联系:13810321968(微信同号)
商务合作 | 开白转载 | 媒体交流 | 文章投稿
请联系:13810321968(微信同号)
原文始发于微信公众号(关键信息基础设施安全保护联盟):精彩连载!企业安全建设指南——安全架构(一)
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论