NIST Special Publication 800-53 Revision 5.2.0 Rev 5.2.0

可接受的安全原则要求系统提供的隐私和性能水平要与用户的期望相一致。个人隐私的感知可能会影响用户行为、士气和效率。根据组织的隐私政策和系统设计，用户应能够限制自己的行为以保护隐私。当系统无法提供直观的界面或满足隐私和性能期望时，用户可能会选择完全避免使用该系统，或者以效率低下甚至不安全的方式使用它。

可追责性和可追踪性原则指出，可以将与安全相关的操作（即主体与对象的交互）追溯到代表其执行该操作的实体。可追责性和可追踪性原则要求有一个可信的基础设施来记录影响系统安全的操作细节（例如，审计子系统）。为了记录有关操作的详细信息，系统能够唯一识别代表其执行操作的实体，并记录所执行的相关操作序列。问责策略还要求对审计跟踪本身进行保护，以防未经授权的访问和修改。最小特权原则有助于将操作追踪到特定的实体，因为它提高了问责的细化程度。将特定操作与系统实体、最终与用户关联，并确保审计记录免受未经授权的访问和修改，可以提供不可否认性，因为一旦操作被记录，就无法更改审计记录。问责制和可追溯性发挥的另一个重要作用是在与安全策略违反相关的事件的日常和取证分析中。审计日志的分析可能提供额外的信息，有助于确定导致安全策略被违反的路径或组件，以及与安全策略违反相关的个人行为。

安全和隐私功能性需求通常来源于 SA-2 中描述的高级安全和隐私需求。衍生的需求包括安全和隐私能力、功能和机制。与此类能力、功能和机制相关的强度要求包括正确性程度、完整性、抗篡改或绕过能力以及抗直接攻击能力。保证要求包括开发过程、程序和方法，以及来自开发和评估活动的证据，这些证据为确信所需功能已实现并具有所需机制强度提供依据。[SP 800-160-1] 将需求工程过程描述为系统开发生命周期的一部分。控制可以被视为对适当的防护措施和保护能力的描述，这些措施和能力旨在实现组织的特定安全和隐私目标，并反映利益相关方的安全和隐私要求。控制的选择和实施是为了满足系统需求，包括开发者和组织的责任。控制措施可以包括技术、管理和物理方面。在某些情况下，控制措施的选择和实施可能需要组织通过派生要求或已实例化的控制参数值来进行额外的规范。派生的需求和控制参数值可能是提供系统开发生命周期中控制实施适当细节所必需的。安全和隐私文档要求涵盖系统开发生命周期的所有阶段。文档为用户和管理员提供了控制实施和操作的指导。此类文档所需的详细程度取决于系统的安全分类或等级，以及组织在多大程度上依赖这些系统的能力、功能或机制来满足风险应对要求。要求可能包括规定的配置设置，这些设置明确允许的功能、端口、协议和服务。系统、系统组件和系统服务的验收标准的定义方式与任何组织收购或采购的标准相同。

信息安全和隐私的资源分配包括在整个系统开发生命周期中用于系统和服务获取、维护以及供应链相关风险的资金。

当组织使用商业现成的信息技术产品时，可能需要替代的配置管理流程。替代配置管理流程包括由组织人员组成的团队，他们在系统、系统组件和系统服务实施变更之前，审查并批准拟议的变更，并进行安全和隐私影响分析。

归档系统或系统组件要求开发人员保留关键的开发成果，包括硬件规格、源代码、目标代码以及开发过程中相关的文档，这些文档可以为系统和组件的升级或修改提供随时可用的配置基线。

攻击面减少与威胁和漏洞分析以及系统架构与设计密切相关。攻击面减少是一种降低组织风险的手段，它通过减少攻击者利用系统、系统组件和系统服务中的弱点或缺陷（即潜在漏洞）的机会来实现。攻击面减少包括实施分层防御的概念，应用最小权限和最小功能原则，采用安全的软件开发实践，弃用不安全的函数，减少未授权用户可访问的入口点，减少执行的代码量，以及消除易受攻击的应用程序接口（API）。

系统及系统组件的攻击面是那些使系统更容易受到攻击的暴露区域。攻击面包括任何可访问的区域，这些区域中的硬件、软件和固件组件的弱点或缺陷为对手利用漏洞提供了机会。攻击面审查确保开发人员分析系统设计和实施的变更，并减轻因这些变更产生的攻击向量。对已识别缺陷的修正包括弃用不安全的功能。

自动化工具在分析大型复杂系统中可被利用的弱点或不足、按严重性对漏洞进行优先排序以及提供风险缓解建议方面可能更有效。

清晰抽象原则指出，一个系统应具有简单、定义明确的接口和功能，这些接口和功能能够提供对数据及其管理方式的一致且直观的视图。系统接口的清晰性、简洁性、必要性和充分性——结合对其功能行为的准确定义——促使分析、检查和测试变得容易，同时保证系统的正确和安全使用。抽象的清晰性是主观的。体现这一原则的示例包括避免冗余、未使用的接口；信息隐藏；以及避免接口或其参数的语义过载。信息隐藏（即（与表示无关的编程）是一种设计方法，用于确保一个系统组件中的信息内部表示对调用或调用该组件的另一个系统组件不可见，从而发布的抽象不受数据内部管理方式的影响。

简化复杂性原则指出，系统设计应尽可能简单和精简（见 SA-8(7)）。小而简单的设计更易于理解和分析，同时也不易出错（见 AC-25, SA-8(13)）。简化复杂性的原则适用于系统的任何方面，但由于为了获得系统新兴安全属性的证据而进行的各种分析，它在安全性方面尤为重要。为了使这些分析成功，一个小而简单的设计是必要的。简化复杂性原则的应用有助于系统开发人员理解系统安全功能的正确性和完整性，并有助于识别潜在的漏洞。简化复杂性的推论指出，系统的简洁性与其可能包含的漏洞数量直接相关。也就是说，更简单的系统包含的漏洞更少。降低复杂度的一个重要好处是，更容易理解系统设计中是否已经体现了安全策略，并且在工程开发过程中引入的漏洞可能性更小。另一个好处是，与在系统设计本身更复杂的情况下所得到的结论相比，对于正确性、完整性和漏洞存在性的任何此类结论都可以以更高的可靠性得出。

随着组织越来越多地使用外部服务提供商，服务提供商的利益可能与组织的利益出现分歧。在这种情况下，如果实施和管理这些控制的供应商的运作方式与使用组织的利益不一致，单纯拥有所需的技术、管理或操作控制可能仍然不足。组织为解决此类问题所采取的措施包括要求对选定服务提供商的人员进行背景调查；检查所有权记录；仅使用值得信赖的服务提供商，例如与组织有过成功信任关系的提供商；并定期、不定期地对服务提供商设施进行例行访问。

系统、系统组件和系统服务的开发者会考虑其开发过程在实现质量目标以及应对当前威胁环境中的安全和隐私能力方面的有效性和效率。

持续监控计划的目标是确定系统、系统组件或系统服务中计划的、必需的和已部署的控制措施，是否能够随着不可避免的变化而随着时间的推移继续保持有效。开发者的持续监控计划应包含足够详细的信息，以便组织能够将其纳入实施的持续监控程序中。持续监控计划可以包括计划进行的控制评估和监控活动类型、控制监控的频率，以及在控制失效或变得无效时采取的措施。

