分类目录归档:安全建设

态势感知的前世今生(之一)

本系列文章将分为几篇介绍一下态势感知的发展历程和行业实践。

起源与定义

态势感知的概念起源于军事理论,早在春秋时期著名的兵书《孙子兵法》中就有提到“知己知彼、百战不殆”,这估计也是最早把对敌情态势的感知作为克敌制胜的关键因素的观点了。

第一次世界大战期间“空战之父”德国的王牌飞行员Oswald Boelcke也曾经提到类似的说法:

the importance of gaining an awareness of the enemy before the enemy gained a similar awareness, and devised methods for accomplishing this.(先敌一步掌握对方的态势并设计出相应的实现方法至关重要)

第二次世界大战期间德国空军飞行员Erich Alfred Hartmann发明了著名的SDAR空战战术理论(即See-Decide-Attack-Reverse),首先通过观察敌人决定如何继续攻击,然后才进行正式攻击,接着脱离接触并重新评估局势进行下一轮的观察。

越南战争期间美国空军上校John Boyd结合空战中的经验和教训总结形成了著名的OODA模型(即Observe-Orient-Decide-Act),通过观察、调整、决定、行动,反复推进并以此形成循环,该模型在美国空军中获得迅速推广。

1995年前美国空军首席科学家Mica Endsley仿照人类的认知过程建立并结合空军战术理论正式发表了关于“态势感知”的第一个理论模型(Endsley模型),该模型将态势感知分为三个阶段,即态势感知、态势理解、态势预测。此后,态势感知开始广泛应用于医疗救援、交通、航空、执法、网络安全等其他领域。

随着计算机网络的发展以及网络安全复杂性的凸显,“网络安全态势感知(Cyber Security Situation Awareness,CSSA)”也越来越得到重视并逐渐成为网络安全领域不可或缺的重要组成部分之一。如今,比较主流的网络安全态势感知的定义主要来自于Endsley提出的,即态势感知是对目标网络空间中的安全威胁进行感知,应用适当的评估、评价、推理分析机制理解攻击意图,并以此预测未来的安全态势

行业实践

有了以上对态势感知发展历程和主流定义的基本了解,可以通过几个行业实践来深入理解一下如何构建网络安全态势感知体系。

美国国家态势感知体系

导读:美国国家态势感知体系以管治为核心,以各自构建、独立管理、信息共享、统一协调、常态化呈现为策略。

美国国家态势感知体系主要由国土安全部(DHS/CISA)负责的联邦政府网络态势感知体系和国家安全局(NSA/CSS)负责的军事网络态势感知体系构成,两者独立构建和运作,但通过情报共享机制由国家情报总监办公室(ODNI)协调汇总所有情报机构的态势信息生成总统每日内参(PDB)提交给美国总统和少数政府高层官员作为国家战略决策的重要输入之一。

pdb

国土安全部通过国家网络空间安全保护系统(NPS),也称ENISTEIN系统,构建了联邦政府的网络态势感知体系。

  • 管理组织:由国土安全部负责统筹管理。
  • 实施阶段:共分为三个阶段进行实施,即2003-2005年的EINSTEIN 1(E1),2005-2008年的EINSTEIN 2(E2),2010-2012年的EINSTEIN 3 Accelerated(E3A)。
  • 落地进展E1/E2已在76个政府机构落地,28个政府机构暂未实施;E3A Email已在78个政府机构落地,8个政府机构正在进行中或延期中,18个政府机构暂未实施;E3A DNS已在82个政府机构落地,5个政府机构正在进行中或延期中,17个政府机构暂未实施。
  • 度量指标:主要有三个度量指标,即潜在恶意行为安全事件平均通知时间、及时告警受潜在恶意行为影响的机构的百分比、被EINSTEIN系统检测或阻断的国家级APT攻击安全事件的百分比。
  • 法案标准:美国政府制定了一系列法案支撑国家态势感知体系的构建和运作,包括《国土安全法案(HSA)》、《情报改革和恐怖主义预防法案(IRTPA)》、《联邦政府信息安全管理法案(FISMA)》、《总统每日内参(PDB)》、《结构化威胁信息表达标准(STIX)》、《自动化威胁信息交换协议(TAXII)》。
  • 关键能力:有四个主要的关键能力,即入侵检测、入侵防御、安全分析、信息共享。
  • 核心技术:构建关键能力的核心技术包括DFI/DPI/DCI技术、智能安全分析(LRA)、DNS Sinkhole、主动防御(TUTELAGE项目)、自动化威胁指标共享(AIS)。
  • 人员编制:在2008-2017年9年间从最初的4人发展到127人,随后人员编制逐年增加,2018年152人,2019年139人,2020年169人,2021年176人。
  • 项目预算:在2008-2017年9年间合计投入了27.88亿美元,随后每年保持约4亿美元的年度预算投入,其中运营预算是建设预算的3.3倍。

cnci

欧洲金融行业态势感知体系

导读:欧洲金融行业态势感知体系以市场驱动为核心,以构建统一的威胁情报共享计划为策略。

欧洲通过建立市场驱动的泛欧金融基础设施欧洲网络韧性委员会(ECRB)的网络信息和情报共享计划(CIISI-EU)构建了泛欧金融行业的态势感知和威胁情报共享体系。

  • 管理组织:由CIISI-EU秘书处负责统筹管理。
  • 组织成员:该计划成员包括泛欧金融基础设施(SWIFT)、中央银行、关键服务提供商、欧盟网络安全局(ENISA)、欧洲刑警组织(EUROPOL)等。
  • 落地进展:该计划总共历经了约2年的时间从专项工作组成立(2019年2月)到项目正式转运营(2020年12月),其中包括需求收集及规划设计,第三方威胁情报服务商的识别、评估、选择和采购,规则与流程制定,中心化情报共享平台构建,组织成员接入系统的部署等。
  • 度量改进:为了确保该计划的持续运作和运营,分别从成员组织间的信任与开放度、成员组织的主动参与率、成员组织的高级管理层的参与度、计划的意义与价值评估、计划的创新发展评估几个指标进行度量和改进。
  • 政策标准:该计划制定和发布了若干政策标准,包括《Terms of Reference》、《Community Rulebook》、《信息交换协议(TLP)》、《结构化威胁信息表达标准(STIX)》、《恶意信息与情报共享标准(MISP)》、《MoSCoW信息分享框架》。
  • 关键能力:主要包括威胁情报种子、中心化情报共享平台(MISP)、信息与情报共享、战略级情报分析、报告呈现、告警通知、定期可信任成员间线上/线下会议、战略信任关系等。
  • 情报类型:根据态势感知与威胁情报呈现对象的不同主要有三类情报,包括面向董事会的战略性情报、面向CISO或安全主管的运营性情报、面向安全运营工程师的战术性情报。

