带你读《企业安全建设指南:金融行业安全架构与技术实践》之一:企业信息安全建设简介

简介: 本书全面、系统地介绍企业信息安全的技术架构与实践,总结了作者在金融行业多年的信息安全实践经验,内容丰富,实践性强。第一部分“安全架构”主要内容:信息安全观、金融行业信息安全的特点、安全规划、内控合规管理、信息安全团队建设、安全培训规划、外包安全管理、安全考核、安全认证等。第二部分“安全技术实战”主要内容:互联网应用安全、移动应用安全、企业内网安全、数据安全、业务安全、邮件安全、活动目录安全、安全检测、安全运营、SOC、安全资产管理和矩阵式监控、信息安全趋势和安全从业者的未来等。

网络空间安全技术丛书
点击查看第二章
点击查看第三章
企业安全建设指南:金融行业安全架构与技术实践

image.png


聂 君 李 燕 何扬军 编著

第1章

企业信息安全建设简介
企业信息安全越来越受到关注,但企业信息安全的本质和原则是什么?该怎么做?趋势如何?我们从更接近实战的角度进行探讨。

1.1 安全的本质

在企业做信息安全会遇到很多困惑,企业信息安全到底应该怎么做?管理、技术、流程和人员哪个更重要?安全团队和安全人才该怎么建设、培养和激励?笔者带着这些问题。
与各种安全圈内各种安全人士交流过,笔者发现长期以来一直困扰的问题与信息安全的本质有关,或者说,需要了解信息安全问题的本质是什么?
互联网本来是安全的,自从有了“研究安全”的人,就变得不安全了。比如SQL注入攻击,自从1999年首次出现后就成为互联网应用安全的头号大敌,SQL注入攻击的本质是把用户输入的数据当作代码执行,而开发人员设计用户输入的功能时,本意只是提供一个用户交互功能,根据用户的输入返回动态页面结果,以便提供更好的用户体验。这个好的出发点,很不幸被恶意的人滥用了。再比如,钓鱼网站目前已成为很多金融企业的首要安全威胁,而在2011年以前,很多金融企业的安全人员甚至都没有考虑过这个问题。时至今日,他们仍会觉得很无辜,因为企业的网站并没有任何安全漏洞,是钓鱼网站的“狡猾”和用户的“傻”,才让攻击者有机可乘。
上面两个例子中,开发人员信任用户输入,用户信任钓鱼网站,从而导致信息安全问题。所以说,信息安全问题的本质是“信任”。计算机用0和1定义整个世界,而企业的信息安全目标是解决0和1之间的广大灰度数据,运用各种措施,将灰度数据识别为0(不值得信任)或1(值得信任)。信任是信息安全问题的本源。比如,某些普通企业设计信息安全方案时,会假设安全人员、开发人员、运维人员是默认被信任的;比普通企业安全要求更高的金融企业、国家机构等设计信息安全方案时,安全人员、开发人员、运维人员可能就是默认不被信任的。不同的信任假设决定了安全方案的复杂程度和实施成本,安全需要找到某个自己可以接受的“信任点”,并在这个点上取得成本和效益的平衡。

1.2 安全原则