连续保护原则指出，用于执行安全策略的组件和数据应得到与安全策略和安全架构假设一致的不间断保护。如果保护存在漏洞，则无法保证系统能够为其设计能力提供机密性、完整性、可用性和隐私保护。关于确保交付能力的任何保证都要求数据和信息得到持续保护。也就是说，在系统控制下，数据和信息不会有任何时期处于未受保护的状态（即在数据和信息的创建、存储、处理或传输过程中，以及在系统初始化、执行、故障、中断和关闭期间）。持续保护需要遵循参考监控器概念的原则（即每个请求都由参考监控器验证；参考监控器能够保护自身免受篡改；并且可以通过分析和测试确定机制的正确性和完整性得到充分保证；以及安全故障和恢复的原则（即在发生错误、故障、失败以及成功攻击时保持安全状态；在恢复到正常、降级或替代操作模式时保持安全状态）。持续保护同样适用于设计为在不同配置下运行的系统，包括那些提供完整操作能力的系统以及提供部分操作能力的降级模式配置。持续保护原则要求对系统安全策略的更改能够追溯到推动该配置的操作需求，并且可以验证（即可以验证所提出的更改不会使系统处于不安全状态。由于问题的复杂性或不可判定性，跟踪和验证不足可能导致不一致状态或保护中断。使用预先验证的配置定义来反映新的安全策略，使分析能够确定从旧策略到新策略的过渡本质上是原子的，并且保证旧策略的任何残留影响不会与新策略发生冲突。展示持续保护能力的基础在于将生命周期保护需求明确表达为利益相关者的安全要求。

开发人员进行的关键性分析为组织进行的关键性分析提供了输入。开发人员的输入对于组织的关键性分析至关重要，因为组织可能无法获取作为现成商业产品开发的系统组件的详细设计文档。这种设计文档包括功能规格、高级设计、低级设计、源代码和硬件原理图。关键性分析对于被指定为高价值资产的组织系统非常重要。由于对手的高度关注或对联邦企业潜在的不利影响，高价值资产可能是中等或高影响的系统。在组织进行供应链关键性分析时，开发者的意见尤为重要。

组织确定某些系统组件可能不可信，因为这些组件存在特定的威胁和漏洞，而对于这些威胁和漏洞，没有可行的安全控制措施能够充分降低风险。重新实现或定制开发此类组件可能满足更高安全性要求，并且通过对系统组件（包括硬件、软件和固件）进行变更来实现，从而使敌手的标准攻击更难成功。在无法获得替代来源的情况下，如果组织选择不重新实施或定制开发关键系统组件，可以采用额外的控制措施。控制措施包括加强审计、限制访问源代码和系统工具，以及防止系统和应用文件被删除。

承包商操作的系统中包含由发起合同的组织拥有的数据，并且承包商拥有在合同规定的时间范围内从其系统中删除数据和/或归还数据的政策和程序。

组织可能根据任务和业务需求、弹性和可信性要求以及分析和测试要求，对组织系统、系统组件或系统服务中控制的设计和实施文档要求不同的详细程度。系统可以划分为多个子系统。系统中的每个子系统可以包含一个或多个模块。系统的高级设计以子系统及子系统之间提供安全相关功能的接口来表示。系统的低级设计以模块及模块之间提供安全相关功能的接口来表示。设计和实现文档可以包括制造商、版本、序列号、验证哈希签名、使用的软件库、购买或下载日期，以及供应商或下载来源。源代码和硬件原理图被称为系统的实现表示。

通过向多个开发人员提供相同的需求规格来实现设计多样性，每个开发人员负责开发满足这些需求的系统或系统组件的不同版本。变体可以出现在软件设计、硬件设计，或者硬件和软件设计的结合中。变体设计的差异可能源于开发人员的经验（例如）。，设计模式的先前使用）、设计风格（例如，将所需功能分解为更小的任务时，确定什么构成单独的任务以及任务分解成子任务的程度）、选择要纳入变体的库，以及开发环境（例如，不同的设计工具使某些设计模式更容易可视化）。硬件设计多样性包括对保留哪些信息为模拟形式以及将哪些信息转换为数字形式做出不同的决策，在不同时间传输相同的信息，以及在采样中引入延迟（时间多样性）。设计多样性通常用于支持容错性。

组织将开发人员进行的配置管理活动的质量和完整性视为实施有效安全控制的直接证据。控制措施包括保护用于生成系统硬件、软件和固件中与安全相关部分的材料的母本，防止未经授权的修改或破坏。维护系统、系统组件或系统服务的变更完整性要求在整个系统开发生命周期内进行严格的配置控制，以跟踪授权变更并防止未授权变更。纳入配置管理的配置项包括正式模型；功能设计、高级设计和低级设计规范；以及其他设计数据；实现文档；源代码和硬件原理图；当前运行的目标代码版本；用于比较新版本与先前版本的安全相关硬件描述和源代码的工具；以及测试夹具和文档。根据组织的使命和业务需求以及现有合同关系的性质，开发人员可能会在系统开发生命周期的运行和维护阶段提供配置管理支持。

开发者提供的培训适用于外部和内部（内部）开发者。培训人员对于确保组织系统中实施的控制措施的有效性至关重要。培训类型包括基于网页和计算机的培训、课堂式培训以及实践培训（包括微培训）。组织还可以向开发人员请求培训材料，以便进行内部培训或为组织人员提供自学培训。组织将确定所需的培训类型，并且可能针对不同的安全和隐私功能、控制和机制需要不同类型的培训。

开发者筛选面向外部开发者进行。内部开发者筛选由 PS-3 处理。由于系统、系统组件或系统服务可能被用于对美国国家或经济安全利益至关重要的关键活动，组织有充分的利益确保开发者是值得信赖的。对开发人员所需的信任程度可能需要与系统部署后访问系统、系统组件或系统服务的个人的信任程度保持一致。授权和人员审查标准包括安全许可、背景调查、国籍和公民身份。开发者的可信度还可能包括对公司所有权及其与可能影响所开发系统、组件或服务的质量和可靠性的实体之间关系的审查和分析。满足所需的访问授权和人员筛选标准包括提供所有获准在所选系统、系统组件或系统服务上进行开发活动的人员名单，以便组织能够验证开发人员是否满足授权和筛选要求。

开发者的安全和隐私架构与设计主要面向外部开发者，尽管它们也可以应用于内部（公司内部）开发。相比之下，PL-8 主要面向内部开发者，以确保组织开发的安全和隐私架构与企业架构相集成。当组织外包系统、系统组件或系统服务的开发时，以及当需要证明与组织的企业架构、安全和隐私架构一致时，SA-17 与 PL-8 之间的区别尤其重要。[ISO 15408-2]、[ISO 15408-3] 和 [SP 800-160-1] 提供了关于安全架构和设计的信息，包括正式策略模型、与安全相关的组件、正式和非正式对应、概念上简单的设计，以及最小特权和测试的结构化设计。

开发测试和评估确认所需的控制措施已正确实施，按预期运行，执行所需的安全和隐私策略，并满足既定的安全和隐私要求。系统的安全属性和个人的隐私可能会受到系统组件互连或这些组件更改的影响。包括升级或更换应用程序、操作系统和固件在内的相互连接或更改，可能会对先前实施的控制措施产生不利影响。在开发过程中进行持续评估可以让开发人员进行额外类型的测试和评估，从而减少或消除潜在的缺陷。测试自定义软件应用程序可能需要采用诸如手动代码审查、安全架构审查和渗透测试的方法，以及静态分析、动态分析、二进制分析或上述三种分析方法的混合。开发人员可以在各种工具和源代码审查中，结合使用这些分析方法，以及安全工具和模糊测试。安全性和隐私评估计划包括开发人员计划执行的具体活动，包括软件和固件组件的分析、测试、评估和审查类型；将应用的严格程度；持续测试和评估的频率；以及在这些过程中生成的工件类型。测试和评估的深度是指与评估过程相关的严格性和细节水平。测试和评估的覆盖范围是指评估过程中包含的工件的范围（即数量和类型）。合同规定了安全和隐私评估计划、缺陷修复流程以及这些计划和流程已被认真执行的证据的验收标准。审查和保护评估计划、证据及文档的方法应与系统的安全类别或分级水平相适应。合同可能规定文档的保护要求。

遵循包括先进软件开发方法、系统工程方法、系统安全与隐私工程方法以及质量控制流程在内的系统开发生命周期，有助于减少系统、系统组件和系统服务中潜在错误的数量和严重程度。减少此类错误的数量和严重性可以减少这些系统、组件和服务中的漏洞数量。在系统工程、系统安全与隐私工程、软件开发、组件与系统评估以及质量控制过程中，开发者所选择和实施的方法与技术的透明性，可以增强对所获取的系统、系统组件或系统服务可信度的信心。