ecrb

参考

关于BIS的《信息安全控制:网络安全条目》的解读及影响分析

本文主要是对美国商务部工业和安全局(BIS)于2022年5月26日发布的《Information Security Controls: Cybersecurity Items》的详细解读及该细则发布后对中国政府和企业的影响分析。

0x00 背景介绍

his

1996年7月,在美国的主导下以西方国家为主的33个国家在奥地利维也纳签署了《瓦森纳协定》(简称“瓦协”Wassenaar Arrangement),决定从1996年11月1日起实施新的控制清单和信息交换规则。其中包含两份控制清单:一份是军民两用商品和技术清单,涵盖了先进材料、材料处理、电子器件、计算机、电信与信息安全、传感与激光、导航与航空电子仪器、船舶与海事设备、推进系统等9大类;另一份是军品清单,涵盖了各类武器弹药、设备及作战平台等共22类。

2004年,美国商务部工业和安全局(BIS)发布了出口管制条例(EAR)的许可例外的国家分组的附件《Supplement No.1 to Part 740-COUNTRY GROUPS》,第一次将中国(China(PRC))列为D:1(国家安全)、D:3(生物化学)、D:4(导弹技术)组中,从而限制涉及国家安全、生物化学、导弹技术领域的商品或技术出口到中国。

cn1

2013年,《瓦森纳协定》将网络安全条目纳入出口管制的范围之中,其中包含了对“入侵软件”的定义,具体包括:

  • 提供入侵软件的命令与分发平台的软硬件
  • 支撑命令与分发平台的开发、部署、使用的技术
  • 用于入侵软件自身开发的技术

2014年,BIS刷新了出口管制条例(EAR)的许可例外的国家分组的附件《Supplement No.1 to Part 740-COUNTRY GROUPS》,开始将中国也列为D:5(美国武器禁运国家)组中。

cn2

2015年5月20日,BIS针对《瓦森纳协定》中关于网络安全条目的出口管制规定的适配和对于美国工业界的影响发布了建议规则,并公开向美国各界征求意见。

2017年12月,经过美国的提议和协商《瓦森纳协定》综合了美国各界的反馈建议和BIS的建议规则最终同意了对原先的网络安全条目的出口管制项做了部分调整和修正,具体体现在三个方面:

  • 对恶意软件的行为的定义做了更加清晰的描述,强调了可被用来进行“命令与控制”的软硬件需要被出口管制;
  • 在“入侵软件”的开发技术中,用于“漏洞披露”和“网络事件响应”的技术可被出口管制豁免
  • 在“入侵软件”的生成、命令与控制、交付技术中,仅用于提供基础软件的更新与升级可被出口管制豁免。

2018年8月13日,美国总统签署生效了《出口控制改革法案》(ECRA),从法律上赋予了BIS发布和维护《信息安全管控:网络安全条目》细则的权力。

2021年10月21日,BIS基于2017年《瓦森纳协定》中关于网络安全条目的出口管制项的修正结论,发布了《信息安全管控:网络安全条目》细则暂行版建立了一个新的许可例外即授权网络安全出口许可例外(ACE)并向美国各界征求意见,并计划2022年1月19日生效。

ci1

2022年1月12日,BIS根据美国各界对《信息安全管控:网络安全条目》细则暂行版的反馈建议延迟其生效时间至2022年3月7日,并同意提供额外的细则实施指导和FAQ。

ci2

2022年5月26日,BIS发布了《信息安全管控:网络安全条目》细则最终版并生效执行。

ci3

0x01 细则内容

(a)范围

授权网络安全出口许可例外(ACE)授权本节(b)段规定的“网络安全条目”的出口、再出口和转让(国内),包括视为出口和再出口,但须受本节(c)段规定的约束。

本许可例外下被视为出口和再出口的物项均需要被授权,但本节第(c)(1)段所述的被视为向E:1和E:2组的国家,及本节(c)(2)段所述的某些“政府最终用户”,并受本节(c)(4)段所述的最终用途限制的约束的出口或再出口除外。即使ACE不适用于某些特定场景,其他许可例外也可能适用。例如,许可例外GOV(第740.11节)授权向美国政府机构和人员出口某些产品;许可例外TMP(第740.9(a)(1)条)授权在某些情况下出口、再出口和转让(在国家)贸易工具。

(b)定义

以下术语和定义仅用于授权网络安全出口许可例外(ACE)。

(1)网络安全条目(Cybersecurity Items):是ECCN 4A005、4D001.a(用于4A005或4D004)、4D004、4E001.a(用于4A005、4D001.a (用于4A005或4D004)或4D004), 4E001.c、5A001.j、5B001.a(用于5A001.j)、5D001.a(用于5A001.j),5D001.c(用于5A001.j或5B001.a (用于5A001.j))和5E001.a(用于5A001.j或5D001.a (用于5A001.j))。

(2)数字组件(Digital Artifacts):是在信息系统上被找到或发现的条目(例如,“软件”或“技术”),这些条目可以显示与该信息系统的使用、危害或其他影响有关的过去或现在行为。

(3)最惠待遇网络安全最终用户

具体包括:
(i)美国子公司;
(ii)银行和其他金融服务提供者;
(iii)保险公司;
(iv)提供医疗或以其他方式进行医学实践的民间卫生和医疗机构,包括医学研究。

(4)政府最终用

就本节而言,主要是指提供任何政府职能或服务的国家、区域或地方部门、机构或实体,包括代表该实体行事的实体或个人。本术语不包括本节第(b)(3)段中列出的任何“最惠待遇网络安全最终用户”。此术语包括但不限于:
(i)国际政府组织;
(ii)政府经营的研究机构;
(iii)高敏感政府最终用户;
(iv)低敏感政府最终用户;
(v)完全或部分由政府或政府授权机构的所经营或拥有的公共事业机构(包括电信服务提供商和互联网服务提供商);
(vi)完全或部分由政府或政府授权机构的所经营或拥有的交通枢纽和服务(例如:航空公司和机场、船舶和港口、铁路和火车站、公共汽车、卡车和公路);
(vii)完全或部分由政府或政府授权机构的所经营或拥有的涉及制造、分销,或提供《瓦塞纳协定》军用清单中规定的物品或服务的零售或批发公司。

