NIST Special Publication 800-53 Revision 5.2.0 Rev 5.2.0

控制基线是预先定义的一组控制措施，专门组装用于满足某个群体、组织或利益社区的保护需求。基线中选择控制措施，目的是要么满足法律、行政命令、指令、法规、政策、标准和指南所强加的要求，要么在基线特定假设下，应对所有基线用户普遍面临的威胁。基线代表了保护个人隐私、信息和信息系统的起点，随后可以根据任务、业务或其他约束进行调整以管理风险（见 PL-11）。联邦控制基线在 [SP 800-53B] 中提供。控制基线的选择由利益相关者的需求决定。利益相关者需要考虑使命和业务需求，以及适用法律、行政命令、指令、政策、规章、标准和指南所强加的要求。例如，[SP 800-53B]中的控制基线是基于[FISMA]和[PRIVACT]的要求。这些要求以及实施该立法的 NIST 标准和指南，指导组织在审查信息类型以及系统上处理、存储和传输的信息后，从控制基线中选择一个。分析信息或系统丧失或被破坏对组织的运营和资产、个人、其他组织或国家的潜在不利影响；并考虑系统和组织风险评估的结果。[CNSSI 1253] 提供了国家安全系统控制基线的指导。

定制概念允许组织通过应用一套明确的定制操作，对一组基础控制进行专业化或个性化调整。定制化措施通过允许组织制定反映其特定使命和业务功能的安全和隐私计划，从而促进这种专业化和个性化，这些计划考虑了其系统运行的环境、可能影响其系统的威胁和漏洞，以及可能影响其使命或业务成功的其他条件或情况。制定指南在 [SP 800-53B] 中提供。调整控制基线是通过识别和指定通用控制、应用范围考虑、选择补偿控制、为控制参数分配值、根据需要用额外的控制补充控制基线以及提供控制实施信息来实现的。[SP 800-53B] 中的一般定制操作可以根据组织的需求补充额外的操作。定制操作可以根据 [FISMA] 和 [PRIVACT] 的安全和隐私要求应用于 [SP 800-53B] 中的基线。或者，采用不同控制基线的其他利益社区可以应用 [SP 800-53B] 中的定制操作，以专门化或定制那些反映这些实体特定需求和关注的控制措施。

中央管理是指对组织范围内所选控制和流程的管理与实施。这包括规划、实施、评估、授权以及监控由组织定义并集中管理的控制和流程。由于控制的集中管理通常与通用（继承）控制的概念相关，这种管理促进并便利了控制实施和管理的标准化，以及组织资源的合理使用。集中管理的控制和流程也可以满足评估独立性的要求，以支持初始和持续的运营授权，并作为组织持续监控的一部分。自动化工具（例如安全信息与事件管理工具或企业安全监控与管理工具可以提高与集中管理的控制和流程相关的信息的准确性、一致性和可用性。自动化还可以提供数据聚合和数据关联功能；警报机制；以及支持组织内基于风险的决策的仪表盘。作为控制选择过程的一部分，组织根据资源和能力确定可能适合集中管理的控制措施。并非所有控制的各个方面都可以集中管理。在这种情况下，该控制可以被视为混合控制，即控制措施可以在集中管理或系统级别上实施和管理。适合进行全部或部分集中管理的控制措施及其增强措施包括但不限于：AC-2(1)、AC-2(2)、AC-2(3)、AC-2(4)、AC-4(全部)、AC-17(1)、AC-17(2)、AC-17(3)、AC-17(9)、AC-18(1)、AC-18(3)、AC-18(4)、AC-18(5)、AC-19(4)、AC-22、AC-23、AT-2(1)、AT-2(2)、AT-3(1)、AT-3(2)、AT-3(3)、AT-4、AU-3、AU-6(1)、AU-6(3)、AU-6(5)、AU-6(6)、AU-6(9)、AU-7(1)、AU-7(2)、AU-11、AU-13、AU-16、CA-2(1)、CA-2(2)、CA-2(3)、CA-3(1)、CA-3(2)、CA-3(3)、CA-7(1)、CA-9、CM-2(2)、CM-3(1)、CM-3(4)、CM-4、CM-6、CM-6(1)、CM-7(2)、CM-7(4)、CM-7(5)、CM-8(全部)、CM-9(1)、CM-10、CM-11、CP-7(全部)、CP-8(全部)、SC-43、SI-2、SI-3、SI-4(全部)、SI-7、SI-8。