开发工具包括编程语言和计算机辅助设计系统。对开发过程的评审包括使用成熟度模型来确定这些过程的潜在有效性。维护工具和过程变更的完整性有助于有效的供应链风险评估和缓解。这种完整性要求在系统开发生命周期中进行配置控制，以跟踪授权更改并防止未经授权的更改。

动态代码分析使用能够监控程序内存损坏、用户权限问题及其他潜在安全问题的工具，对软件程序进行运行时验证。动态代码分析采用运行时工具，以确保安全功能按设计方式执行。一种称为模糊测试的动态分析方法，通过故意向软件程序引入格式错误或随机数据来引发程序故障。模糊测试策略是根据应用程序的预期用途以及应用程序的功能和设计规范而制定的。为了理解动态代码分析的范围以及所提供的保证，组织还可以考虑进行代码覆盖分析（即使用诸如子程序测试百分比或在测试套件执行过程中调用的程序语句百分比等度量指标来检查代码的测试程度）和/或一致性分析（即，检查软件代码中不合适的词，例如非英语单词或贬义词。

经济安全原则指出，安全机制的成本不应高于安全漏洞可能造成的潜在损害。这是风险管理中使用的成本效益分析在安全方面的应用。成本收益分析的成本假设阻止了系统设计者加入超出必要强度的安全机制，其中机制的强度与成本成正比。经济安全原则还要求分析保障的收益与保障成本之间的关系，这里的成本是指为获取相关且可靠的证据所付出的努力，以及为评估证据并得出可信性和风险结论所进行的必要分析。

高效中介访问原则指出，策略执行机制在满足相关方要求且符合表达的约束条件的前提下，应使用最少的共有机制。对系统资源（即CPU、内存、设备、通信端口、服务、基础设施、数据和信息）的访问进行中介，通常是安全系统的主要安全功能。它还使得为利益相关者提供的系统能力实现保护成为可能。如果系统设计不当，资源访问的调解可能会导致性能瓶颈。例如，通过使用硬件机制，可以实现高效的调解访问。一旦获得对低级资源（如内存）的访问权限，硬件保护机制可以确保不会发生越界访问。

组织与外部服务提供商之间的信任关系反映了使用外部服务所带来的风险处于可接受水平的信心程度。信任关系可以帮助组织更有信心地确保服务提供商为所提供的服务提供了足够的保护，同时在进行事件响应或规划升级或淘汰时也非常有用。信任关系可能会很复杂，因为在消费者与提供者的互动中，参与的实体数量可能很大，同时还涉及从属关系和信任等级，以及双方之间的互动类型。在某些情况下，信任的程度取决于组织对外部服务提供商在保护服务、信息或个人隐私所需的控制措施方面能够施加的控制水平，以及所提供的已实施控制有效性的证据。控制的程度由合同或服务水平协议的条款和条件来确定。

外部系统服务由外部供应商提供，组织无法直接控制所需控制措施的实施或控制有效性的评估。组织通过多种方式与外部服务提供商建立关系，包括通过商业合作伙伴关系、合同、机构间协议、业务安排、许可协议、合资企业和供应链交换。使用外部系统服务所产生的风险管理责任仍由授权官员负责。对于组织外部的服务，信任链要求组织建立并保持一定程度的信心，以确保消费者-提供者关系中的每个提供者对所提供的服务提供足够的保护。信任链的范围和性质因组织与外部提供者之间的关系而异。组织记录信任关系的基础，以便可以对这些关系进行监控。外部系统服务文档包括政府、服务提供商、最终用户的安全角色和职责，以及服务级别协议。服务水平协议定义了已实施控制的性能预期，描述了可衡量的结果，并确定了针对已识别的不合规情况的补救措施和响应要求。

对应关系是通过建模获得保证的重要组成部分。它表明实现是模型的准确转换，并且任何额外的代码或实现细节都不会影响所建模的行为或策略。形式化方法可以用来证明高层次的安全属性被形式化系统描述所满足，并且形式化系统描述被某些低层次的描述（包括硬件描述）正确实现。形式化顶层规范和形式化策略模型之间的一致性通常无法完全证明。因此，可能需要结合正式和非正式的方法来证明这种一致性。由于正式方法在证明规范准确反映实现方面的适用性有限，正式的顶层规范与实际实现之间的一致性可能需要使用非正式的演示来实现。与安全相关的组件内部的硬件、软件和固件机制包括映射寄存器和直接内存输入输出。

形式化模型使用形式化语言描述特定的行为或安全与隐私策略，从而使这些行为和策略的正确性能够被形式化地证明。并非系统的所有组件都可以被建模。通常，形式化规范的范围限于所关注的行为或策略，例如非自主访问控制策略。组织根据要描述的行为和政策的性质以及可用的工具来选择正式建模语言和方法。

安全和隐私控制的功能属性描述了在控制接口上可见的功能（即安全或隐私能力、功能或机制），并明确排除了控制操作内部的功能和数据结构。

在系统开发生命周期的早期阶段（例如，在初始需求定义和设计阶段）识别功能、端口、协议和服务，使组织能够影响系统、系统组件或系统服务的设计。在系统开发生命周期的早期参与，有助于组织避免或尽量减少使用那些造成不必要高风险的功能、端口、协议或服务，并理解阻止特定端口、协议或服务，或要求系统服务提供商采取相应措施所涉及的权衡。及早识别功能、端口、协议和服务可以避免在系统、组件或系统服务实施后进行代价高昂的控制改造。SA-9 描述了外部系统服务的要求。组织需要确定哪些功能、端口、协议和服务是从外部来源提供的。

硬件完整性验证允许组织使用开发人员提供的工具、技术、方法和机制来检测硬件组件的未经授权的更改。组织可以通过难以复制的标签、开发人员提供的可验证序列号以及要求使用防拆卸技术来验证硬件组件的完整性。交付的硬件组件还包括这些组件的硬件和固件更新。

分层保护原则指出，一个组件不需要对更可信的组件进行保护。在最受信任组件的退化情况下，它会保护自己不受所有其他组件的影响。例如，如果一个操作系统内核被认为是系统中最值得信赖的组件，那么它会保护自己免受所有它支持的不受信任的应用程序的影响，但相反，这些应用程序不需要保护自己免受内核的影响。用户的可信性是应用分级保护原则时需要考虑的因素。一个可信系统不需要保护自己免受同样可信的用户的影响，这反映了在“高安全”环境中使用不可信系统的情况，在这些环境中，用户的可信度很高，并且会采取其他保护措施来限制和保护“高安全”执行环境。

组件的分层信任原则建立在受信任组件的原则之上，并指出，如果安全依赖关系遵循受信任组件的原则，系统中的安全依赖关系将形成部分顺序。部分顺序为在由异质可信组件组成的安全系统中进行可信性推理或构建保证案例（保证论证）提供了基础。要分析由异质可信组件组成的系统的可信性，必须消除与可信性相关的循环依赖。如果系统较低层中更可信的组件依赖于较高层中不太可信的组件，实际上根据可信组件原则，这将使这些组件属于同一“较不可信”的等价类。信任关系或信任链可以有各种表现形式。例如，证书层次结构的根证书是该层次结构中最受信任的节点，而层次结构中的叶节点可能是最不可信的节点。另一个例子是在分层高保证系统中，系统最底层的安全内核（包括硬件基础）是最值得信赖的组件。然而，层级信任的原则并不禁止使用过于可靠的组件。在低可靠性系统中，可能出现使用高可靠性组件而不是较低可靠性组件是合理的情况（例如，出于可用性或其他成本收益因素）。在这种情况下，高度可信组件对低可信组件的任何依赖都不会降低由此产生的低信任系统的可信度。

