标签归档:体系思考

企业安全建设的体系思考与落地实践之二

前言

不知不觉中距离上一次发文已经四个多月了,这四个月不仅我个人的生活和工作发生了很多变化,我想大部分人的生活因为这场突如其来的疫情也发生了巨大变化。不过,这个世界每天都在“悄无声息”地变化着,而作为一个“有志的技术青年”,“不悲观、不放弃、勤思考、擅质疑,多实践,频总结”,并积极乐观的生活与工作着才更加重要。

今天这篇文章没有太多的技术细节,也可能会让你觉得很枯燥,甚至连文章的标题我都懒得起(只是临时征用了一个之前的文章标题《企业安全建设的体系思考与落地实践》并“敷衍”地加了个“二”,其实二者关系并不大),但是我觉得如果你实在无聊也可以读一读,或许给你些许启发。

思考

在讲述企业安全建设的演讲PPT和书籍中,我们经常会见到各式各样的建设体系和分类,包括我自己写的这一篇《企业安全建设的体系思考与落地实践》,初看觉得有点道理,但是细想下来又让人有一种“食之无味弃之可惜”甚至是“言之凿凿有何卵用”的感觉。

那么怎么来分析和思考这个问题呢?一种最为简单的方法就是“5W(5 Why)根因分析法”,即深入地渐进式地问自己至少5个“为什么”从而挖掘问题的根本原因。

“为什么看似有道理而实际没卵用?”因为其过于强调解决安全体系建设中遇到的共性问题,而忽略不同企业间的差异性问题。

“为什么重共性、轻异性会导致这个结果呢?”因为大部分企业的安全建设真正的难点不在于共性问题的解决而在于怎么寻找解决差异性问题的思路和方法。

“为什么差异性的问题的解决才是企业安全建设的真正难点?”因为这种差异性问题是由不同企业的发展阶段、业务形式、人员管理等多方面因素所造成的,且没有办法在外面直接找到解决这些差异性问题的安全建设方法。

“为什么企业的发展阶段、业务形式、人员管理等多方面因素会造成这些差异性问题?”因为企业的发展阶段决定了安全在企业发展中所处的地位和价值的不同,业务形式决定了企业面临的安全风险的不同,人员管理决定了企业对安全的认知能力的不同。

根据以上一系列的自问自答,我们似乎找到了产生这类感觉的根本原因是由企业的“发展阶段,业务形式,人员管理”的不同所造成的。那么下一个很自然的问题,怎么才能解决因为这些不同所造成的安全建设过程中的困境呢?笔者认为一种方法就是“对症下药”,将安全体系建设根据企业的发展阶段融入公司业务发展和人员管理之中。

实践

本节笔者将试图以自己当前阶段有限的知识和经验来谈谈具体怎样“对症下药”(注:随着笔者自身认知的提升,未来可能会有更有效的“药”)。既然是“对症”,首先就得知道当前企业具体处于什么阶段。笔者将分别针对以下三种阶段的企业聊聊怎么“下药”。

小型创业公司

这类企业的业务形式往往比较单一,可能是某个特别细分的领域;人员管理相对简单,一般都在50人以下。针对这类企业,谈复杂成熟的体系化安全建设还为时尚早,但是这并不意味着安全不重要,相反这正是安全体系建设的早期阶段,投入少见效快。这时,安全建设的重点应该是保证业务的可用性和完整性。企业的大部分网络资产是员工的办公电脑以及公有云服务,因此提高员工的安全意识以及利用好公有云服务提供商的安全解决方案(例如:WAF,Anti-DDOS,主机防护,堡垒机等)对于企业的安全能力建设必然会事半功倍。因此,周期性的安全意识培训和宣讲,标准化的业务上云流程(资源申请,配置管理,云上安全解决方案等)将是小型创业企业的安全建设的“良药”。

中型传统公司

