如何通俗解释可信纵深防御

一、可信防御
攻击者在何时何地通过何种攻击手法发起攻击是无法预测的,但是信息系统的运行状态可以基于网络流量、应用日志和系统进程等信息有效地分析刻画,因此在防御思路上需要将不确定的攻击威胁,通过已知的业务状态转换为有效的防御策略来应对威胁,有效规避风险事件的发生。
因此,在安全风险控制上,首先应遵循可信计算理念来建立可信根,再基于可信根构建信任链,进而基于基础设施层、应用层、网络层、移动端和终端层等各层建立可信策略控制点,最后形成可信防护策略,仅允许执行预期内信息系统运行所依赖的资源和行为,确保防护强度达到可信级。

二、纵深防御
纵深防御的理念来自战争学,该理念在信息安全领域得到了广泛的使用和推广。该理念即通过建立多层重叠的安全防护系统构成多道防线,使得即使某一防线失效也能被其他防线弥补,也即通过增加系统防御的层数或将各层之间的漏洞错开的方式防范差错发生。为了避免因单点防御措施失效导致风险事件的发生,须采用纵深防御理念进行可信防御体系的建设。
无论是网络层、应用层、容器主机层、基础设施层还是硬件可信芯片层,需要通过各层的可信管控能力实施数据内视和可信管控,最终建立可信纵深防御体系。每增加一层可信防御能力,所建设的防御体系的防御强度都会大幅增强,同时也意味着投入成本的增加。因此,我们应在威胁有效应对和业务的合规要求、安全成本投入、管控效率上取得最佳平衡,做到既能满足监管合规要求,又可以高效应对面临的高级和未知威胁,同时可以将可信纵深防御体系的建设成本和管控效率控制在合理范围,不会因为防御体系建设过重而带来过多成本、性能和效率的损耗。

三、可信纵深防御
可信纵深防御是一种新的安全防御体系架构, 结合了可信防御、纵深防御、零信任、安全平行切面等多种新技术理念,是主动免疫可信计算在实际业务场景的落地实践,可以做到只允许预期内的行为执行即主动免疫,而且能够实现对所有威胁路径的多层覆盖,大幅降低风险事件发生的概率。同时它还建立了完备的信任链,将信任关系逐级规约至硬件芯片可信根,保障防御体系自身的安全。建立的防御措施做到仅允许信息系统在安全可信的环境下运行预期内的资源和行为加载、执行,且确保内容均是经过安全评估为无风险的;同时根据业务面临的威胁状况,可信防御措施需要多层覆盖,最终形成可信纵深防御体系,有效地应对0Day攻击、社会工程学攻击、软硬件供应链攻击等高级和未知威胁。
可信纵深防御体系以可信根为支撑,以可信软件基为核心,以密码学方法为主要手段,通过度量、检测、证明以及管控等手段,构建贯穿硬件、固件、系统软件、应用软件和网络行为的完整信任链,为信息系统的运行提供安全可信的底座。可信防御措施进行多层覆盖,以大幅降低风险事件发生的概率。最终达成事前高效规避已知(含高级)和未知威胁的目标,兼顾业务效率与体验要求。
可信纵深防御体系整体架构包含四个关键部分:硬件可信芯片、可信策略控制点、信任链和可信管控中心,由安全防护部件形成的可信防护体系与由计算部件形成的计算体系形成双体系结构。其中可信管控中心又由可信策略管控系统、可信策略刻画系统、安全保障系统、稳定性保障系统四部分组成。在整体架构设计上以硬件可信芯片为信任根;以可信软件基为核心,它由基础设施层、应用层、网络层及移动端和终端层等各层构建的可信策略控制点组成;基于硬件可信芯片构建的信任链来保障可信策略控制点的安全可信;基于可信策略刻画系统及密码学技术生成的“免疫基因抗体”对信息系统的运行环境、资源加载和交互行为进行可信管控,有效识别“自己”和“非己”成分,破坏与排斥进入信息系统机体的有害物质,为信息系统加持“免疫能力”​,保障信息系统和数字资产的安全性;安全保障和稳定性保障技术为整体可信纵深防御体系的落地提供支撑,防止在可信纵深防御体系建设中产生安全漏洞和稳定性风险事件,导致业务受损。

四、关键技术
可信计算:通过主动免疫的方法防御不可预测、不可控的攻击与威胁,基于不可篡改的硬件芯片作为可信根,主动逐层检查系统行为是否可信,建立理论可证完备的信任链。
安全平行切面技术:在业务系统中构建安全防御的平行空间,实现与业务解耦、透视、智能评估、精准管控,兼顾业务效率的同时,高效构建安全纵深防御体系。
零信任防御理念:从不信任,始终验证;不信任网络位置;最小化访问权限;记录和监控所有网络访问流量。
可信芯片:作为信任根,可信芯片负责验证硬件设备的启动参数和程序,确保硬件的安全性和完整性。
信任链构建:通过静态和动态的信任链校验机制,确保从硬件到软件各层级的信任关系。
远程证明:允许系统在远程环境中进行身份验证和状态确认,增强系统的可信赖性。
密钥安全保护:包括密钥的安全存储和使用,确保密钥不被非法获取或篡改。