以人为本的安全原则指出，安全功能及其支持服务的用户界面应直观、用户友好，并对影响该政策及其执行的用户操作提供反馈。执行安全政策的机制不会对用户造成干扰，并且设计时考虑到不会降低用户效率。安全策略执行机制还会在用户做出不安全选择时，提供有意义、清晰且相关的反馈和警告。特别关注的是系统管理和操作人员通过其配置和设置安全策略的界面。理想情况下，这些人员能够理解其选择的影响。具有系统管理和操作职责的人员能够在系统启动前进行配置，并在运行时自信地管理系统，确保其意图正确映射到系统机制上。安全服务、功能和机制不会妨碍或不必要地复杂化系统的预期使用。系统可用性与执行安全策略所需的严格性之间存在权衡。如果安全机制令人沮丧或难以使用，用户可能会禁用它们、回避它们，或以与这些机制设计目的是满足的安全要求和保护需求不一致的方式使用它们。

来自外部服务提供商的信息，关于在提供此类服务过程中使用的具体功能、端口、协议和服务，在需要了解限制某些功能和服务或阻止某些端口和协议所涉及的权衡时，可能会非常有用。

开发人员提供的事件响应计划可能包含组织难以直接获取的信息，并可被纳入组织的事件响应计划中。开发人员的信息也可能非常有用，例如当组织应对商业现成产品中的漏洞时。

独立代理具备验证开发者安全和隐私评估计划正确实施所需的资质，包括专业知识、技能、培训、认证和经验。

对应关系是通过建模获得保证的重要组成部分。它表明实现是模型的准确转换，并且额外的代码或实现细节不会影响被建模的行为或策略。描述性顶层规范（即……）之间的一致性高级/低级设计) 和正式策略模型通常无法被完全证明。因此，可能需要结合正式和非正式方法来展示这种一致性。严格属于安全相关硬件、软件和固件的硬件、软件和固件机制包括映射寄存器及直接内存输入输出。

交互式（也称为基于工具的）应用程序安全测试是一种通过在测试过程中观察应用程序运行情况来检测漏洞的方法。使用工具依赖于对实际运行应用程序的直接测量，并利用对代码、用户交互、库、框架、后端连接和配置的访问来直接衡量控制的有效性。结合分析技术，交互式应用安全测试可以识别广泛的潜在漏洞并确认控制的有效性。基于检测的测试可以实时工作，并且可以在整个系统开发生命周期中持续使用。

逆向修改阈值原则建立在可信组件原则和分层信任原则的基础上，指出对组件提供的保护程度应与其可信度相称。随着对组件的信任度增加，对该组件的未经授权修改的保护也会相应增加。防止未经授权的修改可以通过组件自身的自我保护和固有的可信性来实现，也可以通过安全架构的其他元素或属性为组件提供的保护来实现（包括操作环境中的保护）。

最小公共机制原则指出，多个用户共有并且所有用户依赖的机制应被最小化 [POPEK74]。机制最小化意味着系统的不同组件应避免使用相同的机制来访问系统资源。每一个共享机制（尤其是涉及共享变量的机制）都代表了用户之间的潜在信息通道，因此在设计时必须非常谨慎，以确保不会无意中破坏安全性 [SALTZER75]。实施最小共享机制原则有助于减少不同程序之间共享系统状态的负面影响。一个会破坏共享状态（包括共享变量）的单一程序，有可能破坏依赖该状态的其他程序。最小公共机制原则也支持设计的简化原则，并解决了隐蔽存储通道的问题 [LAMPSON73]。

最小特权原则指出，每个系统组件只被分配完成其指定功能所需的权限，而不应超过这一范围。应用最小权限原则可以限制组件的操作范围，这有两个理想的效果：组件的故障、损坏或误用对安全的影响将被最小化，同时组件的安全分析将变得更简单。最小权限是一个普遍的原则，体现在安全系统设计的各个方面。用于调用组件功能的接口仅对特定子集的用户可用，且组件设计支持足够细粒度的权限分解。例如，在审计机制的情况下，可能会有一个接口供审计管理员使用，用于配置审计设置；一个为审计操作员设计的界面，确保审计数据被安全收集和存储；最后，是为审计审查员设计的另一个界面，他们只需要查看已收集的审计数据，而无需对这些数据进行操作。除了在系统接口上的表现外，最小权限还可以作为指导系统内部结构的原则。内部最小权限的一个方面是构建模块，使得模块内部的函数只能直接操作模块封装的元素。模块操作可能影响的外部元素是通过与包含这些元素的模块的交互（例如，通过函数调用）间接访问的。内部最小特权的另一个方面是，给定模块或组件的作用范围仅包括其功能所必需的系统元素，以及这些元素的访问模式（例如）。读取、写入)是最少的。

预生产环境包括开发、测试和集成环境。由国防部制定的程序保护规划流程是管理国防承包商预生产环境的例子。关键性分析和对开发人员应用控制措施也有助于构建更安全的系统开发环境。

手动代码审查通常只针对系统的关键软件和固件组件。手动代码审查能够有效识别那些需要了解应用程序需求或上下文的弱点，而这些信息在大多数情况下是自动化分析工具和技术（如静态分析和动态分析）所无法获取的。手动代码审查的好处包括能够根据应用程序控制验证访问控制矩阵，并审查加密实现和控制的详细方面。

版本控制的映射完整性处理在初始开发和系统开发生命周期更新期间对硬件、软件和固件组件的更改。保持与安全相关的硬件、软件和固件（包括设计、硬件图纸、源代码）主副本之间的完整性，以及与运行环境中主副本等效数据的一致性，对于确保支持关键任务和业务功能的组织系统的可用性至关重要。

最小化原则指出，组织应仅处理与实现授权目的直接相关且必要的个人可识别信息，并且仅在实现该目的所需的时间内保留个人可识别信息。组织已建立符合适用法律和政策的流程，以实施最小化原则。

组织可以通过使用去标识化或合成数据等技术来将个人隐私风险降到最低。在开发和测试环境中限制使用个人可识别信息有助于降低系统带来的隐私风险。

最小化安全元素原则指出，系统不应包含多余的受信任组件。最小化安全元素原则有两个方面：安全分析的总体成本和安全分析的复杂性。受信任的组件通常由于开发过程更严格而成本更高，更难构建和实现。可信组件需要更严格的安全分析以证明其可靠性。因此，为了降低成本并减少安全分析的复杂性，系统中应尽量少包含可信组件。对可信组件与系统其他组件的交互进行分析是系统安全验证中最重要的方面之一。如果组件之间的交互不必要地复杂，系统的安全性也将比内部信任关系简单且构建优雅的系统更难确定。一般来说，受信任的组件越少，内部信任关系就越少，系统也越简单。

最小化共享原则指出，除非绝对必要，否则系统组件（例如主体、进程、功能）之间不共享任何计算机资源。最小化共享有助于简化系统设计和实现。为了保护用户域资源免受任意主动实体的影响，任何资源只有在明确请求并被授予后才能共享。资源共享的需求可以由内部实体情况下的最小公用机制设计原则来推动，或由利益相关者的要求驱动。然而，内部共享需要经过仔细设计，以避免性能问题以及隐蔽存储和定时通道问题。通过常用机制共享可能会增加数据和信息被未经授权访问、披露、使用或修改的风险，并可能对系统提供的固有能力产生不利影响。为了尽量减少由常用机制引起的共享，这些机制可以设计为可重入或虚拟化，以保持隔离。此外，使用全球数据共享信息受到严格审查。缺乏封装可能会使共享实体之间的关系变得模糊不清。

模块化和分层的原则在各类系统工程学科中都是基础性的。源自功能分解的模块化和分层在管理系统复杂性方面非常有效，因为它们使理解系统结构成为可能。在系统设计中，模块分解或细化是一项具有挑战性的工作，并且难以用通用原则来概述。模块化用于将功能和相关数据结构隔离到定义明确的逻辑单元中。分层使这些单元之间的关系更易于理解，从而明确依赖关系并避免不必要的复杂性。模块化的安全设计原则将功能模块化扩展到包括基于信任、可信度、权限和安全策略的考量。安全知情的模块化分解包括将策略分配到网络中的系统、将系统应用程序分离为具有不同地址空间的进程、将系统策略分配到各层，以及根据硬件支持的特权域将进程分离为具有不同特权的主体。

有关 NIAP 的更多信息，请参见 [NIAP CCEVS]。有关 FIPS 验证的加密模块的更多信息，请参见 [NIST CMVP]。

