安全控制框架 2024

存在限制更改软件库中驻留软件的权限的机制。

存在提供内部支持或与外部提供商签订合同以支持不受支持的系统组件的机制。

现有机制可培训人员检测假冒系统组件，包括硬件、软件和固件。

存在对定制应用程序和服务执行应用程序级渗透测试的机制。

存在对软件版本及其所有组件（例如代码、包文件、第三方库、文档）进行存档的机制，以维护完整性验证信息。

存在仅利用商业现成 (COTS) 安全产品的机制。

[已弃用 - 纳入 AST-09] 存在使用组织定义的技术和方法处置系统组件的机制，以防止此类组件进入灰色市场。

现有机制要求系统、系统组件或服务的开发人员制定持续监控网络安全和数据隐私控制有效性的计划。

现有机制要求系统、系统组件或服务的开发人员在安全开发生命周期 (SDLC) 中组织定义的决策点执行关键性分析。

当商业现成 (COTS) 解决方案不可用时，存在定制开发关键系统组件的机制。

存在将适当的网络安全和数据隐私代表纳入产品特性和/或功能变更控制审核流程的机制。

现有机制要求系统开发人员/集成商咨询网络安全和数据隐私人员，以： (1) 创建并实施安全测试和评估 (ST&E) 计划或类似能力； (2) 实施可验证的缺陷修复流程，以纠正安全测试和评估过程中发现的弱点和缺陷； (3) 记录安全测试/评估和缺陷修复过程的结果。

现有机制要求系统、系统组件或服务的开发人员制定设计规范和安全架构，该设计规范和安全架构： (1) 与组织的安全架构一致并支持该安全架构，该安全架构是在组织的企业架构内建立的，并且是组织企业架构的集成部分； (2) 准确、完整地描述所需的安全功能以及安全控制在物理和逻辑组件之间的分配； (3) 表达各个安全功能、机制和服务如何协同工作以提供所需的安全功能和统一的保护方法。

存在要求系统开发人员和集成商在系统设计、开发、实施和操作期间执行配置管理的机制。

现有机制要求系统、系统组件或服务的开发人员提供有关系统、系统组件或服务的正确使用和操作的培训。

现有机制可确保系统、应用程序和/或服务的开发人员拥有必要的技能和适当的访问授权。

现有机制要求系统开发人员和集成商开发和实施持续的安全测试和评估 (ST&E) 计划或类似流程，以便在发布到生产之前客观地识别和修复漏洞。

现有机制要求软件开发人员确保其软件开发过程采用行业认可的安全实践来进行安全编程、工程方法、质量控制过程和验证技术，以最大限度地减少有缺陷和/或畸形的软件。

存在将网络安全和数据隐私集成到开发、安全和运营 (DevSecOps) 中的机制，以便在整个软件开发生命周期 (SDLC) 中优先考虑安全实践。

存在一些机制，使端点设备能够记录事件并针对尝试访问诊断和测试接口生成警报。

存在获取、保护和分发系统管理员文档的机制，这些文档描述： (1) 系统的安全配置、安装和操作； (2) 安全特性/功能的有效使用和维护； (3) 有关管理（例如特权）功能的配置和使用的已知漏洞。

现有机制要求系统、系统组件或服务的开发人员使用动态代码分析工具来识别和修复常见缺陷并记录分析结果。

存在通过以下方式处理错误情况的机制： (1) 识别潜在的安全相关错误情况； (2) 生成错误消息，提供纠正措施所需的信息，而不会在错误日志和可能被利用的管理消息中泄露敏感或潜在有害信息； (3) 仅向授权人员透露错误消息。

存在的机制要求软件开发人员提供足够详细的信息来描述要在系统、系统组件或服务内使用的安全控制的功能属性，以允许对控制进行分析和测试。

存在要求系统、系统组件或服务的开发者能够对硬件组件进行完整性验证的机制。

