NIST 网络安全框架 2.0 2.0
控制项模式网络安全框架提供了管理网络安全风险的通用语言和系统方法。CSF 2.0 将其范围从关键基础设施扩展到所有组织,并新增了一个治理功能。
网络威胁情报和其他上下文信息已整合到分析中 标准:例如1:安全地向检测技术、流程和人员提供网络威胁情报数据 | 例如2:安全地向检测技术、流程和人员提供资产清单中的信息 | 例如3:迅速获取并分析组织技术的漏洞披露信息供应商、卖方和第三方安全通告
信息来自多个来源的关联 标准:示例1:将其他来源生成的日志数据不断传输到相对较少的日志服务器 | 示例2:使用事件关联技术(例如,SIEM)收集多个来源捕获的信息 | 示例3:利用网络威胁情报帮助关联日志来源之间的事件
不良事件的信息提供给授权人员和工具 标准:例如1:使用网络安全软件生成警报并将其提供给安全运营中心(SOC)、事件响应人员和事件响应工具 | 例如2:事件响应人员和其他授权人员可以随时访问日志分析结果 | 例如3:在组织的工单系统中自动创建和分配工单当发生某些类型的警报时的警报系统 | 示例4:当技术人员发现受损指标时,手动在组织的工单系统中创建并分配工单
已了解不良事件的估计影响和范围 标准:例1:使用SIEM或其他工具来估计影响和范围,并审查和完善这些估计 | 例2:某人自行创建影响和范围的估计
当不良事件符合已定义的事件标准时,即可声明为事件 标准: 示例1:将事件标准应用于已知和假定的活动特征,以确定是否应声明事件 | 示例2:在应用事件标准时考虑已知的误报
潜在的不利事件会被分析,以更好地理解相关活动 标准:例如1:使用安全信息和事件管理(SIEM)或其他工具持续监控日志事件,以发现已知的恶意和可疑活动 | 例如2:在日志分析工具中利用最新的网络威胁情报,以提高检测准确性,并描述威胁行为者、他们的方法及妥协指标omise | 示例3:定期对无法通过自动化充分监控的技术的日志事件进行人工审查 | 示例4:使用日志分析工具生成关于其发现的报告
计算硬件和软件、运行时环境及其数据会被监控,以发现潜在的不利事件 标准: 例1:监控电子邮件、网站、文件共享、协作服务及其他常见攻击向量,以检测恶意软件、网络钓鱼、数据泄露和外泄及其他不利事件 | 例2:监控身份验证尝试,以识别针对凭据的攻击和未经授权的凭据重复使用 | 例3:监控软件配置是否偏离安全基线 | 例4:监控硬件和软件是否有篡改迹象 | 例5:使用在终端存在的技术来检测网络健康问题(例如例如,缺失的补丁、恶意软件感染、未经授权的软件),并在允许访问之前将端点重定向到修复环境
对网络和网络服务进行监控,以发现潜在的不利事件 标准: 例1:监控 DNS、BGP 及其他网络服务以发现不利事件 | 例2:监控有线和无线网络,以检测来自未授权终端的连接 | 例3:监控设施以发现未授权或流氓无线网络 | 例4:将实际网络流量与基线进行比较,以检测偏差 | 例5:监控网络通信用于零信任目的识别安全姿态变化的应用程序
人员活动和技术使用受到监控,以发现潜在的不良事件 标准: 示例1:使用行为分析软件检测异常用户活动,以减轻内部威胁 示例2:监控逻辑访问控制系统的日志,以发现异常访问模式和失败的访问尝试 示例3:持续监控欺骗技术,包括用户账户的任何使用情况
物理环境受到监控以发现潜在的不良事件 标准:实例1:监控物理访问控制系统的日志(例如,通行证阅读器)以发现异常访问模式(例如,偏离常规)和访问失败尝试 | 实例2:审查和监控物理访问记录(例如,访客登记、签到表) | 实例3:监控物理访问控制(例如检查(门锁、闩锁、铰链销、警报器)是否有被篡改的迹象 | 示例4:使用警报系统、摄像头和保安监控物理环境
对外部服务提供商的活动和服务进行监控,以发现潜在的不利事件 标准:示例1:监控外部提供商在组织系统上执行的远程和现场管理及维护活动 | 示例2:监控云服务、互联网服务提供商及其他服务提供商的活动,以发现与预期行为的偏差
有关网络安全的法律、监管和合同要求——包括隐私和公民自由义务——已被理解并得到管理 标准: 示例1: 确定一个流程来跟踪和管理关于保护个人信息的法律和监管要求(例如, 健康保险可携性与责任法案,加利福尼亚消费者隐私法案,通用数据保护条例) | 示例2:确定一个流程来跟踪和管理供应商、客户和合作伙伴信息的网络安全管理合同要求 | 示例3:将组织的网络安全策略与法律、法规和合同要求保持一致
组织使命得到理解,并用于指导网络安全风险管理 标准:例1:共享组织的使命(例如,通过愿景和使命声明、营销以及服务策略),为识别可能阻碍该使命的风险提供基础
组织所依赖的成果、能力和服务已被理解并传达 标准:例1:创建组织对外部资源依赖的清单(例如),设施、基于云的托管提供商)及其与组织资产和业务功能的关系 | 示例2:识别并记录对组织关键能力和服务可能构成故障的外部依赖关系,并将该信息与相关人员共享
已了解内部和外部利益相关者,并已了解和考虑他们在网络安全风险管理方面的需求和期望 标准:例如1:识别相关的内部利益相关者及其与网络安全相关的期望(例如,高管、董事和顾问的绩效和风险期望;员工的文化期望)| 示例2:识别相关的外部利益相关者及其与网络安全相关的期望(例如,客户的隐私期望、合作伙伴的商业期望、监管机构的合规期望、社会的道德期望)
利益相关者依赖或期望组织提供的关键目标、能力和服务得到理解并被传达 标准:示例1:建立评估内部和外部利益相关者所看重的能力和服务关键性的标准 | 示例2:确定(例如从业务影响分析中) 对实现任务目标至关重要的资产和业务操作,以及这些操作丧失(或部分丧失)的潜在影响 | 示例3:为在各种运行状态下(例如,在攻击期间、恢复期间、正常操作)提供关键能力和服务建立并传达韧性目标(例如,恢复时间目标)
组织的网络安全风险管理绩效会被评估并审查,以确定所需的调整 标准: 实例1:审查关键绩效指标(KPI),以确保全组织的政策和程序实现目标 | 实例2:审查关键风险指标(KRI),以识别组织面临的风险,包括可能性和潜在影响 | 实例3:收集并传达网络安全指标与高级领导层的风险管理
网络安全风险管理策略的结果会被审查,以便为策略和方向提供信息和调整依据 标准:示例1:衡量风险管理策略和风险结果在多大程度上帮助领导者做出决策并实现组织目标 | 示例2:检验是否应调整阻碍运营或创新的网络安全风险策略
网络安全风险管理策略会进行审查和调整,以确保覆盖组织的要求和风险 标准:例1:审查审计结果,以确认现有的网络安全策略是否已确保符合内部和外部要求 | 例2:审查网络安全相关岗位的绩效监督,以确定是否需要进行政策调整 | 例3:根据网络安全事件审查策略
基于组织的背景、网络安全战略和优先事项,建立管理网络安全风险的政策,并进行传达和执行。 标准:例如1:创建、传播并维护一份可理解、可使用的风险管理政策,其中包含管理意图、期望和指导声明 | 例如2:定期审查政策及其支持的流程和程序,以确保它们与风险管理策略的目标和优先事项以及网络安全政策的高层方向保持一致 | 示例3:需要高级管理层批准政策 | 示例4:在整个组织内传达网络安全风险管理政策及支持的流程和程序 | 示例5:要求人员在首次入职、每年以及政策更新时确认已收到政策
管理网络安全风险的政策会根据要求、威胁、技术和组织使命的变化进行审核、更新、传达和执行。 标准:示例1:根据对网络安全风险管理结果的定期审查更新政策,以确保政策及支持的流程和程序能够将风险保持在可接受的水平 | 示例2:提供审查组织风险环境变化的时间表(例如)。例如,风险变化或组织使命目标的变化),并传达建议的政策更新 | 示例3:更新政策以反映法律和监管要求的变化 | 示例4:更新政策以反映技术变化(例如采用人工智能)和业务变化(例如收购新业务、新合同要求)
网络安全风险管理活动和结果包含在企业风险管理流程中 标准:例如1:将网络安全风险与其他企业风险一起汇总和管理(例如,合规、财务、运营、监管、声誉、安全)| 示例2:在企业风险管理规划中包括网络安全风险管理人员 | 示例3:在企业风险管理中建立升级网络安全风险的标准
在整个组织中建立了关于网络安全风险的沟通渠道,包括来自供应商和其他第三方的风险。 标准: 示例1:确定如何在双方约定的时间间隔内向高级管理人员、董事和管理层更新组织的网络安全状况。 示例2:识别整个组织中所有部门(如管理、运营、内部审计、法律、采购)如何沟通。采购、物理安全和人力资源——将就网络安全风险相互沟通
风险偏好和风险容忍度声明已经建立、传达并维持 标准:例1:确定并传达风险偏好声明,以表达对组织适当风险水平的期望 | 例2:将风险偏好声明转化为具体、可衡量且广泛易懂的风险容忍度声明 | 例3:完善组织目标和风险偏好 p根据已知的风险暴露和剩余风险定期进行
风险管理目标由组织利益相关者确定并达成一致 标准:例1:在年度战略规划中以及发生重大变更时,更新近期和远期的网络安全风险管理目标 | 例2:为网络安全风险管理建立可衡量的目标(例如,管理用户培训的质量,确保对工业控制系统有足够的风险防护)| 例3:高级领导者就网络安全目标达成一致,并以此来衡量和管理风险与绩效
建立并传达描述适当风险应对选项的战略方向 标准:示例1:为各种数据分类明确接受和规避网络安全风险的标准 | 示例2:确定是否购买网络安全保险 | 示例3:记录共享责任模型可接受的条件(例如),外包某些网络安全功能,由第三方代表组织执行金融交易,使用基于公共云的服务)
建立并传达计算、记录、分类和优先排序网络安全风险的标准化方法 标准:例如1:建立用于网络安全风险分析的定量方法的标准,并指定概率和暴露公式 | 例如2:创建并使用模板(例如风险登记表)记录网络安全风险信息(例如,风险描述、暴露、处理和所有权)| 示例3:在企业的适当层级建立风险优先级标准 | 示例4:使用一致的风险类别列表来支持整合、汇总和比较网络安全风险
战略机会(即积极风险)的特征已被确定,并且被纳入组织的网络安全风险讨论中 标准:示例1:定义并传达识别机会的指导和方法,并将其纳入风险讨论中(例如。优势、劣势、机会和威胁 [SWOT] 分析) | 示例2:确定拓展目标并记录 | 示例3:计算、记录并优先考虑正向风险以及负向风险
网络安全已纳入人力资源实践 标准:例如1:将网络安全风险管理考虑因素整合到人力资源流程中(例如,人员筛选、入职、变更通知、离职) | 例2:在招聘、培训和留用决定中将网络安全知识视为一个积极因素 | 例3:在关键岗位新员工入职前进行背景调查,并定期对担任此类岗位的人员重复背景调查 | 例4:定义并强制执行人员的义务,使其了解、遵守并维护与其岗位相关的安全政策
组织领导对网络安全风险负有责任和义务,并促成一种风险意识强、道德规范高、持续改进的文化。 标准:示例1:领导者(例如,董事) 就在制定、实施和评估组织的网络安全战略中的角色和职责达成一致 | 示例2:分享领导者对安全和道德文化的期望,尤其是在当前事件提供机会突出网络安全风险管理中的正面或负面案例时 | 示例3:领导者指示首席信息安全官保持全面的网络安全风险战略,并至少每年及重大事件后审查和更新 | 示例4:进行审查,以确保负责管理网络安全风险的人拥有足够的权限和协调
根据网络安全风险策略、角色、职责和政策,分配相称的充足资源 标准:示例1:定期进行管理评审,以确保被赋予网络安全风险管理职责的人拥有必要的权限 | 示例2:根据风险容忍度和应对措施确定资源分配和投资 | 示例3:提供充足和足够的人力、流程ess,以及支持网络安全战略的技术资源
与网络安全风险管理相关的角色、职责和权限已被建立、传达、理解并执行 标准:示例1:在政策中记录风险管理的角色和职责 | 示例2:记录谁负责和对网络安全风险管理活动负有责任,以及如何与这些团队和个人进行咨询和通知 | 示例3:包括网络安全责任人员描述中的职责和绩效要求 | 示例4:记录具有网络安全风险管理职责的人员的绩效目标,并定期衡量绩效以识别改进领域 | 示例5:清楚表达运营、风险职能和内部审计职能中的网络安全职责
网络安全供应链风险管理计划包括对合作伙伴关系或服务协议结束后发生的活动的条款 标准: 示例1:建立在正常和不利情况下终止关键关系的流程 | 示例2:定义并实施组件生命周期终结的维护支持和淘汰计划 | 示例3:验证供应商对组织的访问权限当资源不再需要时应立即停用 | 示例4:验证包含组织数据的资产是否已及时、受控且安全地归还或妥善处置 | 示例5:制定并执行终止或过渡供应商关系的计划,同时考虑供应链安全风险和韧性 | 示例6:降低供应商带来的数据和系统风险终止 | 示例7:管理与供应商终止相关的数据泄露风险
供应链中应对网络安全风险的要求已建立、优先排序,并整合到与供应商及其他相关第三方的合同和其他类型的协议中 标准: Ex1:根据其关键性等级及若遭破坏可能产生的影响,为供应商、产品和服务建立安全要求 Ex2:在默认合同条款中包括第三方必须遵循的所有网络安全和供应链要求,以及如何验证对这些要求的遵守情况 Ex3:在协议中定义组织与其供应商及子供应商之间信息共享的规则和协议 Ex4:通过根据关键性及若遭破坏可能产生的影响在协议中纳入安全要求来管理风险 Ex5:在服务水平协议(SLA)中定义安全要求,以在整个供应商关系生命周期内监控供应商的可接受安全绩效 Ex6:在合同中要求供应商披露其产品和服务的网络安全特性、功能及漏洞,期限为产品寿命或服务期限 Ex7:在合同中要求供应商提供并维护当前的组件清单(如克关键产品的软件或硬件物料清单 | 示例8:合同要求供应商审查其员工并防范内部威胁 | 示例9:合同要求供应商通过例如自我声明、符合已知标准、认证或检查等方式提供其执行可接受安全实践的证据 | 示例10:在合同和其他协议中明确组织、其供应商及其供应链在潜在网络安全风险方面的权利和责任
供应商已知并按关键性进行优先排序 标准: 示例1:根据供应商处理或拥有的数据的敏感性、对组织系统的访问程度以及产品或服务对组织使命的重要性等,为供应商关键性制定标准 示例2:保留所有供应商的记录,并根据关键性标准对供应商进行优先排序
网络安全供应链风险管理已被整合到网络安全和企业风险管理、风险评估及改进流程中 标准: 示例1:识别与网络安全和企业风险管理的对齐与重叠领域 | 示例2:建立网络安全风险管理和网络安全供应链风险管理的综合控制集 | 示例3:整合网络安全供应链将风险管理纳入改进流程 | 示例4:将供应链中的重大网络安全风险升级至高级管理层,并在企业风险管理层面进行处理
网络安全供应链风险管理计划、战略、目标、政策和流程已由组织相关方建立并达成一致 标准:实例1:制定表达网络安全供应链风险管理计划目标的战略 | 实例2:制定网络安全供应链风险管理计划,包括计划(带里程碑)、政策和程序指导项目的实施和改进,并与组织利益相关者分享政策和程序 | 示例3:根据组织利益相关者达成并执行的战略、目标、政策和程序,开发和实施项目流程 | 示例4:建立一个跨组织机制,确保各职能之间的对齐,从而促成cy网络安全供应链风险管理,例如网络安全、信息技术、运营、法律、人力资源和工程
供应链安全实践已整合到网络安全和企业风险管理计划中,并且其绩效在技术产品和服务的整个生命周期中进行监控。 标准:示例1:政策和程序要求对所有获取的技术产品和服务保留来源记录 | 示例2:定期向领导提供风险报告,说明所获取的组件如何被证明是安全的受控且真实的 | 示例3:在网络安全风险管理人员和运营人员之间定期沟通,仅从经过认证且值得信赖的软件提供商获取软件补丁、更新和升级的必要性 | 示例4:审查政策以确保其要求由批准的供应商人员执行供应商产品的维护 | 示例5:政策和程序要求检查关键系统的升级用于未经授权更改的物理硬件
在建立正式的供应商或其他第三方关系之前,进行规划和尽职调查以降低风险 标准:例1:对潜在供应商进行彻底的尽职调查,这应与采购规划一致,并与每个供应商关系的风险、关键性和复杂性相称 | 例2:评估技术和网络安全能力的适用性潜在供应商的合规性和风险管理实践 | 示例3:根据业务和适用的网络安全要求进行供应商风险评估 | 示例4:在采购和使用前评估关键产品的真实性、完整性和安全性
相关供应商和其他第三方被纳入事件规划、响应和恢复活动 标准:例1:定义并使用报告事件响应和恢复活动及组织与供应商之间状态的规则和协议 | 例2:识别并记录组织及其供应商在事件响应中的角色和责任 | 例3:包括关键在事件响应演练和模拟中与供应商合作 | 示例4:定义并协调组织与其关键供应商之间的危机沟通方法和协议 | 示例5:与关键供应商共同进行经验教训回顾会
供应商、其产品和服务以及其他第三方所带来的风险在合作关系过程中被理解、记录、优先排序、评估、应对和监控 标准:例如1:根据第三方的声誉以及其提供的产品或服务的重要性调整评估格式和频率 | 例如2:评估第三方遵守合同的证据实际的网络安全要求,例如自我声明、保证、认证及其他材料 | 示例3:监控关键供应商,以确保他们在整个供应商关系生命周期中履行其安全义务,使用各种方法和技术,例如检查、审计、测试或其他形式的评估 | 示例4:监控关键供应商、服务和产品的对其风险状况进行变化评估,并相应地重新评估供应商的重要性和风险影响 | 例5:计划应对意外的供应商及供应链相关的中断,以确保业务连续性
供应商、客户和合作伙伴的网络安全角色和职责已被建立、传达,并在内部和外部进行协调 标准:实例1:确定一个或多个特定角色或职位,这些角色或职位将负责和承担规划、资源配置以及执行网络安全供应链风险管理活动的责任 | 实例2:记录网络安全供应链风险管理的角色和职责d 在政策中的职责 | 例3:创建责任矩阵以记录谁将负责和对网络安全供应链风险管理活动负责,以及如何对这些团队和个人进行咨询和通知 | 例4:在人员描述中包含网络安全供应链风险管理职责和绩效要求,以确保明确性并提高问责制 |示例5:记录具有网络安全风险管理特定职责的人员的绩效目标,并定期衡量这些目标以展示和改进绩效 | 示例6:为供应商、客户和业务合作伙伴制定角色和职责,以应对适用网络安全风险的共同责任,并将其整合到组织政策和适用的第三方协议中ents | 示例7:在内部传达第三方网络安全供应链风险管理的角色和职责 | 示例8:建立组织与其供应商之间信息共享和报告流程的规则和协议
系统、硬件、软件、服务和数据在其整个生命周期中进行管理 标准:例1:在系统、硬件、软件和服务的整个生命周期中整合网络安全考虑因素 | 例2:将网络安全考虑因素整合到产品生命周期中 | 例3:识别为实现任务目标而进行的非正式技术使用(即,“影子 IT”) | 例4:定期识别不必要地增加组织攻击面的冗余系统、硬件、软件和服务 | 例5:在投入生产前正确配置和保护系统、硬件、软件和服务 | 例6:当系统、硬件、软件和服务在组织内部移动或转移时,更新清单 | 例7:根据组织的数据保留政策,使用规定的销毁方法安全销毁存储的数据,并保存和管理销毁记录 | 例8:在硬件报废、退役、重新分配或送修/更换时安全清理数据存储 | 例9:提供销毁纸张、存储介质和其他物理数据存储形式的方法
资产的优先级根据分类、重要性、资源和对任务的影响来确定 标准:例如1:定义每类资产的优先级标准 | 例如2:将优先级标准应用于资产 | 例如3:跟踪资产优先级,并在组织发生重大变化时定期更新
为指定数据类型维护数据及相应元数据的清单 标准:例如 1:维护感兴趣的指定数据类型的列表(例如个人身份信息、受保护的健康信息、财务账户号码、组织知识产权、运营技术数据)| 示例2:持续发现和分析临时数据,以识别指定数据类型的新实例 | 示例3:通过标签或标记为指定数据类型分配数据分类 | 示例4:跟踪每个指定数据类型实例的来源、数据所有者和地理位置
组织管理的硬件库存得到维护 标准:示例1:维护所有类型硬件的库存,包括IT、物联网(IoT)、操作技术(OT)和移动设备 | 示例2:不断监控网络以检测新硬件并自动更新库存
维护组织授权的网络通信以及内部和外部网络数据流的表示 标准: 例1:维护组织有线和无线网络内通信和数据流的基线 例2:维护组织与第三方之间通信和数据流的基线 例3:维护组织的通信和数据流基线组织的基础设施即服务 (IaaS) 使用 | 示例4:维护文档,记录授权系统之间通常使用的网络端口、协议和服务
组织管理的软件、服务和系统的清单得到维护 标准:例如1:维护所有类型的软件和服务清单,包括商业现成软件、开源软件、自定义应用、API服务以及基于云的应用和服务 | 例如2:持续监控所有平台,包括容器和虚拟机的软件和服务清单变化| 示例3:维护组织系统的清单
供应商提供的服务库存得到维护 标准:示例1:列出组织使用的所有外部服务,包括第三方基础设施即服务(IaaS)、平台即服务(PaaS)和软件即服务(SaaS)产品;API;以及其他外部托管的应用服务 | 示例2:在将要使用新的外部服务时更新库存,以确保对组织使用该服务的网络安全风险管理监控充分
通过评估识别改进点 标准: 示例1:对关键服务进行自我评估,考虑当前的威胁和战术、技术及程序(TTPs) 示例2:投资于第三方评估或独立审计,以评估组织网络安全计划的有效性,从而识别需要改进的领域 示例3:通过自动化不断评估对选定网络安全要求的合规性交配的意思
改进是通过执行运营流程、程序和活动识别的 标准:示例1:与供应商开展协作的经验教训总结会议 | 示例2:每年审核网络安全政策、流程和程序,以吸取经验教训 | 示例3:使用指标评估运营网络安全绩效随时间的变化
针对事件响应的计划和其他影响运营的网络安全计划已被制定、传达、维护并改进 标准:示例1:制定应急计划(例如, 事件响应、业务连续性、灾难恢复) 用于应对和恢复可能干扰运营、暴露机密信息或以其他方式危及组织使命和生存能力的不利事件 | 示例2:在所有应急计划中包含联系和沟通信息、处理常见情况的流程,以及优先级、升级和提升的标准 | 示例3:制定漏洞管理计划,以识别和评估所有类型的漏洞,并对风险应对进行优先排序、测试和实施 | 示例4:向负责执行的人员和受影响的各方传达网络安全计划(包括更新) | 示例5:每年审查和更新所有网络安全计划,或在发现需要重大改进时进行更新
从安全测试和演练中(包括与供应商及相关第三方协调进行的测试和演练)识别改进措施 标准:例如:根据事件响应评估的结果识别未来事件响应活动的改进措施(例如、桌面演练和模拟、测试、内部审查、独立审计)| 示例2:根据与关键服务提供商和产品供应商协调进行的演练,识别未来业务连续性、灾难恢复和事件响应活动的改进措施 | 示例3:涉及内部利益相关者(例如高级管理人员、法务部门、人力资源部门) 在安全测试和演练中适当参与 | 示例4:执行渗透测试,以识别机会,改善经领导批准的高风险系统的安全状态 | 示例5:演练应急计划,以应对和恢复发现产品或服务不是由签约供应商或合作伙伴提供,或在收到前已被更改的情况 | 示例6:使用安全工具和服务收集和分析性能指标,以为网络安全计划的改进提供依据
资产中的漏洞被识别、验证并记录 标准:示例1:使用漏洞管理技术识别未打补丁和配置错误的软件 | 示例2:评估网络和系统架构在设计和实施中影响网络安全的弱点 | 示例3:审查、分析或测试组织开发的软件以识别设计、编码和默认配置的漏洞| Ex4:评估存放关键计算资产的设施的物理漏洞和韧性问题 | Ex5:监控网络威胁情报来源,以获取有关产品和服务中新漏洞的信息 | Ex6:审查流程和程序中可能被利用以影响网络安全的弱点
变更和例外情况得到管理、风险影响评估、记录和跟踪 标准: 示例1:实施并遵循正式文档化、审查、测试和批准提出的变更和请求的例外情况的程序 示例2:记录每项拟议变更的可能风险或不进行变更的风险,并提供变更回滚的指导 示例3:记录与每个请求的例外相关的风险tion以及应对这些风险的计划 | 示例4:定期审查基于计划的未来行动或里程碑而被接受的风险
在收购前对关键供应商进行评估 标准:例如1:根据业务和适用的网络安全要求,包括供应链,进行供应商风险评估
确定并记录潜在的威胁利用漏洞的影响和可能性 标准:例1:业务领导者和网络安全风险管理从业人员共同评估风险情景的可能性和影响,并将其记录在风险登记册中 | 例2:列出未经授权访问组织的通信、系统和数据处理可能带来的潜在业务影响在这些系统中或由这些系统产生 | 示例3:说明系统群级联故障的潜在影响
网络威胁情报来自信息共享论坛和来源 标准:例如1:配置具有检测或响应能力的网络安全工具和技术,以安全地获取网络威胁情报信息流 | 例如2:接收并审查来自知名第三方的关于当前威胁行为者及其策略、技术和程序(TTPs)的公告 | 例如3:监控网络威胁来源获取有关新兴技术可能存在的漏洞类型的信息的情报
在获取和使用之前评估硬件和软件的真实性和完整性 标准:例如1:在获取和使用之前评估关键技术产品和服务的真实性和网络安全性
威胁、漏洞、可能性和影响用于理解固有风险并为风险应对优先级提供信息 标准:例如1:开发威胁模型以更好地理解对数据的风险并确定适当的风险应对措施 | 例如2:根据估计的可能性和影响对网络安全资源分配和投资进行优先排序
风险应对措施会被选择、优先排序、计划、跟踪和沟通 标准: 例1:应用漏洞管理计划的标准来决定是否接受、转移、缓解或规避风险 例2:应用漏洞管理计划的标准来选择补偿控制以缓解风险 例3:跟踪风险应对实施的进展(例如行动计划和里程碑 [POA&M],风险登记表,风险详细报告)| 例4:使用风险评估结果来指导风险应对决策和行动 | 例5:按优先顺序将计划的风险应对措施传达给受影响的利益相关者
识别并记录对组织的内部和外部威胁 标准: Ex1:利用网络威胁情报保持对可能针对组织的威胁行为者类型及其可能使用的战术、技术和程序(TTPs)的了解 | Ex2:执行威胁狩猎以寻找环境中威胁行为者的迹象 | Ex3:实施识别内部威胁行为者的流程
已经建立接收、分析和响应漏洞披露的流程 标准:示例1:根据合同中定义的规则和协议,在组织与其供应商之间进行漏洞信息共享 | 示例2:分配责任并验证处理、分析影响及响应网络安全威胁、漏洞或事件的程序的执行情况供应商、客户、合作伙伴和政府网络安全组织的事件披露
为特定岗位的个人提供意识和培训,使他们具备在考虑网络安全风险的情况下执行相关任务的知识和技能 标准:实例1:识别组织内需要额外网络安全培训的专门岗位,例如物理和网络安全人员、财务人员、高级领导以及任何拥有业务关键数据访问权限的人tical data | 示例2:向所有具有专业角色的人提供基于角色的网络安全意识和培训,包括承包商、合作伙伴、供应商以及其他第三方 | 示例3:定期评估或测试用户对其专业角色的网络安全实践的理解情况 | 示例4:要求每年进行复习,以巩固现有的实践并引入新的实践
为员工提供意识和培训,使他们拥有知识和技能,在考虑网络安全风险的情况下执行一般任务 标准:例如1:向员工、承包商、合作伙伴、供应商以及组织非公开资源的所有其他用户提供基本网络安全意识和培训 | 例如2:培训人员识别社会工程攻击和其他常见攻击,报告攻击和可疑活动,遵守可接受使用政策,并执行基本的网络卫生任务(例如例如,修补软件、选择密码、保护凭证)| 示例3:解释违反网络安全政策对个人用户和整个组织的后果 | 示例4:定期评估或测试用户对基本网络安全实践的理解 | 示例5:要求年度复习,以巩固现有的实践并引入新的实践
数据备份会被创建、保护、维护和测试 标准: 例1:近实时连续备份关键数据,并按照约定的时间表频繁备份其他数据 | 例2:每年至少测试一次所有类型数据源的备份和恢复 | 例3:将部分备份安全地存储在离线和异地,以防事件或灾难破坏它们 | 例4:执行地理分隔数据备份存储的地理位置限制
静态数据的机密性、完整性和可用性受到保护 标准: 示例1:使用加密、数字签名和密码哈希来保护文件、数据库、虚拟机磁盘镜像、容器镜像及其他资源中存储数据的机密性和完整性 | 示例2:使用全盘加密保护存储在用户终端上的数据 | 示例3:通过...确认软件的完整性验证签名 | 示例4:限制可移动媒体的使用以防止数据外泄 | 示例5:物理上保护包含未加密敏感信息的可移动媒体,例如放在锁着的办公室或文件柜中
在传输中的数据的机密性、完整性和可用性受到保护 标准:示例1:使用加密、数字签名和加密散列来保护网络通信的机密性和完整性 | 示例2:根据数据分类自动加密或阻止包含敏感数据的外发电子邮件及其他通信 | 示例3:阻止从组织系统和网络访问个人电子邮件、文件共享、文件存储服务以及其他个人通信应用和服务 | 示例4:防止在生产环境中重复使用敏感数据(例如例如,开发、测试和其他非生产环境中的客户记录
正在使用的数据的机密性、完整性和可用性受到保护 标准:例如1:在数据不再需要时,立即删除必须保密的数据(例如,来自处理器和内存的数据)| 例如2:保护正在使用的数据,防止被同一平台的其他用户和进程访问
访问权限、权利和授权在政策中定义、管理、执行和审查,并且包含最小特权和职责分离的原则。 标准:示例1:定期审查逻辑和物理访问权限,以及在人员变更角色或离开组织时,及时撤销不再需要的权限 | 示例2:在授权决策中考虑请求者和请求资源的属性(例如例如,地理位置、日期/时间、请求者端点的网络健康状况)| 示例3:将访问权限和特权限制到必要的最小范围(例如,零信任架构)| 示例4:定期审查与关键业务功能相关的特权,以确认适当的职责分离
用户、服务和硬件已通过身份验证 标准:示例1:要求多因素身份验证 | 示例2:强制执行密码、PIN码和类似身份验证器的最小强度策略 | 示例3:根据风险定期重新验证用户、服务和硬件(例如),在零信任架构中)| 示例4:确保授权人员能够在紧急情况下访问对保障安全至关重要的账户
组织负责管理授权用户、服务和硬件的身份和凭证 标准:例如1:为员工、承包商及其他人员发起新的访问请求或额外访问请求,并跟踪、审核和履行这些请求,在需要时获得系统或数据所有者的许可 | 例如2:签发、管理和撤销加密证书和身份令牌、加密密钥(即,密钥管理),以及其他凭证 | 示例3:从不可变的硬件特性或安全预置到设备的标识符中,为每个设备选择一个唯一标识符 | 示例4:对授权硬件进行物理标记,以用于库存和维护目的
身份声明受到保护、传递和验证 标准: 例1:保护用于通过单点登录系统传递身份验证和用户信息的身份声明 例2:保护用于在联合系统之间传递身份验证和用户信息的身份声明 例3:在所有环境中实施基于标准的身份声明方法,并遵循生成身份声明的所有指导(例如例如,数据模型、元数据)、保护(例如,数字签名、加密)以及身份断言的验证(例如,签名验证)
身份会根据交互的上下文使用凭证进行验证和绑定 标准:示例1:在注册时使用政府签发的身份证明(例如护照、签证、驾驶执照)验证一个人所声称的身份 | 示例2:为每个人颁发不同的凭证(即不得共享凭证)
对资产的物理访问根据风险进行管理、监控和执行 标准: 示例1:使用保安、监控摄像头、锁门入口、报警系统和其他物理控制措施来监控设施和限制访问 示例2:对包含高风险资产的区域采用额外的物理安全控制 示例3:在包含业务区域的区域内为来宾、供应商及其他第三方提供陪同关键业务资产
配置管理实践已建立并应用 标准:例如:建立、测试、部署和维护强化基线,以执行组织的网络安全策略并仅提供必要的功能(即,最小功能原则) | 示例2:在安装或升级软件时,审核所有可能影响网络安全的默认配置设置 | 示例3:监控已实施的软件是否偏离已批准的基线
硬件的维护、更换和移除应与风险相称 标准:例1:当硬件缺乏所需的安全功能或无法支持具有所需安全功能的软件时,更换硬件 | 例2:制定并实施硬件生命周期结束的维护支持和废弃计划 | 例3:以安全、负责任且可审计的方式进行硬件处置
日志记录会被生成并提供用于持续监控 标准: 示例1:配置所有操作系统、应用程序和服务(包括基于云的服务)以生成日志记录 | 示例2:配置日志生成器以安全地将其日志共享给组织的日志基础设施系统和服务 | 示例3:配置日志生成器以记录零信任架构所需的数据
安全的软件开发实践已经被整合,并且在整个软件开发生命周期中对其性能进行监控 标准: 示例1:保护组织开发的软件的所有组件免受篡改和未经授权的访问 | 示例2:确保组织产生的所有软件安全,其发布版本中的漏洞最少 | 示例3:维护在生产环境中使用的软件,并且在不再需要软件时安全地处理它
根据风险对软件进行维护、替换和移除 标准: 例1:在漏洞管理计划规定的时间范围内执行常规和紧急补丁更新 例2:更新容器镜像,并部署新的容器实例以替换现有实例,而不是更新现有实例 例3:将已达到生命周期结束的软件和服务版本替换为受支持和维护的版本 例4:卸载并移除带来不当风险的未经授权的软件和服务 例5:卸载并移除任何不必要的软件组件例如,操作系统实用程序)攻击者可能滥用 | 示例6:定义并实施软件和服务生命周期结束的维护支持和淘汰计划
防止安装和运行未授权的软件 标准:示例1:当风险需要时,仅限执行允许的软件或禁止执行被禁止和未授权的软件 | 示例2:在安装新软件之前验证软件来源及其完整性 | 示例3:配置平台仅使用批准的DNS服务,以阻止访问已知恶意域名 |Ex4:配置平台以仅允许安装组织批准的软件
充足的资源容量以确保可用性得到维护 标准:示例1:监控存储、电力、计算、网络带宽及其他资源的使用情况 | 示例2:预测未来需求,并相应地调整资源规模
组织的技术资产受到环境威胁的保护 标准:示例1:保护组织设备免受已知的环境威胁,如洪水、火灾、风以及过高的温度和湿度 | 示例2:在为组织运作系统的服务提供商的要求中,包括对环境威胁的保护以及提供足够运行基础设施的条款
网络和环境受到防止未经授权的逻辑访问和使用的保护 标准:例如1:根据信任边界和平台类型对组织网络和基于云的平台进行逻辑分段(例如),IT、物联网、运营技术、移动设备、访客),并只允许各分段间所需的通信 | 示例2:将组织网络与外部网络逻辑分段,并仅允许必要的通信进入组织网络 | 示例3:实施零信任架构,将网络访问限制到每个资源的最低必要权限 | 示例4:在允许终端访问和使用生产资源之前检查其网络健康状态
在正常和不利情况下,实施机制以实现韧性要求 标准: 示例1:避免系统和基础设施中的单点故障 | 示例2:使用负载均衡以增加容量并提高可靠性 | 示例3:使用高可用性组件,如冗余存储和电源,以提高系统可靠性
使用批准的方法和信息共享关于事件恢复的公共更新 标准:例1:遵循组织的违规通知程序,以从数据泄露事件中恢复 | 例2:说明为从事件中恢复并防止再次发生所采取的步骤
恢复活动和恢复操作能力的进展情况会传达给指定的内部和外部利益相关者 标准:示例1:按照响应计划和信息共享协议安全地共享恢复信息,包括恢复进展 | 示例2:定期向高级管理层更新重大事件的恢复状态和恢复进展 | 示例3:遵循规定在合同中定义的与供应商共享事件信息的协议 | 示例4:协调组织与其关键供应商之间的危机沟通
已验证恢复资产的完整性,系统和服务已恢复,并确认正常运行状态 标准:示例1:准备一份事后报告,记录事件本身、采取的响应和恢复行动以及经验教训 | 示例2:一旦满足标准,宣布事件恢复结束
在使用备份和其他恢复资源进行恢复之前,需要验证其完整性 标准:例如1:在使用之前检查恢复资源是否存在受损、文件损坏和其他完整性问题的迹象
根据标准宣布事件恢复的结束,并完成与事件相关的文档 标准:例如1:在发现数据泄露事件后,遵循组织的泄露通知程序,包括通知受影响的客户 | 例如2:根据合同要求通知商业伙伴和客户事件 | 例如3:通知执法机关和监管机构根据事件响应计划的标准和管理层批准对事件进行审查
关键任务功能和网络安全风险管理被考虑用于建立事件后操作规范 标准:例如1:在投入生产使用前,检查已恢复资产是否存在妥协指标及事件根本原因的修复情况 | 例如2:在将恢复的系统上线之前,验证所采取恢复措施的正确性和充分性
恢复行动被选择、界定范围、优先排序并执行 标准:示例1:根据事件响应计划中定义的标准和可用资源选择恢复行动 | 示例2:根据对组织需求和资源的重新评估更改计划的恢复行动
事件响应计划的恢复部分在从事件响应流程启动后执行 标准:例如1:在事件响应流程期间或之后开始恢复程序 | 例如2:使所有具有恢复责任的人员了解恢复计划以及实施计划各个方面所需的授权
进行分析以确定事件发生期间发生了什么以及事件的根本原因 标准:例1:确定事件发生期间的事件顺序,以及每个事件中涉及的资产和资源 | 例2:尝试确定在事件中直接或间接涉及的漏洞、威胁和威胁行为者 | 例3:分析事件以找到事件的原因潜在的系统性根本原因 | 示例4:检查任何网络欺骗技术以获取关于攻击者行为的额外信息
收集事件数据和元数据,并保持其完整性和来源 标准:例如1:根据证据保全和管理链程序,收集、保存并保护所有相关事件数据和元数据的完整性(例如,数据来源、收集日期/时间)
事件的严重程度被估计和验证 标准:例1:审查事件的其他潜在目标,以寻找妥协指标和持续存在的证据 | 例2:在目标上自动运行工具,以寻找妥协指标和持续存在的证据
在调查过程中执行的操作会被记录,并且记录的完整性和来源会得到保存 标准:示例1:要求每个事件响应者及其他人(例如系统管理员、网络安全工程师等执行事件响应任务的人员,记录其操作并使记录不可篡改 | 示例2:要求事件负责人详细记录事件,并负责维护文档的完整性以及所报告的所有信息来源
事件被分类和优先排序 标准:例如1:根据事件类型进一步审查和分类事件(例如,数据泄露,勒索软件,DDoS,账户被攻破)| 示例2:根据事件的范围、可能影响和时间紧迫性对事件进行优先排序 | 示例3:通过在迅速从事件中恢复与观察攻击者或进行更彻底调查之间进行平衡,为现有事件选择事件响应策略
事件根据需要进行升级或上报 标准:例如1:跟踪并验证所有正在进行的事件的状态 | 例如2:与指定的内部和外部利益相关者协调事件升级或上报
事件报告经过分级和验证 标准:例1:初步审查事件报告,以确认其与网络安全相关并需要采取事件响应措施 | 例2:应用标准来评估事件的严重性
启动事件恢复的标准已应用 标准:示例1:将事件恢复标准应用于事件的已知和假定特征,以确定是否应启动事件恢复流程 | 示例2:考虑事件恢复活动可能带来的运营中断
一旦宣布事件发生,事件响应计划将与相关第三方协调执行 标准:例1:检测技术自动报告已确认的事件 | 例2:向组织的事件响应外包方请求事件响应援助 | 例3:为每个事件指定事件负责人 | 例4:根据需要启动额外的网络安全计划以提供支持事件响应(例如,业务连续性和灾难恢复)
事件已被控制 标准: 例1:网络安全技术(例如,杀毒软件)以及其他技术的网络安全功能(例如,操作系统、网络基础设施设备)自动执行控制措施 例2:允许事件响应人员手动选择并执行控制措施 例3:允许第三方(例如,互联网服务提供商,托管安全服务提供商)代表组织执行遏制操作 | 示例4:自动将受损终端转移到修复虚拟本地局域网(VLAN)
事件被消除 标准: 示例1:网络安全技术和其他技术(例如操作系统、网络基础设施设备)的网络安全功能自动执行消除操作 示例2:允许事件响应人员手动选择并执行消除操作 示例3:允许第三方(例如,托管安全服务提供商)代表组织执行根除操作
信息与指定的内部和外部利益相关者共享 标准:示例1:根据响应计划和信息共享协议安全共享信息 | 示例2:自愿与信息共享与分析中心(ISAC)共享攻击者观察到的TTPs信息,但移除所有敏感数据 | 示例3:当发生恶意内部人员活动时通知人力资源部门 | 示例4:定期更新向高级领导汇报重大事件的状态 | 示例5:遵循合同中定义的组织与供应商之间的事件信息共享规则和协议 | 示例6:协调组织与其关键供应商之间的危机沟通方式
内部和外部利益相关者会收到事件通知 标准:示例1:在发现数据泄露事件后,按照组织的数据泄露通知程序进行,包括通知受影响的客户 | 示例2:根据合同要求通知业务合作伙伴和客户有关事件 | 示例3:根据内部准则通知执法机关和监管机构有关事件身份响应计划和管理批准