CONOPS 可以包含在系统的安全或隐私计划中，也可以包含在其他系统开发生命周期文档中。CONOPS 是一份动态文档，需要在整个系统开发生命周期中进行更新。例如，在系统设计评审期间，会检查作战概念，以确保其与控制设计、系统架构和操作程序保持一致。对作战概念（CONOPS）的更改反映在对安全和隐私计划、安全和隐私架构以及其他组织文件（如采购规范、系统开发生命周期文件和系统工程文件）的持续更新中。

组织会在安全和隐私架构中战略性地分配安全和隐私控制，以使对手必须克服多个控制措施才能达成其目标。要求对手击败多个控制措施可以通过增加对手的工作量来使攻击信息资源变得更加困难；同时，这也增加了被发现的可能性。协调已分配的控制措施对于确保涉及某一控制措施的攻击不会因干扰其他控制措施而产生不利的、意想不到的后果至关重要。意外后果可能包括系统锁定和连锁报警。在系统和组织中安排控制措施是一项重要活动，需要经过深思熟虑的分析。在提供额外分层时，组织资产的价值是一个重要的考虑因素。纵深防御架构方法包括模块化和分层（参见 SA-8(3)）、系统与用户功能的分离（参见 SC-2）以及安全功能隔离（参见 SC-3）。

在系统和组织中实施的 PL 家族控制的规划政策和程序。风险管理策略是制定此类政策和程序的一个重要因素。政策和程序有助于保障安全和隐私。因此，安全和隐私项目在制定过程中进行协作非常重要。从组织层面制定安全和隐私计划的政策和程序通常更为理想，并且可能不需要在任务层面或系统特定层面制定政策和程序。该政策可以作为总体安全和隐私政策的一部分，也可以通过多项政策来体现，以反映组织的复杂性。如果需要，可以为安全和隐私程序、任务/业务流程以及系统建立程序。程序描述了政策或控制措施的实施方式，并可以针对程序对象的个人或角色进行指导。程序可以记录在系统安全和隐私计划中，也可以记录在一个或多个单独的文档中。可能触发规划政策和程序更新的事件包括但不限于评估或审计结果、安全或隐私事件，或法律、行政命令、指令、法规、政策、标准和指南的变化。单纯重复控制措施并不构成组织政策或程序。

行为规范代表了组织用户的一种访问协议类型。其他类型的访问协议包括保密协议、利益冲突协议和可接受使用协议（参见 PS-6）。组织会根据用户的角色和职责来考虑行为规范，并区分适用于特权用户的规则和适用于普通用户的规则。为某些类型的非组织用户（包括从联邦系统接收信息的个人）制定行为规则通常是不切实际的，因为这类用户数量庞大，而且他们与系统的交互有限。组织和非组织用户的行为规则也可以在 AC-8 中制定。相关控制部分提供了与组织行为规则相关的控制列表。控制的已记录确认部分 PL-4b，如果组织所进行的识字培训、意识培训和基于角色的培训计划中包含行为规则，可以满足这一要求。行为规则的书面确认包括电子或纸质签名，以及电子同意复选框或单选按钮。

系统级别的安全性和隐私架构与 PM-7 中描述的全组织范围的安全性和隐私架构一致，这些架构是企业架构的组成部分，并在企业架构开发过程中形成。这些架构包括架构描述、安全和隐私功能的分配（包括控制）、外部接口的安全和隐私相关信息、接口间交换的信息，以及与每个接口相关的保护机制。这些架构还可以包括其他信息，例如用户角色及分配给每个角色的访问权限；安全和隐私要求；系统处理、存储和传输的信息类型；供应链风险管理要求；信息和系统服务的恢复优先级；以及其他保护需求。[SP 800-160-1] 提供了关于在系统开发生命周期过程中使用安全架构的指导。[OMB M-19-03] 要求对高价值资产使用 [SP 800-160-1] 中描述的系统安全工程概念。安全性和隐私架构会在系统开发生命周期的各个阶段进行审查和更新，从替代方案分析到RFP响应中对拟议架构的审查，再到在实施前和实施过程中进行的设计评审（例如，在初步设计评审和关键设计评审期间）。在当今的现代计算架构中，组织完全控制所有信息资源的情况越来越少。可能会对外部信息服务和服务提供商存在关键依赖。在安全和隐私架构中描述这些依赖关系，对于制定全面的任务和业务保护策略是必要的。为组织系统建立、开发、记录并在配置控制下维护基线配置，对于实施和维护有效的架构至关重要。架构的发展是与高级机构信息安全官员和高级机构隐私官员协调进行的，以确保识别并有效实施支持安全和隐私要求所需的控制。在许多情况下，系统的安全架构和隐私架构可能没有区别。在其他情况下，安全目标可能已得到充分满足，但隐私目标可能仅通过安全要求得到部分满足。在这些情况下，考虑为实现满足而需要的隐私要求将会产生一个独立的隐私架构。然而，文档可能仅反映了合并后的架构。PL-8 主要面向组织，以确保为系统开发架构，并且确保这些架构与企业架构集成或紧密结合。相反，SA-17 主要面向外部信息技术产品及系统开发人员和集成商。SA-17，即与PL-8互补，当组织将系统或组件的开发外包给外部实体，并且需要证明其与组织的企业架构以及安全和隐私架构的一致性时会被选择。