现有机制要求流程所有者识别、记录和证明对运行其技术解决方案所需的端口、协议和其他服务的业务需求。

现有机制将商业提供的信息保障 (IA) 和支持 IA 的 IT 产品的使用限制为已根据国家信息保障合作伙伴 (NIAP) 批准的保护配置文件成功进行评估的产品，或者加密模块经过 FIPS 验证或 NSA 批准。

存在检查信息输入有效性的机制。

现有机制可以减轻与使用运行技术解决方案所需的不安全端口、协议和服务相关的风险。

存在利用完整性验证机制进行安全更新的机制。

现有机制利用测试方法来确保系统、服务和产品在其接口上受到无效或意外输入时继续按预期运行。

存在利用至少一 (1) 个恶意软件检测工具来识别产品或安全更新的最终二进制文件中是否存在任何已知恶意软件的机制。

现有机制要求系统、系统组件或服务的开发人员采用手动代码审查流程来识别和修复需要了解应用程序需求和设计的独特缺陷。

现有机制可确保建立基于风险的技术和功能规范来定义最小可行产品（MVP）。

存在保护物理诊断和测试接口以防止误用的机制。

现有机制要求系统、系统组件或服务的开发人员在安全开发生命周期 (SDLC) 的早期确定要使用的功能、端口、协议和服务。

现有机制可确保供应商/制造商： (1) 交付系统、组件或服务时实施预先建立的安全配置； (2) 使用预先建立的安全配置作为任何后续系统、组件或服务重新安装或升级的默认配置。

存在设计和实施产品管理流程来更新产品（包括系统、软件和服务）的机制，以改进功能并纠正安全缺陷。

通过制定和实施产品篡改和假冒 (PTC) 实践（包括检测和防止假冒组件的方法）来保持对组件真实性的认识。

存在基于安全编码原则开发应用程序的机制。

存在维护分段开发网络的机制，以确保安全的开发环境。

现有机制可确保安全迁移实践在迁移到生产环境之前清除测试/开发/登台数据和帐户的系统、应用程序和服务。

默认情况下，存在实施安全配置设置的机制，以降低部署安全设置较弱的软件的可能性，否则会使资产面临更大的受损风险。

存在管理单独的开发、测试和操作环境的机制，以减少未经授权的访问或更改操作环境的风险，并确保不影响生产系统。

存在利用软件保障成熟度模型 (SAMM) 来管理系统、应用程序和服务开发的安全开发生命周期的机制。

存在为系统、应用程序和服务生成或获取软件物料清单 (SBOM) 的机制，其中列出了正在使用的软件包，包括版本和适用的许可证。

存在对软件设计进行独立审查的机制，以确认所有网络安全和数据隐私要求均得到满足，并且任何已识别的风险均得到令人满意的解决。

存在托管源代码和支持文档的机制，以确保在软件提供商停业或无法提供支持的情况下软件的可用性。

存在要求系统、系统组件或服务的开发者能够对软件和固件组件进行完整性验证的机制。

存在发布软件版本完整性验证信息的机制。

现有机制要求系统、系统组件或服务的开发人员使用静态代码分析工具来识别和修复常见缺陷并记录分析结果。

存在从不同供应商获取网络安全和数据隐私技术的机制，以最大限度地降低供应链风险。

自动化机制的存在是为了提高整个资产生命周期中安全实践的准确性、一致性和全面性。

现有机制可促进实施量身定制的开发和收购战略、合同工具和采购方法，以满足独特的业务需求。

存在通过现有网络安全和数据隐私控制确保测试数据完整性的机制。

存在执行威胁建模和其他安全设计技术的机制，以确保识别和解释对软件和解决方案的威胁。

现有机制可通过以下方式防止不受支持的系统： (1) 当开发商、供应商或制造商不再提供对组件的支持时更换系统； (2) 需要对继续使用满足任务/业务需求所需的不受支持的系统组件提供理由和书面批准。

存在批准、记录和控制开发和测试环境中实时数据使用的机制。