分布式的安全资源，位于不同层次或不同系统元素，或用于支持可信性的不同方面，可能会以意想不到或错误的方式相互作用。不良后果可能包括级联故障、干扰或覆盖空白。安全资源行为的协调（例如通过确保在进行假设补丁已传播的配置更改之前，在所有资源上都安装了该补丁，可以避免这种负面交互。

在外部系统中保持对加密密钥的独占控制可以防止外部系统的员工解密组织数据。组织对加密密钥的控制可以通过在组织内部对数据进行加密和解密来实现，当数据发送到外部系统或从外部系统接收时，或通过使用一个组件，使加密和解密功能可以在外部系统本地执行，但允许组织独占访问加密密钥。

将组织信息存储在外部系统中可能会限制对其数据安全状态的可见性。组织在不将数据转移出外部系统的情况下，验证和确认其存储数据完整性的能力能够提供这种可见性。

部分有序依赖原理指出，系统中的同步、调用及其他依赖关系是部分有序的。系统设计的一个基本概念是分层，系统按功能相关的模块或组件组织成定义明确的层次结构。这些层在层间依赖关系上是线性排序的，高层依赖于低层。在为高层提供功能的同时，一些层可以是自包含的，不依赖于低层。虽然在给定系统中对所有函数进行部分排序可能不可行，但如果将循环依赖限制在各层之内，循环性带来的固有问题就更容易管理。部分有序的依赖关系和系统分层对系统设计的简洁性和连贯性有显著贡献。部分有序的依赖关系也有助于系统的测试和分析。

渗透测试是一种评估方法，在这种方法中，评估人员利用所有可用的信息技术产品或系统文档，并在特定约束条件下，试图规避信息技术产品和系统已实施的安全和隐私功能。对进行渗透测试的评估人员有用的信息包括产品和系统设计规范、源代码以及管理员和操作员手册。渗透测试可以包括白盒、灰盒或黑盒测试，由熟练的专业人员进行分析，他们模拟对手的行为。渗透测试的目标是发现系统、系统组件和服务中的漏洞，这些漏洞可能是由于实现错误、配置缺陷或其他操作上的薄弱环节或不足所导致的。渗透测试可以与自动化和手动代码审查结合进行，以提供比通常情况下更高水平的分析。在进行渗透测试时，如果捕获或记录了用户会话信息及其他可识别个人身份的信息，将会妥善处理这些信息以保护隐私。

性能安全原则指出，安全机制的构建应避免不必要地降低系统性能。性能和安全的相关利益相关者及系统设计要求应被明确阐述和优先排序。为了使系统实现满足其设计要求并被利益相关者接受（即，根据利益相关者的要求进行验证)，设计人员遵守能力性能对保护需求所施加的特定约束。计算密集型安全服务的整体影响（例如加密) 被评估并证明不会对更高优先级的性能考虑产生重大影响，或者被认为在性能与可靠保护之间提供了可接受的权衡。权衡考虑包括除非不可用或不足，否则使用计算负担较轻的安全服务。安全服务的不足由功能能力和机制的强度决定。机制的强度是根据安全要求、性能关键的开销问题（例如，密码密钥管理）以及对威胁能力的评估来选择的。性能安全原则促使系统引入有助于执行安全策略但开销最小的功能，例如可以在其上构建高级服务的低级硬件机制。这类低级机制通常非常特定，功能非常有限，并且经过性能优化。例如，一旦授予对某部分内存的访问权限，许多系统会使用硬件机制来确保所有后续访问都涉及正确的内存地址和访问模式。这一原则的应用强化了从系统底层开始设计安全性的必要性，并在低层引入可作为高层机制构建模块的简单机制。

系统和服务获取政策与程序涉及在系统和组织中实施的SA系列控制。风险管理策略是制定此类政策和程序的重要因素。政策和程序有助于保障安全性和隐私性。因此，安全和隐私项目在系统和服务采购政策及程序的制定上进行协作非常重要。一般来说，组织层面的安全和隐私项目政策和程序是更可取的，并且可能无需专门针对特定任务或系统的政策和程序。该政策可以作为一般安全和隐私政策的一部分，或者通过多项政策来体现组织的复杂性。如果需要，可以为安全和隐私计划、任务或业务流程以及系统建立相应的程序。程序描述了政策或控制措施是如何实施的，并且可以针对作为程序对象的个人或角色。程序可以记录在系统安全和隐私计划中，或记录在一个或多个单独的文档中。可能导致系统和服务采购政策与程序更新的事件包括评估或审计发现、安全或隐私事件，或法律、行政命令、指令、法规、政策、标准和指南的变更。仅仅重新陈述控制措施并不构成组织政策或程序。

谓词许可原则指出，系统设计人员在允许执行高风险操作或访问高度敏感的数据、信息或资源之前，应考虑要求多个授权实体提供同意。[SALTZER75] 最初将谓词许可称为特权分离。这也等同于职责分离。将权限分配给多个方可以降低滥用的可能性，并提供保障，即单一的意外、欺诈或信任违反不足以导致不可挽回的行为，从而避免产生重大损害。这种机制的设计选项可能需要同时采取行动（例如发射核武器需要两位经过授权的不同人员在很短的时间内给出正确的指令，或者是一系列操作，其中每个后续操作都由某些前一步动作触发，但没有任何一个人能够触发多于一个操作。

程序严格性的原则指出，系统生命周期过程的严格程度应与其预期的可信度相称。程序严格性定义了系统生命周期程序的范围、深度和细节。严格的系统生命周期程序通过多种方式有助于确保系统正确且没有非预期功能。首先，这些程序在生命周期过程中实施了制衡机制，以防止引入未指定的功能。其次，对系统安全工程活动所产生的规范和其他系统设计文档所应用的严格程序，有助于理解系统的实际构建情况，而不是仅仅相信组件的实现本身就是权威（且可能具有误导性）的规范。最终，当有详细的规格说明描述其当前设计时，对现有系统组件进行修改会更容易，而不是通过研究源代码或原理图来尝试理解其工作原理。程序上的严格有助于确保安全功能和保证性要求得到满足，并为确定可信度和风险状况提供更充分的信息依据。程序上的严格程度应与系统所需的保证级别相匹配。如果系统所需的可靠性较低，高度的程序严格性可能会增加不必要的成本，而当高可靠性至关重要时，高度的程序严格性所带来的成本是值得的。

信息处理和数据存储的地理位置可能会直接影响组织成功执行其使命和业务功能的能力。对高影响信息和系统的妥协或泄露可能对组织资产和运营、个人、其他组织以及国家造成严重或灾难性的负面影响。将高影响力信息的处理和存储限制在美国法律管辖范围内的设施中，可以对这类处理和存储提供更大的控制力。

信息处理、信息和数据存储或系统服务的地点可能会直接影响组织成功执行其使命和业务功能的能力。当外部供应商控制处理、存储或服务的位置时，就会产生这种影响。外部服务提供商用于选择处理、存储或服务位置的标准可能与组织使用的标准不同。例如，组织可能希望将数据或信息存储位置限制在特定地点，以便在发生信息安全或隐私事件时，有助于促进事件响应活动。事件响应活动，包括取证分析和事后调查，可能会受到处理和存储发生地以及系统服务来源地的相关法律、政策或规程的影响。

组织使用质量指标来确定系统质量的可接受水平。指标可以包括质量关卡，这些关卡是完成标准或充分性标准的集合，代表系统开发项目特定阶段的满意执行。例如，质量关卡可能要求消除所有编译器警告，或确定这些警告不会影响所需的安全或隐私功能的有效性。在开发项目的执行阶段，质量关卡提供清晰、明确的进展指示。其他指标则适用于整个开发项目。指标可以包括根据组织的风险容忍度定义漏洞的严重性阈值，例如要求交付的系统中不存在 CVSS（通用漏洞评分系统）严重性为中或高的已知漏洞。