这类企业一般在某个行业里已经深耕了多年,业务形式比较确定且变化少;人员相对较多,管理也比较稳定。由于企业已经运行了多年人员管理较为固化加之业务变化少,很容易造成其对于安全的体系建设的内在动力不足,更多的驱动力是来自于外在的监管要求(比如网络安全法,等保,GDPR,以及各种行业合规要求等)和安全事件的发生。对于这类企业,安全建设的重点应该以外部监管的要求为支点,以实际安全的落地要求为抓手,以发生的安全事件为“契机”,循序渐进地推动企业往体系化的安全建设的方向去走,将安全的防御策略融入到业务场景帮助业务解决实际运营中遇到的各种安全风险(如:法律法规对隐私数据保护的要求,行业合规对客户数据处理的规定等),并积极协助和推动业务系统往更加安全的方向迭代和升级(如:利用传统企业往IT化、云化的方向演进的趋势,积极融入安全的建设思想,系统性地解决业务系统升级过程中的安全痛点)。同时,通过外部的要求和内部的迭代演进,把安全的认知意识通过已有的成熟的人员管理体系(如:内部培训,绩效考核,工作方法,奖惩制度等)逐步固化到每一个企业员工的日常工作和思考方式中。这个阶段的企业,切忌不可盲目跟风当前“最流行”的安全概念,如果连最基本的日志都收集不全、边界安全都没完善,还谈什么威胁情报、Anti-APT、Red Teaming、零信任之类的,此时这些不过是“镜花水月”、“空中楼阁”罢了。

大型互联网公司

这类公司的业务繁杂且变化迅速;人员繁多且管理复杂。其一般已经具备了相应的的安全防御能力,安全体系建设也已经基本完成。这些公司最大的问题是已有的安全体系无法快递地适配或者说是跟进业务的发展,这就造成快速发展的业务与缓慢跟进的安全建设之间的矛盾。笔者认为,解决这种矛盾的方法之一就是安全建设融入业务发展,业务发展驱动人员管理,人员管理促进安全建设。

640

安全建设融入业务发展

我们常常看到各种安全建设体系里提到很多细分领域如:“安全治理”、“安全合规”、“数据安全”、“SDL”、“基础安全”、“内网安全”、“应用安全”、“安全运营”、“云安全”等等,每个领域往往都是各自为政、单打独斗,相互之间也会彼此独立,却很少能看到如何将这些所谓的细分领域彼此关联并融入到具体业务发展中去。很多时候我们在谈论安全建设时很容易陷入脱离业务来谈安全的怪圈,没有真正地理解业务所面临的的安全困境和痛点,所以需要从“外挂式安全”变成真正的“原生式安全”。

所谓“原生式安全”,并不是什么新的概念,而是将安全建设伴随着业务发展的整个生命周期融入业务的产生、设计、上线、运营、迭代、下线等各个阶段之中,旨在让各个细分领域彼此关联形成一个互相联动的整体。

举个例子,一个新业务的发展往往经过以下流程:业务团队根据市场调研的结果挖掘出客户需求;研发团队根据需求设计并持续开发和交付相关的业务产品和支撑系统;运维团队维护和管理已交付的业务系统;运营团队从上线的业务系统中拉取并分析客户数据做持续运营。我们可以采取下面的方式将安全建设融入到业务发展的生命周期里。

一、安全合规和治理所制定的安全政策既要帮助业务团队确定需求的合规性,也要将各种安全政策和标准通过工具的形式融入到软件/系统开发的SDL流程中(如:CICD流水线),让研发团队在系统架构设计之初通过自动化工具即可了解所设计系统的潜在数据风险等级以及相应的标准化的数据处理方案(如:传输加密与否?存储加密与否?何种类型的加密算法?哪些可用的公共加密组件?哪些可用的专有敏感数据存储系统?等等)。

二、在编码阶段提供给研发团队默认安全配置的代码仓库模板和相应的缺省加固后的开发框架以及统一的认证、授权、密钥存储等公共安全系统或组件。

三、在测试阶段提供集成在流水线之中的动/静态安全测试工具。

四、在部署阶段采用自动化的方式申请资源(如:统一的经过安全加固后的操作系统或容器镜像等)和配置参数。

五、在上线阶段所有资源信息自动同步纳管CMDB并与HR系统中的员工(服务owner团队)联系方式关联。

经过上述方式,我们便可以将安全政策和标准融入业务威胁建模之中,公共安全组件和框架融入业务开发之中,安全测试融入业务测试之中,安全加固融入业务部署之中,安全监控和纳管融入业务上线之中,并最终形成一个标准的具备“原生式安全”的业务发展流程。

