2019年7月金融行业安全月刊.pdf

本 | 期 | 看 | 点 P04 安全成本节约的选择 P10 零信任技术架构研究目录 P04 安全成本节约的选择 家观点 专 P10 零信任技术架构研究 P16 安全视角下的资产管理 P19 漏洞管理，从入门开始 P22 容器网络之访问控制机制分析 P38 Blueher o 挖矿蠕虫变种空降 P40 巴尔的摩勒索攻击事件已造成 1800 万美元损失 P42 佛罗里达州一城市同意向黑客支付 60 万美元赎金 以恢复电 脑记录 P44 GoldBrut e 僵尸网络横空出世，百万台 RDP 服务器瑟瑟发抖 业研究 行 P46 Or acle Weblogic 远程代码执行漏洞（C VE-2019-2725）补 丁绕过威胁预警通告 P47 多个 Linux 内核远程拒绝服务漏洞威胁预警通告 P50 关于 Absolut e 公司防盗追踪软件安全风险威胁预警通告 P52 E xim 远程代码执行漏洞（C VE-2019-10149）威胁预警通告 P53 TP -Link Wi-Fi 扩展器远程代码执行漏洞（C VE-2019-7406） 威胁预警通告 洞聚焦 漏 P56 绿盟科技产品更新提示 P60 绿盟科技助力新疆金融业网络安全风险防控技能竞赛完美落幕 P63 正式发布 | 绿盟科技等保一体机 品动态 产 绿盟科技金融事业部 安全月刊 2019年第7期 S C ONTENT S 绿盟科技官方微信 安全月刊在线阅读 家 观点 专 S S安全月刊 / 2019.7 4 专家观点 安全成本节约的选择 可管理安全服务正当时 金融技术部 傅 戈 不久前，我和沿海某金融机构 信息安全负责人进行了交流，该负责 人的一些观点对我颇有震撼。在交流 中，该负责人阐述了他对机构信息安 全建设的看法。主要观点有以下这么 几个： 信息安全工作毋庸置疑肯定 重要，但是否一定要设立大 量的信息安全岗位去招聘相 应人员； 信息安全人员的技能要求 高，满意的人员非常难以 招到； 信息安全人员的薪资要求不 低，但是人员的复用性却比 较低，从机构经营的投资回 报来看并不一定值得； 以机构整体的视角来看，机 构本身就需要以一种快速响 应、弹性适应的方式开展业 务和进行发展，在此情况 下，机构人员的编制也需要 适应业务发展的节奏； 该机构在IT建设中已不断要求关键业务系统开发商在系统中集成一些 安全防护和安全检查的功能，降低系统安全运维对人员技能要求的 难度； 基于以上认识和考虑，该机构更愿意采取安全服务外包的模式； 作为一个已在安全行业从业多年的安全人员而言，对于如此支持和彻 底践行安全服务外包的机构还是相当少见。回去后笔者连续数日在思考客 户的观点，回想并整理近年来的变化，思索可管理安全服务（Manageable Security Ser vic es，以下简称MS S）在今后对企业机构用户而言是不是一种更 好的安全策略选择。 网络安全整体形势的变化 不断攀升的人力和设备成本 有数据表明，在2014年底的时候，我国信息安全专业应届生的平均薪资 为3704元，而根据2018年的统计表明，2017届信息安全专业应届生的在毕业 半年后的月收入平均为6386元 1 。4年里应届生的薪酬涨幅为72.4%。而具备5 年工作经验的信息安全人才，目前在北上广深的年薪资水平均在30万以上。 与此对应的是，信息安全人才的需求仍不断上涨。2017年9月由中央网信办网 络安全局、教育部高教司指导，教育部高等学校信息安全专业教学指导委员 会主办的第十一届网络空间安全学科专业建设与人才培养研讨会上指出 “我国网络空间安全人才年培养规模在3万人左右，已培养的信息安全专业人 才总量不足10万，离目前需要的70万差距巨大。”。另有数据表明仅2018年2019.7 / 安全月刊 5 专家观点 上半年的对信息安全人才的需求上涨25%，这直接导致信息安全人才在未来数年 内都将处于人力资源的卖方市场。 此外，随着监管要求的日益严格、安全威胁的不断演变和增长，传统的安全 设备将越来越难以应对以上要求和变化。集中化、平台化、智能化、模块化的安 全运营将是未来的建设发展方向。虽然新的产品和技术能带来正向的投资回报， 但显而易见，这样的投资成本绝对不低。 图1：安全技术带来的成本节约 3 日益严格的监管要求 在国内，随着中华人民共和国网络安全法（以下简称网络安全法） 的正式颁布实施，新时代和新形势下网络安全的工作开展以立法的形式得以确 立。随后网络安全法的配套法规文件及相关国家网络安全新标准的陆续进行 发布，如关键信息基础设施安全保护条例（征求意见稿）和信息安全技术 网络安全等级保护基本要求GB/T 22239-2019，形成了对网络安全法在执 行落地环节的有力支撑。此外，各行业监管机构也根据国家安全战略的要求，配 合网络安全法推出了比以前更为细致的监管要求和监管动作。如公安部连续 4年开展了全国性的护网检查专项行动，关键信息基础设施机构一直都是检查的 重点对象。以上种种情况无疑向网络运营者、关键信息基础设施等机构不断传递 着需要从国家安全战略层面认真看待网络安全，重新审视内部网络安全建设合规 状况的重要信息。 不断扩展的安全内容 随着科学技术的不断应用和发展，网络安全的概念和范畴也不断的在发生安全月刊 / 2019.7 6 专家观点 变化，网络安全的涵盖内容也越来越 广。以金融行业为例，移动互联技术 催生了移动安全；虚拟化/云计算技 术则引发了云安全；开放银行的应用 则需要考虑API安全、数据安全；人 工智能的应用则意味着未来将是以人 工智能的手段来防御对抗人工智能的 攻击。简言之，企业机构所面临的网 络安全建设内容将随着新兴技术的出 现与应用，新型业务的设计与开展而 需要不断的扩展。 持续增加的安全威胁 网络安全的威胁一直都存在， 然而由于黑客的日益复杂以及犯罪 市场的扩散，网络威胁带来的损失 将持续增加。国外研究机构的报告显 示2021年全球因此遭受的计算机网 络犯罪的损失预估将是6000亿美元. 与2015年相比增长了100% 2 。根据 Ac c enture 然后， 要保证用户所用终端是安全终端，或者该终端处在安全状态;最后，还要有个 条件策略，指定哪些人能访问哪些东西。 零信任依靠多因子身份认证、身份与访问管理(IAM)、编排、分析、加 密、安全评级和文件系统权限等技术来做上述工作。最小权限原则也是零信 任倚赖的监管策略之一，也就是只赋予用户完成特定工作所需的最小访问 权限。 基本上，零信任就是公司企业收回安全战场控制权，在各部门应用网络 分隔和下一代防火墙，控制网络接入的身份、对象、地点和时间，是从内而 外地施行控制，而不是由外而内。 现今的大部分IT场景中，零信任不仅仅是技术，还有关思维和过程。 ht tp:/ne t security .51c t o . c om/ art /201801/564513.htm（“零信任” 安全架构将成为网络安全流行框架之一）安全月刊 / 2019.7 14 行业研究 行业方案 三、“零信任”安全架构技术实践 3.1 Google-BeyondCorp 谷歌公司称，在2009年经历高度复杂的AP T攻击极光行动（Oper ation A ur or a）后，该公对员工与设备如何访问内部应用的安全架构，开始尝试重新设 计。由此，零信任架构Be yondCorp开始萌芽。 与传统的边界安全模式不同，Be yondCorp摒弃了将网络隔离作为防护敏感 资源的主要机制。取而代之的是，所有的应用都部署在公网上，通过用户与设备 为中心的认证与授权工作流进行访问。 这就意味着，作为零信任安全架构的Be yondCorp，将访问控制权从边界转 移到个人设备与用户上。由此员工可以实现在任何地点的安全访问，无需传统的 VPN。 谷歌的零信任安全架构涉及复杂的库存管理，记录具体谁拥有网络里的哪台 设备。设备库存服务来从多个系统管理渠道搜集每个设备的各种实时信息，比如 活动目录（Ac tiveDir ec t or y）或Puppe t . 对于用户的认证则基于一套代表敏感程度的信任层。无论员工使用什么设备 或身处何处，都能得到相应的访问权限。低层次的访问不需要对设备做太严格的 审核。 谷歌企业项目经理Max Salt ons t all表示，对于访问授权是基于上下文：“你2019.7 / 安全月刊 15 行业研究 行业方案 是谁，是否经过严格认证？你使用什么设备？对你的设备了解情况如何？” 在谷歌网络中不存在特权用户。谷歌使用安全密钥进行身份管理，比密码更 难伪造。每个入网的设备都有谷歌颁发的证书。网络的加密则是通过TL S（传输 层安全协议）来实现。 与传统的边界安全模型不同，Be yondCorp不是以用户的物理登录地点或来 源网络作为访问服务或工具的判定标准，其访问策略是建立在设备信息、状态和 关联用户的基础上，更偏向用户行为和设备状态的分析。 据了解，谷歌Be yondCorp的主要包括三大指导原则： 无边界设计 从特定网络连接，与你能获得的服务没有关系。. 上下文感知 根据对用户与设备的了解，来授予所获得的服务。 动态访问控制 所有对服务的访问必须经过认证、授权和加密. ht tps:/ .northso ar . c om/Ne ws/ de tial/227（谷歌的零信任安全架构 实践）安全月刊 / 2019.7 16 行业研究 行业方案 安全视角下的资产管理 金融事业部 张政祺 对于企业信息安全管理而言，所涉及的资产面很广，包括硬件资产，如安 全产品、服务器、个人终端、网络设备等；包括广义上的软件资产，如服务器应 用、虚拟化设备等。在安全建设中，这些资产无疑是安全防护的重点，因此如何 做好资产管理工作，也是企业安全工作的基础任务之一。 现状 当前绝大部分企业都会有自己的资产管理流程及规范，建立信息化的资产 库，但是就安全管理视角来看还是或多或少的存在一些问题。 1. 新增资产及下线资产管理 大部分企业中信息化的资产数据与实际的资产情况大相径庭，据不完全统 计资产偏差大致在25%左右。在新增资产或资产下线时，不能做到很好的信息同 步，就会造成资产偏差，这对于安全管理是极为不利的。 新增的资产数据缺失会对安全管理带来困扰，形成资产盲区，对新资产的防 护处于空白，很可能成为外部攻击者的主要攻击路径，安全隐患极大； 下线资产的未更新对于网络架构、安全防护的整体性考量都有影响，且浪费 了有限的防护资源与人员精力。 2. 安全维度资产数据缺失 前文中提到虽然大部分企业都有自己的“资产库”，但是其中的数据与安全 管理或者安全运维所期望的数据仍存在较大的差距。例如资产的端口开放情况对 于漏洞修复及攻击面收敛都有作用，在面临真正的攻击应急时具有很大价值，但2019.7 / 安全月刊 17 行业研究 行业方案 实际情况是“资产库”中通常不会存有这部分信息。当然，安全维度的资产数据 范围还需要有经验的安全运维工程师及资产管理专家根据实际的业务情况及安全 防护要求来拟定。 3. 资产数据更新机制 目前的资产数据记录方式通常有两种，一是以文本形式记录，二是存储在企 业的“资产库”中。针对二者的数据更新，基本都是通过人工方式来实现的，包 括在引言部分提到的软硬件资产数据。 人工更新的方式主要有两个问题： a）数据更新实时性差，可能在数据变更前就发生响应的安全事件，这对于 应急响应及安全处置都是极为不利的，严重的情况甚至会产生相反的效果。 b）数据更新不准确，人工的方式难以保证资产及其关联信息更新的准 确性。 难点及对应方案 上一章节描述了企业当前的资产管理现状，形成此状态的原因多种多样，下 文总结一下目前的资产管理难点及应对方案。 1. 多部门的协同工作 资产管理工作责任通常是落在IT运维部门，但是资产信息的来源是来自多方 的，因此建立完善的、可用的、可落地的资产库难度还是很大的。 首先需要明确资产库建设的主责任人，且所有涉及的相关部门都要安排接口 人，提出日常工作可能涉及到的资产数据，经各方评估确认这些资产数据的必要 性，形成明确的资产数据列表，并落地执行。 2. 资产数据收集难度大 在明确了各方责任并且输出了资产数据列表后，需要输入对应的资产数据。 常规的资产库中例如IP、MA C信息都是明确需要，且易收集确认的数据，但是其 他的例如安全部门所需的端口情况、应用部门所需的应用版本及内核情况等数据 都需要花较大的精力去收集，且更新机制也难以规范。面临此种状态，需要加入 自动化的资产数据收集及更新能力，解决多种数据的采样及准确率要求。安全月刊 / 2019.7 18 行业研究 行业方案 3. 安全维度的资产数据应用 安全部门当前对于资产数据的应用还处于较为初级的水平，针对不管是内 部脆弱性或者是外部的风险都应结合资产数据，形成针对脆弱性的筛查、修复能 力、安全风险的处置建议等。在安全视角下，常用的资产数据有如应用系统版 本、端口情况、业务域组、资产部署区域等。 4. 新技术的引入 越来越多的企业开始使用云计算和虚拟化技术，数据中心的建设应用此类新 技术已经成为常态化，面临此类技术如何建立新的资产管理方式、明确资产数据 成为了新的难点。 现状 资产管理在安全工作中其实是很小的一环，很多时候被忽视，甚至认为没有 技术含量，但是要洞察网络内的安全风险，或者是脆弱性筛查，资产管理都是不 可缺少，且是极为重要的，做好资产与各类数据的深度结合，发挥其真正价值是 网络安全建设的重要基石。2019.7 / 安全月刊 19 行业研究 行业方案 新的攻防对抗形势在不断的变化发展，但仍会利用各种漏洞，比如：NSA网 络攻击军火库泄露，永恒之蓝漏洞大爆发，S trut s2和weblogic漏洞频发，都给攻 击者和对应的黑产团伙带来很多素材。而另一组统计数据也表明，其实攻击者攻 击过程并非都会利用0day漏洞，而99%攻击都是利用的已知漏洞。对于攻击者来 说，IT系统的方方面面都存在脆弱性都是可被利用的点，这些方面包括常见的操 作系统漏洞、应用系统漏洞、弱口令，也包括容易被忽略的错误安全配置问题， 以及违反最小化原则开放的不必要的账号、服务、端口等。 在新攻击威胁已经转变的情况下，如果还是每年购买几次安全厂商例行的季 度或者年度扫描，来进行网络系统的漏洞检查，已无法满足新洞频发，应急频繁 的现状。无法真正达到通过安全检查事先修补网络安全脆弱性的目的，也无法跟 上漏洞周五见的步伐。网络安全管理人员需要对网络安全脆弱性进行全方位的检 漏洞管理，从入门开始 金融技术部 刘 帅安全月刊 / 2019.7 20 行业研究 行业方案 查，对存在的安全脆弱性问题一一修补，并保证修补的正确完成。这个过程的工 作极为繁琐，单靠漏扫服务或者开源漏扫工具无法从脆弱性检查方面覆盖资产全 面的风险管理。 而从0到1总要有个过程，笔者建议的方式是，先从购买一个商业扫描器，制 定每周或者每月的定期扫描计划开始。在扫描开始前需要跟各系统负责人及资产 责任人申请扫描授权，确认可扫描时间段，以及可扫描范围，和最近是否有升级 计划，相关资产是否会将扫描请求转发给第三方系统等。然后在业务低峰时段下 发定时扫描任务，扫描结束后，将结果按照所属资产责任人的情况分别发送，并 通知相关责任人进行漏洞整改。 漏扫报告发送之后，与之伴随的问题也来了，由于现在主流扫描器的部分漏 洞是基于版本做判断的，因此不可避免的会产生一些误报。如何解决这些误报， 核心思想是获取到相关资产、组件准确的版本信息，然后通过与漏洞的影响版本 来做准确的匹配。获取资产版本的信息目前主要有如下几种途径： 1、登录扫描，在扫描器里输入或者导入各资产的用户名和密码进行登录扫 描。该方式的难点在目前很多金融机构都通过堡垒机来进行日常运维，并且上收 了账号、口令，此外堡垒机还会定期进行自动改密操作。而且堡垒机本身是基于 用户角色来进行相关资产的运维管理权限的授权，因此如果设备异构，会涉及不 同品牌安全设备间的协同，会产生一些定制开发的工作量。笔者认为两者协同的 一个合理方式应该是，扫描器根据堡垒机的改密周期定期去同步其纳管的资产和 用户名密码表。 2、CMDB资产数据库信息联动获取。 3、采用ag ent方式扫描或ag ent采集资产信息回传。 扫描报告准确了，对应后面的修复问题也来了，很多暴露出来的漏洞会因 为各种因素、如供应商不见了、该系统准备下线了、该系统很重要框架不敢动、 该系统过x月会升级等等而无法及时修复。出现这种情况该怎么办？这时候就是 体现修复的艺术了。漏洞根治的方法的肯定还是打补丁，升级版本。如果确实无 法升级的，可以采取一些漏洞缓解措施，像很多大数据组件的漏洞可以通过开启 Linux防火墙策略限制访问，只允许本地访问或者是只允许关业务节点访问；也可 以通过w af、ips、防火墙等产品的相关防护策略进行防护；还有的还可以通过一 些临时修改配置方案的来对相关漏洞进行规避。 漏洞修复完以后，如果条件允许即刻就进行验证，以确保漏洞修复工作的有 效性。如果无法及时验证，便待下次扫描结束后，通过同一扫描父任务的周期性2019.7 / 安全月刊 21 行业研究 行业方案 扫描子任务对比来发现漏洞的增减变化，来确认漏洞的修复效果，并完成管理管 理的闭环。 依托国内权威中文漏洞知识库和已在国际上享有盛名的NSFOCUS安全小 组，绿盟远程安全评估系统（RSAS）已经是国内知名的漏洞管理产品之一，配 合专业的Web扫描模块，它能够定期和持续地给用户提供全面可靠的安全评估服 务，满足多种应用需求，并且提供完整的漏洞管理机制，有效降低用户网络和主 机风险，更大限度地保证用户网络和系统的安全性和稳定性。安全月刊 / 2019.7 22 行业研究 行业方案 一、引言 随着容器技术成熟和敏捷开发的推广，微服务技术在业界越来越得到普遍的应用，但业务微服务化后又引入了一 些新的安全挑战，特别是在访问控制层面。例如： (1) 容器部署可以根据需求动态扩展，但也导致容器IP和端口频繁变换，所以基于静态的IP和端口的防护规则会 失效； (2) 东西流量剧增，约为南北流量的20多倍，要防护来自大量虚拟网络的东西向流量就需要设置大量防火墙规则， 规则匹配导致的计算和时间开销将会成为一大问题； (3) 微服务环境下的访问控制需发生在每一工作负载（workload）内，即提供端点（endpoint）到端点 （endpoint）的访问控制，广泛部署的访问控制点应足够轻量，否则单点所增成本将迭代地引起总体成本的剧增。 那么面对上述三种挑战，容器环境中的访问控制机制应该作何改变呢？ 二、容器环境下的防火墙 防火墙是实现访问控制不可或缺的手段，它与网络环境是息息相关的，网络环境的变化会对其提出一些新的 要求。 在传统环境中： 1.网络是相对静态的，大多网络防护规则都是基于静态的IP地址和端口的； 2.内部是默认可信的，网络边界较清晰，访问控制机制部署在网络边界处； 3.大部分的网络流量会经过网关 在容器环境中： 1. 容器的新增和消亡总在发生，IP分配变换频繁； 2. 多应用混合部署，边界不清晰。内部通信关系极其复杂，无法预先设置安全防护策略； 容器网络之访问控制机制分析 创新中心 李 欣2019.7 / 安全月刊 23 行业研究 行业方案 3 . 容器间流量可见性差，为了检测和防护看不见的流量，我们想到了引 流，但大范围引流很容易制造出新的瓶颈点，这在东西流量剧增的微服务环境下 也不太现实 但不管如何变化，通过防火墙实现网络访问控制的功能没有变化，只是对防 火墙的实现方式提出了新的挑战。 容器环境中网络防护如下图所示： 常见的防火墙形态主要包括： 1 ) L3/L4层包过滤技术：传统环境下网络拓扑相对稳定，包过滤规则也相对 固定，而容器环境下网络漂移随时都在发生，包过滤规则需要根据网络变化随时 调整包过滤规则。在K uberne t es环境下我们可以借助于Ne tworkP olic y或者一些其 它的工具来动态更新规则，因为Ne tworkP olic y是基于P od的，在容器部署发生变 化时也可以进行动态保护。 2 ) 应用防火墙：容器环境下的应用防火墙通常需要与容器运行时或者容器 编排工具集成，借助于DPI（深度包检测）技术来保护容器间的通信，同时借助 于行为学习自动创建防护策略来保护容器环境。通过识别流量的应用信息，可实 现面向业务的动态微分段，成为了保护东西向流量场景中容器应用免受恶意攻击 第一道防线。 3 ) Web应用防火墙：运行Web应用程序、面向互联网的容器可以通过检测 常见攻击的方法进行保护，这符合传统的Web应用程序防火墙功能。但是，要知 道这仅限于常见的外部攻击，对于容器之间的访问防护还需分析它们之间的通信 协议。 总之，传统的防火墙已不能满足容器环境下的访问控制，要达到更细粒度的 访问控制，须采用可以动态感知资产、资产的属性和连接点等信息变化的新型防 火墙，才可以有效防止源于内部应用程序级别的攻击。安全月刊 / 2019.7 24 行业研究 行业方案 三、容器环境下的访问控制机制 访问控制和网络隔离做为计算机网络的两大防护手段，由于篇幅原因，在 此我们只谈访问控制。在综合对比分析了Github上容器编排项目K ubernetes、 Ap ache Mesos、Dock er Sw arm、Dock er Compose等的活跃程度（数据截止到 2018-12-12），我们发现K uberne t es的活跃程度是最高的，故此以K uberne t es为 例来说明。 默认情况下，K ubernetes中的P ods不严格限制任何输入流，也不设置防火 墙规则来限制P od间的通信。当K uberne t es被用作多租户平台或共享P aaS时，对 工作负载进行适当的访问限制就显得非常必要。K uberne t es在这方面也做出了努 力，Ne tworkP olic y1是K uberne t es社区提出的网络访问控制的官方解决方案。 下面的访问控制也是基于Ne tworkP olic y展开的。 NetworkP olicy提供了基于策略的网络控制，用于隔离应用并减少攻击面。 它使用标签选择器模拟传统的分段网络，并通过策略控制它们之间的流量以及来 自外部的流量，其主要作用于网络层和传输层。 K uberne t esNe tworkP olic y特点： 1. 网络策略是针对于pod的，适用于一个pod或一组pod。如果一个指定的 网络策略应用于一个pod，那么对pod的流量是由网络策略的规则决定的。 2. 如果一个pod没有应用任何Ne tworkP olic y，那么该pod将接受来自所有来 源的流量。 3. 网络策略可以在入口、出口或两个方向为pod定义流量规则。默认情况 下，如果没有显式指定任何方向，则对入口方向应用网络策略。 4. 将网络策略应用到pod时，策略必须有明确的规则来指定入口和出口方向 允许流量的白名单。所有不符合白名单规则的流量将被拒绝。2019.7 / 安全月刊 25 行业研究 行业方案 5. 多个网络策略可以被运用到任何pod上。匹配到任何一条网络策略的流量 都是被允许的。 6. 网络策略作用于连接而不是单个数据包。例如，如果配置策略允许从pod A到pod B的流量，那么也允许从pod B到pod A连接的返回包，即使有策略不允许 podB发起到podA的连接。 在K uberne t es中一切对象皆资源，定义Ne tworkP olic y资源的y aml文件中的 spec字段数据结构展开图如下所示： 由上图可知NetworkP olicy通过podSelector、namesp ac e Selector来筛选 pod，还有就是通过IPBlock，它的访问控制粒度是pod或者CIDR级别的，通过 Ingr ess和Egr ess分别定义进出pod的流量。要知道的是Ne tworkP olic y只制定了策 略，并没有对策略进行实现，策略的实现还要依赖于网络插件驱动，即需要各网 络插件自己实现NPC（ne twork polic y c ontr oller）。有关如何编写Ne tworkP olic y 的y aml文件可以参考官方文档2，在这里不详细叙述。 此外，不同的插件对于Ne tworkP olicy的实现程度也不一致，接下来就简单 分析下各主流插件。 1. Calico Calic o是一个纯三层协议，它使用BGP协议来传达信息，它还提供了网络安 全规则的动态执行。以DaemonSe t3形式部署在K uberne t es集群中,部署的容器 按功 能主要包含以下三种：