(5)就本条而言,“部分由政府或政府授权机构经营或拥有”是指外国政府或政府授权机构实际拥有或控制(直接或间接)外国实体25%或更多的有表决权证券,或外国政府或政府授权机构有权任命外国实体董事会过半数的董事成员。

(c)约束

授权网络安全出口许可例外(ACE)不授权以下场景中的“网络安全条目”的出口和再出口、或(国内)转让:

(1)出口至《Supplement No.1 to Part 740-COUNTRY GROUPS》国家分组清单中的E:1或E:2组的国家。

(2)出口至《Supplement No.1 to Part 740-COUNTRY GROUPS》国家分组清单中的D:1、D:2、D:3、D:4或者D:5组的国家的“政府最终用户”,但是排除以下的情况:

(i)数字组件(Digital Artifacts)(特指与涉及由“最惠待遇网络安全最终用户”拥有或运营的信息系统的网络安全事件有关的数字组件),向同时列在D组和A:6组的国家的警察或者司法机构提供用于刑事或民事调查或起诉的网络安全事件;

(ii)“网络安全条目”,向同时列在D组和A:6组的国家的国家计算机安全事件应急响应小组提供用于应对网络安全事件、“漏洞披露”,或用于刑事或民事调查或起诉的网络安全事件。

(3)本节(c)(1)和(c)(2)段中的约束也适用于与“漏洞披露”和“网络事件响应”有关的活动,包括出口、再出口和转让(国内)。

注解:就本节(c)(1)和(c)(2)而言,ECCN 4E001.a和4E001.c中已经排除了“漏洞披露”和“网络事件响应”。

(4)出口至《Supplement No.1 to Part 740-COUNTRY GROUPS》国家分组清单中的D:1组或D:5组国家的“非政府最终用户”,但是排除以下的情况:

(i)向任何“最惠待遇网络安全最终用户”提供ECCN 4A005、4D001.a(适用于4A005或4D004)、4D004、4E001.a(适用于4A005, 4D001.a (适用于4A005或4D004)或4D004)和4E001.c中定义的“网络安全条目”。

(ii)“漏洞披露”或“网络事件响应”。

(iii)被视为出口。

(5)如果出口商、再出口商或转售商在出口、再出口或转让(国内)时“知道”或“有理由知道”(包括视为出口和再出口)”网络安全条目”将用于在未经信息系统所有者、经营者或管理员(包括此类系统内的信息和流程)授权的情况下影响信息或信息系统的机密性、完整性或可用性。

0x02 影响分析

导读:对中国政府最终用户及中国非政府最终用户的影响分析

根据BIS在2022年5月26日发布的《信息安全管控:网络安全条目》细则最终版中描述的授权网络安全出口许可例外(ACE),可以整理出以下的ACE例外的申请流程和典型应用场景。

inf1

if2

从以上分析可知,自2022年5月26日起,对中国政府最终用户及中国非政府最终用户的影响主要体现在以下几个方面:

  • 出口和再出口、或(国内)转让给已被列入实体清单中的中国政府或非政府企业最终用户的的“网络安全条目”或“数字组件”即使用于“漏洞披露”、“网络事件响应”也需要优先遵从实体清单中的管控要求。
  • 出口和再出口、或(国内)转让给中国政府最终用户的“网络安全条目”、“数字组件”即使用于“漏洞披露”、“网络事件响应”也不允许ACE例外,换句话说,中国政府最终用户将无法直接获得美国软件供应商提供的涉及“入侵软件”的“网络安全条目”或“数字组件”的漏洞披露以及网络事件响应相关的信息,对于非“入侵软件”的基础软件的漏洞信息获取和更新升级暂无影响。
  • 出口和再出口、或(国内)转让给中国非政府最终用户的“网络安全条目”、“数字组件”用于“漏洞披露”、“网络事件响应”允许ACE例外,亦即,中国非政府最终用户仍旧可以直接获取来自于美国软件供应商提供的涉及“入侵软件”的“网络安全条目”或“数字组件”的漏洞披露以及网络事件响应相关的信息,对于非“入侵软件”的基础软件的漏洞信息获取和更新升级暂无影响。

0x03 FAQ

一、该细则是不是美国近期针对中国的进一步出口管制制裁?

从BIS的出口管制条例实施的历史背景可以看出,BIS早在2004年和2014年就分别将中国加入了D:1、D:3、D:4及D:5组的国家分组中并实施严格的出口管制;此次细则的发布其实是对自2013年《瓦森纳协定》将网络安全条目纳入出口管制的范围之中以来对美国工业界出口所造成的负面影响和合规成本上升后的一定程度上的松绑和微调,以及对执行过程中一些模糊问题的明确、调整和修正。实际上,并没有看出明显的针对中国的进一步出口管制制裁。

二、中国政府和企业还能否收到海外的漏洞信息?

参见上文中的分析,涉及“入侵软件”的“网络安全条目”或“数字组件”定义中的软件和技术,中国政府将无法直接获得美国软件供应商的漏洞披露以及网络事件响应相关的信息,但是中国非政府企业仍旧可以直接获取来自于美国软件供应商的漏洞披露以及网络事件响应相关的信息;此外,对于非“入侵软件”的基础软件的漏洞信息暂无影响。

三、中国政府和企业正在使用的美国软件公司的基础软件还能否正常更新和升级?

纵观BIS细则全文和历史脉络,该细则并没有涉及基础软件的更新和升级,只是明确强调了在“入侵软件”的生成、命令与控制、交付技术中,仅用于提供基础软件的更新与升级可被出口管制豁免。也就是说,中国政府和企业正在使用的非“入侵软件”的基础软件(如Windows、office、oracle等)的正常更新和升级不在该细则的管控范围内,因此暂时不受任何影响。

四、对于中国非政府企业的跨境安全研究和合作及漏洞奖励计划有什么影响?

对于已被列入实体清单中的中国非政府企业会存在一定的影响,因为BIS在2022年5月26日发布的《信息安全管控:网络安全条目》细则最终版优先遵从实体清单的管控要求。

faq