对于信息安全工作目标和实现方案,每个企业可以根据自己的实际情况做出选择,可谓各有千秋,但有些普适性的基本原则是相通的。概括而言,信息安全原则主要有三点:持续改进、纵深防御和非对称。
1.持续改进
有没有办法确保一台服务器不被不明武装分子攻陷?有没有一个类似“照妖镜”的工具,一旦安装上就可以高枕无忧,让恶意的攻击者无所遁形?有没有一个万能的“上帝之手”,帮我们干掉所有安全问题?很遗憾,以上“神器”都不存在。
在解决安全问题的过程中,不可能一劳永逸。很多安全厂商在推销自己的安全产品时,吹得天花乱坠,似乎无所不能,从早期的防火墙、防病毒、入侵检测,到现在的态势感知、威胁情报、智能分析,安全防御技术本身并没有革命性的变化。一套入侵检测技术包装个名词,就能摇身一变从IDS到IPS、SIEM,再到现在的威胁情报,但本质上,都还是开发检测规则,进行异常模式识别。安全产品、安全技术不能光靠名词的改变来实现转型升级,而是需要不断地随着攻击手段的发展而升级,也需要有人来运营,否则安全就是稻草人,在变化的攻击手段前不堪一击。
因此,持续改进,PDCA(plan,do,check,act)循环,螺旋式上升,是信息安全的第一个原则。
2.纵深防御
在典型的入侵案例场景中,攻击者利用Web应用漏洞,获得低权限WebShell,然后通过低权限的WebShell上传更多文件,并尝试执行更高权限的系统命令,进一步在服务器上提权,再横向渗透,获得更多内网权限。在这个典型的攻击路径中,如果在任何一个环节设置有效的安全检测和防御措施,攻击都可能被检测和阻止。
因此,在安全防护技术没有革命性发展的当下,企业必须坚持纵深防御原则,从网络层、虚拟层、系统层、应用层,到数据层、用户层、业务层、总控层,进行层层防御,共同组成整个防御体系。这是信息安全的第二个原则。
3.非对称
对于攻击者来说,只要能够找到企业系统的一个弱点,就可以达到入侵系统的目的,而对于企业信息安全人员来说,必须找到系统的所有弱点,不能有遗漏,不能有滞后,才能保证系统不会出现问题。这种非对称性导致攻击者和安全人员的思维方式不同,也是企业信息安全工作难做的根本原因,因为破坏比建设要容易。战争中发明的各种反舰、巡航导弹、潜艇属于非对称作战武器。
该怎么扭转这种劣势呢?答案就是,安全防护人员也需要非对称思维。
那么,在信息安全领域,应该发展哪些非对称的安全防护“武器”呢?在这种情境下,各种“蜜”的产品应运而生了,蜜网站、蜜域名、蜜数据库、蜜表、蜜字段、蜜数据、蜜文件……如果企业在面对攻击时进行安全反制,恶意攻击者就很难全身而退。据我所知,很多企业已经进行了商业化大规模部署,并在实际对抗中取得不错的效果,这应该是未来安全防护发展的一个有益方向。
认识到非对称,并找到解决非对称问题的方法,这是信息安全的第三个原则。

1.3 安全世界观

对于信息安全人员来说,最重要的是建立“安全世界观”,即解决安全问题的思路,以及看待安全问题的角度和高度,而不是具体掌握了多少漏洞,拿下了多少权限,或者发现了多少风险。不同的企业、不同的安全人员,一定会有不同的安全世界观。笔者的安全世界观是:信息安全就是博弈和对抗,是一场人与人之间的战争。交战双方所争夺的是对信息资产的控制权,谁能够在博弈和对抗中牢牢地把控住各类信息资产的控制权,谁就取得了胜利。

1.4 正确处理几个关系