业务发展驱动人员管理

随着自带“原生式安全”属性的标准业务发展流程的成熟,必定会对人员的要求越来越高,那些安全意识薄弱的人员会被不断教育或者逐渐淘汰,人员的安全认知能力也会因为成熟的流程而逐渐被提升并固化到日常的工作生活之中,最后变成了每个人员的安全潜意识。

人员管理促进安全建设

当具备安全潜意识的人员越来越多,他们就有可能自主发现更多潜在的安全问题,并输出安全需求,从而促使安全建设的持续发展和迭代,形成一个良性的闭环。

后记

洋洋洒洒写了这么多,其实想表达的意思就是一句话:安全建设应该以“客户”为中心,从安全的受众出发,彼此融入,协同发展。

笔者的一直以来的安全观可以总结成以下几个词:原生(Security-native)、身份(Identity)、自动化(Automation)、情报驱动(Intelligence-driven)。

参考

企业安全建设的体系思考与落地实践

前言

企业安全建设是一个老生常谈的问题,由于每个人的工作经验和心得体会的不同,因此看法和实践通常也不一样。此文仅是笔者最近一段时间关于企业安全建设的体系思考和落地实践的一些个人看法,提供一种思考和分析问题的方式,仅代表笔者当前阶段的认知以及个人的阶段性总结。切记,“尽信书则不如无书”!

什么是体系思考

所谓体系思考,就是通过自身的知识和经验的积累,结合企业的现状,对存在的安全问题进行分类和整理,并总结出一套适合的安全建设体系的思考方式。有了这样的思考能力,就可以帮助我们形成合适的安全方法论来快速解决安全建设过程中的种种问题,做到目标明确,思路清晰,步步为营。

一谈到体系思考,相信很多人的第一感觉肯定是觉得很虚,认为只有不懂技术的人喜欢拿这种东西来装x,并喜欢以此来掩盖自己技术上的不足。实际上,笔者在很长一段时间内也是存在这种观点,然而随着工作经验的慢慢积累,越发觉得这种观点的片面性和不可靠性。不可否认,安全行业或者说所有行业里都或多或少存在以此为噱头的“砖家”,但是这并不能否定掉体系思考的价值和重要性。从某种程度上来说,体系思考可能比具体的技术实践更加重要。举个例子,笔者经常看到一些一个人安全部的文章,写的很详实,建立各种系统,解决各种当前存在的安全问题,当读第一遍的时候你可能会觉得写的不错,可是当你仔细读完之后,你会慢慢发现似乎缺少了一个贯穿始末的中心线,而这个中心线就是“体系思考”。设想,如果我们在做企业安全建设时进行了很好的体系化思考,明确知道当前所处的阶段,当前阶段的目标与困境,实现目标和解决困境的思路,落地实践的计划,那么我们就可以更加清楚地明白我们为什么建设这些系统且哪些安全问题需要被优先解决而不至于陷入“跟风”或者“人云亦云”的窘境,这时我们解决的就不在是一个个的表面问题而是一类的根本问题。

如何进行体系思考

明确体系思考的重要性是进行企业安全体系化建设的重要前提。根据笔者的个人经验,培养体系思考能力一般需要如下过程:

  • 积累:知识的积累是进行体系思考的前提和基础,需要了解和见识足够多的行业最佳实践,各种落地实践中面临的难点,解决难点的思路和方法。
  • 分类:有了一定的知识积累,需要对这些知识进行很好的整理,分类和总结。
  • 思考:当零散的知识点被整理和分类后,需要通过5W1H+Not的方式对这些知识分类进行思考,例如:什么样的角色(who)在什么样的企业(where)在什么样的时间节点(when)出于什么样的的目的(why)以什么样的方式(how)做什么样的事情(what),以及不这么做又会如何(Not)。
  • 实践:通过思考一般可以在大脑中形成初步的体系,但仍旧是“纸上谈兵”,这时就需要透过实践来检测思考的结果,并及时修正一些由于当前思考的局限性造成的误解或者盲点,作为下一轮的知识积累,并如此往复。

如何从体系思考到落地实践

