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