对于暂未被列入实体清单中的中国非政府企业在获取海外安全研究者或公司的漏洞信息或网络安全事件响应信息暂无影响。

0x04 附录

术语解释

网络安全条目(Cybersecurity Items)

来源:https://www.bis.doc.gov/index.php/documents/pdfs/2872-cyber-tools-le-ace-faqs-final-version-nov-2021/file

The Category 4 ‘cybersecurity items’ related to “intrusion software” (which is defined in Section 772.1 of the EAR) are identified by the following ECCNs, summarized as follows:

  • 4A005 : Systems and equipment specially designed or modified for the generation, command and control, or delivery of “intrusion software”, and components of those systems or equipment that are themselves specially designed or modified to have these capabilities.
  • 4D004 : “Software” specially designed or modified for the generation, command and control, or delivery of “intrusion software”.
  • 4E001.c : “Technology” for the “development” of “intrusion software”.
    Note: 4E001.c does not apply to “vulnerability disclosure” or to “cyber incident response”
  • 4D001.a (for 4A005 or 4D004) : “Software” specially designed or modified for the “development” or “production” of items controlled by ECCN 4A005 or 4D004.
  • 4E001.a : “Technology” (which may include “source code”) for the “development”, “production” or “use” of items controlled by ECCN 4A005, 4D004 or 4D001.a (for 4A005 or 4D004).
    Note: 4E001.a does not apply to “vulnerability disclosure” or to “cyber incident response”

Meanwhile, the Category 5 – Part 1 ‘cybersecurity items’ related to IP network communications surveillance are identified by the following ECCNs, summarized as follows:

  • 5A001.j : Systems and equipment specially designed or modified to have all (not just some) of the functional characteristics and technical capabilities listed in ECCN sub-paragraphs j.1 (5A001.j.1.a., .b, .c) and j.2 (5A001.j.2.a, .b), and components of those systems or equipment that are themselves specially designed or modified to have all these characteristics.
  • 5B001.a (for 5A001.j) : Test, inspection and production equipment specially designed for the “development” or “production” of items controlled by ECCN 5A001.j, and components or accessories (of the test, inspection and production equipment) that are themselves specially designed or modified as such.
  • 5D001.a (for 5A001.j) : “Software” specially designed or modified for the “development”, “production” or “use” of items controlled by ECCN 5A001.j.
  • 5D001.c. (for 5A001.j or 5B001.a (for 5A001.j)) : “Software” specially designed or modified to provide characteristics, functions or features of items controlled by ECCN 5A001.j or 5B001.a (for 5A001.j).
  • 5E001.a (for 5A001.j or 5D001.a (for 5A001.j)) : “Technology” (which may include “source code”) for the “development”, “production” or “use” (beyond mere operation) of items controlled by ECCN 5A001.j or 5D001.a (for 5A001.j).

参考链接

关于大型互联网企业DevSecOps体系构建的总结与思考

最近几年随着软件供应链攻击和数据安全事件的频繁出现,企业面临着重大的软件供应链安全和数据泄露风险,这间接促使了越来越多的企业开始关注DevSecOps,并且期望借此来解决相关的安全风险。

在开始今天的分享之前,先简单介绍一下DevSecOps的定义,这里主要采用援引于DoD(美国国防部)的一段定义,即DevSecOps实际上是一种旨在统一软件开发、安全、运维运营的有组织的软件工程文化和实践。

DevSecOps is an organizational software engineering culture and practice that aims at unifying software development (Dev), security (Sec) and operations (Ops).

devsecops

由于DevSecOps理念是将安全防御思维贯穿到整个软件开发和运维运营阶段,这就使得DevSecOps体系的构建变成一个可能的解决数据安全和供应链安全的有效途径。今天的这篇文章主要来谈谈大型互联网企业DevSecOps体系构建的总结和思考,为了方便读者理解笔者将会以一个虚拟的公司Parana来做说明。

组织与文化

导读:正如DoD的定义中所讲,DevSecOps不是指具体的技术或者工具平台而是一种软件工程文化和实践,因此对于期望构建DevSecOps体系的企业来说首先需要建设这样的组织和文化。

早在2002年Parana公司的创始人就开始在全公司top-down推广SOA(service-oritented architecture)文化[1]:

  • 所有团队必须通过服务接口公开他们的数据和功能
  • 团队间必须通过这些接口相互通信
  • 不允许其他形式的进程间通信:不允许直接链接、不允许直接读取另一个团队的数据存储、不允许共享内存模型、不允许任何后门;唯一允许的通信是通过网络上的服务接口调用
  • 每个团队可以根据自己的需求使用任何技术来实现
  • 所有服务接口,无一例外,都必须从头开始设计为可外部化的,也就是说,团队必须进行规划和设计,以便能够将接口暴露给外界的开发人员

此外,Parana公司的理念是Two-Pizza团队[2],即每个团队是一个不超过两个Pizza可以喂饱人数的最小独立组织。团队越小,协作越好。而协作非常重要,因为软件发布的速度比以往任何时候都快。团队交付软件的能力可能是组织在竞争中脱颖而出的一个因素。设想一下需要发布新产品功能或需要修复错误的情况,往往都希望这尽快发生,这样就可以有更短的上市时间。 这样的理念在某种意义上也非常契合DevSecOps的内在逻辑,每个应用的开发运维运营团队应该是一个整体而不是割裂的组织,这样既减少了跨组织间的沟通成本也大大提升了软件交付的敏捷性及软件运行的安全性。

通过在公司top-down推行SOA企业文化和Two-Pizza团队组织形态,Parana公司具备了构建DevSecOps体系的基础,每个Two-Pizza团队类似于军队中的最小作战单元(班),“麻雀虽小但五脏俱全”,每个团队中基本上都配备了以下角色。

  • 软件开发工程师:负责软件架构和开发
  • 技术项目经理:负责软件立项、周边协作及项目管理
  • 软件支持工程师:负责软件测试、运维和运营

流程与工具

导读:有了相应的组织和文化,接下来就是如何通过流程和工具将DevSecOps的理念固化下来,并持续运作。本节将从计划、开发、编译与测试、发布与交付、部署与运维、监控与反馈几个阶段进行介绍。

一、计划阶段