前面写了这么多“废话”,相信能够坚持看到这里的某些同学肯定要喷我了,“你扯了这么多大家都懂的道理,你到底有哪些体系思考的结果呢?Talk is cheap, show me the code”。本节笔者将尝试从具体的企业安全建设来阐述一下我的一些个人看法。

第一步,企业安全建设相关知识的积累,我个人的做法是:

一,学习国内外知名企业(如:国外的FAANG,国内的BAT等)的安全建设的思路和做法,最快捷的方式当然是入职这样的企业,或者也可以通过这些公司公开的blog,paper或者其他安全相关的资料来学习,如:

二,学习公开的网络安全标准和最佳实践,如:

第二步,企业安全建设的分类,这里我分享两种不同的分类方法:

一,基于企业资产保护的安全建设分类。该分类的核心思想是安全建设围绕着资产的保护,比如,我们一般可以把一个企业的资产大致分为以下几类:

  • 基础设施资产:包括网络资产,设备资产,物理资产等;
  • 业务资产:包括应用资产,数据资产等。

二,基于企业数据生命周期的安全建设分类。例如:阿里推出的DSMM (数据安全能力成熟度模型)就是一个比较典型的以数据生命周期安全为核心思想的分类方法:

  • 数据安全过程纬度:包括数据生命周期安全(数据的采集,传输,存储,处理,交换,销毁)和通用安全。
  • 能力成熟度等级纬度:基于统一的分级标准,细化组织机构在各数据安全过程域的五个级别的能力成熟度分级要求。
  • 安全能力纬度:明确组织机构在各数据安全领域所需要具备的能力维度,明确为组织建设、制度流程、技术工具和人员能力四个关键能力的维度。

第三步,企业安全建设的体系思考。根据第二步中提到的两种不同的分类,我们可以分别从不同角度思考如何进行体系建设。
一,针对基于企业资产保护的安全建设分类,我们首先明确我们的核心思想是资产保护,那么所有的安全建设的思路就需要围绕着这个核心来进行。因此,至少需要组建如下的团队来做支撑:

  • 对于基础设施资产,则需要基础架构安全团队来解决企业基础网络安全架构的安全风险和威胁,安全运营中心(SOC)团队来保证安全的持续运营、改进和交付。
  • 对于业务资产,则需要应用安全团队来保证业务程序、软件、系统和服务的安全开发以及业务数据在整个生命周期中的保护,安全合规团队来保证业务数据使用的合法与合规,风控团队来确保业务的连续性和风险的可控性等。

按照上述的思考方式,我们可以根据资产的细化对上述的团队进行更加细致的划分,并最终形成一个完整的安全建设体系。
二,针对企业数据生命周期的安全建设分类,这里的核心思想是数据在整个生命周期中的安全保护,那么当我们在思考安全建设体系时考虑的就应该是怎么通过具体的措施来逐步提升数据在每个阶段的保护措施。比如DSMM就可以按照人类常见的思考和解决问题的思路来理解,即:

  • 过程分割:将数据保护按照生命周期分割成若干个阶段,如:采集,传输,存储,处理,交换,销毁;
  • 列出关键点:针对每个阶段列出所有的关键点PA(过程域);
  • 评估当前水平:对于每个关键点PA评估当前所处的成熟度的等级水平;
  • 细化操作要求:结合当前所处的成熟度等级的对每个关键点PA细化具体的操作要求BP(基本实践);
  • 执行落地操作:根据具体的操作要求BP来进行安全建设和改进。

根据上面的思考过程,我们也可以初步形成一个较为完整的安全建设体系。

第四步,企业安全建设体系的落地实践。我们还是以上面两种基于不同角度思考得出的安全体系来做例子。
一,针对以资产保护为核心的安全体系,落地实践的重点强调的是对于各个细化资产的安全保护。比如,

  • 网络设备的保护:防火墙 (Juniper FW),IPS/IDS (Suricata/Snort),DPI (Bro),堡垒机,Web代理网关(IronPort),邮件网关(FireEye/IronPort),DNS RPZ,VPN,WiFi等;
  • 网络架构的保护:NAC,SDN,ZeroTrust (类似于Google的BeyondCorp),VPC等;
  • 服务器/办公电脑的保护:反病毒,EDR,HIDS/HIPS等;
  • 移动终端的保护:MDM (VMware AirWatch)等;
  • 物理门禁的保护:异常警报,访问日志,监控摄像头等;
  • 业务系统和服务的保护:SDLC (包括安全开发规范以及相关的自动化工具、流程、平台的建设),VRP (漏洞赏金计划)等;
  • 业务数据的保护:数据分类标准,数据处理标准 (传输和存储),数据共享要求,合规管理要求,业务风控体系,通用安全系统和组件(KMS, 统一认证和授权平台,AAA)等;