降低复杂性的原则指出，系统设计应尽可能简单和小巧。一个小而简单的设计更易理解、更易分析，并且不易出错。降低复杂性的原则适用于系统的任何方面，但由于获取系统新兴安全属性证据所需的各种分析，它对安全性尤其重要。为了使此类分析成功，设计应小而简单。采用降低复杂度的原则有助于系统开发人员理解系统安全功能的正确性和完整性，同时也便于识别潜在的漏洞。降低复杂性的推论指出，系统的简单性与其包含的漏洞数量直接相关；也就是说，系统越简单，漏洞越少。降低复杂性的一个好处是，更容易理解系统设计中是否已实现预期的安全策略，并且在工程开发过程中引入的漏洞可能较少。另一个好处是，与在系统设计本质上更复杂的情况下得出的结论相比，对于正确性、完整性以及漏洞存在的任何此类结论都可以以更高的保证程度得出。从旧技术向新技术过渡（例如在从 IPv4 过渡到 IPv6 的过程中，可能需要在过渡期间同时实施旧技术和新技术。这可能会导致在过渡期间系统复杂性暂时增加。

可重复且有文档记录的程序原则指出，构建系统组件所采用的技术和方法应允许在以后完全且正确地重建相同的组件。可重复且有文档记录的程序有助于开发出与早前创建的组件完全相同的组件，而这些组件可能已被广泛使用。对于其他系统工件（例如文档和测试结果），可重复性支持一致性以及检查工件的能力。可重复且有文档记录的程序可以在系统开发生命周期的各个阶段引入，并有助于评估系统的保证性声明的能力。示例包括用于代码开发和审查的系统化程序、用于开发工具和系统工件配置管理的程序以及系统交付的程序。

对类似软件应用中发现的漏洞进行分析，可以为正在开发的系统提供潜在的设计和实现问题的参考。开发者组织内部可能存在类似的系统或系统组件。漏洞信息可以从各种公共和私营部门来源获取，包括美国国家标准与技术研究院（NIST）的国家漏洞数据库。

信息安全服务包括安全设备的操作，如防火墙或密钥管理服务，以及事件监控、分析和响应。评估的风险可以包括系统、任务或业务、安全、隐私或供应链风险。

安全默认原则规定，系统的默认配置（包括其组成的子系统、组件和机制）应体现对安全策略的严格和保守执行。安全默认原则适用于初始（即，默认）系统配置以及遵循“拒绝除非明确授权”策略的访问控制和其他安全功能的安全工程和设计。这一原则的初始配置方面要求系统、子系统或系统组件的任何“出厂”配置都不应有助于违反安全策略，并且在安全策略本身要求操作用户进行配置的情况下，能够防止系统以默认配置运行。限制性默认设置意味着系统将以“出厂状态”运行，具备足够的自我保护能力，并能够在制定预期的安全策略和系统配置之前防止安全漏洞。在“出厂状态”产品提供的保护不足的情况下，利益相关者会在建立安全初始状态之前评估使用该产品的风险。遵循安全默认原则可以确保系统在成功完成初始化后处于安全状态。在系统未能完成初始化的情况下，它要么使用安全默认值执行请求的操作，要么不执行该操作。参考与此原则平行的持续保护以及安全失败与恢复原则，以提供检测和恢复故障的能力。对这一原则的安全工程方法指出，除非请求被发现格式良好并且符合安全策略，否则安全机制会拒绝请求。不安全的替代方法是允许请求，除非显示出它与策略不一致。在大型系统中，为默认被拒绝的请求授予许可所满足的条件，通常比为了拒绝默认被授予的请求而需要检查的条件更加简洁和完整。

安全分布式组合的原则指出，执行相同系统安全策略的分布式组件的组合将产生一个系统，其执行该策略的效果至少与各个组件本身一样好。许多安全系统设计原则都涉及组件如何或应该如何交互。从分布式组件的组合中创建或启用功能的需求可能会放大这些原则的相关性。特别是，从独立系统到分布式系统或系统群的安全策略转换可能会产生意想不到或新出现的结果。通信协议和分布式数据一致性机制有助于确保在分布式系统中一致的策略执行。为了确保系统范围内的策略执行正确性，分布式组合系统的安全架构进行了全面的分析。

安全可演进性的原则指出，当系统的结构、接口、互连（即系统架构）、功能或配置（即安全策略执行）发生变化时，系统的开发应有助于维护其安全属性。变化包括新的、增强的或升级的系统能力；维护和持续活动；以及重新配置。虽然不可能对系统演变的每个方面都进行规划，但可以通过分析任务或业务战略方向、预期的威胁环境变化以及预期的维护和保障需求来预见系统升级和变更。期望复杂系统在开发时未考虑的环境中仍然保持安全是不现实的，无论这些环境是与操作环境相关，还是与使用相关。系统在某些新环境中可能是安全的，但不能保证其涌现行为始终是安全的。从一开始就在系统中建立可信性更为容易，因此系统可信性的维护需要为变化进行规划，而不是以临时或非方法化的方式适应。这一原则的好处包括降低供应商生命周期成本、降低拥有成本、提高系统安全性、更有效地管理安全风险以及减少风险不确定性。

安全故障与恢复原则指出，系统功能或机制的任何故障，以及为应对故障采取的任何恢复措施，都不会导致安全策略的违反。安全故障与恢复原则与持续保护原则相似，以确保系统能够在其运行的任何阶段（即在一定范围内）检测到实际和即将发生的故障。、初始化、正常运行、关闭和维护）并采取适当措施以确保不违反安全策略。此外，在指定情况下，系统能够从即将发生或实际发生的故障中恢复，以恢复正常、降级或替代的安全操作，同时确保保持安全状态，从而不违反安全策略。失效是一种状态，其中组件的行为偏离了其针对明确记录的输入所规定或预期的行为。一旦检测到安全功能失败，系统可能会重新配置自身，以绕过失败的组件，同时保持安全性，并提供原系统的全部或部分功能，或者系统可能会完全关闭自身，以防止进一步违反安全策略。为了实现这一点，系统的重配置功能被设计用以确保在重配置的各个阶段持续执行安全策略。另一种可用于从故障中恢复的技术是回滚到安全状态（可能是初始状态），然后关闭或更换失败的服务或组件，以便恢复安全操作。组件的故障可能被使用它的其他组件检测到，也可能无法检测到。安全失败原理表明，组件在失败时应处于拒绝访问而非授予访问的状态。例如，一个名义上的“原子”操作在完成之前被中断，并不会违反安全策略，而且其设计目的是通过使用更高级别的原子性和回滚机制（例如事务）来处理中断事件。如果某项服务正在被使用，其原子性特性将得到充分记录和描述，以便使用该服务的组件能够适当地检测和处理中断事件。例如，一个系统被设计为能够优雅地响应断开连接，并在断开后支持重新同步和数据一致性。采用策略执行机制复制的故障保护策略，有时称为纵深防御，即使一个机制未能保护系统，也可以使系统保持在安全状态。然而，如果这些机制相似，额外的保护可能只是表象，因为对手可以简单地连续攻击。同样地，在一个网络系统中，攻破一个系统或服务的安全性可能使攻击者能够对其他类似的复制系统和服务进行同样的攻击。通过采用多个具有显著不同特性的保护机制，可以降低攻击复制或重复发生的可能性。进行分析以权衡此类冗余技术的成本与收益，并考虑其对资源使用增加和整体系统性能产生的不利影响。随着这些机制的复杂性增加，例如在动态行为情况下，还会进行额外的分析。复杂性增加通常会降低可信度。当某个资源无法持续受到保护时，关键是要在该资源再次用于安全环境之前，检测并修复任何安全漏洞。