Parana公司在计划阶段要求每个软件项目立项后需要在应用服务安全评估系统中进行注册,该系统会根据《数据分类分级要求》、《数据分级处理标准》、《TOP威胁风险库》等生成应用服务风险评估问卷,通过回答问卷系统会自动根据问卷结果生成应用服务等级(Red、Orange、Yellow、Green),不同的级别对应着不同的安全要求,如:

  • Red/Orange:需要有授权的安全评估人员完成应用服务的威胁建模分析并提交相应的修复方案,且必须在上线前完成内部的渗透测试
  • Yellow/Green:研发团队可以自行进行威胁建模分析,不强制上线前需要完成渗透测试,但是必须提交应用服务的应急响应计划和关键业务联系人以备出现安全事件后可以及时响应和跟进修复

对于威胁建模能力的构建,Parana公司建立了安全BP威胁评估培训与分层授权(Security Certifier Training)机制。简而言之,就是在每个业务研发团队中培养具备威胁建模分析能力的研发人员。通过绩效考核权重(提升安全能力在研发工作中的正向考核权重)、业务主管推荐(提升安全能力在业务考核中的负向考核权重)鼓励研发人员主动申请成为威胁建模分析专员,再举行定期的安全技术培训、考试及威胁建模实战演练选出合格的威胁建模分析专员进入专家池,且对专家池中的人员每年进行能力复核和刷新,后续主要依赖专家池中的人员对Red/Orange级别的应用进行威胁建模分析和评估。

二、开发阶段

Parana公司主要依赖零信任网关(midway-auth)和基于FIDO协议的硬件token的多因素认证(MFA)确保仅合法的内部研发人员可以接入到公司内的源代码开发平台;另外通过统一权限管理平台(Bindle)动态管理研发人员与所有artifacts的访问权限确保仅授权的人员可以访问指定的内部artifacts,主要包括:

  • Permission Groups: 包含操作内部特定系统的权限组
  • Codes: 源代码
  • Packages: 包含多个代码文件的代码包
  • VersionSets: 包含所需依赖关系的代码包集合,类似于docker镜像
  • Environments: 包含微服务安装、配置、启动所需的所有信息的集合,类似于k8s的pods
  • Hostclasses: 服务部署和运行的主机组,类似于k8s的nodes

公司通过内部Code Review平台强制要求研发的每个commit在push之前都需要人工进行Peer Review,防止潜在恶意代码进入主干代码。为了实现开发的默认安全,降低已知安全风险,Parana公司花了很大力气提升开发阶段的公共安全能力:

  • 公共安全组件:加解密模块、统一认证鉴权模块、凭据管理模块
  • 默认安全的开发框架:内置了隐私敏感数据脱敏、凭据管理、常见漏洞默认防御能力的适配各种开发语言的应用开发框架
  • 分层分级的数据仓库服务:满足不同分类分级数据安全要求的统一存储服务,可供开发团队按需选择,最大限度地降低因研发团队自行设计开发而导致的安全风险

公司禁止直接使用或者引用外部代码仓或者依赖库,使用前必须先引入内部代码仓,具体体现在以下几点:

  • 遵循”谁引入、谁负责“的原则,确定内部owner
  • 引入前需要确保符合公司开源软件许可政策
  • 引入时同步三方依赖的名称、版本等信息至软件物料清单系统(SBOM)进行持续的漏洞监控
  • 持续监控指定版本的三方依赖的漏洞信息,并及时通知三方依赖的内部owner更新升级

三、编译与测试阶段

Parana公司在代码每次编译阶段都需要经过IAST/SAST/DAST的安全测试,重要应用代码上线前还需要经过专门的渗透测试。

  • 使用自研和商用的SAST(静态应用安全测试)和DAST(动态应用安全测试)对自研代码进行安全扫描和测试
  • 使用安全组件分析(SCA)工具扫描代码中依赖的所有三方开源组件识别已知漏洞使用流水线自动触发二方及三方依赖库版本升级、自动化测试
  • 此外,根据应用服务安全风险评估的等级在上线前完成专门的应用服务渗透测试

四、发布与交付阶段

Parana公司的所有应用服务源代码最终都会被编译成VersionSets(即包含了所需依赖关系的代码包集合,类似于docker镜像)进行发布并交付,所有过程都是由编译引擎(Brazil)自动完成的(无人工介入),从而确保了VersionSets的完整性。研发团队自身或者其他团队需要使用这个应用只需要在自己的流水线上consume这个VersionSets即可[3]。以上这个过程,也可以使用持续交付平台(Pipelines)通过配置流水线自动化完成整个交付过程:代码push-》编译-》测试-》部署。

五、部署与运维阶段

Parana公司使用自动化部署平台[4](Apollo)将包含微服务安装、配置、启动所需的所有信息的集合的Environments自动化部署到应用服务运行的主机组Hostclasses上。

  • 部署服务
  • 无停机部署
  • 健康追踪
  • 版本化的artifacts和回滚

上述这些过程同样可以通过Pipelines实现自动化安全配置(Security Config)、工作负载(workload)加固与扫描、安全补丁与漏洞修复。

六、监控与反馈阶段

Parana公司通过默认安全的开发框架引导应用服务自身进行应用、性能等日志收集与异常监控,针对潜在的安全异常要求研发团队通过公共的数据收集与融合组件(Sushi)统一上报到安全运营中心处理,同时会持续对开发人员的角色及职责与被访问代码仓关联度行为进行分析以识别潜在的软件供应链和内部威胁者(Insider Threat)等风险。

实践与安全

导读:DevSecOps流程的各个阶段中也面临着一些常见的威胁类型,本节将重点讲讲Parana公司的应对策略和落地措施。

sec

综上,我们较详细地解读了Parana公司是如何构建自己的DevSecOps体系,相信对于希望构建此类体系的企业来说有一定的借鉴意义。
secops

参考

[1] https://apievangelist.com/2012/01/12/the-secret-to-amazons-success-internal-apis/

[2] https://docs.aws.amazon.com/whitepapers/latest/introduction-devops-aws/two-pizza-teams.html

[3] https://gist.github.com/terabyte/15a2d3d407285b8b5a0a7964dd6283b0

[4] https://www.allthingsdistributed.com/2014/11/apollo-amazon-deployment-engine.html

[5] AWS re:Invent 2015: DevOps at Amazon: A Look at Our Tools and Processes (DVO202): https://www.youtube.com/watch?v=esEFaY0FDKc

[6] DevOps Culture at Amazon: https://www.youtube.com/watch?v=mBU3AJ3j1rg