企业信息安全建设过程中,需要正确处理以下几种关系:
□科学与技术
□管理与技术
□业务与安全
□甲方和乙方
1.科学与技术
科学讲究严谨,艺术讲究美感。安全既是一门科学,也是一门艺术。
安全的科学性,体现在无论是安全体系还是具体安全措施,其落地都是严谨和严肃的。在企业安全建设中,有的开发和运维同事觉得在内网就安全了,已经拒敌于门外了,从而放松了安全要求,但实际中攻击者通过一些边缘攻击进入内网,从而进一步渗透入内部服务器的案例比比皆是。因此必须全面、整体、综合性地考虑安全,并且认真、踏实、谨慎地落地实施。
安全的艺术性,体现在安全工作的权变,不是所有情况都适用同样的安全要求,需要不断地权衡利弊,选择当前情况下的最优。比如,服务器安全基线根据所处安全域的不同有不同的基线标准,漏洞跟踪处理时,安全部门通过补偿措施降低风险,从而允许一些业务系统带病上线,这都是权变的体现。
2.管理与技术
安全管理与安全技术孰轻孰重?有的企业拼命搞ISO27001安全体系,发布各种安全制度政策,实施各种安全流程控制,做各种安全审计和检查,搞得民怨沸腾,往往效果也不好。从事漏洞挖掘和攻防的人会觉得搞安全管理的人太虚,这也不会,那也不会,每天就是搞体系制度流程,能挡住我一个0day吗?会挖洞和写PoC吗?反过来,安全管理的人会觉得漏洞挖掘和攻防都是具体的工作,没有良好的组织架构、制度流程、意识培训等安全治理体系,“人”这个最重要的要素,可能会让所有的安全技术防范措施形同虚设,甚至毁于一旦。
其实,安全管理和安全技术更像是灯芯与灯油的关系,谁也离不开谁。管理和技术,必须“两手抓、两手都要硬”。
首先,从安全管理的角度看,安全政策和流程如果没有技术和自动化手段保障,无法有效落地,而脱离安全技术的安全政策和流程也有可能失效,例如,管理10台和10 000台服务器,用同样的安全政策和流程肯定是行不通的。
其次,从安全技术的角度看,没有管理的辅助,可能会变成“为了技术而技术”的“自嗨”,例如,在企业安全建设中,困难不在技术上,至少技术不是最重要的点,而是需要不断地去说服并影响开发运维和业务部门的同事,如果技术人员能跳出技术思维,站在更高层面去思考安全问题解决方案,安全人员的境界就提高了好几层。
3.业务与安全
这个话题非常有意思。刚工作时,我认为安全是为业务服务的,但安全会一定程度地阻碍业务发展。随着认识加深,我的认知发生了一些变化—安全是为业务服务的,安全更是业务的属性之一,不安全或没有安全考虑的业务就像不合格的产品一样,终究是要被市场淘汰的。
本质上,安全是一项服务,安全服务是安全团队提供给用户和客户的一种服务类别。如果在设计安全方案和安全要求时没有最大化这种服务的价值,那么在充分竞争的情况下,安全团队也是要被市场淘汰的。我经常问自己和团队,如果公司不是只有我们一支安全团队,我们安全团队在公司范围内不是垄断的,而是其他安全团队也提供安全服务,在共同竞争的情况下,我们提供的安全服务还能被用户认可买单吗?只要答案为“否”,就说明安全团队还有提升的空间。
传统观念认为,安全总是这也不能做、那也要控制,安全就是拖业务的后腿,安全总是降低业务发展效率,在企业中安全往往也被做成了这个样子。造成这种现状,企业安全主管首先要反思。这是因为安全团队设计安全方案和要求时,不是以业务和服务为出发点,而是以安全团队省时省事、尽量少承担责任为出发点。后者设计出的安全方案当然是阻碍业务发展、降低效率。但如果一套安全方案和要求,能够在降低甚至不降低业务发展的情况下还能保障安全,业务团队和开发运维当然是欢迎的,毕竟谁都不愿意冒着巨大的风险强行上线新的业务。
如果安全团队能和业务、开发运维一起剖析,站在对方立场设计方案和执行要求,用户从心里一定是会认可安全团队和安全服务的。很多企业的实践证明,坚持安全服务的做法,会让安全团队之路走得更为顺畅。
4.甲方与乙方
乙方是指给企业(甲方)提供安全产品和服务的一方,包括安全产品原厂、代理商、集成商和外包公司等。甲方和乙方的关系也可理解为灯芯和灯油的关系,谁离开谁都会失败。有好的灯芯和灯油,也会有差的灯芯和灯油,关键在于各守本分,各尽其责。
企业中较为常见的场景是,乙方老板说,贵公司是我们的大客户,我们一定会服务好。乙方销售则在旁边配合,我们的产品和服务是最好的,用我们的绝对不会有问题。但一旦甲方稍微追问一句,贵公司打算怎么服务好我们?你们的产品和服务相比竞争对手好在哪里?你们了解我们的实际问题和需求吗?基本上90%的乙方就接不上话了。更有甚者,个别老板和销售的回答令人啼笑皆非,我们的产品和服务就是最好的,不用你们会后悔的。有风度的甲方此时往往还需要心情平静地答复,你们的产品和服务我都了解了,挺不错的,希望有机会合作。但内心简直是崩溃的。
另一方面,也听到较多的乙方抱怨甲方,主管啥也不懂,就知道不能出事,出事背锅;安全人员啥也不会,只知道指挥我们干活,把我们工程师不当人用。乙方眼里90%的甲方都是这个印象。
笔者无意为任何一方辩护,包括作为甲方的自己。因为甲乙双方都是站在自己的立场处理问题,无可厚非。但甲方和乙方都需要检讨:
甲方,应该对自己承担的职责负责,不管用什么方法,结果是必须搞定安全问题,但要能识别什么是能搞定的方案,以及哪些是方案中靠谱一员的乙方。和乙方的关系挺简单,如果乙方能为甲方创造安全价值,那给乙方匹配等量的安全回报,继续长期合作;否则对不起,多听一秒都是浪费生命。
乙方,应该是对自己的承诺负责,要了解你的客户,不是签单成功就万事大吉。合同落地才是刚刚开始,在甲方的辨识能力和社会口碑传播效应越来越强的今天,做一锤子买卖只能让自己的路越走越窄。谁都不傻,不是吗?