当具备了以上这些用于保护各种资产的安全系统或者规范后,我们就可以做更多的系统分析和互相联动,具体可以参见笔者之前写的几篇文章《谈一谈如何建设体系化的安全运营中心(SOC)》,《甲方安全建设的一些思路和思考》,《Red Team从0到1的实践与思考》。
二,针对以数据生命周期安全为核心的安全体系的落地实践,DSMM已经表述的很详细了,具体参见http://www.hackliu.com/wp-content/uploads/file/20180326/1522063004775728.pdf,这里就不在赘述了。

此外,有了这些具体的实践措施,如何做到顺利的落地呢?笔者提供以下两种不同的思路供大家参考和探讨:
一,从上而下的思路,此方法适用于大型或者安全成熟度较高的企业。通常情况下,这类企业由于安全建设已经相对完善,安全的目标也相对明确,针对此种情况的落地通常可以从上层设置目标开始,逐步制定短中长期计划,建立相应的支撑项目,最后落地实践。
二,从下而上的思路,此方法适用于中小型或者安全成熟度较低的企业。这类企业由于安全建设的不完善,通常比较难在短时间内找到明确的目标来指导实践的落地。这时,反向操作的效果可能会更好点,比如:先评估当前企业面临的真实威胁、风险和外部要求(如合规和政策需求,第三方合作需求),然后评估优先级,接着建立不同项目来解决问题,随后根据项目的成果来指定短中长期计划,最后利用这些计划和已知的数据来设定目标(即所谓的数据驱动安全),随着安全体系建设的逐步成熟便可以采用从上而下的思路来继续完善和持续改进。

后记

引用一段《中国超越》这本书的作者张维为教授曾经在其书中提到的一段话:

邓小平说过,一个听过枪声的士兵和没有听过枪声的士兵就是不一样,实地考察过一个地方和没有考察过也是不一样的。

笔者认为这句话同样适用于这篇文章的主题,如果没有亲身参与过体系化的安全建设或进行过体系化的安全思考,那么本文所提到的内容可能并不能使您感同身受或者有所收益,但期望这篇拙劣的文章可以给您带来一丝思考和启发。

最后,在此深深地感谢平时在工作学习中给予我帮助和指导的行业前辈们以及来自于“基于量子透明计算的可信自主可控区块链式拟态安全态势感知的威胁情报联盟微信交流群”的群友们,让笔者深知学习、思考、分享和交流的重要性。

参考

谈一谈如何建设体系化的安全运营中心(SOC)

0x00 前言

本文主要是谈谈笔者对于如何建设体系化的安全运营中心(SOC)的一点经验和思考,观点仅代表个人,仅供参考,不具普遍意义。

0x01 什么是SOC

SOC, 即Security Operations Center,我们一般称之为安全运营中心,主要是负责企业的入侵检测,应急响应,以及安全监控等,通常我们会笼统地概括成两个方面即Blue Team (Defensive Security)和Red Team (Offensive Security),详见《甲方安全建设的一些思路和思考》,这里不再赘述了。

那么什么样的企业需要SOC呢?笔者认为凡是有安全团队的企业都需要这样的一个团队。唯一的区别在于,企业规模的大小和业务的复杂性决定了SOC的职责范围和其运作方式。举个例子,对于规模较大的互联网企业,它的SOC的职责包括但不限于以下几种:

  • Incident Response (应急响应)
  • Malware Analysis (病毒分析)
  • Digital Forensics (电子取证)
  • Threat Hunting (入侵检测)
  • Threat Intelligence (威胁情报)
  • Vulnerability Management (漏洞管理)
  • Penetration Testing (渗透测试)
  • Red Teaming

而规模较小的企业,则可以按照企业实际的规模和业务需要逐步包含以上的职责范围。

0x02 如何组建SOC

理论基础