[7] Automating safe, hands-off deployments: https://aws.amazon.com/builders-library/automating-safe-hands-off-deployments/

关于如何更好地呈现红蓝对抗价值的思考

虽然红蓝对抗机制和蓝军团队建设的经验和思考笔者已经通过不同渠道(博客、公众号、公开演讲等)多次分享了,但是今天这篇文章主要是谈一谈关于如何更好地呈现红蓝对抗的价值。

众所周知,近几年由于国家政府的重视红蓝对抗已经开始在国内各大组织和企业内蓬勃发展,但是笔者发现国内在运用红蓝对抗的价值呈现上还是有待提高的。纵观当前国内的情况,大家更重视这种形式的直接结果,如发现了几个漏洞之类的,却似乎很少公开提及如何将红蓝对抗更深次的价值呈现出来,这既包括横向上对防守团队的防御体系建设的促进,也包括纵向上对管理层的红蓝对抗价值呈现的理解。

笔者近年来一直在从事红蓝对抗机制和团队的建设,也在平时的工作中经常思考如何更好将红蓝对抗结果的价值呈现最大化,负责过蓝军建设的同学一定会或多或少被问到过类似的问题,即“红蓝对抗对企业到底有多大价值?如何量化体现?”。

一般的红蓝对抗的流程会在复盘阶段的《红蓝演练行动报告》和《复盘总结报告》中呈现红蓝对抗的结果价值,按照笔者的经验大多数情况下这两个报告一般会包括如下几方面内容:

  • 攻击过程与时间线
  • 发现的关键漏洞和修复建议
  • 发现的关键安全问题和改进建议

但是这些仅仅反映了单次红蓝演练行动中发现或者暴露的问题,而大多数情况下最终会被体现为演练过程中发现了哪些漏洞的问题。对于处于红蓝对抗演练初级或者早期阶段的企业或者组织来说,或许比较能给管理层带来短暂的震撼和重视,但是经历了多次演练后就可能会面临一些“漏洞审美疲劳”的问题,诸如:

  • 蓝军发现的这些漏洞是已知漏洞
  • 蓝军的这些攻击方式是已知攻击路径
  • 蓝军发现的这些安全问题是已知问题,且并不关键

那么如何避免由于将红蓝对抗的结果呈现单纯漏洞化而导致非蓝军人员或者管理层片面地以为红蓝对抗就是找漏洞的误解,笔者认为应该从红蓝对抗的本质出发,我们都知道以攻促防是红蓝对抗的本质,因此需要蓝军从业人员懂得从方法论设计、根因分析模型、数据量化分析等维度来深度呈现红蓝对抗的价值。

首先我们来看看国外同行是如何从这几个维度来实践的。

方法论设计

洛克希德马丁的Kill-Chain模型就是典型的红蓝对抗的方法论,其将攻击者的思考逻辑抽象成具体的攻击步骤,指导攻击者实施攻击,同时也帮助防守者理解攻击思维。

kill-chain

根因分析模型

MITRE的ATT&CK则是一个标准的根因分析模型,遵循Kill-Chain方法论通过解构攻击过程中具体的TTPs让不从事攻击的人员也可以理解攻击者思维及具体的攻击过程从而做到“知己知彼”。

attck

数据量化分析

FireEye的攻击生命周期模型是利用数据思维量化分析攻击过程中最容易被攻击者青睐的TOP攻击点从而为防守者提供防御投入的数据依据。
fe
fe2
通过研究和学习以上国外同行在红蓝对抗价值呈现的经验并结合自身的经历,笔者这几年也提出并实践了一套红蓝对抗价值呈现模型即红蓝对抗飞轮模型,并尝试将实战红蓝对抗演练行动解构成多个单点的攻击技术点,再通过数据统计方法挖掘防御的薄弱点,最后结合业界最佳实践提出针对性的防御体系改进建议。

红蓝对抗飞轮模型

红蓝对抗飞轮模型即实施红蓝对抗行动,从每次行动中梳理攻击路径,将攻击路径中的攻击技术点映射到MITRE的ATT&CK矩阵(也可以是组织或者企业内部自建的ATT&CK矩阵)中的TTPs上,根据映射后的攻击TTPs识别相应的安全问题,按照FireEye的攻击生命周期模型统计多次行动中的TTPs的使用频率或次数总结出共性安全问题,最后针对数据量化分析后的共性问题结合业界最佳实践提出改进建议。
fw

0x00 实施红蓝对抗、发现攻击路径

00

0x01 映射攻击TTPs、识别安全问题

01

0x02 统计共性问题

fw2
02

0x03 改进防御体系

03

根据该模型,我们便可以建立起一个包含了方法论设计、根因分析模型及数据量化分析为一体的红蓝对抗价值呈现体系。利用这一套体系建立起横向和纵向的价值呈现标准和语言,用数据量化体现红蓝对抗的价值。

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

前言

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

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

思考

在讲述企业安全建设的演讲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)。

参考

基于MITRE ATT&CK的Red Teaming行动实践

前言

如果要评选最近一年内国内信息安全圈最火的一个安全新名词,那一定是“MITRE ATT&CK”了。这个词在其被引入国内的那一刻起,就似乎备受青睐,常见于各种文章、PPT、演讲之中,大有赶超前几年的安全热词“威胁情报”之势。一时间造成了一种如果在2019年没听说过“MITRE ATT&CK”的安全从业人员不算是真正的业内人士的错觉。可是,物极必反,但凡被吹捧的越高往往跌的越惨,笔者私下里也在多个场合听到一些对“MITRE ATT&CK”被过度吹捧的反感言论,其实看待任何新鲜的事物和概念都需要冷静分析、客观思考、取其精华、去其糟粕,最后为我所用才是正道。

根据MITRE ATT&CK的官方描述,我们可以知道其是一个梳理攻击者的入侵行为(包括战术和技术)的知识库,其目的在于帮助防守方全面地了解和分析攻击者的TTPs。对于乙方安全公司,可以利用ATT&CK来开发各种安全产品或服务的威胁检测方法提高入侵检测的覆盖面;而对于甲方企业,则可以利用ATT&CK来设计各种威胁模型来检测与之对应的攻击手法,提高整体的防御检测的能力。

本文将探讨如何利用ATT&CK站在攻击者视角来组织和实践Red Teaming行动,更加有针对性的模拟真实世界的攻击者以达到“实战养兵”的目的。至于什么是Red Teaming,本文将不再赘述,具体可参阅笔者之前的文章《Red Team从0到1的实践与思考》。