1.5 安全趋势

未来已来,如果只着眼于当下的安全,很可能疲于奔命,被超越或抛弃。因此,必须看到安全的趋势方能提早布局,确保立于不败之地。
1.安全度量
安全度量是指如何衡量企业安全的效果。做安全的人遇到的最大挑战就是讲不清楚安全的价值。安全这个东西很微妙,不像业务可以用销售额和用户数来衡量,也不像运维可以用可用性指标(比如故障数)来衡量,也不像研发可以用bug数、项目完成率、扩展性、专利等来衡量。安全往往是事件性的,很可能你什么都不做,但一年都不出问题;也可能你花了很大力气,花了很多钱,却还是问题频出。所以我们很难用单一的事件性指标来衡量数据安全做得好还是不好。
企业做安全,最终还是要对结果负责,对于安全效果,有两个最关键的核心指标:一个是漏洞数,一个是安全事件数。这两个关键安全指标,却没有一个安全厂商愿意承诺,他们通常都只愿意承诺卖出设备的功能效果,或者服务的响应时间。由于漏洞数涉及企业发现能力,每年第三方漏洞报告平台(如补天或CNCERT)上,漏洞数量排前十的大多是互联网公司,但不能因此认为互联网公司安全能力靠后,相反,由于互联网公司面临安全威胁且自身发现能力(各种SRC虽然是白帽提交的安全漏洞,但可以理解为自身发现能力提高导致)较强,所以发现的漏洞数量靠前。很多没有爆出安全漏洞的企业不是因为做得有多好,而是自身发现能力不够。
在这种情况下,有必要把漏洞数分成两类:一类是通过众测与SRC获得的外部上报漏洞数量,一类是通过自身安全防护和检测发现的安全漏洞数量。某些金融机构已引入专业的蓝军团队进行攻防,检测红军安全防护和安全检测能力,将是未来安全度量的发展趋势。
安全事件数的情况和漏洞数大体相同,不同点是,安全事件数没有第三方报告平台,数据主要来自于监管通报等被动暴露以及主动发现,数据统计要更难一些。
2.历史问题免疫
运维管理目前事实上的标准是ISO20000服务管理体系,这套体系也称为ITIL运维流程管理,ITIL众多流程中有个核心流程—问题管理。问题管理有个有意思的做法,通过问题管理的思维模式,对企业所有曾经出现过的历史故障进行举一反三的持续改进,从而实现对历史故障免疫。
既然安全性要当作可用性来运维,那么安全管理也应该能做到对历史问题免疫,而这也应该成为安全未来趋势之一。笔者理解历史问题免疫有两个含义:一是对企业曾经出过的安全漏洞和安全事件做举一反三的彻底整改,从人、技术、流程、资源四个维度分析问题产生根源,查找差距,并建立机制进行防护,从而根本上解决已出现的安全问题,实现历史安全问题免疫。二是对已部署的安全措施的有效性做100%确认,比如已经部署了防病毒客户端,那么就一定要关注防病毒客户端安装率、正常率两个指标,这两个指标能做到99.99%的应该算执行力和安全有效性不错的企业了。类似的指标也同样应该在已部署的安全措施中得到确认。严格来说,历史问题免疫这一点其实不能算安全趋势,而应该是常识,在各种安全概念层出不穷的今天,希望越来越多的甲乙方能回归常识。
3.安全成为属性
越来越多的企业重视信息安全,这种重视可能是主动的,但仍然被动居多。不管怎样,今天的安全人员面对的安全环境越来越恶化,但得到的资源和支持却比任何时候都多,这一点体现在:安全将成为各类系统甚至人才的关键属性之一。举个例子,十年前,很少看到系统需求阶段就会有安全需求,测试阶段有安全测试,开发人员需要接受专业的安全编码开发规范培训。十年后,这些都很常见了,甚至是标配(默认)。对安全知识和技能的掌握也从单纯安全人员必备变成了开发人员的必备技能,实际上,安全意识和安全开发能力较强的开发人员,薪酬水平和发展空间已高于技能单一的程序员。程序员在用代码改变世界的同时,也有义务更好地保护世界。安全将成为越来越多的需求品,成为非专业安全人员的一种标配属性,这将是安全发展趋势之一。
4.安全人才缺口增大
安全人才缺口越来越大,想必各企业的安全主管或者CSO都深有体会。甚至越来越多的甲方企业,会要求乙方建立专门服务于本企业的专业安全队伍。从市场经济的角度看,需求增大,必将导致更多的优秀人才投身于安全行业,这对原有安全人员也必将是个挑战。安全行业是典型“活到老、学到老”的行业,逆水行舟,不进则退,各位安全人士一定感同身受。