五、实施可信纵深防御的方法包括
基于硬件可信芯片构建信任根:利用硬件可信芯片和密码学方法对物理机的启动参数和启动程序进行可信管控,确保硬件芯片、启动参数、系统OS等均是安全可信的。
基于安全切面构建可信策略控制点:在数字银行IT架构中分析、选型或设计可信策略控制点,实现对风险场景的数据内视和可信管控。
基于信任链保障可信防御产品或能力的安全可信:利用硬件可信芯片提供的可信存储和密码技术,构建完备的信任链,将信任机制由硬件可信芯片逐层传递至基础设施层、应用层和网络层等各个层面的可信策略控制点,保障可信策略控制点的安全性。
基于可信管控中心实施可信管控:可信管控中心负责可信策略的生成、配置下发、事件上报和行为审计等工作,同时为整个可信纵深防御体系的运行提供安全性和稳定性的保障能力。

参考:
《数字银行安全体系构建》

如何通俗解释安全平行切面

安全平行切面是一种将软件工程中的面向切面编程(AOP)思想应用于安全体系建设的技术体系,其核心目标是构建一个与业务逻辑正交融合的安全空间,使安全能力能够融入企业的技术基础设施中,并与业务代码解耦。

与传统安全方案比,安全平行切面既不像外挂式安全体系,安静旁观,隔靴搔痒;也不像内嵌式安全体系,入侵业务,绑腿走路。而是通过端—管—云各层次的切面,能够在不修改业务逻辑的情况下,将安全可信的管控能力动态部署到目标系统的执行空间内部,从而实现对系统内部数据的自由观测,精确阻断攻击和风险,并进行精细化的数据治理。

安全平行切面的应用场景非常广泛,包括数据保护、身份验证、访问控制和威胁检测等多个领域。通过在业务逻辑和流量关键环节中构建切点组合,可以更快速地发现潜在威胁并实现对异常访问的精准感知和快速阻断。

实施安全平行切面通常涉及以下步骤:
定义安全需求:明确需要通过安全平行切面实现的保护目标和安全需求。
设计切面和切点:根据安全需求,设计切面(Aspect)和切点(Pointcut),确定在业务流程的哪些环节需要插入安全措施。
开发切面逻辑:开发或配置切面逻辑(Advice),这包括定义安全策略、异常检测、访问控制、数据加密等安全功能。
集成和部署:将设计好的切面逻辑集成到业务系统中,并在实际环境中进行部署。
测试和验证:对集成了安全平行切面的系统进行测试,确保安全措施有效且不会影响业务系统的正常运行。
监控和维护:持续监控切面的性能和效果,根据安全威胁的变化进行必要的调整和维护。
培训和文化建设:对团队进行安全平行切面的培训,提高安全意识,建立安全文化。

安全平行切面的核心优势在于它能够提供精准的内视能力和高效的干预能力,使得安全措施更加精细化和动态化。同时,安全平行切面还支持多层级的安全布防,能够实现不同层级间的安全管控,并通过多层级安全切面的联动形成整体的防御体系,达到更好的安全治理、防护和对抗效果。

什么是RASP

Gartner在2012年引入了RASP(Runtime Application Self-Protection,运行时应用程序自我保护),这是一种在应用程序运行时提供安全保护的技术,通过嵌入到应用程序中,实时监控和阻止针对应用程序的攻击,使应用程序具备自我防护能力。其核心思想是将安全防护代码集成到应用程序本身中,实时采集应用的高风险行为,结合特征规则、上下文语义分析及第三方安全产品数据关联分析,实现对应用程序的实时检测和防御,通过实时监控和防御来保护应用程序免受各种网络攻击。

具体来说,RASP通过以下几种方式实现自我保护:
1、动态代码注入:RASP通过动态代码注入技术,将自身防御逻辑注入到底层API中,从而实现无须人工干预、无感知的高精准检测和防御外部攻击。
2、API钩子:通过监控应用程序调用的API函数,实现对应用程序行为的监控。
3、上下文感知:RASP能够获取应用运行时的上下文信息,包括代码、框架配置、应用服务器配置、库和框架、运行时数据流、后端连接等,从而提供更精准的威胁检测。
4、安全策略配置:管理员可以通过配置安全策略来适应不同的应用程序需求和威胁模式,定义哪些行为是允许的,哪些是禁止的。
5、规则匹配与行为基线:RASP利用规则匹配、词法分析、行为及运行堆栈检测等方法,识别潜在的安全漏洞并防止攻击。这些功能有助于识别未知漏洞并给出详细的漏洞详情,极大降低误报率。
6、自定义逻辑检查:不依赖请求特征检测攻击,而是在应用执行关键操作时,执行一段自定义的逻辑检查是否存在异常,以应对未知漏洞。
7、实时监测和阻断:RASP在应用程序运行时检测到恶意行为,并立即进行阻止,有效防止了恶意代码的执行。
相较于传统的Web应用安全产品,RASP从海量的攻击中排除掉大量无效攻击,聚焦发现真实的已知和未知安全威胁。