在组建SOC之前,我们需要对一些基本安全理论有一定的了解。只有掌握了这些基础理论知识,我们在组建SOC的时候就会比较有针对性和方向性。

应急响应的ACERR处理模型

一般情况下,任何安全事件的应急响应都可以分为以下几个阶段:

  • Assessment(评估):主要是初步梳理安全事件的类型,产生的原因和评估潜在影响范围;
  • Containment(控制):这个阶段主要是快速找到止损/减轻方案(或者是临时应对措施)将事件影响尽可能控制在最小范围内;
  • Eradication(消除):这个阶段是要找到安全事件产生的根本原因并提出和实施根治方案;
  • Recovery(恢复):主要是确保所有受影响的系统或者服务完全恢复到安全状态;
  • Review(总结和审查):这是每个应急响应的最后阶段主要是总结和梳理安全事件处理和响应的整个时间线和应对方案,学习和审查安全事件产生的根本原因并生成知识库以便以后遇到同类安全事件可以快速地找到处理和应对的方法。

Cyber Kill Chain模型

Cyber Kill Chain模型将攻击者的攻击过程分解为如下七个步骤:

  • Reconnaissance(侦查): 入侵者选择目标,对其进行研究,并尝试识别目标网络中的漏洞;
  • Weaponization(工具化): 入侵者创建针对一个或多个漏洞定制的远程控制的恶意软件工具,例如病毒或蠕虫;
  • Delivery(投送): 入侵者将恶意软件工具投递到目标(例如,通过电子邮件附件,网站或USB驱动器);
  • Exploitation(攻击利用): 恶意软件工具的利用触发器,它在目标网络上执行来利用漏洞;
  • Installation(安装植入): 恶意软件工具安装入侵者可用的后门;
  • Command and Control(命令与控制): 恶意软件使入侵者能够对目标网络进行持久访问和利用;
  • Actions on Objectives(目标行动): 入侵者采取行动实现其最终目标,例如数据泄露,数据销毁或加密勒索。

通过以上的模型将攻击者的攻击过程分解,我们就可以找到对应的防御方法:

  • Detect(检测):确定攻击者是否在嗅探或者扫描;
  • Deny(拒绝):防止信息泄露和未授权访问;
  • Disrupt(中断):阻止或更改攻击者的出站流量;
  • Degrade(降级):反击命令与控制;
  • Deceive(欺骗):干扰命令与控制;
  • Contain(控制):网络分段隔离。

MITRE’s ATT&CK矩阵

MITRE’s ATT&CK矩阵,是一个用于分析网络入侵者的战术和技术的知识库,它可以用于了解和分析攻击者所有当前已知的攻击技术和行为,以便于规划安全性改进以及验证防御体系是否正常工作。通俗地说,这其实就类似于对攻击者进行画像,再利用这个入侵分析矩阵来全面了解我们的攻击者从而帮我们来设计和改进我们的防御体系。

系统工具

这部分可以参照以下资源,这里就不再赘述了:

0x03 SOC如何工作

当我们组建好了SOC,如何才能让其有效的工作呢?下面我将分别从组织架构,职责划分,有效协作几个方面来做简单地的讲解。

组织架构

SOC就像一台机器,而SOC的每个组成部分就是机器的一个个零部件。一个体系化的SOC运营就是把整体的安全运营拆分成一个个独立的子模块,通过各个子模块之间的相互配合和协作,最终有效处理一个复杂的安全事件。从组织架构上,一般会把SOC分解为Defensive Security团队和Offensive Security团队,如下:

 

职责划分

SOC组织架构是需要支持不同的工作职责的,我们把这些不同的子模块/团队按照职责的不同划分成以下几类:

Tier 1团队

主要负责直接应对和处理企业内外的各种安全事件,例如:Incident Response,提供7*24小时的应急响应服务。这类团队通常需要具备足够的技术知识面,良好的沟通和协调能力,出色的安全事件分析能力等。

Tier 2团队

主要为Tier 1团队提供技术上的深度支持,例如:Malware Analysis,Digital Forensics,Threat Hunting,Threat Intelligence,以及Vulnerability Management等。这类团队注重的是分析和调查安全事件和问题的根本原因,实施有效的应对措施和防御策略。

Tier 3团队