1.6 小结

本章从宏观角度对安全的本质、安全原则、安全世界观和安全趋势进行了探讨,指明了做好安全工作的大方向。

相关文章
|
2月前
|
存储 监控 安全
360 企业安全浏览器基于阿里云数据库 SelectDB 版内核 Apache Doris 的数据架构升级实践
为了提供更好的日志数据服务,360 企业安全浏览器设计了统一运维管理平台,并引入 Apache Doris 替代了 Elasticsearch,实现日志检索与报表分析架构的统一,同时依赖 Doris 优异性能,聚合分析效率呈数量级提升、存储成本下降 60%....为日志数据的可视化和价值发挥提供了坚实的基础。
360 企业安全浏览器基于阿里云数据库 SelectDB 版内核 Apache Doris 的数据架构升级实践
|
3月前
|
安全 网络虚拟化 云计算
阿里云转发路由器Transit Router:构建云上高效、灵活且安全的网络架构之利器
本评测报告围绕阿里云转发路由器Transit Router(TR)在跨地域跨VPC网络互通、企业云上网络架构规划和第三方SD-WAN设备对接三个场景的表现进行了详细评估。评测结果显示,TR凭借强大的路由控制能力和灵活的互通策略,在云上构建高效、灵活且安全的网络架构方面表现出色。同时,TR与第三方SD-WAN设备的良好兼容性也为企业提供了更多组网选择。本报告旨在为企业在云上网络架构规划和部署过程中提供参考和指导。
|
1月前
|
监控 安全 数据管理
现代化后端开发:微服务架构下的数据管理与安全挑战
随着信息技术的不断发展,现代化后端开发正日益注重微服务架构下的数据管理与安全挑战。本文将探讨微服务架构在后端开发中的应用,重点关注数据管理和安全方面的挑战,并提供相应的解决方案。
|
1月前
|
存储 NoSQL Redis
陌陌技术分享:陌陌IM在后端KV缓存架构上的技术实践
在本文中,陌陌数据库负责人冀浩东将聚焦探讨陌陌的 KV 系统架构选型思路,深入解析如何进行此类系统的甄选决策,同时进一步分享陌陌团队在采用 OceanBase(OBKV)过程中所经历的探索与实践经验。
32 0
|
1月前
|
消息中间件 存储 SQL
Flume【基础知识 01】简介 + 基本架构及核心概念 + 架构模式 + Agent内部原理 + 配置格式(一篇即可入门Flume)
【2月更文挑战第18天】Flume【基础知识 01】简介 + 基本架构及核心概念 + 架构模式 + Agent内部原理 + 配置格式(一篇即可入门Flume)
463 0
|
1月前
|
分布式计算 API 数据处理
Flink【基础知识 01】(简介+核心架构+分层API+集群架构+应用场景+特点优势)(一篇即可大概了解flink)
【2月更文挑战第15天】Flink【基础知识 01】(简介+核心架构+分层API+集群架构+应用场景+特点优势)(一篇即可大概了解flink)
59 1
|
1月前
|
存储 缓存 安全
【ARM架构】ARMv8-A 系统中的安全架构概述
【ARM架构】ARMv8-A 系统中的安全架构概述
31 0
|
2月前
|
边缘计算 Kubernetes 物联网
大规模 IoT 边缘容器集群管理的几种架构 -0- 边缘容器及架构简介
大规模 IoT 边缘容器集群管理的几种架构 -0- 边缘容器及架构简介
|
2月前
|
存储 消息中间件 API
|
2月前
|
存储 监控 安全
阿里云云通信短信服务安全之安全架构
阿里云云通信长期致力于通过多种渠道向客户透明服务相关情况。客户一般可通过阿里云官网提出对阿里云云通信相关资质、服务使用情况、产品说明等信息,我们将7*24小时不间断处理您的建议与咨询。对于客户合理的要求,阿里云云通信服务团队均会及时响应客户的需求。同时,阿里云云通信也在探索更多增加透明度的方式,如对公邮箱、线上查询接口、钉钉服务客户群等。