实施RASP时,可以采取以下步骤:
1、明确应用的安全需求和目标:包括识别关键的安全风险点、确定需要防护的攻击类型以及定义安全策略。
2、根据应用的技术栈和具体需求,选择适合的RASP工具。例如,Java应用可以选择OpenRASP等开源框架,或者使用商业解决方案如AWS WAF等。
2、集成RASP探针:在应用中集成RASP探针,这些探针会在应用运行时插入到业务代码中,监控其行为并进行实时检测。探针可以部署在主机或容器环境中,无需修改原有代码。
3、配置RASP规则:定义一套安全规则来指导RASP如何工作。这些规则包括允许和禁止的行为模式,并根据不同的应用场景进行调整。管理员可以通过图形界面或API配置这些规则。
4、测试:在生产环境部署RASP之前,进行彻底的测试,以确保它不会对应用程序的性能产生负面影响,并且能够有效地检测和阻止攻击。
5、部署:将RASP部署到生产环境中,并确保其与应用程序一同启动。
6、培训和维护:对开发和运维团队进行RASP相关的培训,并定期更新RASP规则和签名,以应对新的安全威胁。
7、监控和调整:部署RASP后,需要监控其性能和产生的安全警报,并根据监控结果调整RASP规则,以减少误报和提升防护效果。
8、定期评估:评估RASP性能和效果,根据新的安全威胁和漏洞进行更新和优化。同时,结合IAST(交互式应用程序安全测试)和DAST(静态应用程序安全测试)等工具,进一步提高防护能力。
9、应急机制:建立有效的应急响应机制,以便在发生安全事件时迅速采取措施。同时,合理管理和记录日志信息,便于事后分析和审计。

默认安全体系

默认安全体系(Default Security)是指在系统、网络或应用程序的设计和实施过程中,将安全措施作为标准配置和操作的一部分,以确保即使在未明确配置安全设置的情况下,也能提供一定级别的保护。默认安全使安全性成为组织文化的一部分,减少对用户或管理员进行复杂安全配置的依赖,从而提高整体的安全性和抵御威胁的能力。

默认安全的最终目标是:规避已知安全风险,存量风险治理逐步完成,同时新增业务默认经过安全评估和安全措施覆盖。类似于针对已知疾病的疫苗与抗体,对于已知类型风险,系统应达到投产即安全的状态。

默认安全体系的重要组成部分有:

1、安全默认配置:
确保所有系统、设备和应用程序在初始安装和设置时都具有安全的默认配置,如禁用不必要的服务、关闭未加密的远程访问等。

2、加密和数据保护:
在默认情况下启用数据加密,包括传输中的数据和静态数据,以及敏感信息的加密存储。

3、安全开发生命周期(SDL):
将安全实践集成到软件开发生命周期的每个阶段,确保安全缺陷在早期被发现和修复。

4、安全测试和验证:
对所有系统和应用程序进行定期的安全测试,包括静态和动态代码分析、渗透测试等。

5、访问控制和认证:
实施强大的身份验证机制,如多因素认证,并在默认情况下启用访问控制。

6、最小权限原则:
按照最小权限原则为用户和应用程序分配权限,确保它们仅拥有完成其功能所必需的访问权限。

7、安全审计和监控:
启用日志记录和监控,以便在默认情况下跟踪和审计所有关键操作和事件。

8、安全补丁和更新:
确保系统和应用程序在默认情况下自动接收和应用安全补丁和更新。

9、用户安全意识教育:
教育用户了解默认安全措施的重要性,并鼓励他们采取安全意识行动。

10、应急响应计划:
制定应急响应计划,以便在安全事件发生时迅速采取行动。

11、合规性和政策制定:
确保默认安全措施符合相关的法律、法规和行业标准。

12、技术架构设计:
在设计阶段就考虑安全性,采用安全的网络架构和系统设计原则。

安全架构实践公理

2020年7月,TOG(The Open Group)联合SABSA,正式发布中文版指南《安全架构实践的公理》(其英文版发布于2019年7月),其中20条安全架构实践公理如下:

公理1:业务风险驱动安全
安全架构应通过最大化收益和最小化损失来支持业务目标。
必须牢记的是,组织资产并不是为了被保护而存在,它们的存在是为了创造价值。而利用资产创造价值,通常意味着使该资产面临风险。这正是矛盾之处。
为了提供最优架构,安全架构师不仅要从防止负面结果的角度来看待它们对组织的贡献,还要从促成积极结果的角度来看待它们。
如果安全架构无法支撑组织利用其资产来完成业务工作,则该安全架构可能被边缘化和显得无用。
安全架构应基于业务风险驱动,并且应该是对这些风险进行适当响应。

公理2:场景
不要虚构场景,否则后果自负。专为一种场景而设计的安全系统或解决方案,并不总是可以有效地在另一种场景中工作。
这并不是反对重用,可重用的基于组件的架构有很多好处。但是,如果为了节省时间和精力,将安全系统重用于不同的用例,则需要针对这两个用例之间的差异,进行新的风险分析。
该指南还专门针对系统设计中的一个常见错误——访问控制过程的身份识别、身份验证、授权过程的混淆,进行了澄清。

公理3:范围
明确定义安全架构的范围很重要。在这方面,系统收益(SOI)的概念很有用(如ISO/IEC/IEEE 42010:2011中所定义)。

公理4:情报
安全系统应利用情报来主导响应活动。通过威胁情报,既可以了解对手的意图、能力、攻击方式,也可以了解自身的漏洞情况。
建议对潜在威胁场景进行建模分析,来实现最佳效果。