安全元数据管理原则指出，当策略要求完全保护信息或安全子系统自我保护时，元数据在安全策略方面应被视为“一级”对象。安全元数据管理的原则基于这样的认识：一个系统、子系统或组件无法实现自我保护，除非它保护其依赖于正确执行的数据。数据通常不会被存储它的系统解释。对于处理数据的用户和程序来说，数据可能具有语义价值（即它包含信息）。相反，元数据是关于数据的信息，例如文件名或文件创建日期。元数据与它所描述的目标数据绑定，以一种系统可以解释的方式存在，但它不必存储在目标数据内部或附近。可能存在其目标本身就是元数据的元数据（例如文件名的分类级别或影响级别，包括自引用的元数据。元数据的表面次要性可能导致其应有保护需求被忽视，从而导致违反包含信息外泄在内的安全策略。与元数据保护不足特别相关的一个问题是与多级安全（MLS）系统相关的风险。MLS 系统根据相对敏感等级调节主体对客体的访问。因此，所有在 MLS 系统控制范围内的主体和客体要么被直接标注，要么被间接赋予敏感等级。MLS 系统标注元数据的推论指出，包含元数据的客体是被标注的。与数据保护需求评估类似，也需要确保对机密性和完整性保护进行单独评估、指定并分配到元数据，就像对任务、业务和系统数据所做的那样。

安全系统修改原则指出，系统修改应在符合利益相关者的安全需求和风险容忍度的前提下，维持系统的安全性。系统的升级或修改可能会将安全系统变为不安全的系统。系统修改的程序确保如果系统要保持其可信性，那么用于初始开发的相同严格标准也将适用于任何系统更改。由于修改可能影响系统维持安全状态的能力，因此在实施和部署之前，需要对修改进行仔细的安全分析。这一原则与安全可演化性的原则相类似。

系统安全和隐私工程原则与系统开发生命周期密切相关，并在整个生命周期中得到实施（见SA-3）。组织可以将系统安全和隐私工程原则应用于正在开发的新系统或正在升级的系统。对于现有系统，组织在进行系统升级和修改时，会在可行范围内应用系统安全和隐私工程原则，考虑到这些系统中硬件、软件和固件组件的当前状态。系统安全和隐私工程原则的应用有助于组织开发值得信赖、安全且具有弹性的系统，并减少对中断、危险、威胁的易感性，以及为个人造成隐私问题的可能性。系统安全工程原则的例子包括：开发分层保护；建立安全和隐私政策、架构和控制，作为设计和开发的基础；将安全和隐私要求纳入系统开发生命周期；划定物理和逻辑安全边界；确保开发人员接受构建安全软件的培训；根据组织需求定制控制措施；并进行威胁建模以识别用例、威胁代理、攻击向量和模式、设计模式，以及减轻风险所需的补偿控制措施。应用系统安全和隐私工程概念和原则的组织可以促进可信、安全系统、系统组件和系统服务的开发；将风险降至可接受水平；并做出明智的风险管理决策。系统安全工程原则也可用于防范某些供应链风险，包括在设计中引入防篡改硬件。

信息安全和隐私代表可以包括系统安全官员、高级机构信息安全官员、高级机构隐私官员以及系统隐私官员。由具有信息安全和隐私专业知识的人员参与非常重要，因为系统配置的更改可能会产生意想不到的副作用，其中一些可能与安全或隐私相关。在过程早期检测此类变化可以帮助避免可能最终影响系统安全性和隐私状况的意外负面后果。本控制增强中的配置变更管理和控制过程是指组织在 SA-10b 中定义的变更管理和控制过程。

系统开发团队选择和部署安全与隐私追踪工具，包括漏洞或工作项跟踪系统，这些系统有助于分配、分类、筛选以及跟踪与开发流程相关的已完成工作项或任务。

与安全相关的硬件、软件和固件代表系统、组件或服务中被信任能够正确执行以维持所需安全属性的部分。

自我分析原理指出，系统组件能够在执行的各个阶段对其内部状态和功能进行有限程度的评估，并且这种自我分析能力与系统所投入的可信度水平相称。在系统层面，自我分析可以通过自下而上建立的可信度分级评估来实现。在这种方法中，较低级的组件会检查较高级组件的数据完整性和正确功能（在一定程度上）。例如，受信任的启动序列涉及一个受信任的低级组件，该组件证明下一级较高级组件的可信性，从而可以建立一个传递的信任链。从根本上说，一个组件会自我证明，这通常涉及对其完整性的公理化或环境强制假设。自我分析的结果可以用来防范外部引起的错误、内部故障或瞬时错误。遵循这一原则，可以在不让错误或故障的影响扩散到组件外部的情况下，检测出一些简单的故障或错误。此外，自检还可以用于验证组件的配置，检测其配置是否与预期配置存在潜在冲突。

自立可信原则指出，系统在自身可信性方面尽量减少对其他系统的依赖。一个系统默认是可信的，与外部实体的任何连接仅用于补充其功能。如果一个系统必须与另一个外部实体保持连接以维持其可信性，那么该系统将容易受到恶意和非恶意威胁，这可能导致该连接的丧失或退化。自我可信原则的好处是，系统的隔离会使其不那么容易受到攻击。这个原则的一个推论与系统（或系统组件）独立运行的能力有关，然后在重新与其他组件连接时重新同步。

软件和固件完整性验证允许组织使用开发者提供的工具、技术和机制检测对软件和固件组件的未经授权的更改。完整性检查机制还可以应对软件和固件组件的伪造问题。组织通过开发者提供的安全单向哈希等方式来验证软件和固件组件的完整性。交付的软件和固件组件还包括对这些组件的任何更新。

对于支持关键任务服务或功能的系统或系统组件，经常有必要对其进行增强，以最大化资源的可信度。有时，这种增强是在设计阶段完成的。在其他情况下，则是在设计之后进行的，要么通过修改相关系统，要么通过添加额外组件来增强系统。例如，可以向系统添加补充认证或不可否认性功能，以增强关键资源对依赖于组织定义资源的其他资源的身份识别。

静态代码分析提供了一种用于安全审查的技术和方法，包括检查代码中的弱点，以及检查是否包含具有已知漏洞、过时或不受支持的库或其他代码。静态代码分析可以用于识别漏洞并实施安全编码规范。在开发过程的早期使用效果最佳，此时每次代码更改都可以自动扫描潜在的弱点。静态代码分析可以提供明确的修复指导，并帮助开发者识别需要修复的缺陷。正确实施静态分析的证据可以包括关键缺陷类型的总缺陷密度、缺陷已由开发人员或安全专业人员检查的证据，以及缺陷已被修复的证据。高密度的被忽略的发现，通常称为误报，表明分析过程或分析工具可能存在问题。在这种情况下，组织会将证据的有效性与来自其他来源的证据进行权衡。

最小特权原则指出，每个组件仅被分配足够的权限来完成其指定的功能，但不应超过这一限度（参见 SA-8(14)）。应用最小特权原则可以限制组件操作的范围，这具有两个理想效果。首先，系统组件的故障、损坏或误用所造成的安全影响被降至最低。其次，组件的安全分析得到了简化。“最小权限”是一个贯穿所有安全系统设计各方面的原则。用于调用组件功能的接口只对某些特定用户子集可用，组件设计支持足够细粒度的权限分解。例如，在审计机制的情况下，可能会有一个审计管理员的界面，用于配置审计设置；一个审计操作员的界面，确保审计数据被安全收集和存储；最后，还有一个审计审查员的界面，他只需要查看已收集的审计数据，而不需要对这些数据进行操作。除了在系统接口上的表现外，最小权限还可以作为指导系统内部结构的原则。内部最小权限的一个方面是构建模块，使得模块内的函数只能直接操作模块封装的元素。模块操作可能影响的外部元素是通过与包含这些元素的模块的交互（例如，通过函数调用）间接访问的。内部最小特权的另一个方面是，给定模块或组件的作用范围仅包括其功能所必需的系统元素，以及对这些元素的访问模式（例如，阅读、写作）是最少的。

在[SP 800-160-1]中应用安全设计原则有助于对系统、系统组件和服务进行完整、一致且全面的测试和评估。这种测试的彻底性有助于产生证据，从而生成有效的保证案例或论据，以证明系统、系统组件或服务的可信性。

充分文档原则规定，负有与系统互动职责的组织人员应获得足够的文档和其他信息，以便这些人员能够促进系统安全，而不是造成损害。尽管尝试遵守诸如以人为本的安全和可接受的安全等原则，系统本质上是复杂的，安全机制的设计意图及其误用或配置错误的后果并不总是直观明显的。缺乏信息和训练不足的用户可能由于遗漏或失误引入漏洞。文档和培训的可用性有助于确保人员队伍具备知识，其中每个人都在实现诸如持续保护等原则方面发挥关键作用。文档书写清晰，并辅以培训，以提高安全意识和对安全相关职责的理解。