主要负责从攻击视角来检验当前已有的入侵检测和防御能力,例如:Penetration Testing和Red Teaming等。这类团队侧重于站在入侵者的角度来模拟实际的攻击者对企业资产和信息实施有计划和目的的渗透和入侵,以此来检验Tier 1和Tier 2团队的应对和处置能力,包括:

  • 能否检测到?
  • 多久能检测到?
  • 检测到什么程度?
  • 有无实时阻断能力?
  • 多久能阻断?
  • 等等…

有效协作

当我们已经具备了以上的组织架构和清晰的职责划分,接下来一个问题就是如何让各个团队之间进行有效的协作从而发挥最大的功效来应对各种安全威胁,我将尝试用下面几个典型的案例来简单加以阐述。

被动应急与响应

Incident Response团队收到一个员工上报的钓鱼邮件,进过初步分析发现该钓鱼邮件附带一个HTML文件引诱收件人点击一个外部链接来下载和打开一个Word文档文件,沙箱分析这个文档不包含任何宏来启动PowerShell或者VB脚本等常见利用方法。

首先,Incident Response团队对外部可疑域名执行DNS sinkhole操作。应急响应人员迅速查询邮箱安全网关日志发现多个内部员工收到了来自于该外部可疑发件人的邮件,并立即清除所有邮件服务上的该可疑邮件,同时更新邮件网关的检测和过滤规则。

随后,Malware Analysis团队去深度分析和调查该Word文档。经调查发现该可疑样本利用了一个已公开披露的Office软件的漏洞执行命令从Stage 2域名下载并安装后门来链接C2的IP,调查结果反馈给Incident Response团队。

然后,Incident Response团队根据已获得域名和C2信息分析网络,EDR,DNS,DHCP等日志找到所有执行该Word文档的终端电脑和用户。

Digital Forensics团队跟进对已感染终端进行实时或者线下取证分析获取到更多的IOC和TTP信息,调查结果同样反馈至Threat Hunting和Incident Response团队。

Incident Response团队梳理所有已知信息(包括:域名,IP,文件hash,命令行,注册表等等)添加至IOC检测平台,确保终端防病毒软件可以检测所有已知的后门样本,确保所有已知恶意域名和IP被block,隔离所有已感染主机,重置已感染用户的用户凭证等等。

Vulnerability Management团队扫描所有存在该office软件漏洞的主机并进行补丁推送。

Threat Hunting团队根据所有已知的TTP开发和添加检测规则或者模型用于主动检测。

主动检测与响应

Threat Hunting团队针对某类恶意软件的行为特征开发了一个检测规则或者模型,并触发了一例可疑的告警。

Incident Response团队的安全分析师跟进调查EDR日志发现某终端主机确实存在与该类恶意软件类似的行为特征,并联系Digital Forensics和Malware Analysis团队对感染主机进行实时取证分析和Malware分析,结果显示该恶意软件生成了可以bypass当前终端防病毒软件的后门,并利用了一些当前检测规则未知的方式来与C2通信。同时,分析发现该恶意软件的感染是由于员工安全意识不足插入了不可信的U盘等外部设备引起的。

之后,与被动应急与响应类似,Incident Response团队梳理所有已知信息(包括:域名,IP,文件hash,命令行,注册表等等)添加至IOC检测平台,确保终端防病毒软件可以检测所有已知的后门样本,确保所有已知恶意域名和IP被block,隔离所有已感染主机,重置已感染用户的用户凭证等等。并对引起该问题的员工所在的部门强制进行企业安全意识培训。

最后,Threat Hunting团队根据所有最新调查发现的TTP来更新或者优化当前的检测规则或者模型,以此来形成一个有效的主动检测与响应的安全闭环。

威胁情报分析与利用

Threat Intelligence团队通过情报共享组织掌握到了一条最新的情报,即有黑客在知名黑客论坛售卖能够收集某些特定企业的用户数据的工具,其进行初步地分析和梳理该情报后发现:

  • 情报源的可靠性较高,因为其发布于知名黑客论坛,且该黑客以往多次售卖过类似可利用的工具;
  • 所在公司确实是该工具宣称的特地目标企业之一;
  • 该工具的主要作用是收集目标企业的客户支付信息和账户登录凭证信息;
  • 该工具的分发手法主要是社工和web攻击。