公理5:信任
安全架构应该保障系统可以准确建模业务实体关系中存在的信任的性质、类型、级别、复杂性。
信任是人际关系的特征。但我们可能要给非人员对象以信任。当这样做时,其实是在说,我们可以信任操作这类对象的人员,或可被操作这类对象的人员所信任。因此,一个可信的系统是指我们信任参与系统生命周期过程的人员。
信任从来都不是二进制,而是一个很长的灰度连续体,很少有黑色或白色。
“信任”和“被信任”不是镜像关系。
即使是最复杂的信任关系,也可以自顶向下分析成一系列简单的单向信任关系。通过严格执行此项分析,可以将任何业务关系分解为简单且独立的单向信任组件。

公理6:整体分析
安全需求应与其它的功能性需求和非功能性需求集成在一起。安全需求通常被描述为非功能需求(NFR),并且不应将其与其他功能需求或非功能需求分离。只有将所有需求都视为SOI(系统收益)整体风险的一部分时,安全架构才能有效工作。
架构通常被视为不同视角的一系列观点。这些观点通常被称为架构域。例如:业务架构域、应用架构域、信息架构域、数据架构域、服务管理架构域、技术架构域。就像看一座被群峰环绕的山谷,远近高低的观点各不同。
而安全架构域是从另一个视角来看的另一种观点,但与其它视角有很大不同,因为它是一个跨领域的域,必须以整体的方式解决所有其它域的安全和风险管理问题。因为风险无法分为孤立的架构域,所以安全架构师必须同时从所有视角看到山谷,即拥有可以随意旋转的全息视图。

公理7:简洁性
系统和服务应在保证功能性的前提下尽可能简洁。
复杂是安全的敌人,必须在保持整体性的同时,将其简化为子结构进行管理。安全架构将会受益于面向服务的架构(SOA)方法,在这种方法中,我们看到了“一切即服务”(EaaS)。服务的性能对于实现顶级业务绩效目标至关重要。
任何架构类型的主要目标之一就是管理复杂性。必须通过自上而下的分解来分解高度复杂的SOI(系统收益),从最高级别的业务目标开始,并创建逐渐简化的SOI层次,并对其逐层解决。
高度复杂的系统,倾向于表现出涌现性。涌现性的示例包括:两个或多个进程争用同一系统资源时发生死锁;网络在超出容量后的流量拥塞。
系统安全漏洞主要来自两个来源:设计错误和涌现性。两者不相同,不应混淆。涌现性是系统工程的一种现象,并非一开始就被设计出来。复杂性本身就是导致出现这一现象的原因。

公理8:重用
在可行的情况下,尽可能重用受信任的系统开发实践和系统组件。
安全架构师不应从零开始,不要重新发明轮子。从通用框架和参考架构开始,并针对特定的场景进行定制,始终是效率更高的方法。
框架示例包括:
NIST网络安全框架(CSF):是150多个RFI响应和许多利益相关方会议的产物。
ISO 27000系列:是用于组织和监控企业安全机制的一组控件和过程。
ISO 31000-2018:定义了一个周期性的风险管理流程。
SABSA平衡风险模型:提供了定义风险相关组件的组织结构。

公理9:弹性
安全系统应在受到胁迫时依然正常运行。
架构的弹性不仅仅是设备,还必须包括人员和流程。
弹性的关键特征是计划内的系统降级——通过控制将系统降级,而非由于无法控制导致故障。
良好的弹性设计的一个例子,是在大容量云服务数据中心中使用混沌工程。混沌工程通过在时间敏感的在线服务中,不断进行故障自动转移测试,来验证系统弹性。

公理10:过程驱动
安全开发过程应使用清晰的生命周期,来解决要求的时间跨度,并引入利益相关方。
战略:安全架构的目标是支持组织的长期的业务战略。安全架构本身是一项战略活动,需要长期的投资和管理层的支持。
战术:安全架构是通过一系列步骤开发和实施的:利用变更项目从而使长期愿景变为现实。
运营:安全架构提供技术、工具、流程来确保日常的安全,并对业务运营提供风险管理。

公理11:优化冲突解决
安全应通过平衡业务风险,来优化解决利益相关方的冲突。
利益相关方的关注通常会发生冲突。安全架构的作用之一是以最佳方式解决这些冲突,在功能需求和其他非功能需求与安全需求之间取得平衡。这些利益冲突可能非常复杂,源于安全架构的跨复杂领域的性质。

公理12:清晰的沟通
安全应使用有利于业务和技术利益相关方之间进行有效沟通的通用术语。
安全架构师必须至少会两种“语言”,能熟练使用业务涉众的语言(“业务术语”)和技术人员的知识(“技术术语”)。

公理13:易用性
安全系统应该尽可能对用户透明且易于使用。
不易使用或导致生产受到影响/破坏的安全控制措施,通常会被忽略、禁用、废除,导致资源容易受到攻击,从而失去了控制措施的价值。而被绕过或未被使用的安全系统将毫无价值。
可用性差的经典示例,是密码的使用。另一个示例是Web浏览器使用PKI证书对网站进行验证。

公理14:安全设计
安全性应依赖于经过验证的特定控制措施,而非隐藏。
每本安全书籍都强烈建议不要使用“通过隐藏构建安全性”。其实通常被否定的,是希望安全漏洞不被发现的侥幸心理。
安全不应依赖于暗箱操作或其它晦涩的形式,而应依赖于经过验证的特定控制。就像密码学的安全性,应取决于对加密密钥的保护,而非加密算法。

公理15:优先级
使用较强的保护机制来保护较弱的机制,而非相反。
最重要的事物不应依赖于不重要的事物。

公理16:设备主权
所有设备均应能够在不受信任的网络上保持其安全策略。
保护机制通常位于本地或靠近被保护的资源更有效。这使得防护机制更容易随受保护资源一起迁移。
物联网设备的市场壁垒,使得设备主权原则难以适用。安全架构师必须面对这一挑战。不可能强迫市场将高级安全性集成到IoT设备中,因为这是一种市场驱动的现象,受成本和收益的感知驱动,但是设计整体集成的分层方式将改善一定程度的安全性。

公理17:纵深防御
通过分层防御可以获得更高的安全性。
纵深防御是一种传统方法,它通过在攻击路径上应用多层或多级安全性,来最大程度地保护每个资源。
为了使纵深防御有效,各层之间必须彼此独立,各层应该由不同类型的控制措施组成,而非多层使用同一类型的控制。
当控制措施失效时,选择失效而开放,还是失效而关闭,取决于资源的敏感性和它所支持的服务的需求。在此领域,有限状态机(FSM)建模可用于探索系统可能进入的所有可能状态。

公理18:最小特权
主体(人员、事物、流程等)应仅被授予执行其授权任务所需的权限。
部署最小特权系统和服务的能力,在一定程度上取决于可以执行细粒度访问控制的技术和流程。细粒度的访问控制,要求以一种方式捕获或存储有关资源或资产以及最终用户的元数据,以便访问控制系统可以通过它来做出有关资源的访问决策。
职责分离也是从纵深防御中衍生出来的一种特殊形式的最小特权。

公理19:访问管理
访问控制包括三种不同的操作过程:
识别:识别并区分主体;
认证:验证主体的身份;
授权:授予主体适当的访问权限。

公理20:通信安全
设备和应用程序应使用开放、安全的协议进行通信。
在当今过度连接的世界中,无法假设未加密的传输具有任何级别的安全性。
最重要的一点是,无论加密服务是否已打开并处于最佳运行状态,网络服务都无法向应用服务发出信号。因为网络无法理解应用程序的数据结构。
规则很简单:网络需要网络安全服务来保护。应用程序需要应用安全服务来保护。
通信安全架构是一门复杂的学科。它必须在通信设备之间采用敌对环境,并且必须同时满足应用程序层安全性和网络层安全性。

参考:
《网络安全架构:安全架构实践的公理》
安全内参是个很好的安全类技术网站,大家可以关注一下:安全内参官网

可信计算的核心技术

可信计算(Trusted Computing)是一种增强计算机系统安全性的技术,旨在确保计算机系统和应用的完整性、可靠性和安全性。它通过一系列机制和技术手段,如硬件安全模块、加密技术、安全验证等,来确保系统和应用的可信度,增强信息系统的内生安全能力。

可信计算和等级保护2.0是密不可分的,特别提出了把可信计算技术植入基础软硬件和网络的要求:
1、把可信验证要求植入芯片、CPU、服务器、操作系统、数据库等基础软硬件
2、把可信验证要求植入网络设备、网络安全产品,解决底层安全问题
3、把可信计算技术植入“安全管理中心、安全通信网络、安全区域边界、安全计算环境”网络要素,实现对网络要素全覆盖
4、把可信计算技术植入整机、云计算平台、物联网、工控系统、移动互联网
5、把可信计算技术植入第二级以上网络

可信计算的关键技术主要包括:
1、硬件层面的可信根(Trusted Root):可信计算通常从硬件层面开始构建,使用如TPM(Trusted Platform Module)等安全芯片作为信任的根基,确保从硬件到软件的整个启动过程是可信的。
2、系统启动的可信验证:在系统启动过程中,利用可信根对系统的引导程序、系统程序等进行可信验证,确保其未被篡改或破坏。包括计算设备固件引导程序和操作系统引导程序,以及计算设备固件程序和操作系统程序 。
3、可信验证(Trusted Verification):基于可信根,构建信任链,一级度量一级,一级信任一级,把信任关系扩大到整个计算节点,从而确保计算节点可信的过程 。
4、动态可信验证(Dynamic Trusted Verification):对验证对象(文件或程序)的静态内容、运行时内存中存储的关键变量及数据、属性等进行实时、周期性的可信判断。
5、可信计算模块(Trusted Computing Module):通常指TPM(Trusted Platform Module),是一种安全芯片,用于存储加密密钥和进行平台的可信度量 。
6、可信软件基(Trusted Software Base):确保操作系统和应用程序的代码在执行时是可信的,没有被恶意修改。
7、可信软件栈:可信软件栈(Trusted Software Stack, TSS)是一组软件组件,可以在操作系统上实现可信计算的功能。它包括了管理TPM(或其替代品)的驱动程序和工具,可以用来提供密钥管理、度量和报告等功能
8、远程证明(Remote Attestation):允许远程验证计算节点的可信性,确保远程通信的安全性。
9、安全审计(Security Audit):通过记录和分析系统活动,确保系统的安全性和合规性。
10、可信网络连接(Trusted Network Connect):确保网络连接的安全性和可信性,防止未授权访问和数据泄露。
11、用户和设备身份认证:通过强身份认证机制确保用户和设备的身份可信,如使用数字证书、生物识别等技术。
12、数据保护:使用加密技术保护数据的机密性和完整性,确保敏感信息不被未授权访问或泄露。
13、安全审计与合规性:实施安全审计,确保可信计算的实施符合相关的法律法规和标准要求。
14、安全管理中心:建立安全管理中心,对可信验证的结果进行集中管理、监控和响应,确保系统的持续安全。

什么是DevSecOps

DevSecOps是一种将安全实践集成到开发和运维(DevOps)过程中的方法论:安全不仅仅是安全团队的责任,而是整个IT部门(包含开发、测试、安全和运维等团队)所有成员的责任,需要贯穿业务生命周期的每个环节。
其核心理念是“安全内建”,即在软件开发的每个阶段都考虑安全性,而不是将其作为事后处理。DevSecOps 旨在通过自动化和协作来提高软件的质量和安全性,同时加快交付速度。

DevSecOps 的关键组成部分:
1、 安全左移(Shift Left Security):将安全活动前移到软件开发生命周期的早期阶段,以便在设计和编码阶段就识别和修复安全漏洞。
2、 自动化:通过自动化工具和流程来执行安全测试、代码审查和合规性检查,以提高效率和一致性。
3、 持续集成/持续部署(CI/CD):在软件开发过程中实现自动化的构建、测试和部署,确保安全措施能够快速响应开发变更。
4、 文化和团队协作:建立一种文化,其中开发、运维和安全团队共同协作,共同对软件的安全性负责。

如何实施 DevSecOps:

1、 建立跨功能团队:
组建包含开发、运维和安全专家的跨功能团队,确保从项目开始就考虑安全性。

2、 安全培训:
对团队成员进行安全意识和最佳实践的培训,确保他们了解安全的重要性和实施方法。

3、 定义安全策略和标准:
制定清晰的安全策略和标准,确保团队成员理解并遵循。

4、 集成安全工具:
选择并集成自动化的安全工具,如静态代码分析器、动态应用安全测试(DAST)工具、容器安全扫描工具等。

5、 实施安全编码实践:
在编码阶段实施安全编码标准和实践,减少安全漏洞。

6、 自动化安全测试:
在CI/CD流程中自动化安全测试,包括代码审查、自动化扫描和渗透测试。

7、 持续监控和响应:
实施实时监控和日志分析,以便快速检测和响应安全事件。

8、 合规性和审计:
确保遵守相关的法律法规和行业标准,定期进行安全审计。

9、 反馈和改进:
建立反馈机制,根据安全测试和监控结果不断改进安全措施。

10、 文档和透明度:
记录安全流程和事件响应计划,确保团队成员和利益相关者之间的透明度。

11、 灾难恢复和业务连续性:
制定和测试灾难恢复计划,确保在安全事件发生后能够快速恢复正常运营。

12、 文化建设:
培养一种安全文化,鼓励团队成员积极报告潜在的安全问题,并参与安全改进。

实施 DevSecOps 需要组织层面的支持和承诺,以及跨部门的协作。通过将安全集成到 DevOps 的每个环节,组织可以更有效地管理风险,同时加快软件交付的速度。

如何通俗解释零信任安全管控

零信任与传统的安全模型存在很大不同:
传统的安全模型:“一次验证+静态授权”的模式,就是“我记住你了,自己人”
零信任安全模型:“持续验证+动态授权”的模式,就是“你谁啊,凭证拿来”

用一句话解释零信任就是:别想刷脸,凭证拿来
无论你是哪个服务,无论你在内网还是外网,无论一天交互多少次,没有凭证,或者凭证无法验证通过,就会被阻止

零信任模型的核心原则:
1、永不信任:对内对外均不给予自动信任
2、持续验证:对所有入站和出站请求执行彻底验证
3、身份管理:对人、终端和应用进行统一身份化管理
4、精细授权:通过微分段、应用分级、功能分级、数据分级等技术,做到最小权限原则,减少潜在攻击面
5、动态授权:基于访问主体、目标客体、环境属性(终端状态、网络风险、用户行为等)进行权限动态判定
6、全局防御:持续监控终端风险、用户行为异常、流量威胁、应用鉴权等信息,实时进行信用评估
7、快速处置:对低分的主体,立即实施阻断措施

零信任模型的核心能力:
1、全面身份化能力
零信任的信任关系来源于对所有参与对象的身份验证,所有参与对象共同构建端到端信任链,参与对象包括网络、终端、人员、应用等。身份是访问控制体系的基石,零信任需要为所有对象赋予数字身份,基于身份而非网络位置来构建访问控制体系。
2、最小权限分配
零信任强调按需分配资源,实施细粒度的权限访问控制,仅授予访问主体执行任务所需的最小权限。
3、持续且动态的访问控制
零信任依据访问主体的身份信息、终端信息、网络信息等信任要素,通过实时计算信任要素形成访问控制策略。在资源访问过程中,一旦访问控制策略的决策依据发生变化,零信任将重新计算分析,动态调整认证和授权策略。
4、资源受控安全访问
零信任默认网络环境是不安全的,要求对所有业务场景、所有资源的所有访问请求进行强制身份识别和授权判定,确认访问请求的权限、信任等级符合访问控制策略后才予以放行。且要求所有的访问连接都必须加密。
5、组件联动能力
零信任需要具备较高的联动性,各类组件能够相互联动才能有效防范各类威胁并做到攻击快速闭环,切忌不可机械堆砌产品组件。

零信任架构的三大技术基础:
1、三大技术SIM之SPD,软件定义边界:应用程在部署时需要指定安全边界,以便将服务与不安全的网络隔离开。
2、三大技术SIM之IAM,身份识别与访问管理:解决身份唯一标识、身份属性、身份全生命周期管理的功能问题。
3、三大技术SIM之MSG,微隔离:在逻辑上将数据中心划分为不同的安全段,将网络边界分割到尽可能的小,然后为每个独立的安全段定义访问控制策略。

零信任架构的核心技术:
1、终端环境感知:对终端身份进行可信标识,赋予每个终端唯一的数字身份,并能够维护终端身份属性,对终端环境进行实时感知和度量,支撑零信任安全解决方案实现持续风险评估。
2、身份鉴别:身份引擎将出差人员、内部员工、合作伙伴、供应商等不同人员纳入统一认证平台,打通终端 PC、网络设备、应用系统、公司网络等各种业务系统之间的身份数据屏障。所有身份数据集中管理和共享,避免身份孤岛带来的身份数据不一致或重复、身份数据质量不可控等制约业务发展的问题,降低信息化成本。采用MFA(多因子认证)方式对同一用户进行身份鉴别,从而加强身份验证的安全性。
3、分级管控:身份引擎统一维护所有授权客体(包括应用资源、API 资源、服务资源)的安全等级。每次范围资源必须进行认证,当授权主体的安全等级大于授权客体的安全等级时,授权主体才能访问授权客体,反之则不能访问。
4、动态授权:基于对网络环境、终端环境、用户行为的持续风险评估实现授权动态判定,并且能够将访问目标的权限控制细化到应用级、API等级和服务等级,只对访问主体开放最小授权,极大地收缩了潜在攻击面,解决了传统静态授权带来的越权风险高、授权粒度粗等问题。
5、持续验证:案对人、终端和应用进行统一身份化管理,建立以身份为中心的访问控制机制。以访问主体的身份、网络环境、终端环境和用户行为等作为
认证的考量要素,并针对网络环境、终端环境、用户行为等进行持续风险评估,实现对接入用户和终端的持续验证,解决了由于安全边界逐渐模糊带来的一系列问题。
6、风险审计:根据认证日志、鉴权日志等输入,对用户安全等级的进行评价,重点对登录模式异常、访问时间异常、操作行为异常、访问习惯异常、访问关系异常等进行风险审计。
7、安全接入代理:统筹管理所有访问连接,为认证成功且具有权限的访问主体建立安全访问通道,帮助企业构建虚拟网络边界。可分为安全接入网关、API 网关、SDP网关三种类型。其中,安全接入网关、API 网关用于敏感应用场景,SDP 网关用于非敏感应用场景。

零信任架构的三层架构:
1、安全管理中心,部署安全态势感知引擎
安全态势感知引擎:对环境感知代理发送的终端风险评分、身份引擎发送的认证日志和鉴权日志、关键节点镜像的网络流量进行智能分析,实现对用户、终端、网络的安全评估。

2、策略控制中心,包括身份引擎、控制引擎
身份引擎:负责对接入用户以及终端设备进行统一认证和鉴权。当用户安全等级变更时,及时更新用户拥有的访问权限,并向安全接入代理网关下发权限变更指令。
控制引擎:通过与安全态势感知引擎联动,实现威胁事件的检测智能、处置智能、全局防御,显著提升威胁的闭环效率。

3、策略执行器,部署环境感知代理、安全接入代理网关(包括安全接入网关、SDP网关、API网关三种类型)。
环境感知代理:负责统一管理和执行终端管控策略,能够实时感知终端环境状态,并向安全态势感知引擎上报终端风险评分。
安全接入代理网:关作为终端用户访问企业内网的控制设备,能够统筹管理所有访问连接,为认证成功且具有权限的访问主体建立安全访问通道,帮助企业构建虚拟网络边界。根据用户访问场景选择安全接入代理网关的类型。

参考:
华为IP网络系列丛书:《零信任》

常见网络攻击方式02

1、DNS欺骗
攻击者把自己伪装为DNS服务器,在用户解析IP的时候,解析到恶意网站,或者钓鱼网站
其实,现实中不少用户都受到过此类攻击

2、DNS缓存污染
攻击本地DNS缓存,达到访问伪装网站的目的

3、最终极的,还有DNS根服务器攻击:
由于DNS的根服务器都在国外(美国、英国、瑞典、日本),所以其实各国都有一些应对方案

4、ARP欺骗
在局域网下,还有可能遇IP地址欺骗,就是伪装为可信IP,麻痹被攻击者

5、MAC泛洪攻击
在局域网下,伪造大量的MAC地址数据帧,把交换机的MAC地址标撑爆,导致交换机无法正确按端口进行数据转发,必须进行数据广播
攻击者通过网络嗅探等方式,获取敏感信息

6、VLAN跳跃攻击
利用VLAN的配置漏洞,精心构造网络包,达到穿透VLAN通讯,获取其他VLAN信息的效果

7、SSL劫持
利用中间人攻击方式,分别与上下游通讯节点建立加密连接,进行数据转发的同时,获取明文通讯信息

8、流量劫持(网络端)
域名劫持:篡改DNS解析记录,比如上面的DNS缓存污染
BGP劫持:攻击者通过操纵边界网关协议(BGP)来劫持网络流量,引导流量通过恶意路径