社交媒体、社交网络和外部网站/应用使用限制涉及使用社交媒体、社交网络和外部网站时的行为规则，这些规则适用于组织人员在执行公务或处理官方事务时使用该类网站时、组织信息涉及社交媒体和社交网络交易时，以及人员从组织系统访问社交媒体和网络网站时。组织还会制定特定规则，以防止未经授权的实体通过社交媒体和社交网站直接或通过推断获取非公开的组织信息。非公开信息包括个人身份信息和系统账户信息。

信息技术产品各有优劣。提供种类广泛的产品可以补充单个产品的功能。例如，提供恶意代码防护的供应商通常会在不同时间更新其产品，通常会根据其优先级和开发计划，为已知的病毒、木马或蠕虫开发解决方案。通过在不同地点部署不同的产品，至少有一种产品检测到恶意代码的可能性会增加。在隐私方面，供应商可能提供能够在系统中跟踪个人身份信息的产品。不同的产品可能使用不同的跟踪方法。使用多种产品可能会更有保障地对个人身份信息进行清点。

系统安全和隐私计划的范围限定在系统及定义的授权边界内的系统组件，并包含系统的安全和隐私要求概述以及为满足这些要求所选择的控制措施。这些计划描述了在系统背景下每个选定控制的预期应用，提供了足够的细节，以便正确实施控制并随后评估控制的有效性。控制文档描述了系统特定控制和混合控制的实施方式，以及关于系统功能的计划和预期。系统安全和隐私计划也可以用于系统的设计和开发，以支持基于生命周期的安全和隐私工程流程。系统安全和隐私计划是动态文档，会在系统开发生命周期中不断更新和调整（例如，在能力确定、方案分析、招标请求和设计评审期间）。第2节。1 描述了在系统开发生命周期中与组织相关的不同类型的需求，以及需求与控制之间的关系。组织可以制定一个单一的、综合的安全和隐私计划，或维持单独的计划。安全和隐私计划将安全和隐私需求与一套控制措施及控制增强措施关联起来。这些计划描述了控制和控制增强如何满足安全性和隐私要求，但未提供控制和控制增强的设计或实施的详细技术说明。安全和隐私计划包含足够的信息（包括通过明示或参考方式说明的选择和分配操作的控制参数值规格），以使设计和实施能够明确符合计划的意图，并在计划实施后对组织运营和资产、个人、其他组织及国家的风险进行后续评估。安全和隐私计划不必是单一的文件。计划可以是各种文件的集合，包括已经存在的文件。有效的安全和隐私计划会广泛引用政策、程序以及其他文件，包括设计和实施规范，其中可以获取更详细的信息。使用参考资料有助于减少与安全和隐私计划相关的文档工作，并将与安全和隐私相关的信息维护在其他已建立的管理和运营领域，包括企业架构、系统开发生命周期、系统工程和采购。安全和隐私计划不需要包含详细的应急计划或事件响应计划信息，而可以通过明确说明或引用的方式，提供足够的信息来界定这些计划需要完成的内容。可能需要与组织内的其他个人或团队协调和规划的安全及隐私相关活动包括评估、审计、检查、硬件和软件维护、采购及供应链风险管理、补丁管理以及应急预案测试。规划和协调包括紧急和非紧急情况（即（计划的或非紧急的非计划）情况。组织为规划和协调安全及隐私相关活动而定义的流程，也可以在其他适当的文件中包含。