Threat Intelligence团队根据情报共享组织提供的已知IOC和OSINT信息整理出了初步的TTP,并反馈给Incident Response团队和Threat Hunting团队。

随后,Incident Response团队跟进分析确定了下一步的调查方向,比如:

  • 监控最近一段时间的登录接口以及涉及用户支付流程的页面是否产生了异常流量;
  • 检查最近企业的钓鱼邮件的过滤和分析结果,如钓鱼邮件的上升趋势;
  • 关注终端的恶意代码检查和趋势分析来尝试找到更多的可能的攻击痕迹;
  • 利用一些已知的IOC与内部的日志监控系统做匹配和联动,例如:该黑客的id是已知的,可以尝试做更多的匹配分析来检查恶意代码中是否存在与这个id有关的关键词等。

一旦上述任何调查方向有了新线索,便可以联系Tier 2团队跟进分析和调查,确定更多IOC和TTP,并做相应的应对措施。

最后同上,Threat Hunting团队根据所有已知的TTP开发和添加检测规则或者模型用于主动检测。

Red Teaming实践

Red Teaming团队通过以下的TTP来模拟Threat actors入侵企业从而检验Tier 1和Tier 2团队能否进行有效检测和响应。

目标(Goals)

模拟某个国家级的APT组织来入侵企业从而获得企业的敏感数据

战术(Tactics)

  • 鱼叉式钓鱼
  • 物理访问
  • 社工
  • 远控软件的投递与安装
  • 确保后门软件不能被虚拟机,debugger或者沙箱分析
  • 后门使用加密配置文件,支持高度定制和可配置化,如

    • phishing基础架构
    • C2基础架构
    • 持久化机制
    • 加密密钥
  • 基于Domain Fronting的C2通信

技术(Techniques)

  • PowerShell
  • 脚本化与无文件化,如:MsBuild.exeDotNetToJScript
  • 软件打包bypass防病毒软件
  • 保证持久化

    • 计划任务
    • 注册表/启动目录
    • 修改快捷方式
    • WMI(Windows Management Instrumentation)事件订阅
  • Bypass UAC来实现本地提权
  • Pass the Hash/Pass the Ticket来实现横向移动
  • Tor proxy配置以及Domain Fronting绕过流量检测

流程(Procedures)

初始感染

利用鱼叉式钓鱼发送钓鱼邮件,将恶意程序放置在信誉度良好的外部站点上,编写精心设计和欺骗性很高的邮件内容来引诱目标用户点击该外部链接打开恶意文档,如word文档,hta文件等。

建立根基

一旦目标用户打开恶意文档,执行PowerShell脚本下载不具备危险性的XML文档并调用MsBuild.exe来执行XML文档中内嵌的恶意代码注入内存来绕过防病毒检测生成一个具备少量功能的downloader,如偷取用户凭证,收集浏览器历史,或者截图等。

权限提升

通过已安装的downloader下发特定的用户凭证盗取工具(如:WCE, Mimikatz, Procdump, Keylogger等)来盗取用户密码或密码hash,同时收集防病毒软件的信息并绕过防病毒来完成权限提升。

内部侦查

通过一些常见的系统命令或者下发定制脚本来探测内网信息,如枚举域信息,组策略对象中的各种用户和用户组配置信息。

横向移动

使用收集到的用户凭证,PtH (Pass the Hash), PTT (Pass the Ticket)利用RDP,PsExec, Mimikatz, RemCom等来完成内网的横向移动。

维持权限

利用计划任务,注册表/启动目录,修改快捷方式等方式来保证持久化。

完成目标

逐步渗透内网的核心机器,偷取企业的核心数据,并利用DNS隧道,Domain Fronting或者加密数据通过HTTPS等更加隐秘的方式外带出去,达成最终目标。

实践活动完成后,Red Teaming团队与Tier 1和Tier 2团队复盘整个模拟入侵过程的时间线,分析和总结没有被检测到的点以及整个入侵防御体系存在的问题,并提出改进方案,以便在下一次的实践中检验改进成果。

0x04 总结

笔者观点,SOC的体系化建设:系统工具是基础,体系结构是重点,有效协同是关键。

0x05 参考