规划

有效的Red Teaming行动是离不开充分的事前准备和行动规划的。那么如何利用Red Teaming行动来模拟真实攻击者呢?目前比较流行的方法有以下几种:

  • 模拟直接威胁者:根据特定的威胁情报来模拟攻击者,所谓“以情报驱动的Red Teaming行动”,目前深受国际主流互联网企业的Red Team团队的青睐,例如针对某些特定行业或者国家的APT组织的TTPs的模拟;

  • 模拟已知威胁者:根据已披露的APT组织的TTPs来模拟攻击者,例如利用MITRE ATT&CK来规划Red Teaming行动所需的TTPs;

  • 模拟未知威胁者:根据真实入侵的各个阶段收集到的具体目标信息实时地规划攻击路径从而模拟攻击者。

这三种方法其实应该算是Red Teaming行动在企业处于不同的威胁阶段时应该采用的不同方法,个人以为前两种应该作为甲方企业自身Red Team的主要工作方向,第三种可作为前两种的进阶补充或者乙方Red Teaming服务的工作重心。具体而言,第一种方法主要是模拟直接威胁者,通过威胁情报提前发现直接威胁者的TTPs并加以模拟来检测防守团队应对直接威胁的防御能力,这是Red Teaming行动的基本目标;第二种方法主要是模拟已知威胁者,通过模拟目前所有已知的攻击组织的TTPs来全面而系统地识别防守团队的防御弱点并帮助其提高检测所有已知威胁的覆盖率,这是Red Teaming行动的主要目标;第三种方法主要是模拟未知威胁者,通过模拟真实黑客的潜在入侵行为来检测当前企业面对未知威胁的防御能力,这是Red Teaming的进阶目标。

本文将重点介绍一下第二种方法即利用MITRE ATT&CK来规划Red Teaming行动从而全面而系统地模拟已知威胁者,换句话说就是以ATT&CK里所列的TTPs以“连点成线”的方式来规划所有可行的攻击路径。

实践

我们都知道官方的ATT&CK框架只是笼统地归纳总结了所有目前已知的攻击者的Tactics(战术阶段)和每个Tactics对应的Techniques(技术点),但却并没有深入地介绍每个Technique的具体技术细节,这实际上就为Red Teaming行动的模拟带来了很大的不便,也就意味着Red Team自己需要分析和整理一个包含每个技术点详细介绍的ATT&CK框架,笔者根据自身的实践经验已经做了类似的落地工作如下:

有了这样的基本框架,作为Red Teaming行动的实施者就可以按照以下的步骤来规划和实施具体的Red Teaming行动了。

确定目标

确定Red Teaming行动的目标通常是评估行动结果与效果的最有价值的衡量标准,因此行动前制定明确可度量的目标是非常重要的。比如,我们可以制定以下的行动目标:

  • 成功地在目标系统或者网络里执行所有已经选取的TTPs;

  • 识别所有选取TTPs被防守团队检测和中断所花费的时间。

制定计划

一旦确定了行动目标,我们就可以依据ATT&CK框架来制定具体的行动计划了。首先,我们可以按照不同的Tactics把整体的行动分为以下几个阶段。

事前准备(Pre-Attack)

  • T1266 – Acquire OSINT data sets and information. 从开源情报数据中收集目标企业员工的邮箱信息。

初始访问(Initial-Access)

  • T1192 – Spearphishing Link. 利用第三方可信的云存储服务来存放恶意的Word文档作为钓鱼链接。

执行(Execution)

  • T1155 – AppleScript. 利用AppleScript在Mac上运行Python脚本。

  • T1059 – Command-Line Interface. 使用cmd.exe执行系统命令和恶意代码。

  • T1085 – Rundll32. 利用Rundll32执行恶意DLL文件。

  • T1118 – InstallUtil. 利用InstallUtil执行恶意代码。

  • T1086 – PowerShell. 利用PowerShell在Windows上下载和执行恶意代码。

持久化与特权提升(Persistence & Privilege Escalation)

  • T1197 – BITS Jobs. 使用BITSAdmin下载恶意文件。

  • T1053 – Scheduled Task. 利用schtasks建立计划任务实现持久化和特权提升。

防御绕过(Defensive Evasion)

  • T1221 – Template Injection. 使用Word远程模版注入的方式执行恶意宏绕过邮件网关的沙箱检测。

  • T1088 – Bypass User Account Control. 利用Windows计划任务中的环境变量绕过UAC。

凭据访问(Credential Access)

  • T1003 – Credential Dumping. 利用Procdump拉取lsass.exe进程的内存并从中获取明文的用户凭据。

命令与控制(Command and Control)

  • T1104 – Multi-Stage Channels. 使用各种后门工具,Metasploit反向Shell,甚至是RAT工具来作为多层C2通道。

  • T1219 – Remote Access Tools. 利用开源RAT打造自己的远程控制平台。

数据渗出(Exfiltration)

  • T1041 – ExfiltraOon Over Command and Control Channel. 通过C2通道渗出目标数据。

然后,我们就可以根据上述选择的TTPs设计具体的模拟攻击路径,如下图:

准备TTPs

根据上面制定的行动计划,我们接下来需要分析所有已选取TTPs的具体技术实现,准备payload以及相应的测试,这时我们就需要依赖在本节一开始提到的包含每个Techniques具体技术细节的ATT&CK攻击框架,以下以部分在上述已制定的行动计划中选取的TTPs的准备为例。

T1192 – Spearphishing Link. 利用第三方可信的云存储服务来存放恶意的Word文档作为钓鱼链接。

T1155 – AppleScript. 利用AppleScript在Mac上运行Python脚本。

T1085 – Rundll32. 利用Rundll32执行恶意DLL文件。

T1197 – BITS Jobs. 使用BITSAdmin下载恶意文件。

T1221 – Template Injection. 使用Word远程模版注入的方式执行恶意宏。

T1003 – Credential Dumping. 利用Procdump拉取lsass.exe进程的内存并从中获取明文的用户凭据。

T1219 – Remote Access Tools. 利用开源RAT打造自己的远程控制平台。

T1041 – ExfiltraOon Over Command and Control Channel. 通过C2通道渗出目标数据。

