乌云章华鹏:如何构建高效的安全运维服务平台



  • 主题:如何构建高效的安全运维服务平台

    时间:4 月 12 日 20:30 —— 22:00

    地点:青云QingCloud 技术分享群,文末有二维码。

    讲师:章华鹏,乌云唐朝安全巡航产品负责人。
    WeChat_1459824969.jpeg
    曾作为百度云安全部高级安全工程师先后经历百度安全管理运营团队、百度内部应急响应团队、内部监控体系建设和百度云加速项目。对甲方安全建设有丰富的经验和深刻的理解。2015 年初加入乌云担任唐朝安全巡航产品负责人,同时章华鹏作为一个国内活跃的知名白帽子,曾经帮助 BAT 等企业多次发现高危安全风险,网络的 ID 是 booooom 。

    本期内容介绍:

    本次分享的话题是“如何构建高效安全的运维服务平台”,包括:企业的数据安全问题,运维安全中面临的网络、系统服务、应用相关配置等问题。

    扫描下方二维码,输入『听课』,小编拉你入群
    20.pic_hd.jpg



  • 如何构建高效的安全运维服务平台

    大家好,我是乌云的章华鹏,今天和大家分享的话题是“高效安全运维服务平台的构建”,包括:企业的数据安全问题,运维安全中面临的网络、系统服务、应用相关配置等问题。

    企业安全的核心是数据安全

    当我们在讨论如何构建安全运维服务平台之前,我们需要考虑的问题是构建这样一个平台的核心需求是什么?核心需求是帮助企业解决安全风险,避免因为安全风险带来的业务损失。
    我们都知道对于一个依赖互联网的企业来说,数据是企业的核心资产,那么归根结底,其实企业安全的核心是数据安全,所以我们首先要明白企业的数据到底在哪里?
    业务是数据的载体,IT资产是业务的载体,那么运维的核心对象即是企业的IT资产,由此可见,企业安全运维应该是运维的一项基础要求。
    运维安全面临哪些问题?
    高效安全运维平台构建的前提—了解企业面临的风险。企业的运维安全主要分为:网络、系统服务、应用相关配置三个方面。

    网络安全

    主要是网络边界被突破带来的安全风险。对于大多数存在互联网业务的公司来说,服务都会分为内网和外网两块区域,通常这两部分业务是相互隔离的。
    一般来说,企业内网主要部署着一些公司内部的敏感系统,这些系统只需要对内部员工开放,与互联网是隔离的。既然存在边界隔离,那么就会存在一些网络边界被穿透的安全隐患。
    企业网络边界安全的典型风险主要表现在以下几个方面:包括某台服务器同时部署内网&外网业务、SSRF漏洞、IDC与办公网网络互通、未授权代理配置、IDC服务器被入侵等等。
    这里对其中一些比较专业的概念做一个解释,某台服务器同时部署内网&外网业务这个其实就很容易理解了,比如有两个研发公用一台服务器,其中这台服务的内网IP映射到一个内部的业务系统,比如ERP;但同时这台服务器又部署了一个外部的业务,比如企业的官方博客,而这个博客绑定的是外网IP/域名。
    SSRF漏洞,说白了就是相当于一个应用层的代理,可以利用这个应用层的代理来对内网任意地址发起请求。
    未授权代理配置主要一些类似Squid这样的代理未添加授权控制,导致任何人都可以直接通过这个代理带请求内网资源的问题。
    在乌云平台,经常可以看到这样一些案例,一些攻击者可以通过突破边界来漫游企业的内网,从而拿到公司内部的核心信息。

    上图是一个关于某互联网公司SSRF的案例,详见乌云http://www.wooyun.org/bugs/wooyun-2016-026212,类似内网漫游的案例在乌云漏洞报告平台上搜索一下有超过400条的记录。

    系统服务安全

    系统服务相关的安全问题主要体现在系统基础依赖组件及基础服务漏洞两个方面。
    典型的系统服务相关安全问题主要包括OpenSSL 心脏滴血、Shellshock BASH远程命令执行、Redis 未授权访问、各种基础服务的弱口令等配置问题。
    近些年爆发的一些全球性安全事件包括:心脏滴血、BASH远程命令执行等漏洞,影响范围非常广,这些都是由于系统的基础依赖组件存在安全问题导致的。

    上图是一个国内某电商网站的心脏滴血漏洞,乌云主站搜索redis 相关的风险也有将近400 条。

    应用配置安全

    应用配置安全主要体现在应用上线流程和各种配置不当方面。

    在应用上线流程中常见的安全问题,例如上线代码的SVN及Git配置文件目录未删除导致代码信息泄露,数据库及代码的备份文件放在 WEB目录下导致被黑客下载等问题。
    通常Webserver的配置也是配置风险的大头问题,这里面不乏由于Webserver配置不当导致任意系统文件遍历,列目录风险等问题。
    问题这么多,这么办?

    如何构建安全运维服务平台

    基础资产管理

    企业安全的核心是数据安全,而基础资产是这些核心数据的载体,所以在构建这样一个安全运维服务平台之初,我们首先应该做好基础资产的发现和管理。
    基础资产发现,甲方可以从两个角度来考虑,一个是依赖于内部的资产运维管理流程,另外一个是站在外部攻击者的角度来进行资产探测,这样做的话可以有效的进行互补,因为如果仅从内部资产运维管理流程中来对接企业的IP、域名等资产的话对于内部资产管理的要求会很高,而往往企业内部规范落地很难,导致一些资产会遗漏,而外部探测的方式就能够很好的弥补。
    外部资产发现的方式主要包括:子域名的暴力枚举,通过一个子域名命名常用字典来挨个遍历子域名;第三方的DNS数据分析获取企业相关的子域名和IP;除此之外还可以通过第三方查询接口、网站爬虫、域传送漏洞的方式获取相关子域名IP的信息。
    基础的域名IP资产梳理完毕后,我们需要思考如何把资产管理这件事情做的更加高效。
    域名IP是一个比较粗粒度的资产,为了方便应对全球不断变化的安全风险,我们需要做到更加精细化的资产识别,比如每个域名IP上所部署的应用及服务相关信息,一旦这些应用及服务在互联网上暴露出来安全风险,运维服务平台就能第一时间进行响应,这些都依赖于指纹识别技术。
    指纹识别方面包括服务指纹识别和应用的指纹识别。
    服务指纹识别方面Nmap完全可以满足大家的需求,而且可以方便的进行指纹规则的定制;
    应用指纹识别方面我们可以考虑从HTTP协议层面,包括特殊WEB应用的HTTP Headers字段的特征,比如某应用会使用特殊的Cookie值。另外包括特殊应用独有的静态JS/CSS/HTML文件特征。
    通过这些特征基本可以识别市面上所有的第三方应用特征。

    持续风险监测

    在前面的资产管理模块中我们提到资产指纹识别主要分为服务及应用指纹识别两方面,同样在进行风险检测时也是关注服务及应用的风险检测。
    服务风险检测主要包括系统基础服务相关的通用漏洞和服务配置不当的风险检测;
    应用风险检测主要包括一些第三方应用的通用漏洞和自研的应用风险。第三方应用的通用漏洞通常根据具体漏洞的利用方法来编写具体的检测策略即可,而自研的应用风险如典型的SQL注入,则只能通过尝试不同的攻击测试Payload来判断是否存在漏洞,这通常和具体的漏洞场景有关。
    那么如何让风险检测这件事情变得更加高效呢?
    我们知道关于风险的检测最重要的就是检测策略,而且互联网相关的技术是在不断变化的,也带来不一样的漏洞风险。这就给企业在覆盖不同风险的检测策略上带来了极大的困难,那么如果我们能够联合安全社区的力量来完善策略就能够完美且高效的解决这个问题,而作为平台方只需要做的一件事情就是提供足够好的引擎框架来方便社区的安全专家为平台提供策略。
    同时还需要有良好的机制来运营社区,比如说将风险发现的结果和白帽子编写检测策略的奖励对应起来,这样可以很好的激励白帽子写更多更好的检测策略。

    安全事件处理

    当企业发现了风险以后接下来需要做的事情就是去进行事件的处理,企业需要建立一个及时有效的处理流程:首先从发现问题开始,接下来是进行风险通告,通告到存在风险的具体业务部门,同时指导业务部门进行风险整改。
    这个环节有一个很重要的细节就是,业务部门的研发人员其实是不了解安全的,所以在重视安全问题及修复过程中可能会存在修复不当的情况,所以在通报修复的过程中最好有安全人员进行跟进。
    最后修复处理完毕后还要进行及时的回归测试。
    当然,除了需要去及时处理一些已知存在的安全风险,还需要有预警全球正在爆发的通用安全事件的能力,比如当年爆发的Struts2漏洞的时候,漏洞爆发的第一时间需要预警到各个可能受影响的业务部门,要求业务部门及时配合自查整改。这样能够更大程度上赢得修复的时间。
    关于安全事件处理流程如何更加高效?
    核心是需要把安全运维服务平台和业务部门的产品生命周期管理流程打通,最好有API直接对接到产品开发上线的流程中去,安全问题作为产品的严重BUG一样得到及时的排期修复。
    同时这个过程中一定要有一个专业的安全人员进行跟踪服务,确保问题不会修复不当,导致问题反复出现。在全球风险预警方面最好对接社区的力量,因为小团队无法跟踪全球最新的安全风险动态。

    持续风险管理

    由于业务是在持续不断的迭代更新,所以为了保证业务在迭代更新过程中不断的规避风险,需要对业务系统进行周期性的持续监测。
    这样能够避免由于迭代更新带来新的安全风险和避免曾经修复的安全问题回滚再次出现。另外一方面可以对持续风险监测的结果进行趋势分析,这样能够帮助我们发现企业当前一段时间主要面临的安全问题,在下一阶段的安全建设上就能够提供有效的指导建议。
    关于如何高效的进行持续风险管理,一方面需要能够自主的配置周期性的检测,这样可以适应企业的迭代更新频率;另一方面还需要支持不定时的手动启动检测风险来满足突发的应用上线。
    在风险管理方面可以支持定期的报表导出和自定义的导出策略,如此能够更加高效的满足风险运营管理的需求。
    以上就是本次分享的所有内容。



  • 占楼

    本楼用来收集问题

    1、测试系统能不能与现在的nginx共用一台机器呢?

    最好不要这样用,因为测试系统通常安全性会比较差,那么很容易成为系统的突破口,导致影响线上业务。

    2、我想咨询一下从我们公司目前的运维体系,无论是从信息安全保障出发,还是从安全需求项目建设角度出发,还都停留在被动防御阶段。我们如何化运维安全的被动防御为主动防御,化响应式的安全管理工作为主动干预式的安全管理工作,将威胁从模糊化变为具体化,让运维安全体系落地呢?

    首先我们需要具备主动发现风险的能力,基于我们发现的这些风险,就能够梳理出来一个list,根据这个list去排排优先级,每个大的风险点就会对应到企业安全建设的一块事情,这样我们把被动响应变成了主动防御和建设,基于安全风险的需求来做安全体系建设,这样比较容易落地实施。
    拿安全问题来推动安全建设是最好的

    3、高效的运维服务平台是通过集成很多脚本或在小工具来实现减低运维人员的运维时间和发现问题的应急反应速度,还是说形成一套完善的机制和流程,加上服务平台的分发作用来实现一个高效安全的运维服务平台的。

    这个就不做额外的说明了

    4、越来越多的应用提供商选择了docker作为基础架构去部署,这在运维的时候,与传统的那种会有什么样的不同,以及如何利用docker进行安全方面的加固?

    docker 在部署运维方面比较方便,同样在安全管理方面也会很遍历,不管是发现问题还是解决问题,都很方便,在加固方面可以实现更简单的策略下发,docker本身的安全性也是比较好的。尤其适合我们做一些本身应用直接需要隔离的环境

    5、请问对于运维审计部分,我们的侧重点应该覆盖到哪里,那些是必须优先处理的。
    运维授权又怎样合理的优化改进并保证安全性呢?

    运维审计重点放在一些关键敏感系统的操作日志上,比如核心的dba服务器的 bash日志、数据库操作日志、机器的登陆记录,可以规划出一个核心重点区域出来。当然做了这些以后,最好要做一些合规性检查,避免有人不按规范操作。比如自己拿高权限删各种日志,登陆不走跳板机,这些需要监控起来。

    6、想问一下,你的安全平台是独立的还是和运维平台集成在一起的,制度上有没有安全这块标准出来,有没有系统的一些截图之类的?



  • question:您好,我想咨询一下从我们公司目前的运维体系,无论是从信息安全保障出发,还是从安全需求项目建设角度出发,还都停留在被动防御阶段。我们如何化运维安全的被动防御为主动防御,化响应式的安全管理工作为主动干预式的安全管理工作,将威胁从模糊化变为具体化,让运维安全体系落地呢?thanks!



  • 请问下 高效的运维服务平台是通过集成很多脚本或在小工具来实现减低运维人员的运维时间和发现问题的应急反应速度,还是说形成一套完善的机制和流程,加上服务平台的分发作用来实现一个高效安全的运维服务平台的。谢谢



  • question:越来越多的应用提供商选择了docker作为基础架构去部署,这在运维的时候,与传统的那种会有什么样的不同,以及如何利用docker进行安全方面的加固?



  • @QingCloud

    1、最好不要这样用,因为测试系统通常安全性会比较差,那么很容易成为系统的突破口,导致影响线上业务。



  • @兰玛珊蒂

    首先我们需要具备主动发现风险的能力,基于我们发现的这些风险,就能够梳理出来一个list,根据这个list去排排优先级,每个大的风险点就会对应到企业安全建设的一块事情,这样我们把被动响应变成了主动防御和建设,基于安全风险的需求来做安全体系建设,这样比较容易落地实施。

    拿安全问题来推动安全建设是最好的



  • @开心绿茶

    这个就不做额外的说明了



  • 请问对于运维审计部分,我们的侧重点应该覆盖到哪里,那些是必须优先处理的。
    运维授权又怎样合理的优化改进并保证安全性呢?



  • @1135326346

    docker 在部署运维方面比较方便,同样在安全管理方面也会很遍历,不管是发现问题还是解决问题,都很方便,在加固方面可以实现更简单的策略下发,docker本身的安全性也是比较好的。尤其适合我们做一些本身应用直接需要隔离的环境



  • 问题6:想问一下,你的安全平台是独立的还是和运维平台集成在一起的,制度上有没有安全这块标准出来,有没有系统的一些截图之类的?



  • @阿奇尔_佰佰佰大王
    运维审计重点放在一些关键敏感系统的操作日志上,比如核心的dba服务器的 bash日志、数据库操作日志、机器的登陆记录,可以规划出一个核心重点区域出来。当然做了这些以后,最好要做一些合规性检查,避免有人不按规范操作。比如自己拿高权限删各种日志,登陆不走跳板机,这些需要监控起来。



  • 想问一下,你们的安全平台是独立的,还是和运维平台是集成在一起的,有没有运维安全的流程出来look一下,还有方不方便看一下你们的一些安全平台是怎么样的?



  • @shuiche80 收到,我会让讲师尽快给您回复。


登录后回复
 

与 青云QingCloud 社区 的连接断开,我们正在尝试重连,请耐心等待