Author: John Lycas

This article summarizes the intersection of Enterprise Architecture (EA) and the implementation of security and privacy controls. While other sources have described where security and privacy are represented in EA [1], the focus here is to gain an understanding of the intersection from the other perspective – where is EA specified in security and privacy controls and what are the implications for the EA practitioner?

What guidance is available on security and privacy controls?

The National Institute of Standards and Technology (NIST) Special Publication (SP) 800-53, Security and Privacy Controls for Information Systems and Organizations, provides a catalog of security and privacy controls for federal information systems and organizations to protect organizational operations and assets, individuals, other organizations, and the Nation from a diverse set of threats including hostile attacks, natural disasters, structural failures, human errors, and privacy risks. The controls are flexible and customizable and implemented as part of an organization-wide process to manage risk. The controls address diverse requirements derived from mission and business needs, laws, Executive Orders, directives, regulations, policies, standards, and guidelines [2].  A revision 5 of NIST SP 800-53 is currently out in draft form.

Where is EA specified in the security and privacy controls guidance? 

In NIST SP 800-53, EA is called out in the configuration management (CM), planning (PL), program management (PM), and system and services acquisition (SA) security and privacy control families. Specific guidance related to EA is as follows [2]:

• Baseline Configuration CM-2 – Baseline configurations of systems reflect the current enterprise architecture.
• Security and Privacy Plans PL-2 – Develop security and privacy plans for the system that are consistent with the organization’s enterprise architecture.
• Security and Privacy Architectures PL-8 – Develop security and privacy architectures for the system that describe how the security and privacy architectures are integrated into and support the enterprise architecture. Review and update the security and privacy architectures to reflect updates in the enterprise architecture.
• Enterprise Architecture PM-7 – Develop an enterprise architecture with consideration for information security, privacy, and the resulting risk to organizational operations and assets, individuals, other organizations, and the Nation.
• System Development Life Cycle SA-3 – The effective integration of security and privacy requirements into enterprise architecture also ensures that important security and privacy considerations are addressed early in the system life cycle and that those considerations are directly related to organizational mission and business processes. This process also facilitates the integration of the information security and privacy architectures into the enterprise architecture, consistent with risk management strategy of the organization.
• Developer Security Architecture and Design SA-17 – Require the developer of the system, system component, or system service to produce a design specification and security architecture that: Is consistent with and supportive of the organization’s security architecture which is established within and is an integrated part of the organization’s enterprise architecture [*].

What are the implications for the EA practitioner? Following NIST SP 800-37, Risk Management Framework for Information Systems and Organizations, [3], security and privacy controls are selected, tailored, and documented that are necessary to protect the information system and organization commensurate with risk. Ultimately, organizations employ a tailoring process to achieve cost-effective, risk-based solutions that support organizational missions and business needs. Organizations have the flexibility to tailor at the organization level for systems in support of a line of business or mission/business process, at the individual system level, or by using a combination of the above. Tailoring decisions, including the justification for those decisions, are documented in the security and privacy plans for organizational systems. It is likely that this selection process will determine that some to all of the NIST SP 800-53 controls listed above with EA touchpoints, are needed.  In turn, this will drive coordination between the EA and the security and privacy architects. As described in NIST SP 800-53 [2] and NIST SP 800-39 [4], the security or privacy architect serves as the primary liaison between the enterprise architect and the systems security or privacy engineer and coordinates with system owners, common control providers, and system security or privacy officers on the allocation of controls. The security or privacy architect is responsible for ensuring that stakeholder protection needs and the corresponding system requirements necessary to protect organizational missions and business functions and individuals’ privacy are adequately addressed in the enterprise architecture including reference models, segment architectures, and solution architectures (systems supporting mission and business processes). [3] Enterprise architects, therefore, work with both security and privacy architects to provide the relevant artifacts to address the controls that are informed by the EA. In addition, the security and privacy architects are developing information that can enrich the EA, necessitating a two-way flow.  The implications for the Enterprise Architect are as follows:

• Review the security and privacy reference and solution architectures for alignment to the EA.
• Recommend enterprise shared services defined in the EA where appropriate to meet security and privacy needs.
• Maintain the EA list of approved applications and standards for use by the security and privacy architects.
• Update the EA based on changes to the security and privacy architectures.
• Ensure that mission/business process-driven security requirements and protection needs are defined and allocated to appropriate organizational information systems [4].

Bibliography

  [*] PL-8 is primarily directed at organizations to ensure that they develop security and privacy architectures for the system, and that the architectures are integrated with or tightly coupled to the enterprise architecture through the organization-wide security and privacy architectures. In contrast, SA-17 is primarily directed at external information technology product and system developers and integrators. SA-17, which is complementary to PL-8, is selected when organizations outsource the development of systems or system components to external entities, and there is a need to demonstrate consistency with the organization’s enterprise architecture and security and privacy architectures.

Approved for Public Release; Distribution Unlimited. MITRE Public Release Case Number 20-0521