依据以上TTPs的技术细节,我们就可以快速地制作Red Teaming行动各个阶段所需的payload(如钓鱼样本,反弹shell样本,持久化与特权提升样本等)和工具(如C2平台,RAT远控工具等)。

实施攻击

计划好Red Teaming行动的具体时间表(例如尽量避开公司业务高峰期和敏感期,尽可能地减少对实际业务的潜在影响),按照规划好的攻击路径和已经准备好的TTPs对目标企业网络实施攻击。

完成报告

在完成攻击后,完整且详细地记录以上各个步骤的详细信息和攻击行为时间线,对照行动开始前确定的目标完成结果分析,并最终形成报告,提交至防守团队进行复盘和改进。

总结

洋洋洒洒写了这么多,总结起来其实就是一句话:Red Teaming的攻击形式多种多样、纷繁复杂,短期内也不太可能找到一种万能的框架或者方法来模拟所有可能的攻击路径,在此情况下,利用ATT&CK来指导和落地Red Teaming行动仍不失为帮助防守团队识别当前企业面临的TOP安全威胁的有效方法之一。

参考

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

前言

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

什么是体系思考

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

一谈到体系思考,相信很多人的第一感觉肯定是觉得很虚,认为只有不懂技术的人喜欢拿这种东西来装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,这里就不在赘述了。

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

后记

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

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

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

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

参考

Red Team从0到1的实践与思考

0x00 前言

近年来Red Team越来越收到国内外企业的关注,恰逢笔者正在一家大型互联网公司从事Red Team相关的工作和实践,故以此文来简单阐述一下笔者对于Red Team从0到1的一些实践和思考。正所谓“一千个人眼中有一千个哈姆雷特”,此文中仅探讨笔者亲历的Red Team建设工作以及体系思考,观点谨代表个人,读者需酌情参考。

0x01 Red Team是什么

Red Team的概念最早来源于20世纪60年代的美国军方,原文定义如下:

An independent group that challenges an organization to improve its effectiveness by assuming an adversarial role.

翻译过来的大致意思是:一个通过承担对抗性角色来挑战组织以提高其有效性的独立的团体叫做Red Team。

后来,由于信息安全行业与军方的一些相似性,这个概念被引入到了安全行业,现在国际上一般以如下比较通用的定义来描述信息安全行业中的Red Team:

基于情报目标导向来模拟攻击者对企业实施入侵的专门的安全团队

由于Red Team和传统的渗透测试在一些攻击手法上有一些类似,二者很容易引起大家的混淆,很多人甚至干脆把他们混为一谈。我们可以从以下几个方面谈谈二者之间的主要区别:

  • 方法:前者主要来源于威胁情报,后者则是利用黑客的思维来发起攻击;
  • 目标:前者侧重于检测防御能力的弱点以及评估潜在的业务影响(下一节会详细介绍),后者则是在有限的时间内尽可能地发现更多的漏洞;
  • 计划:前者比较灵活且无固定时间限制,后者则需要指定目标范围和测试时间;
  • 过程:前者注重测试的隐蔽性,尽可能的绕过现有的防御系统,后者一般会提前告知防御团队且设置白名单例外,无需隐藏测试行为。

0x02 Red Team的目标

既然已经知道了Red Team的定义,就需要进一步了解一下Red Team的目标,要知道Red Team并不是为了攻击而攻击。我们经常会看到一种比较常见的观点是认为Red Team的目标是站在攻击者的角度来模拟真实入侵者攻击企业从而识别企业的防御弱点。笔者认为这个观点并不完整,也因太过笼统不足以清晰地表述Red Team的目标。其实可以结合前一节中的定义,来细化Red Team目标,具体包含下面几个部分:

  • 学习和利用已知真实攻击者的TTPs来用于攻击:因为Red Team是以情报和目标为导向的,因此我们需要通过威胁情报来了解已知真实攻击者的攻击目标和意图,以及通过ATT&CK和APT组织的分析报告来学习真实攻击者攻击不同行业的TTPs,这样有利于我们有针对性地模拟真实攻击者来攻击目标企业;
  • 评估现有防御能力的有效性以及识别防御体系的弱点并提出具体的应对方案:这是Red Team最为人所知的目标之一,让Blue Team通过已发现的不足来强化防御能力和改进流程,并最终提高真实攻击者的攻击成本;
  • 利用真实有效的模拟攻击来评估因为安全问题所造成的潜在的业务影响:这一点通常很容易被忽略,通过Red Team我们可以为企业管理者提供有效的数据来量化和衡量安全投入的ROI。

0x03 谁需要Red Team

Red Team听起来似乎价值很大,那么是不是所有企业都需要Red Team呢?答案是否定的。事实上,Red Team是建构在有相对健全或者成熟的防御体系之上的,这一点从上一节谈到的目标中有很好地体现。一般来说,一个企业只有拥有了基本的防御和检测的能力,并需要持续检验和改进这种能力时,Red Team才是一个非常不错的选择。如果一个企业连基本的入侵检测能力都没有健全,这种时候搞Red Team就好比空中楼阁,也没有实际的价值和好处。

0x04 Red Team如何工作

本节我将尝试从基本构成,工作流程,协作配合几个角度来谈谈Red Team如何在企业落地实现。

基本构成

在开始组建Red Team时,以下几个部分是不可或缺的基本构成,有了这些基础我们才能开展后续的Red Team工作。

知识储备

为了更好地模拟已知真实攻击者来实施攻击,一般情况下,我们可以通过威胁情报报告,ATT&CKAPT组织分析报告等来积累和学习这些真实攻击者的TTPs。其中一种流行的方法是,以ATT&CK Matrix和APT组织为参考,对具体的攻击技术细节进行分析和总结。

基础架构

工欲善其事,必先利其器。一次成功的Red Team活动是离不开强有力的基础架构的支持的,我们一般按照Red Team的攻击流程至少需要以下几类系统或工具:

  • 信息收集工具:如OSINT(Maltego,ShodanCensysGoogle DorksGithub,SNS等),企业邮箱和域名采集工具(The Harvester等),漏洞扫描器等;
  • Payload生成工具:如Cobalt Strike,Metasploit,Empire,DotNetToJScriptSharpShooterCACTUSTORCHmacro_pack等等;
  • C2架构:包括钓鱼与payload分发系统,基于各种协议(DNS,HTTP,ICMP)或者外部系统(Domain Fronting,Github,SNS等)的short-haul和long-haul C2,如: