从设计安全到内生安全技术白皮书 2023_第1页
从设计安全到内生安全技术白皮书 2023_第2页
从设计安全到内生安全技术白皮书 2023_第3页
从设计安全到内生安全技术白皮书 2023_第4页
从设计安全到内生安全技术白皮书 2023_第5页
已阅读5页,还剩142页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

从设计安全到内生安全技术白皮书2023年12月前言设计安全发展沿革1.1美国:改变网络安全风险平衡041.2美国:网络空间知情工程081.3美国:系统安全工程111.5小结设计安全实施与挑战2.1技术支撑182.1.1安全语言182.1.2安全架构202.1.3安全运营技术252.2规则制定262.2.1软件开发规则272.2.2漏洞管理规则292.2.3供应链规则302.2.4安全测试规则322.3意识培养352.3.1S&S联合协同352.3.2数字资产意识362.3.3网络安全文化392.4设计安全亟需面对的挑战412.4.1关注未知安全风险412.4.2一体化安全系统架构设计2.4.3安全量化测试与认证2.5小结内生安全赋能制造侧安全3.1内生安全概述3.2内生安全引领范式转变3.2.1新思维视角3.2.3新评价机制3.3内生安全构造增量优势3.3.1未知威胁抵御3.3.2设计安全策略的合理权衡3.3.3破坏式安全测试方法3.3.4阻断风险演变路径3.3.5架构涌现的内生弹性3.4内生安全赋能电力关键基础设施制造侧安全3.4.1威胁分析3.4.2设计思路3.4.3安全增益分析总结参考文献网络领域存在令人不安的现状,社会接受了这样一种期望,即所有软件都必须通过补丁处理的缺陷,其中大部分都是在恶意行为者利用软件中的弱点之后进行的,这种“偏差正常化”意味着我们正在接受不符合我们自己的安全标准的软件漏洞/后门问题是所有包含数字元素的软硬件系统底层驱动生态环境中不可能无法避免“补丁上或补丁后”还可能引入新的安全漏洞的矛盾问题。此外,许多安全事件并非来源于单一的系统组件故障,而是因为非故障组件之间的不安全相互作用所致。漏洞/后门问题是所有包含数字元素的软硬件系统底层驱动生态环境中不无法避免“补丁上或补丁后”还可能引入新的安全漏洞的矛盾问题。此外,许多安全事件并非来源于单一的系统组件故障,而是因为非故障组件之间的不安全相互作制造商需将客户产品安全置于产品全生命周期的前沿和中心没有单一的解决方案可以结束恶意网络行为者利用计安全”的产品仍将继续遭受漏洞。但是,大量漏洞是由相对较小的根本原因子集造成的。制造商应制定书面路线图,使其现有产品组合与更安全的设计实践保持一不是企图消除内源性问题本身。其核心是利用结构加密/环境加密,阻断内外因相再也不能投机取巧地进行渐进式的改进了。如果我们要共同强的对手构成的威胁,我们必须拥抱彻底的透明度和问责制,这在今天会让人感到随着数字经济的蓬勃发展,数字产品已融入日常生活的方方面面,相较于制造商而言,当前数字产品的用户却承担了过多的网络安全责任全漏洞,没有任何测评机构能为数字产品作无漏洞后门的担保;另一方面,网络安全的成本和不利后果却都由用户和第三方机构承担。可以预见的是,随着物理空间和数字空间的进一步融合,当前由用户和第三方机构提供“外挂式”的网络安全方法将不再满足关键业务的“使命确保”近年来,为了应对日益严峻的网络安全风险,欧美各国不约而同地提出网络安全应进行范式转变,敦促网络安全责任从用户侧向制造侧转移,强调数字产品制造商亟需将“设计安全”作为产品设计和开发过程的前沿和中心,从数字产品全生命周期的初始设计阶段就有意识地确保设计安全强调制造商应切实承担自身网络安全责任,这对于网络安全的发展而言是一个重大的模式转变。然而,当前设计安全的技术和方法等本质上还是“尽力而为”尽可能减少漏洞的实践考虑,仍未彻底转换当前网络安全打鼹鼠式的思维视角,仍未彻底摆脱“漏洞归零”的方法论和思维惯性。然而,由于人类认知能力桎梏、工程师能力限制、系因此,当前设计安全应当在转移安全责任的基础上再向前走一步,从“尽力而为”的打鼹鼠范式跃迁为安全可量化、可测试、可验证的内生安全范式,使数字产品获得原生的或内源性的安全,保障系统能在不依赖(但不排斥)攻击者先验知识(库)或精确感知与探测分析的条件下,阻断内外因相互作用,防止未知的未知安全威胁演变为安全事件,打破显而易见,制造侧安全是当下网络空间安全发展的必经之路。本白皮书首先介绍了国际上制造侧安全实现(即设计安全)的发展沿革和最新动向,对设计安全的技术内涵、原则方法进行了归纳总结。其次,针对设计安全仍面临的挑战,本白皮书基于中国原创的内生安全理论和思想,对内生安全如何赋能制造侧安全、引领网络安全范式转变进行了阐述。最后,结合典型电力场景阐述了内生安全赋能制造侧设计安全、默从设计安全到内生安全技术白皮书“设计安全”的定义源于制造侧安全的目标和愿景,是欧美国家对网络安全责任的深刻反思。近年来,随着数字化转型不断深入,以高级持续性威胁(AdvancedPersistentThreat,APT)、零日漏洞(0day)为代表的网络安全问题愈发突出,网络安全威胁规模越来越大,危害也越来越深。更严重的问题是,数字制造商的安全责任失衡,企业将自身经济利益置于产品安全之上,选择性无视潜在的安全风险。例如,前美国政府网络安全高官Grotto就曾撰文,指责微软公司在一边制造网络安全问题,一边设法解决这些问题,并从中获利。文中指出,微软公司已经在某种程度上“锁定”了政府客户,政府机构及其他部门除了使用微软公司提供的安全服务外几乎别无选择。又例如,英特尔近期被指控在2018年就发现了其处理器存在“Downfall”漏洞,然而英特尔为了避免更新修补漏洞影响处理器性能,选择对该漏洞置之不理,放任存在安全隐患的产品进入市场,让使用者面临不必要的安全风险。今年7月,TikTok也被曝出早在2022年4月,英国国家网络安全中心就已警告TikTok存在正在被利用的漏洞,而后者却并未选择修复漏洞,最终导致土耳其总统连任选举期间多达70万个土耳其TikTok账户遭到黑客攻击,个人信息和访问权限被窃取。正如欧盟委员会科学联合研究中心在报告中指出的那样,“数字行业缺乏有效竞争,且很容易出现激励错位。”一方面,数字产品为了争夺客户,需要迅速投入并占领市场;另一方面,客户更换产品的可能性较小,用户粘性强,这种“胜者全拿”的网络效应驱使制造商明知其产品有漏洞仍然将其投入市场。正因如此,美国在今年发布的《国家网络安全战略》中指出,“现有驱动美国数字生态系统的底层架构存在严重缺陷。”为了应对上述问题,欧美认识到不能继续放任数字商品“野蛮生长”,设计安全的概念便应运而生。欧美国家对设计安全的极力提倡说明他们已转换视角,转变思路,强调数字产品制造商自身的安全责任。2023年2月,美国网络安全和基础设施安全局执行总监发表演讲“停止在网络安全问题上推卸责任”(StopPassingtheBuckonCybersecurity),强调企业必须将安全融入科技产品,阐明了美国向制造侧转移网络安全责任的强硬态度。欧美认为,目前“外挂式”的网络安全方法已不再能满足当今数字化转型的需要,只有通过制造侧发力,在系统工程的早期阶段就将网络安全问题考虑进来,才能最小化网络安全风险。对于设计安全的目标实体和具体实施方案,欧美各国提出了众多战略和指南文件,本章将对其进行简要梳理。美国在2023年最新发布的《国家网络安全战略》中提出,现有驱动美国数字生态系统的底层架构存在严重缺陷,美国必须从根本上改变(makefundamentalchanges)数字生态系统的底层驱动,向防御优势方转变[1-1]。2023年7月,美国白宫发布《国家网络安全战略实施计划》,提出要推动开发安全设计和默认安全的原则和实践,并指定专门部门负责实施并设定时间节点,保持每年进行动态更新。作为对网络安全战略的响应,美国网络安全和基础德国联邦信息安全办公室、荷兰国家网络安全中心、新西兰计算机应急小组、新西兰国家网络安全中心等联合发布了《改变网络安全风险平衡:设计安全与默认安全的原则与方法》[1-2],其内容主要围绕软件产品的安全设计和配置提供指导建议。该指南指出,只有结合安全的设计实践,才能打破不断创建和应用修复程序的恶性循环。仅半年之该指南将“设计安全”术语阐述为包含“设计安全”和“默认安全”两方面。之所以提供这样一个指南,是因为这些国家和机构认为当前的网络系统融入了日常生活的方方面面,关键系统中不安全的技术和漏洞会引发恶意网络入侵,导致严重的潜在安全风险。而从历史上看,技术制造商一直依赖于修复客户部署产品后发现的漏洞,要求客户自费应用这些补丁,因此在当前阶段,其认为技术制造商比以往任何时候都更需要将“设计安全”和“默认安全”作为产品设计和开发过程的焦点。为了创造一个技术和相关产品对客户更安全的未来,这些机构敦促制造商修改他们的设计和开发计划,只允许向客户运送设计安全和默认安全的产品。其中设计安全的产品是指客户的安全是核心业务目标,而不仅仅是技术功能;而默认安全的产品是指可以安全使用的、几乎不需要或根本不需要更改配置的、并且没有额外成本的“开箱即用”产品。总之,这两个原则将保证安全的大部分负担转移给了制造商,并减少了客户从设计安全到内生安全技术白皮书1.软件制造商应对客户购买产品的安全负责,并相应地改进产品。安全责任不应仅仅落2.拥抱彻底的透明度和问责制。软件制造商应以提供安全的产品为傲,并根据其能力与其他制造商社区区分开来。这可能包括共享他们从客户部署中获得的信息,例如默认情况下采用强身份验证机制的接受情况。这还包括坚定承诺确保漏洞通告和相关的通用漏洞和披露记录是完整和准确的。然而,要警惕将通用漏洞和披露视为负面指标的情绪,因为这些数字3.建立组织结构和领导能力来实现这些目标。虽然技术专业知识对于产品安全至关但高级管理人员是组织中实施变革的主要决策者。软件制造商在产品开发中将安全作为关键要素的承诺需要与组织的客户建立合作伙伴关系,以了解:a.提供产品部署指南和量身定制的威胁模型。b.计划实施安全控制,以符合默认的安全原则。c.制定资源分配策略,适应公司规模,并替代传统的开发实践,以实现安全设计。d.保持开放的内外沟通渠道,包括员工和客户反馈,以处理产品安全问题。这应该在内部论坛(如全员会议或午餐会议)以及外部产品营销和客户互动中强调软件安全性。e.在客户部署中衡量效果。高级管理层应关心根据在最新版指南中,对上述三个原则涉及的具体内容进行了详细说明,本文在图1-1中对其进行(消除献认密码(消除献认密码进行现场测试漏洞管理拥抱开放标准(提供升级工具发布未使用权限的数据建立内部安全控制发布详细的自我声明的安全软拥抱漏洞透明度发布漏洞披露政策发布内存安全的路线图开发实践业务中安全实践创建设计安全委员会创建井发展客户委员会软件制造商应对客户购买产品的安全负责开发实践情况1)设计安全1)设计安全“设计安全”定义:技术产品的构建方式合理地防止恶意网络行为者成功获取设备、数据和连接基础设施的访问权。软件制造商应进行风险评估,以识别和列举关键系统可能遭受的常见网络威胁,然后在产品蓝图中包含考虑到针对不断演化的网络威胁形势的具体保护措施。同时建议采用安全的信息技术开发和实施多层次的防御措施,即所谓的纵深防御,以防止网络威胁活动危害系统或获取未经授权的敏感数据访问权。最后,建议制造商在产品开发阶段针对这样的“设计安全”定义,指南参考美国国家标准与技术研究院发布的《安全软件件开发实践,可以集成到每个软件开发周期模型中,遵循这些实践应该有助于软件生产者减少发布的软件中漏洞的数量,减少未检测或未解决漏洞被利用的潜在影响,继而解决漏洞的内存安全编程语言:尽可能优先使用内存安全语言。创作机构承认,其他特定的内存缓解措施,如地址空间布局随机化、控制流完整性和模糊化,对遗留代码库有帮助,但不足以被视为设计上的安全措施,因为它们不能充分防止漏洞被利用。现代内存安全语言的一些例安全硬件基础:包含能够实现细粒度内存保护的体系结构功能,例如CapabilityHardwareEnhancedRISCInstructions(CHERI)所描述的那些功能,它可以扩展传统的硬安全软件组件:从经过验证的商业、开源和其他第三方开发人员处获取并维护安全性良好的软件组件(如软件库、模块、中间件、框架等),以确保消费级软件产品的安全性。Web模板框架:使用实现用户输入自动转义的Web模板框架,以避免跨站点脚本等静态和动态应用程序安全测试:使用安全测试工具来分析产品源代码和应用程序行为,导致SQL注入的无标题用户输入)等问题。静态和动态应用程序测试工具可以合并到开发过程中,并作为软件开发的一部分自动运行。静态和动态应用程序测试应补充其他类型的测试,如单元测试和集成测试,以确保产品符合预期的安全要求。当发现问题时,制造商应进行根代码评审:努力确保提交到产品中的代码通过其他开发人员的同行评审,以确保更高的漏洞披露计划:建立漏洞披露计划,允许安全研究人员报告漏洞。作为其中的一部分,常见漏洞与公开威胁完整性:确保已发布的常见漏洞与公开威胁包括根本原因或常见弱点列举,以实现软件安全设计缺陷的全行业分析。虽然确保每个常见漏洞与公开威胁都是正确和完整的需要花费额外的时间,但它允许不同的实体发现有利于所有制造商和客户的行业纵深防御:设计基础设施,使单个安全控制的妥协不会导致整个系统的妥协。例如,确保严格提供用户权限并使用访问控制列表可以减少受损账户的影响。此外,软件沙盒技术可例如不要求所有员工都进行防钓鱼的多因素身份验证,那么他们就不能被视为提供安全的设2)默认安全2)默认安全“默认安全”定义:指产品在初始状态下具有抵御常见攻击的能力,且无需额外费用。这些产品在不需要最终用户采取额外安全措施的情况下,保护免受最常见的威胁和漏洞的影响。“默认安全”产品的设计旨在让客户深刻地意识到,当他们偏离安全的默认设置时,除非他们安装和配置过程中要求管理员设置强密码。要求特权用户启用多因素认证(Multi-Factor源部下属的爱达荷州国家实验室(IdahoNationalLaboratory,INL)于2015年提出建立CIE学科施CIE,包括后果驱动的CIE(Consequence-drivenCyber-informed美国能源部实施网络空间知情工程的主要原因是现代工程实践因未考虑网络攻击后果而存在根本性挑战。工业界和学术界无法彻底解决几乎所有监控设计络专家),并利用网络安全专家的专业知识,在各种能源系统的工程生命周期中最小化网络风CIE是一种知识体系和方法,用于描述在传统模拟环境中引入数字计算机系统所带来的风安全风险可能导致的后果事件来量化描述已知或未险,CIE提出设计简化原则用来降低漏洞的数量,通过工程风险管理来降低网络安全风险的后最后,这些设计原则通过工程手段融合在一起形成纵深防解和减轻网络安全风险。CIE使用的工程生命周期模型将生命周期简化为七个核心系统工程阶键考虑因素的原则分为设计和组织原则。CIE通结构化和彻底的流程来确定网络攻击可能在何处导致高后果影响,并检查如何通过安全的设过程中附加信息技术安全控制的需要。使用协调的控制和流程来消除高来强制执行这些信息流。该项CIE原则可以限制攻击者以其不希望的方式使用系统或其信息的相互依赖性评估:整合来自多个学科(如安全、质量、维护、化学)和部门(如运营、业务)的输入,以了解数字滥用如何影响其运营领域。这确保了工程师能够充分规划系统相互依赖性带来的风险,这些风险可能超出了工程师的传统权限。正如前文已提到的,系统安全工程是设计安全策略的一个重要参考。美国国家科学技术委员会于2019年发布的《联邦网络安全研究与发展战略计划》中提出,网络安全防御框架的保护这一要素便依赖于系统的安全设计。系统安全工程注重系统早期阶段的风险管理和安全设计,被誉为美国网络安全领域“圣经”的《网络安全设计权威指南》(EngineeringTrustworthySystems)其副标题为:在第一时间做好网络安全设计(GetCybersecurity美国国家标准与技术研究院(NationalInstituteofStandardsandT列出版物的最初版本于2016年11月发布,名为“系统安全工程”(SystemsSecurityEngineering),它提供了关于可信赖安全系统工程的指南,强调了安全性在系统工程中的重要性。2018年3月,NIST对原版文件进行了更新,反映了当时的最新安全实践和标准。大的内容更新和设计变更,将标题修改为“可信赖安全系统工程设计”(EngineeringTrustworthySecureSystems),梳理了可信赖安全系统的工程设计原则和概念,形成了各类系统安全性设计的共识[1-15]。NISTSP800-160系列出版物站在系统工程的角度对设计安全NIST定义系统安全工程是系统工程的一个分支学科,其主要目标是确保系统在其生命周期中应用系统安全的原则、理念和方法,从而实现系统的可信赖设计和资产保护。为实现系统安全工程的目标,NIST提出了一个整体的系统安全工程框架,该框和任务的三个上下文(contexts):问题上下文、解决方案上下文、可信赖上下文。基于以上问题上下文为安全系统定义打下基础,问题上下文主要关注对于利益相关者不可接受的损失,考虑对任务、操作能力和性能的相关要求,以及所有相关的成本、进度、性能和风险驱动的限制条件。问题上下文为早期生命周期阶段的解决方案提供信息,从而提供对问题及相关约束更准确的陈述。定义明确且经由利益相关者验证的问题定义上下文能够为所有系统解决方案上下文为系统的体系结构和设计建立了安全方面(aspects)和约束,包括:满足问题上下文的要求和目标,实现系统设计,以及提供证据证明问题上下文的要求和目标已经得到满足。解决方案上下文同时采用主动和被动的系统安全保护策略,控制事件、条件和可信赖上下文是一种决策上下文,它通过推理提供基于证据的证明,即基于安全目标得出一组声明,认为相关系统是可信的(或不可信的)。可信赖上下文是基于保证案例(assurancecase)的概念,保证案例是一组定义明确、结构合理的论点和证据,能够表明系网络安全性、弹性、可信赖性或生存性。有效的安全保证案例包括源自安全目标的基本安全声明、证实这些声明可信的相关证据,以及将各种证据与所支持的安全主张联系起来的有效论点。图1-2展示了系统安全工程框架及其关键组件。CONCEPTS,PRINCIPLES,MEANS,METHODS,PROCESSES,PRACTICESTOOLforAcceptableR7图1-2系统安全工程框架可信赖安全设计被定义为一种为利益相关者提供信心的方式,使其相互冲突的能力需求、关注点、优先级和约束得到满足。可信赖安全系统的设计目标是建立和保持系统功能在可接受的水平,同时最大限度地减少损失的发生和损失的程度。系统设计必须提供预期的行为和表1-1列出了可信赖安全设计的相关原则,这些原则以研究、开发和应用经验为基础,从安全工程早期纳入可信操作系统开始,一直延续至今天的组件、环境和系统,并预计将持续普遍适用于新兴和成熟的方法。可信赖安全系统设计的原则涉及功能安全性(safety)、网络安全性(security)、可靠性(reliability)、生存性(survivability)和弹性(resilience)及其他相关的专业工程学科等多个领域。这些原则的最终目标是为了让系统能够可信控制设计原则设计原则异常检测最小权限相称的保护中介访问组合信赖持续保护纵深保护降低复杂性多样性(动态性域分离(域隔离)最小依赖的信赖分级保护结构化分解与组合最简化功能可信赖系统控制从设计安全到内生安全技术白皮书系统安全工程提供了一种全生命周期的设计思路,在风险识别的基础上建立安全的系统从系统工程的角度来看,数字产品所面临的风险主要来自数字经济转型下物理世界、信息网欧盟十分重视当前网络安全责任转型的大背景,对于设计安全已有一套成熟的理论指导,并通过政策和立法积极推动网络安全责任从用户侧向制造侧转移。2020年底,欧盟发布了未来数字化十年的网络安全战略[1-16],指出了欧盟的关键基础设施和基本服务日益相互依存和数字化现状,要求其所有联网设备在设计上确保安全,对网络攻击具有弹性。欧盟理事会自2020年开始筹划数字产品制造商实施网络弹性设计的立法相关事宜。2021年9月,欧盟理事会主席冯·德莱恩首次提出立法要求,其立法逻辑为:制造商缺乏认真对待安全问题的动机,如果没有政策制定者的适当干预,市场无法应对不断上升的网络安全风险。2022年5月,欧盟理事会提出立法进程要求,同年9月,欧盟公布法案草稿。2023年7月,欧盟成员国达成共同立场,授权与欧洲议会谈判最终条文。欧盟的《网络弹性法案》标志着网络弹性/设计安欧盟对于设计安全的理论基础主要来自于欧盟委员会科学联合研究中心(JointResearchCentre,JRC)于2020年发布的研究报告《网络安全—我们的数字之锚(欧洲视角)》指出了当前数字发展中的弱点和网络安全新挑战。报告在摘要中提到:“安全对于数字产品的必要性,以及欧盟出台政策进行管理的动机。报告认为,通常情况下,公司对产品的改进和服务动机来源于市场激励。然而,数字行业缺乏有效竞争,且很容易出另一方面,信息系统的设计通常面临弹性与性能的权衡,制造商缺乏必要的激励措施来投资产品全生命周期的安全开发。因此,近50%制造商明知其产品有漏洞仍然将其投入市场,这使得网络安全市场具有强烈负外部效应(negativeextern但同时也会降低数字产品后续的危害影响,从长远看仍然可以降低制造商的维护和修补成本以及最终用户全生命周期的使用成本。综上所述,“市场失灵的地方,政府必须干预”,这份报告为欧盟在网络安全领域的政策和法规制定提供了理论支持。JRC在报告中聚焦于网络安全风险,从缓解风险的角度提出网络安全的主要研究思路。与其他类型的风险一样,网络安全风险包含两个主要因素:负面网络事件发生的可能性和此类事件的潜在威胁后果。即使一件负面事件发生的可能性低,但如果其后果影响很大,由此产生的风险仍然非常大,例如针对一个国家核电站设施某些部件的重大恐怖网络攻击。负面网络事件发生的可能性取决于有动机进行攻击的威胁行为者以及其攻击手段,而成功攻击目标的结果则是产生的影响。基于这三个主要维度:威胁行为者(即网络攻击者)、漏洞(即系统弱点)和影响(即成功的网络攻击的不利影响),JRC提出了一种网络安全风险演变概念模型,如图1-3所示,图中的箭头表达了三个主要维度之间的相互作用。·威胁行为者指的是任何有动机通过网络攻击获取某种回报的行为者或团体。包括寻求获利的纯粹网络犯罪分子,也包括追随特定意识形态的活动者,或是由国家支持的攻击者。·威胁向量是威胁行为者利用威胁工具进行网络攻击的手段,如图中第一个内部箭头所示。威胁工具可以是任何形式的恶意软件,如计算机病毒。漏洞可以包含多种具体形式,主要反映了软件和计算机代码设计中的安全弱点。·威胁行为者寻求从攻击中获得回报,最终造成影响。网络攻击的影响通常是由攻击者有意追求的回报与攻击的附带损害的组合造成的。例如,银行木马程序窃取的资金和攻击导致图1-3中三个重叠圆圈内的区域表示有效的网络安全风险。JRC认为,在现实世界中,风险的三个要素始终存在,因此需要使用既定的有限资源,制定风险缓解策略(控制措施),将风险降低到可接受的水平。报告将网络安全风险缓解策略总结为三个方面,分别针对风险的三个主要维度:(1)威慑威胁行为者;(2)缓解漏洞;(3)通过网络弹性限制影响。在策在《数字之锚》中,设计安全被定义为在新产品和服务的开发生命周期的早期进行安全需求识别,并相对于功能需求进行了适当的优先级排序。设计安全和默认安全是网络安全的重要指导原则,其目标是减少数字系统、服务和流程中的漏洞。然而,目前这一原则在行业中没有被广泛应用,因为数字产品的安全工作者经常不被视为最终产品价值构建的直接贡献者。为解决这一矛盾,报告中提出了一些措施,包括在适用于产品和服务开发的法规中引入漏洞管理是设计安全和默认安全的有效补充,因为即使在遵循默认安全和设计安全原则方面尽了最大努力,漏洞很可能会随着时间的推移而被发现。漏洞管理的目标是为这些事件弹性设计被定义为确保系统能够在不利条件下持续运行,弹性设计与设计安全的原则和网络弹性是欧美在网络安全方面的一个重要研究方向,是弹性工程、网络(空间)安全和使为了实现上述原则,JRC提出了一些典型技术,包括多样性和模块化分层防御、冗余和降级模式功能、快速响应与恢复、安全认证与标签等。在JRC看来,必须在系统的全生命周期阶段贯彻设计安全、默认安全、漏洞管理、弹性设计等原则,才算实现制造侧安全,这些从设计安全到内生安全技术白皮书由于目前网络安全责任的严重失衡,仅通过用户侧或第三方机构基于事后修补的方式已难以应对日益严峻的网络安全威胁。因此,欧美各国纷纷出台网络安全战略及政策,希望通过数字化转型倒逼网络安全转型,将网络安全责任向制造侧转移,打造安全弹性的数字生态系统。基于这样的背景和目标,设计安全的概念应运而生。对于设计安全的具体实施方案,美国CISA、NIST、能源部以及欧盟都基于各自的视角提出了多种策略。但无论侧重点如何,设计安全都强调数字产品制造商应认识到自身的安全责任,在系统设计之初赋予产品具体的PHRLPHRL02当前,欧美国家主要的网络安全机构已提出诸多策略,为设计安全的具体实施进行支撑和指导。设计安全实施的具体举措包含在数字产品生命周期的各个阶段,本章将其归纳为技术支撑、规则制定和意识培养三个方面,并进行简要分析。2.1技术支撑2.1.1安全语言2.1.1安全语言设计安全的一个重要方面是关注内存安全问题。美国国家安全局于2022年发布指南[2-1],旨在帮助软件开发商和软件运营商预防和缓解软件内存安全问题。之所以提出这样一份指南是因为内存安全问题在可利用的漏洞中占比非常大,微软曾统计其在2006年到2018年70%的漏洞都是由于内存安全问题造成的[2-2];谷歌公司也曾发布类似统计数据[2-3]。恶意网络攻击行为者会利用不良的内存安全问题来访问敏感信息造成极大的负面影响。美国国家安全局认为常用的语言,如C和C++,在内存管理方面提供了很大的自由度和灵活度,因此其对程序员的要求很高,程序员需要理解内存操作行为,同时对内存引用操作进行细致的检查,简单的错误就会导致出现内存安全漏洞。尽管存在软件分析工具可以检测很多项目代码存在的内存安全问题,但只有基于设计安全原则的内存安全语言所提供的固有保护才可以防止大多数内存安全问题。现有可以替代C和C++的内存安全语言包括C#、Rust、Go、Java、Ruby或Swift等。内存安全是指在访问存储器时,不会出现缓冲区溢出或是迷途指针等和存储器有关的程序错误或漏洞。C和C++语言之所以不被认为是内存安全语言,是因为其可以进行很多指针运算,访问存储器时也不会进行边界检查。本文将存储器错误问题归纳如表2-1所示:表2-1存储器操作错误问题总结分类设计原则设计原则设计原则缓冲区溢出程序向缓冲区中写入数据使缓冲区容量溢出时,导致相邻缓冲区过读竞争危害页当指针所指向的对象被释放或者收回,但是对该指针没有址空指针引用故障指针变量可以指向堆地址、静态变量和空地址单元,当引障,有可能产生不可预见的错误内存泄漏堆栈溢出使用过多的存储器时导致调用堆栈产生的溢出非预期的别名同一个存储器同时被二个不同用途的函数配置及修改美国国家安全局也指出,内存安全语言中的“内存安全”也是相对的,“大多数内存安全语言承认,软件有时需要执行不安全的内存管理功能来完成某些任务。因此,有一些类或函数被认为是非内存安全的,并允许程序员执行可能不安全的内存管理任务。某内存不安全的内容进行明确的注释,以使程序员和程序的任何审查者意识到它是不安全的。内存安全语言还可以使用以非内存安全语言编写的库,因此存在不安含内存不安全机制的方法颠覆了固有的内存安全性,但它们有助于定置,从而可以对这些代码部分进行额外的审查”。为了能更直观的了解内存安全语言,我们这从设计安全到内生安全技术白皮书Java是一种广泛使用的编程语言,可用于编码Web应用程序。它已成为开发人员近二十开发的通用、编译型编程语言。设计准则为“安全、并发、实用”,支持函数式、并发式、过编译成功后,变量内存何时回收已被确定并硬编码到二进制程序中,待程序运行到回收时将自2.1.2安全架构2.1.2安全架构设计安全是将安全性集成到系统、应用程序或产品的设计和开发过程中,而不是事后添加安全措施。网络安全架构与“设计安全”之间存在紧密联系,因为架构提供了指导和框架,以确保安全性得以在整个系统或网络的设计和开发中考虑。设计安全的核心理统构建和开发阶段预防漏洞和威胁。这与网络安全架构的目标相一致,即通网络风险。这里我们从设计安全技术支撑的角度,总结了三个主流的网络安全技术框架,分别是零信任网络安全架构(ZeroTrustNetworkArchitecture)、纵深防御架构(Defensein1)零信任1)零信任然而,零信任架构采用了一种全新的思维方式,即不信任任何人或设备,即使他们内部或外部都与组织有关。这种零信任的思想鼓励组织以一种更加审慎的方式对待网络访问,将网络零信任架构的核心原则在于“永不信任,不断验证”[2-5]。这意味着无论是内部员工还是外部用户,他们在访问网络资源时都需要进行身份验证和授权,无论是从内部网络还是从最小特权原则:要求用户只能访问他们工作所需的资源,而不是所有资源。这降低了潜多层次的安全:零信任架构采用多层次的安全来验证用户、设备和应用程序的身份。这包括多因素身份验证,将密码、生物识别数据、智能卡等多种身份验证因素结合在一起,提持续监测:是零信任架构的关键组成部分,它通过不断监控用户和设备的活动,以及网络流量,以便及时检测和应对潜在威胁。这种实时监测可以快速识别异常行为,帮助组织采这意味着资源的访问权限将根据用户的实际需要和身份进行动态控制,而不是基于静态的权多因素身份验证:是确保身份验证的强大方法。它要求用户提供多个验证因素,例如知识因素(密码)、拥有因素(智能卡)和生物识别因素(指纹或面部识别)等。网络分割:为了减小横向移动攻击的风险,零信任架构采用网络分割的策略,将网络分日志和分析:零信任要求组织收集和分析大量的日志数据,以监测异常活动和潜在的安全威胁。高级分析工具和人工智能技术可帮助组织快速识别安全事件,并采取适当的措施来尽管零信任架构为提高网络安全性提供了强大的框架,但其实施也面临一些挑战。例如实施零信任可能需要组织重新设计其网络架构,包括重新审视现有的身份验证和授权流程,这可能需要大量的时间和资源,强制多重身份验证和访问控制可能会对用户体验产生负面影响。用户可能感到不便,尤其是在频繁的身份验证步骤时。因此,需要在安全性和便捷性之间寻求平衡,实施零信任可能需要投入大量的成本,包括安全技术的采购、员工培训和监控总而言之,零信任架构是一种现代网络安全范例,其是设计安全的重要支撑技术之一,从设计安全到内生安全技术白皮书其核心原则在于不信任任何人或设备,以确保网络资源的安全性。表2-2将常见的网络安全措施与零信任原则进行了对应。尽管实施零信任可能会面临一些挑战,但它仍是提高组织网络安全性的重要方法。这一新兴领域将继续发展,以适应不断变化的网络安全威胁。最小特权原则多层次的安全持续监测网络流量与设备监控√为所有用户应用最低权限√对办公网络与公共网络进行分区√√√√纵深防御也被称为“分层防御”,也是实现设计安全的一个重要技术之一[2-6]。通常纵深防御使用多种安全产品和实践来保护网络、Web资产和资源等[2-7]。纵深防御是设计安全的重要支撑技术之一,单一安全产品无法完全保护网络免受可能面临的每一次攻击,而多种安全产品和实践可以帮助检测和预防出现的攻击,使系统能够有效地缓解各种威胁。纵深防御的一个优点是冗余,当某一道防线受损之后,其他安全措施可以帮助限制和减轻攻击行为对整个网络和系统的损害;而这种优点是单点防御所不具备的[2-8]。从设计安全到内生安全技术白皮书生物识别技术:包括指纹识别、面部识别和虹膜扫描等,提供更高级别的身份验证,以定期培训员工,以提高他们对安全威胁的意识,包括如何识别恶意邮件、社会工程学攻纵深防御技术将这些多层次的控制和策略整合在一起,以建立坚固的安全基础,从而最大程度地保护组织的信息和资产,降低各种威胁带来的风险影响。这些措施需要持续更新和333)3)NIST网络安全框架NIST的网络安全框架(NISTCybersecurit络安全的指南和工具集。它于2014年首次发布,作为美国总统行政命令的一部分,但它已被NIST网络安全框架NIST网络安全框架5244·确保员工培训和意识。检测(Detect):侦测领域的目标是快速识别网络安全事件和威胁。活动包括:·进行漏洞扫描和安全审计。NIST网络安全框架不仅提供了以上核心领域的指导,还强调了持续改进和适应的概念。组织可以根据其特定需求和风险面临的情况,自定义和实施这些措施。该框架还提供了工具2.1.3安全运营技术2.1.3安全运营技术网络安全运营技术是设计安全中一项至关重要的组成部分,旨在保护组织的网络和信息资产免受各种威胁和攻击的侵害。网络安全运营技术中的入侵检测和入侵恢复于确保系统的安全性和弹性。入侵检测系统(IntrusionDetectionSystem,IDS)和入侵防御这些系统能够识别异常模式和警告迹象,为安全团队提供了及时的速应对威胁、隔离受感染的系统、恢复受影响的服务,以及分析入侵事件以源头。这一过程还包括修复漏洞、清除恶意代码、强化访问控制,并采来入侵的风险。综合而言,入侵检测和入侵恢复技术在设计安全实时监测和迅速应对威胁,它们帮助确保网络系统的持续稳定和可靠性,从而维护了组织的络安全。根据检测的数据来源,现有入侵检测系统可分为:网络入侵检测系统(Network流量的工具,通常位于网络边界,监控流入和流出的数据包。通过分析数据包,检测异常流量模式和已知攻击签名。比如Snort,一个常用的NIDS工具,可以检测到各种攻击,如扫描、机上,监视主机级事件,如文件系统更改、进程活动和系统调用。它们识别行为。比如Ossec,一种开源的HIDS工具,可监视文件完整性、日志活动和入侵恢复则涉及恢复受影响系统的正常运行状态,并进行调查以了解入侵的性质和来源。这一过程包括修复漏洞、清除恶意代码、更新访问控制策略,并采取预防措施以防止未来的入系统。如果网络中某个服务器受到恶意软件感染,将其从网络2.2规则制定针对设计安全转移网络安全责任的目标,近期以美国、欧盟为首的网络了一系列关于系统开发、供应链管理、安全测试等方向的规则或要求,目的是保证数字产品生产商能够按照既定规则更有效地控制和减少漏洞。本节将对目前主流的设计1)开源软件管理1)开源软件管理由于美国联邦政府、州政府、地方政府和大量关键基础设施都在很大程度上依赖于开源软件,因此美国网络安全和基础设施安全局(CybersecurityandInfrastructureSecurityAgency,CISA)认为有必要制定相关规则管理、掌握和保护相关开源软件的开发,从而降低政府机构和关键基础设施面临的风险。CISA于2023年9月发布开源软件安全路线图(CISAOpenSourceSoftwareSecurityRoadmap),用以支持健康、安生态系统建设[2-11]。路线图提出了2024到2026财年亟需实现的4大目的(Goal)和15个对应目标(Objective)。本文将路线图的4个预期目的总结如下:社区之间的工作关系,建立一个安全、有弹性的开源生态系统,为帮助提高更广泛的开源软件生态系统安全性做出贡献。CISA认为,目前开源社区已经有许多专注于安全的举措正在进为了解CISA如何更好地支持开源软件生态系这一目的期望确保联邦政府对开源软件的合理使用。与负责参与开源软件的公司类似,联邦政府必须建立相应流程来管理自身对开源软件的使用及为依赖的开源软件做出贡献的方CISA已经意识到开源软件的公益性,并认识到保护更广泛的开源软件生态系统的努力将为了实现对开源软件的有效管理,CISA成立了专门机构联合网络防御协作中心(JointCyberDefenseCollaborative,JCDC),探索实时的公私合作模式,将私营部门的可见性、洞察力、创新性与联邦网络生态系统的能力和权威相结合,并将安全管理模式从应对威胁和漏2)框架设计2)框架设计架设计方面做了多项努力。如2.1.2节中提及的网络安全框架(CybersecurityFramework,CSF)是NIST于2014年提出的网络安全防御框架,该文件是目前全球认可的网络安全体系,为管理跨部门网络安全风险的通用语言和系统方法提供指导。NISTCSF由标准、指南和管理网络安全相关风险的最佳实践三部分组成,其核心内容可以概括为经典的IPDRR能力模型,即风险识别能力(Identify)、安全防御能力(Protect)、安全检测能力(Detect)、安全响应在设计安全概念兴起后,NIST于2023年8月起草了CSF2.0的重要更新。本次更新主要体现在NIST将CSF的适用范围扩大到所有设施扩大到所有数字信息相关组织,不管其类型或规模如何。这一差异体现在CSF的正式名称上,从限定性更强的“提高关键基础设施网络空间安全的框架”更名为通俗化名称“网络建配置文件提供了指导。配置文件可以为网络空间安全界适用于特定的领域或案例提供帮助。与此同时,CSF2.0还提供了参考工具在线资源支持,该在线资源将允许用户浏览、搜索与其他资源之间的关系的“参考文献”,从而使将该框架与其他指南一起用于管理网络空间安框架等,设计安全中的许多概念都来源于美国NIST多年以来深耕的网络空间安全标准化生态。间推移而发生变化,因此该项依据需要有时间标业务基本职能(MissionEssentialFunction注意:该漏洞需要组织内部进行个人级别的监督。针对该漏CISA另一项针对漏洞管理的努力是开展通从设计安全到内生安全技术白皮书动化,减少了漏洞被披露到企业修复之间的时间,并为未来的漏洞信息自动共享提供了工具。除此之外,设计安全还鼓励政府机构和制造具包为目前尚无漏洞披露流程但希望创建披露流程的组织提供了相关规则。NCSC提出漏洞披如今的信息物理系统大多依赖于错综复杂、全球遍布、广泛互联的供应链生态。因此,在推动数字制造商底层软硬件安全开发和漏洞管理的同时,美国也意识到供应链安全的重要供应链中的弱点,这一问题既涉及商业软件,也涉及开源软件,对私营企业和政府企业都有影响。为了解决供应链安全问题,美国政府发布了一项网络安全行政命令(EO14028),制定了保护联邦政府软件供应链安全的新要求,该命令涉及软件供应商和开发人员的系统审查、流程改进和安全标准等。作为回应,美国国家安报告《保护软件供应链:供应商的推荐实践》(SecuringtheSoftwareSupplyChain:RecommendedPracticesforSuppliers)[2-14]。该报告的目标是根据行业最佳实践和原则提供指导,包括安全需求规划、从安全角度设计软件体系结构、添加安全功能以及维护软件美国NIST早在2015年就发布了供应链风险管理的相关文件(NISTSP800-161),当时文件的主要目标群体是联邦的信息系统和相关组织,其主要关注的供应链风险也集中在信息和通信技术产品和服务。2022年5月,NIST对该出版物进行了更新,发布NISTSP800-161r1:《系统和组织的网络安全供应链风险管理实践》(CybersecuritySupplyChainRiskManagementPracticesforSystemsandOrganizations),为数字系统和组织提供了识别、评估和减轻各级供应链中网络安全风险的指导[2-15]。该出版物采用多层次的安全供应链风险管理(Cybersecuritysupplychainriskmanagement,C-SCRM)纳入风险管评估的指导。具体来说,NIST在文件中提出了一个三层次的方法来配置和构建一个C-SCRM活动:接受企业级别的指导,并将其转化为针对特定任务领域和业务线的战略、政策和为了实现更大的供应链透明度,美国政府敦促各供应商给所属数字产品提供软件材料清家网络安全状况的行政命令,要求商务部和国家电信和信息管理局发布确保软件供应链安全许可证信息、版本号和供应商。通过提供所有细节的正式列表,使其他人能够了解其软件中的内容并据此采取行动,从而降低了生产者和消费者的风险。美国C将通过促进社区参与、开发和进步来推进SBOM工作,重点是扩展和操作,以及工具、新技2023年9月,CISA发布了来自信息和通信技术供应链风险管理工作组的新的供应链风险控制产品硬件材料清单框架(HardwareBillofMaterialsFramework,HBOM)[2-16]。HBOM产品提供了一个框架,包括组件属性一致性的命名方法、识别和提供不同类型组件信息的格式,全面的信息和明确的指导,各组织可以防范经济和安全风险,增强整体抵御能力;通过HBOM提高透明度和可追溯性,利益相关者可以识别和解决供应链中的潜在风险,确保数字全并负责向政府机构、行业及其他合作方提供供应链风险管理政策及技术指导。总体来说,设计安全所提倡的供应链管理主要通过软件成分分析、交互式应用安全检测、运行时安全防要求所有员工进行防钓鱼的多因素身份验证,那么他们就不能被视为提供了设计安全的产品。A1管理(Governance):制定管理组织网络和信息系统安全方法的政策和流程;A4供应链(Supplychain):理解和管理依赖于外部供应商的信息系统安全风险。BB3数据安全(Datasecurity):防止对存储和数据基本功能造C1安全检测(Securitymonitoring):监测以发现潜在的安全问题并跟踪现有安全措施的C2主动安全事件发现(Proactivesecurityeventdiscovery):检测相关网络和信息系统最小化网络安全事件影响。有能力将网络安全事件对基本功能最小化网络安全事件影响。有能力将网络安全事件对基本功能运行的不利影目标DD1响应和恢复计划(Responseandrecoveryplanning):制定适当的事故管理和缓解流D2经验学习(Lessonslearned):从安全事件中吸取教训并基于这些经验教训提高基本职每一项原则都可以分解为一组较低级别的有助于网络安全和弹有这些结果才能完全满足最高级别原则。对一个组织满足某一特定原综上所述,目前较为通用的设计安全评估方法和测试方法主要基于自上2.3意识培养从历史上看,功能安全工程和网络安全工程是两个不同且不太相关的领域,功能安全问题和网络安全问题也常被视为单独的问题去解决。功能安全起源于机械工程,而安全工程是然而,信息物理系统(Cyber-PhysicalSystems,CPS)的出现打破了功能安全工程和网络安全工程的边界。随着信息物理系统数字化程度的提升,二者交叉程度越深,独立考虑功能安全和网络安全问题不再能够确保系统安全,也很难同时实现功能安全和网络安全。从智能家电到智能工业控制、智慧城市、智能交通,等等,因为可以提高产品、服务和基础设施的效率、功能和可靠性,信息物理系统正被社会广泛使用,且人们对信息物理系统的依赖程度逐渐加深。由于信息物理系统特性越来越依赖于计算、网络和信息处理,信息物理系统中的功能安全和网络安全变得紧密耦合。功能故障可能会导致网络安全措施的失效,恶意网络攻击也可能会削弱系统,并在物理世界中造成严重后果,从而消除技术带来的所有优势功能安全和网络安全的交织与耦合,当前系统工程过程需要联合考虑功能安全和网络安全,即实现功能安全和网络安全的联合协同(下称S&S联合协同)。实现功能安全与网络安全的联合协同已成为安全工程领域的重要课题,当前的S&S联合协同仍是从风险分析和处理的角度来实现。为了实现设计安全,首先需要共同分析影响系统可靠性的功能安全和网络安全风险。Schmittner等人提出“故障模式、漏洞和影响分析”方法[2-19],综合分析故障和网络攻击对系统可靠性的影响。该方法将系统分为子系统和组件,确定了威胁模式的可能性。该方法是传统概率风险评估方法的扩展。考虑到网络风险不仅包括数字故障和非故意网络事件,还包括对手可能试图故意破坏、威慑、否认、降级或破坏数字系统,从而将数字化系统置于预期设计之外的可能性。因此,为实现设计安全,网络空间知情工程提出通过后果优先级的方式识别和分析安全风险(尤其是网络安全风险),并开发了后果驱动的网络空间知情工程(Consequence-drivenCyber-informedEngineering,CCE)。其根据风险可能导致的后果进行优先级排序,并对不同优先级的风险采取消除、缓解、保护、FrankJ.Furrer[2-20]等人则认同需要通过严格应用和执行安全原则来实现,其给出安全原则包括:1、访问控制原则,2、信任控制平面与网络平面分离原则,3、安全文化原则,4、安全标准与政策原则,5、安全管理体系原则,6、安全实现原则,7、产品责任原则以及8、记录保管原则等。这些主要安全原则从不同角度指导了安全的实现,帮助系统开发人员在设计阶段实现功能安全和网络安全的有机整合。而L.Bukowski等人在书中强调安全工程的概念,特别是受到干扰、危险和威胁的程的基本概念包括安全策略的制定、实施和正确性评估,以及安全措施的成本与效益之间的平衡。该书为此提出了以生命周期为基础的系统安全工程框架,该框架涵盖了系统在整个生命周期中的所有过程和活动,并专注于特定的安全考虑因素,包括保护信息免受攻击的过程,以及保密性-完整性-可用性三元模型等。该研究综合考虑生命周期安全工程、网络安全和安除此之外,为了在设计安全中实现S&S联合协同,还需在系统生命周期的每个阶段协调功能安全和网络安全的作用。为此,Schmittner等人提出一个组合开发周期。基于现有标准和最佳实践中的生命周期模型,该方法将功能安全和网络安全纳入一个统一的工程过程生命周期,具有一套平衡的措施,用于减轻开发过程中的功能安全和网络安全风规范中,综合分析和考虑确保功能安全的网络安全影响。在设计阶段开始时,对功能安全和网络安全目标的定义进行了整合。在开发阶段,考虑采取功能安全和网络安全措施来实现设计目标。例如,可以使用防篡改硬件来增强对环境影响的鲁棒性。在实施/实现阶段,限制动态元素使用的功能安全编码标准从而减少缓冲区溢出利用的次数。功能安全和网络安全开发阶段被定义为一个超越发布时间的持续过程。作为事件响应的一部分,新的漏洞需要重新考虑功能安全和网络安全概念,并对其他系统质量属性进行影响分析。除了在退役过程中保持必要的功能安全级别外,还需要考虑潜在的攻击者是否能够从已处理的系统中了解潜在的漏2.3.2数字资产意识2.3.2数字资产意识数字经济转型背景下为各项基础设施、设备的数字化带来了难以的物理模块具有不同的弱点和模式。数字资到这一点,网络空间知情工程将数字资产意识列为其基本原则,数字资产工作机理。数字资产意识不只是当前网络安全实践强调的识数字资产意识一方面要求维护一个完整准确的数字资产清单,从分析一个组织所拥有的硬件和软件,还可以跟踪和解析其中的数字资产清单是一项基本要素,但实际中确认和部署阶段则是确保系统按照设计意图被成而带来意外风险的功能,从而在设计阶段限制不必要功能或制定措施缓解系统被滥用/误用风现,数字资产清单是否充分详细说明了设计中规定的所有商用现成数字在运行和维护阶段,需要考虑如何不断重新评估数字资产以意想不到的方式运行的潜力,如何持续审计以跟踪数字资产的功能,以及在运行过程中发生了什么变化风险评估与缓解的设计安全并非一蹴而就,需要通过全生命周期不断题,可以确保部分数字资产退役或替换后的系统仍能安全运行,或为实现替过全生命周期不断迭代反馈才能排除各种已知风险,并基于专家经验审在过去的50年里,功能安全文化渗透到了大多数行业,因为控制系统失效而导致人身伤害是不可接受的,事故可能会造成巨大的经济损失和公众的不信任。相比之下,网络安全最初被视为一个抵御互联网攻击的信息技术问题。然而,随着数字化程度的不断加深,网络攻击不仅会削弱功能安全控制,还会削弱物理安全控制。尤其在信息物理系统中,网络攻击会通过系统的信息域和物理域耦合接口对功能安全造成威胁。比如,通过覆盖数字组件或系统的设计指令来执行恶意行为,能实时智能地影响这些数字组件或系统,从而可能对组织的功由于网络被纳入工程过程,因此工程学科必须纳入网络安全。所有工程师、运维人员等与目标系统利益相关者都是网络防御团队的一部分,必须使他们都了解网络攻击是如何被用于恶意操纵的。从工程的角度来看,网络安全文化必须制度化,并仔细考虑与数字组件或系为此,网络空间知情工程建议将网络安全提高到与功能安全同等的接受和实践水平。就像功能安全文化一样,网络安全文化需要全体员工的参与和认可,了解安全需求及其在整个安全文化中的作用有助于确保他们遵循强化网络安全所需的流程和程序。通过组织跨职能和跨学科团队在系统设计和实施中考虑数字风险,从而将网络安全纳入组织文化,在整个组织网络空间知情工程建议围绕系统设计过程建立网络安全文化,并将网络安全文化影响到系统的所有利益相关者,而非传统的将网络安全视为对组织技术和实践实施的一套事后安全措施。为此,工程设计团队需要认识到数字故障或网络攻击对正在设计的系统的影响,其核心责任是帮助对系统负责、咨询或了解系统的所有利益相关者了解网络安全的必要性,以及每个利益相关者的角色如何对系统产生积极和消极的影响,从而实现系统的整体安全性。工程设计团队可以效仿建立安全文化的最佳实践,比如定期讨论如何以及为何将网络安全纳入系统,承认和庆祝团队成员的良好决策和正确行动,并将失败视为学习和改进的机会,等等。由于设计过程之外的团队成员可能没有意识到他们的工作角色如何有助于或削弱整个系统的从设计安全到内生安全技术白皮书网络安全,因此在网络安全文化中,工程设计团队对个人进行个性化对话很重要。因此,网络安全文化不只需要工程设计团队实现设计安全,同时需要通过对所有利益相关者基于角色进行个性化网络安全培训,降低设计意图之外引入的意外风险,同时有助于运维等成员有意识地关注和收集网络安全相关事件,从而为实现修补或升级系统的设计安全提供风险评估依题的方式实现网络安全文化。从实现设计安全的角度来看,组织需要在概念阶段和需求阶段尽可能了解目标系统的目的和期望,实现目标系统对工程师团队有哪些要求,在设计阶段使目标系统复杂度尽可能低并能容忍可能出现的错误,在开发、测试、验证、确认和部署阶段如何培训个人和团队,如何激励个人畅所欲言,报告在各阶段发现的人员、流程、技术等方面的问题,后续的运行维护、退役和替换则是确保运维人员知晓如何应对异常情况或状况,在概念阶段,需要考虑高级领导层对目标系统的目的有何意图和期望,参与创建、操作和维护系统的高级领导层、经理和主管以及技术人员和工人的利益是什么,对目标系统的期望如何转移到硬件供应商、咨询工程师之类的其他组织,等等。通过考虑这些问题,可以确保系统设计能实现预期目标,同时确保目标系统所有利益相关者的利益和目标一致,从而降哪些潜在的组织优势和劣势与系统需求相互作用或相关,操作概念中的错误前兆在哪,比如任务需求、工作环境、个人能力、人性等等。因为人类科技发展和认知水平的阶段性特征导致软硬件代码设计脆弱性或漏洞问题无法彻底避免,而且工程师团队人员能力存在限制,因此通过考虑这些问题,可以某种程度降低因工程师团队认知能力桎梏和工程能力限制导致的在设计阶段,需要考虑如何避免通过增加复杂性的方法来解决设计问题和改进系统,如何改进对合理错误的检测,如何提高从错误中恢复的能力,等等。通过考虑这些问题,简化系统复杂度,从而降低系统攻击面。此外,通过设计系统,使其容忍可能出现的错误,赋予在开发阶段,需要考虑在系统的整个生命周期中,个人和团队需要什么样的培训、教育和实践来操作、维护、保护和防御目标系统,如何确认和记录积累技术债务的选择。通过考虑这些问题,确认团队人员如何培训,使团队成员能对系统进行正确的操作、维护、保护,降低团队成员无意识地滥用或误用系统,同时能在运行维护阶段中及时发现滥用/误用以及异从设计安全到内生安全技术白皮书在测试、验证、确认和部署阶段,需要考虑是否有足够多的工作人员参与测试,以感知意外事件和现象,是否鼓励工作人员及时发现问题,而不用担心因发现系统漏洞而遭到报复。通过这方面的网络安全文化建设,可以更及时、全面地发现系统设计存在的漏洞、意料之外在运行和维护阶段,需要考虑当操作员遇到异常情况或状况时如何应对,如何确定“人为错误”的罪责,以确定待解决问题的根本原因,根据行为和选择去判断采取哪些干预措施,而非根据所实现的后果采取防护措施,等等。通过考虑这些问题,确保设计阶段采取的各种在退役和替换阶段,需要考虑保存系统的哪些信息对替换或其他系统很重要,这有助于综上所述,网络空间知情工程通过在全生命周期推行网络安全文化,实现所有系统的利益相关者都能具备网络安全意识,都能基于自己的角色为系统的全生命周期安全做出贡献。通过形成网络安全文化,将网络安全嵌入组织的价值观和优先事项中,并通过行为和选择证明网络安全可以从强制性转变为固有质量。同时也可以看出,实现设计安全并非只需关注工程过程的设计阶段,而需要全生命周期贯穿设计安全理念,所有利益相关者通过直接或间接2.4设计安全亟需面对的挑战现有设计安全的出发点仍是减少漏洞、修补漏洞,其强调网络安全基本问题是软硬件设计的脆弱性带来的漏洞问题,漏洞一旦被攻击者利用就会造成安全事件,因此需要在设计之初就分析可能存在的网络安全风险,修补已知漏洞,利用简化设计来降低漏洞数量、减小攻击表面,或者进行弹性设计,以便在漏洞被利用造成后果后进行快速恢复。然而,漏洞后门是无法完全消除的,基于现有设计安全方法设计的系统无法实时应对未知的未知安全威胁和例如,网络空间知情工程提出以后果优先级的方式描述并排序风险,在具体实现中,后果驱动的网络空间知情工程(Consequence-drivenCyber-informedEngineering,CCE)通过确立基准假设来描述敌手能力,然后分别从敌手视角和系围和边界条件,并根据边界条件确定潜在的破坏性事件,根据影响区域、持续时间、攻击广从设计安全到内生安全技术白皮书度等维度评估潜在破坏性事件的后果,并进行优先级排序,在系统设计阶段,采用系统工程的方法有效处理高后果的潜在风险。欧盟JRC在《数字之锚》报告中从缓解风险的角度实现设计安全,它通过网络事件发生的可能性和此类事件的潜在威胁后果角度识别和描述风险。具体实现中,其设计安全的目标是减少数字系统、服务和流程中的漏洞,并融合弹性设计以应对难以消除的风险。1.1节的《改变网络安全风险平衡:设计安也是通过风险评估来识别和列举关键系统可能遭受的常见网络威胁,然后在设计之初在目标可以看出,已有的设计安全路线侧重基于对风险的先验认统中可能存在无法被检测的失陷,但是其做出的应对仅限于被动的失陷影响业务的中断性损失也是难以弥补的。后果导向的风险分析方法某需关注未知安全风险,在设计之初赋予目标系统感知未事件驱动的弹性恢复,而应能主动感知未知威胁,从而保当前的设计安全领域在面对网络安全问题时,往往缺少一体化安全系统架构设计的理念。这使得设计安全的各项技术和措施在增加成本的同时,还可能导致系统变得更加复杂,进而当前设计安全策略缺少一体化架构设计的缺点主要有以下几个方面。首先,这种缺失会相互之间缺乏协调和配合,这不仅增加了系统的复杂性,还可能导致资源浪费和性能下降。例如,如果系统中同时存在多个防火墙、入侵检测系统等安全组件,它们可能存在重复或冲其次,缺少一体化架构设计还会降低系统的鲁棒性。鲁棒性是指系统在遭受攻击或出现故障时仍能保持正常运转的能力。缺乏一体化设计的各种安全措施可能难以协同工作,无法形成整体的防御合力,这使得系统在面临复杂多变的网络安全威胁时更容易受到攻击和破坏。例如,如果系统中的防火墙和入侵检测系统之间缺乏有效的联动机制,当恶意攻击突破防火此外,缺少一体化架构设计还可能导致安全策略的执行不力。由于各种安全措施可能存在不同的配置和管理方式,这可能导致安全策略在执行过程中出现偏差或漏洞。例如,如果系统的各个组件由不同的团队或厂商提供,每个团队或厂商可能遵循不同的安全标准和规范,最后,缺少一体化架构设计还会降低安全管理的效率。由于各种安全措施可能存在不同的管理和监控工具,这可能导致安全管理过程变得复杂和繁琐。例如,如果系统中有多个安全监控工具,每个工具可能需要独立管理和配置,这不仅增加了管理成本,还可能导致安全综上所述,一体化架构设计对于提高设计安全性具有重要意义。通过将各种安全措施和要素整合到一个统一的框架中,一体化设计可以简化安全管理流程、提高系统的鲁棒性、增强安全策略的执行力度、降低系统的复杂性和冗余性等。这不仅可以提高系统的安全性,还一体化安全系统架构设计是一种将各种安全措施和要素整合到一个统一框架中的方法。这种方法有助于提升系统的整体安全性,降低复杂性并提高鲁棒性。特别是面对日益严峻的体化安全系统架构设计有助于实现统一的安全策略规划。在面对复杂的网络安全威胁时,一个统一的安全策略是至关重要的。只有当所有的安全措施都遵循相同的安全策略,才能确保各种安全措施能够协同工作,从而更有效地应对各类威胁。其次,一体化安全系统架构设计有助于简化网络安全管理流程。通过整合各种安全措施,一体化设计可以降低安全管理的复杂性,提高安全管理的效率。这不仅可以降低安全管理的成本,还可以提高安全管理的效果。对于企业来说,简化安全管理流程可以提高企业的运营效率,降低企业的经济成本。再次,一体化安全系统架构设计有助于提高系统的鲁棒性。鲁棒性是指系统在遭受攻击或出现故障时仍能保持正常运转的能力。一体化设计可以使各种安全措施更好地协同工作,提高系统整体的鲁棒性。当系统遭受攻击时,各种安全措施可以迅速响应并联合抵御攻击,从而最大程度地减少损失。例如,当系统遭受高级持久性威胁攻击时,一体化设计的防御系统可以快速检测、隔离并清除恶意软件,从而减少损失。此外,一体化安全系统架构设计有助于提升网络安全防御效果。通过将各种安全措施和要素整合到一起,可以更好地协调各个部分的工作,从设计安全到内生安全技术白皮书提高整体防御效果。最后,一体化安全系统架构设计有助于降低网络安全风险。虽然一体化设计的初始投入可能较高,但长期来看,它可以降低维护和升级的成本。此外,由于一体化设计可以提高鲁棒性并降低复杂性,因此可以减少因安全问题导致的损失。这不仅可以保障数字化深度转型背景下,信息物理域高度融合,物理域面临的攻击威胁逐渐增多,信息域造成的破坏性也随之增大。同时,由于网络空间各层级漏洞成因复杂、点多分散,难以完全根除,加之信息物理跨域攻击路径和机理错综复杂,难以完全探明,传统可靠性安全评估方法越来越难以保证信息物理系统的安全性。当前设计安全/默认安全强调制造侧安全责任,敦促数字产品制造商向客户运送“开箱即用”的安全产品,而这些数字产品的安全性如何自证就成为了一个亟待解决的难题。欧盟JRC在《数字之将安全量化认证视为设计安全风险管理的一项重要手段。然而,该文中也指出,目前尚无全球公认的安全定量标准。正如本白皮书在2.2节中所分析的,当前设计安全提供的安全测试规则通常基于指标体系静态评估和已知漏洞库比对展开,缺少破坏式或注入式安全测试,难以事实上,网络空间的安全度量一直以来都是各方网络安全机构的研究重点。例如美国性评估、指标定量得分评估、网络弹性覆盖图等方法上取得了积极的进展。MITRE提出的网络弹性定量评分方法是一种可定制的评分方法,通过两种方式进行定位或背景调整:第一,它反映了利益相关者的优先级(即哪些目标、子项目和能力是重要的)。第二,根据关于操作和威胁环境的既定假设进行性能评估(即提供优先级能力的程度或优先级活动的实际执行情题的根本原因或常见弱点列举(CommonWeaknessEnumeration,CWE),从而实现对软件安全设计缺陷的全行业分析。可以看出,设计安全将已知漏洞库的比对作为安全测试的重要综上所述,当前主流的安全度量方法依赖于对系统环境的理解、对已知漏洞库的比对,系统安全基线的表达、评估指标体系的建立及评分等。这种通过定性分析和半定量评级结合的方法虽然能清晰地指出网络安全/弹性和具体安全措施之间的逻辑关系,也相对易于实施,从设计安全到内生安全技术白皮书但仍然存在一些说服力不足的问题。例如,如何明确证明一个系统的安全性达到了某个量级,评估指标不同的系统之间应该如何对比安全性,复杂系统的可塑性和涌现性应该如何评估等。因此,设计安全仍需研究一种合理且令人信服的安全量化测试方法和规则,特别是破坏式或注入式的安全测试方法,对不同的数字产品、供应链进行安全认证,从而实现制造商对于数设计安全强调制造商应切实承担自身安全责任,从数字产品制造初期开始严格管理其设计和开发计划,而不是仅依

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论