安全配置的示例包括美国政府配置基准（USGCB）、安全技术实施指南（STIGs）、以及对功能、端口、协议和服务的任何限制。安全特性可以包括要求已更改默认密码。

系统开发生命周期过程为组织系统的成功开发、实施和运行提供了基础。在系统开发生命周期早期将安全性和隐私考虑因素纳入其中，是系统安全工程和隐私工程的基本原则。在系统开发生命周期中应用所需的控制措施需要对信息安全和隐私、威胁、漏洞、不利影响以及关键任务和业务功能的风险有基本的理解。SA-8中的安全工程原则帮助个人正确地设计、编码和测试系统及系统组件。组织包括合格的人员（例如在系统开发生命周期过程中，包括高级机构信息安全官员、隐私高级官员、安全与隐私架构师以及安全与隐私工程师，确保已建立的安全和隐私要求被纳入组织的系统中。基于角色的安全和隐私培训计划可以确保具有关键安全和隐私角色与职责的个人具备开展指定系统开发生命周期活动所需的经验、技能和专业知识。将安全和隐私需求有效地整合到企业架构中，也有助于确保在系统生命周期的各个阶段都能考虑到重要的安全和隐私因素，并且这些因素与组织的使命和业务流程直接相关。这一过程还促进了信息安全和隐私架构与企业架构的整合，这与组织的风险管理策略是一致的。由于系统开发生命周期涉及多个组织，（例如外部供应商、开发人员、整合商、服务提供商），采购和供应链风险管理职能与控制在系统生命周期的有效管理中起着重要作用。

系统文档帮助人员理解控制措施的实施和操作。组织会考虑建立具体措施来确定所提供内容的质量和完整性。系统文档可用于支持供应链风险管理、事件响应及其他职能。需要文档的人员或角色包括系统所有者、系统安全官员和系统管理员。获取文档的尝试包括联系制造商或供应商以及进行基于网络的搜索。由于系统或组件的年代久远，或缺乏开发人员和承包商的支持，可能会出现无法获取文档的情况。当无法获取文档时，如果文档对控制措施的实施或操作至关重要，组织可能需要重新创建文档。对文档的保护应与系统的安全类别或等级相称。涉及系统漏洞的文档可能需要更高水平的保护。系统的安全运行包括最初启动系统以及在系统运行中断后恢复系统的安全运行。

当一个组织通过合同规定为了完成其组织任务或职能而运营一个记录系统时，该组织应在其权限范围内，使[PRIVACY]的要求适用于该记录系统。

技术更新规划可能包括硬件、软件、固件、流程、人员技能、供应商、服务提供商和设施。使用已过时或即将过时的技术可能会增加与不受支持的组件、假冒或改装组件、无法实现安全或隐私要求的组件、运行缓慢或无法操作的组件、来自不可信来源的组件、人员无意错误或复杂性增加相关的安全和隐私风险。技术更新通常发生在系统开发生命周期的运维阶段。

系统、系统组件和系统服务可能会与系统开发生命周期的需求和设计阶段创建的功能和设计规范存在显著偏差。因此，在系统开发过程中以及交付之前，对这些系统、系统组件和系统服务进行威胁建模和漏洞分析的更新，对于这些系统、组件和服务的有效运行至关重要。在系统开发生命周期的这个阶段进行威胁建模和漏洞分析，可以确保设计和实现的变更得到考虑，并且由于这些变更产生的漏洞已被审查和缓解。

可信通信通道的原则指出，在构建一个系统时，如果组件之间的通信存在潜在威胁（即组件之间的互连），每个通信通道的可信度应与其所支持的安全依赖程度相称（即其他组件对其执行安全功能的信任程度）。可信的通信渠道是通过限制对通信渠道的访问（以确保通信双方的可信度达到可接受的匹配）以及对通过通信渠道传输的数据实施端到端保护（以防止数据被拦截和篡改，并进一步提高端到端通信的可靠性）相结合来实现的。

可信组件原则指出，一个组件的可信程度至少应与它所支持的安全依赖关系相称（即其他组件在多大程度上信任它执行其安全功能）。该原则使组件的组合能够保持其可信性而不会被无意间削弱，同时确保信任不会因此而被错误置放。最终，这一原则要求有某种度量方法，可以在同一抽象尺度上衡量对组件的信任和组件的可信性。当考虑存在复杂信任依赖链的系统和组件时，受信任组件的原则尤为相关。信任依赖也被称为信任关系，可能存在信任关系链。受信组件的原则同样适用于由子组件组成的复合组件（例如，一个子系统），这些子组件可能拥有不同的可信度水平。保守的假设是，复合组件的可信度等同于其最不可信的子组件的可信度。有可能提供一个安全工程的理由，说明某一特定复合组件的可信度高于保守假设。然而，任何此类理由都反映了基于明确的可信度目标陈述以及相关且可靠的证据的逻辑推理。复合组件的可信性与在组件内增加纵深防御层或复制组件并不相同。纵深防御技术并不会使整体的可信性超过其中最不可信组件的可信性。

安全相关硬件、软件和固件更新的可信分发有助于确保这些更新是开发者维护的主副本的正确表现，并且在分发过程中未被篡改。

可信的描述、源代码和目标代码的生成能够在开发过程中应对硬件、软件和固件组件在各版本之间的授权变更。重点是开发人员对配置管理过程的有效性，以确保新生成的与安全相关的硬件描述、源代码和目标代码版本能够继续执行系统、系统组件或系统服务的安全策略。相比之下，SA-10(1) 和 SA-10(3) 允许组织使用开发者提供的工具、技术或机制来检测对硬件、软件和固件组件的未经授权的更改。

对系统组件的支持包括软件补丁、固件更新、更换零件和维护合同。不受支持的组件示例包括供应商不再提供关键软件补丁或产品更新的情况，这可能会为攻击者利用已安装组件的漏洞提供机会。不替换不受支持的系统组件的例外情况包括提供关键任务或业务能力的系统，这些系统的新技术尚不可用，或者系统高度孤立，无法安装替换组件。替代支持来源解决了这样一个需求：当系统组件仍然对组织的使命和业务功能至关重要，但原制造商、开发者或供应商不再提供支持时，仍需为这些组件提供持续支持。如有必要，组织可以通过为关键软件组件开发定制补丁来建立内部支持，或者通过合同关系获得外部供应商的服务，这些供应商为指定的不受支持组件提供持续支持。这类合同关系可以包括开源软件增值供应商。使用不受支持的系统组件所带来的风险可以通过一些方式降低，例如禁止将此类组件连接到公共或不受控的网络，或实施其他形式的隔离。

FIPS 201 批准的产品列表中的产品符合 NIST 对联邦雇员和承包商个人身份验证（PIV）的要求。PIV 卡用于系统和组织中的多因素身份验证。

用于通过加密手段保护机密信息的商业现成信息保证（IA）或支持IA的信息技术产品，可能需要使用NSA批准的密钥管理。参见[NSA CSFC]。

实时数据也被称为运营数据。在预生产环境（即开发、测试和集成）中使用实时或运营数据可能会对组织造成重大风险。此外，在测试、研究和培训中使用个人身份信息会增加此类信息被未经授权披露或滥用的风险。因此，组织管理因使用实际或运行数据而可能产生的额外风险非常重要。组织可以通过在系统、系统组件和系统服务的设计、开发和测试过程中使用测试数据或虚拟数据来将此类风险降到最低。可以使用风险评估技术来确定使用实际或运行数据的风险是否可接受。

通过各种分析技术（从非正式到正式）可以验证测试和评估是否覆盖了所需的全部控制。这些技术中的每一种都提供了相应的保证水平，该水平与分析的正式程度相对应。通过形式建模和分析技术，包括控制实施与相应测试用例之间的关联，可以严格证明在最高保障级别下的控制覆盖情况。