9、证书欺骗
攻击者把自己伪装为CA厂商,把自己伪装为加密网站,欺骗性很强
这种攻击前几年还真出现过,危害不小

10、拒绝服务攻击DoS
精心构造网络包,把服务器拖垮,服务器没有额外资源处理正常请求,对外表现为拒绝服务

SYN洪水攻击:利用TCP握手机制,构造大量SYN包,耗尽服务器TCP连接资源,达到拒绝服务的攻击目的
ICMP洪水攻击:伪造大量ICMP包,比如ping包,耗尽服务器资源,达到拒绝服务的攻击目的
UDP洪水攻击:伪造大量UDP包,带有不同的IP地址,耗尽服务器资源,达到拒绝服务的攻击目的

11、分布式拒绝服务攻击DDoS
利用上面说的肉鸡或僵尸网络,架设攻击软件,对一些网站拼命发起请求,让网站访问量剧增,资源耗尽,最后导致系统崩溃,无法继续提供服务
在云厂商推广期间,更有甚者批量注册大量云服务器,发起DDoS攻击,你能信
现在,由于IoT设备的剧增,但安全防护短期内又跟不上,有些攻击者就利用这些IoT设备,构建了僵尸网络,专门进行DDoS攻击

12、低速率拒绝服务攻击(LDoS)
现在各大云厂商都有自己的DDoS防火墙,让DDoS攻击效果大打折扣
通过周期性地发送大量数据包,利用网络协议的漏洞来降低被攻击端的服务性能

13、嗅探攻击
潜伏在网络中,做一个安静的嗅探器
抓取网络中全部数据,有针对的获取有价值数据
随着加密通信的加强,越来越难了
但就算是网络流量的大小,有时候也是机密

14、重放攻击
作为A和B的中间人,收到A的消息后,篡改,然后给到B
随着加密通信的加强,越来越难了

安全开发是如何执行的

谈到安全开发,咱们就要先明确一个问题,安全开发的目的是什么呢?

所有做过开发的小伙伴,一定会有一个概念,一个程序的逻辑Bug,一定越早发现,损失越小。
如果能在需求阶段,发现并解决这个Bug,损失可以是最小的。

安全开发也是这样,希望达到的目的就是:
安全风险左移,早发现,早管理,持续改进

在安全开发上面,其实有一些现成的框架可以遵循,比如SSDLC(适合迭代式开发)、DevSecOps(适合DevOps式开发)等。

本文就说一下,我们的SSDLC是如何执行的。

当前,在能执行之前,需要进行相关的建设,包括:
明确安全风险,明确安全基线,指定安全策略,进行安全教育,部署安全工具,进行相关培训等等。
这个每个公司差异比较大,选择的组件和厂商也大不相同,就不详细描述了。
我们重点说一下,一个安全相关的需求,是如何落地的。

1、安全需求
1.1安全需求识别
组织应该达成一个共识,哪些需求比如过安全评审,比如:
a、任何账号、密码相关的
注册、登录、密码验证、验证码、密码修改、账号注销等等
b、任何用户可以发布信息的
留言、灌水、内容发布、即时通讯、提交信息并展示
c、任何上传和下载的
d、任何交易相关的
大促、活动、秒杀、刷单、刷票、业务风险响应
e、任何钱相关的
积分、交易、资金往来、营销、相关接口
f、涉及SQL编写的
g、任何敏感信息存储或展示的
购买、支付、个人信息查询、添加删除信息、充值密码
移动端图片保存、人脸识别、手势密码
h、任何证书相关的
i、任何访问控制相关的
前后端访问控制、系统对接、日志、短信、邮件
j、任何批量操作相关的
查询、导入、导出
k、合规安全相关
隐私政策、个人信息采集、敏感信息传输、生物特征识别、账号注销
等等。
1.2安全需求强制纳入安全评审,安全管理人员可以指定其他需求进入安全评审、
1.3安全小组对需求进行评审,判定是否可以继续推进

2、安全设计
2.1设计人员给出方案
2.2安全小组评审设计方案,判定是否可以继续推进
2.3测试同学,同步书安全测试用例
2.4安全小组评审设测试用例,判定是否可以继续推进

3、安全开发
3.1、开发同学IDE安装好安全组件,组件可规范编码,并进行静态扫描,及时发现代码问题
3.2、开发同学自测后,提交代码库
3.3、开发同学在测试环境,运行流水线
3.4、流水线自动混淆、编译、加固、打包、部署,同步进行各类扫描,包括:黑盒、白盒、组件、镜像、隐私检测等
3.5、流水线给出相关漏洞
3.6、开发同学修复漏洞

4、安全测试
4.1、测试同学进行功能验证
4.2、测试同学进行安全验证:渗透、越权等
4.3、测试同学进行性能验证
4.4、验证通过后,提交相关报告

5、安全验证
5.1、此时可以进行UAT验证
5.2、在版本库相同的情况下,开发同学将代码发布到UAT环境
5.3、流水线门禁根据规则判定,是否可以发布
5.4、测试同学初步验证
5.5、用户验证

6、安全部署
6.1、此时可以把代码部署到生产环境

当然,上面的开发流程,只是整个安全开发体系中的一环。
实施安全开发流程,需要庞大的前期资源投入,以及渡过一个较长的不断改进的过程。