Security Reference Model

Introduction

Definition/Description (What) – The Federal Information Security Management Act (FISMA)[1] defines information security as “the protection of information and information systems from unauthorized access, use, disclosure, disruption, modification. Or destruction in order to provide confidentiality, integrity, and availability.”

Purpose/Function (Why) – There is considerable guidance across the Federal community for security planning, reporting, and monitoring investments. Federal Government IT programs have a wide range of security requirements. FISMA requirements include but are not limited to compliance with Federal Information Processing Standards agency specific policies; Authorization to Operate requirements; and vulnerability and security event monitoring, logging, and reporting. This section will not replicate that guidance; instead, this section will focus upon the Identity and Access Management (IdAM) aspect of security as it is elemental to all of the reference models. This section will describe:

  • Differences between identity and access management.
  • Roles and responsibilities of stakeholders.

Stakeholder Performance Guide (Who & How) – Security transcends each of the Federal Enterprise Architecture Reference Models (e.g., Business Data Application/Service, Infrastructure, and Performance) and impacts each of those stakeholders responsible for its implementation. Security compliance should also be included within Governance since it is an enforcement point for Information Technology investments.[2]

 

[1] Public Law 107-347-DEC. 17 2002. Federal Information Security

Management Act, 2002. 44 U.S.C., Sec 3542.

[2] Office of Management and Budget, Federal Enterprise Architecture Framework, Version 2, (January 29, 2013), available at http://69.89.31.228/~mkerncom/wp-content/uploads/2013/02/Federal-Enterprise-Architecture-Framework-v2-as-of-Jan-29-   2013.pdf


Security Principles

The term “security” is exceptionally broad and means many things to many people. In the context of this section, the focus is specifically upon the IdAM aspect of security,[1] which is the most common user-facing aspect of security. Identity and Access Management (IdAM) is about how a system interacts with its users and includes Identity and Access Management components. Identity Management is focused on knowing who it is (as well as the individual’s basic characteristics) that is interacting with a system or data. Access Management is focused on determining whether or not that individual should be permitted to interact with a specific resource in a specific way.

The Federal Identity, Credential, and Access Management (FICAM) Roadmap and Implementation Guidance[2] (“FICAM Roadmap”) defines the concepts as:

  • Authorization and Access – are the processes of granting or denying specific requests for obtaining and using information processing services or data and to enter specific physical It ensures individuals can only use those resources they are entitled to use and then only for approved purposes, enforcing security policies that govern access throughout the enterprise.
  • Authentication – is the process of verifying that a claimed identity is genuine and based on valid Authentication typically leads to a mutually shared level of assurance by the relying parties in the identity. Authentication may occur through a variety of mechanisms including challenge/response, time-based code sequences, biometric comparison, PKI or other techniques. Information must be protected against unauthorized access for national security, privacy, and other reasons. The government has a wealth of information obtained via a variety of means and has an obligation to ensure that that information is used appropriately. This means ensuring that all access is appropriate, permissible, and accountable. The government also has a responsibility to be financially efficient. A well thought-out IdAM architecture meets both of these goals by allowing a system to effectively control access, improving the security of the data in a system, while at the same time reducing duplication by leveraging external (shared) IdAM services. Fine- grained access control, enabled by IdAM, allows the system owner to manage the system risk by safeguarding use of information without hindering responsible sharing of mission information.

Leveraging such external services allows the system owner to focus on the mission need the system is intended for, while leveraging enterprise IdAM and security services which have been designed to meet the specific needs of the IdAM and security domains. This focus not only strengthens the capabilities of the system, but also allows for the enterprise to recognize economies of scale on reusable IdAM and security services. Systems incorporating interfaces to interoperate with such reusable services add flexibility to adapt as such services mature and policy dictates new additional requirements. Security that incorporates the capabilities prescribed in the FICAM Roadmap allows system owners to build robust security appropriate to their mission needs that complements other network and cybersecurity activities in a way that meaningfully manages the risk of the system both independently and in conjunction its network environment.

Figure 1 provides a high-level view of core components of the FICAM Roadmap. FICAM provides the framework for implementing secure role-based and data access capabilities using authorized identities and credentials to secure and safeguard data and information.

 

SRM-Fig1

Figure 1. FICAM Conceptual Diagram

 

IdAM needs to balance the need to safeguard the system and its data with the need to responsibly share information and enable the mission. Identity Management and Access Management are two primary Service Types in the FICAM Roadmap, with Part A, as the Federal Government segment architecture for ICAM and IdAM.

This is a high-level snapshot of the Identity Credential and Access Management activities that will continue to evolve and mature over time. It contains a tri-fold of the ICAM Landscape and describes on-going initiatives and describes common terminology used across the ICAM community.

 

 

[1] Other significant aspects include Certification & Accreditation (now called Assessment & Authorization), FISMA compliance, Physical Security, Network Security, Communications Security, and many others. These aspects are outside of the scope of this document.

[2] Federal Identity, Credential, and Access Management (FICAM)

Roadmap and Implementation Guidance, Version 2.0, December 2, 2011. Federal Chief Information Officers Council. The guidance is available at http://www.idmanagement.gov/sites/default/files/documents/FICAM_Roadmap_and_Implementation_Guidance_v2%200_201112   02_0.pdf


Stakeholder Roles And Responsibilities

IdAM addresses the policies and technical practices defined by a data owner, vetted by governance and oversight bodies, and enacted by a system owner to protect the information contained in the system. These policies and technical practices must be incorporated into the business practices of the system owner, implemented in the technical capabilities of the system, and enforced as users’ access and use the system. As IdAM capabilities become more robust for identifying users and their business purpose in accessing system information, the security model for the system should evolve to take advantage of the additional opportunities for safeguarding system information through fine-grained access control.

Executives must recognize the value of implementing reusable (sharable) IdAM services for mission systems and must reinforce the value provided by such services to their organization through the support of an organizational EA function, aligned with larger federal EA efforts, that identifies and incorporates such shared services. Program Managers must ensure that their system engineering lifecycle incorporates their organization’s architecture considerations, as well as larger federal enterprise considerations. The Program Manager must ensure that the requirements for the system incorporate interfaces for external IdAM services so that reusable enterprise shared services can be leveraged for the mission system, and that the timeline for use of such services is aligned with the organizational or federal roadmap and timeline for implementation for those services. The Solution Architect will need to create a system that provides flexible interfaces to interoperate with IdAM and security services and standards. Those interfaces must adapt as those services and standards evolve during the lifecycle of the system.

Data Architects, working with the relevant Data Owners, must ensure that data is accurately tagged in such a way that access control may be maintained over it. An effective access control capability must know certain things about each piece of data, such as its sensitivity, releaseability, or copyright restrictions. These requirements must be incorporated into a data tagging methodology, in alignment with relevant data standards, and built into the system.

System owners must work to balance safeguarding and sharing through appropriate risk management measures, applying IdAM’s safeguarding capabilities close to their data and system while additionally leveraging those employed by the fabric, network, or environment as a whole. The security concept for the system should reflect that environment, using the security of the surrounding environment to complement the local system security to provide defense in depth. Network-wide security measures are necessary supporting elements of security, but are not sufficient on their own to satisfy modern information safeguarding needs.

Significant stakeholders in IdAM are diverse and include Data and Mission Owners, Program and Project Managers, System Owners, Enterprise Architects, Information Assurance, and even Procurement personnel.

  • Data and Mission Owners – are responsible for determining, in plain English, the access control policies for the data they maintain stewardship over. Does their data require users to be from a certain part of the organization? Perhaps have a certain security clearance or have taken certain training? Can their information be accessed by others outside of their Department or Agency? Under what circumstances?
  • These policies must be developed in coordination with, and often approved by, some sort of Governance or Oversight body that often includes General Counsel, the Privacy Office, and others involved in legal and regulatory activities.
  • Program and Project Managers – are responsible for ensuring the system lifecycle, Beginning with the requirements definition through the design and implementation, incorporates the capabilities necessary to meet IdAM and Security requirements for their systems and ensuring that the funding for such capabilities is provided for in the system budget planning.
  • System Owners – are responsible for ensuring that their systems implement the access control policies defined by Data Owners, as well as for ensuring that their systems implement only the FICAM Service Types that can’t be shared.
  • The FICAM Roadmap lists the following service types: Digital Identity, Credentialing, Privilege Management, Authentication, Authorization and Access, Cryptography, and Auditing and Reporting.
  • A system owner should generally not need to address Digital Identity or Credentialing, as those service types can generally be implemented at the organizational level and System owners may need to incorporate pieces and parts of Privilege Management, Authorization and Access, Auditing and Reporting, and aspects of both Authentication and Cryptography into their system lifecycle.
  • Enterprise Architects – are responsible for ensuring that shared IdAM-related services are known about and, where appropriate, re-used. Does an in-progress project truly need to have all of its own internal IdAM services? Can it re-use an existing enterprise service?
  • Information Assurance Personnel – are responsible for ensuring that IdAM is implemented properly, when a shared service is first constructed, when it is re- used, and when a system builds its own internal capabilities.
  • Procurement Personnel – are responsible for ensuring that IT procurements incorporate the right standards, allowing a system to leverage a shared IdAM service. These personnel are also responsible for ensuring that requests for proposal indicate the desired re-use.

System owners should focus on the IdAM service types inherent to their system, and should leverage reusable services where applicable.

Certain FICAM Service Components may be provided by enterprise capabilities (e.g., cryptography for classified communications security) or by shared capabilities (e.g., shared PKI services), and implementers should examine each of the FICAM Service Components, taking into account the security domain on which they operate, to determine which should be reused and which should be built within their system. This “focus on the system” approach allows the system owner to protect their systems, and data, more robustly than either the traditional perimeter network defense model or a situation where the implementer must account for all FICAM Service Components on their own.


Stakeholder Performance Guide

It is the responsibility of the geospatial system investment owner (both existing and pending), to understand and ensure compliance with information security policy and individual agency practices. Information security considerations must occur prior to the procurement and implementation phases of the System Development Life Cycle (SDLC). Security controls, policy, and processes must be built into the SDLC for information security to be implemented successfully and cost-effectively. Each organization should have a mechanism by which risk and security concerns inform the design and implementation of systems and applications, to avoid creating cost and schedule impacts due to security requirements being added at the operations and maintenance stage of the SDLC. The continuous assessment of risk and the effectiveness of controls are required throughout the entire lifecycle of the IT system.[1] Table 1 provides an overview ok key security activities that must occur at each phase of the SDLC.

 

Table 1. Key Security Activities by SDLC Phase

SDLC PHASE

KEY SECURITY ACTIVITIES FOR THIS PHASE INCLUDE:

Initiation

Initial delineation of business requirements in terms of confidentiality, integrity, and availability:

•   Determine information categorization and identification of known special handling requirements to transmit, store, or create information such as personally identifiable information

•   Determine any privacy requirements

•   Early planning and awareness will result in cost and timesaving through proper risk management planning. Security discussions should be performed as a part of (not separately from) the development project to ensure solid understanding among project personnel of business decisions and their implications to the overall development project.

Development/ Acquisition

Conduct the risk assessment and use the results to supplement the baseline security controls:

•  Analyze security requirements

•  Perform functional and security testing

•  Prepare initial documents for system authorization and accreditation

•  Design security architecture

Implementation/ Assessment

Integrate the information system into its environment:

•   Plan and conduct system certification activities in synchronization with testing of security controls

•   Complete system accreditation activities

Operations and Maintenance

Manage the configuration of the system:

•   Institute processes and procedures for assured operations and continuous monitoring of the information system’s security controls

•   Perform reauthorization as required

Disposal

Build and execute a Disposal/Transition Plan:

•   Archive critical information

•   Sanitize media

•   Dispose of hardware and software

 

The Performance Guidance (Table 2) provides a summation of the key decision points to facilitate the awareness and understanding of the roles and responsibilities of geospatial investment owners for security considerations.

 

Table 2. Stakeholder Performance Guide: Security

STAKEHOLDER PERFORMANCE GUIDE

SECURITY

Role

Responsibility

Approach

Benefit

Executive Leadership

• Identify appropriate access policy for system data necessary to ensure responsible information sharing according to mission need.

• Ensure risk management function for the organization is established and applies repeatable, consistent evaluation criterion.

• Embrace the use of reusable, shared services for IdAM and security capabilities within the agency, and ensure Enterprise Architecture provides for adoption of federal shared services, particularly IdAM and security services, as they become available.

• Empower organizational enterprise architect to direct the inclusion of relevant IdAM and security standards in organizational IT acquisition actions by holding systems accountable for EA compliance.

• Understand Policy Requirements:

◦ Mission need for system information security

◦ Business processes that incorporate the system information

◦ Severity of risk of unauthorized disclosure

• Risk management function should be staffed sufficiently and empowered to reconcile interests of stakeholders. Clear risk management criteria formed with input from all relevant stakeholders (security, privacy, CRCL, mission owners).

• Designate organizational Executive Agents responsible for implementing IdAM and Security EA and policy. Responsible for:

◦ Organization. EAs represent organization at relevant intergovernmental committees, governance bodies, and WGs.

◦ Develop acquisition strategy that requires transition of solutions to repeatable shared services.

• EA functions include:

◦ Organizational process for approval of systems to ensure EA for IdAM and Security (services and standards). If compliance not currently feasible, POA&Ms to be required.

◦ Engage organizational acquisitions and procurement functions to ensure contractual commitments and acquisitions are consistent with IdAM and Security EA and implementation plans.

◦ Recommend restriction of funding of noncompliant systems.

• A clear statement of information sharing policy can be vetted through the relevant stakeholders and then digitally implemented within mission systems to efficiently execute the mission.

• Provides consistent feedback that can be incorporated for system design and avoids delays from inability to plan due to ambiguous guidance or interference from dissatisfied stakeholders.

• Assist in complying with Federal policy guidance and drives cost efficiencies through shared, common services.

• Ensures that system planning incorporates appropriate guidance from an early stage to avoid delays or wasted expenditures resulting from noncompliant system architecture.

• Incorporating EA function into organizational approval process provides enforcement mechanism for EA compliance at an early stage, when noncompliance can be more easily mitigated.

Program Manager

• Ensure access policy requirements for the system information are included in system acquisition, tech refresh actions, and system engineering lifecycle.

• Ensure compliance/evaluation/ approval of the system in accordance with the organizational risk management framework.

• Ensure requirements for relevant IdAM requirements are included in procurement language.

• Identify access policy rules that have been enumerated for information contained in the system.

• Program Manager actively engages with relevant governance bodies from system planning phase onward (see Table 1).

◦ Give EA organization visibility into each phase of system lifecycle.

◦ EA communicates emerging requirements to Program Managers.

• Draft and include approved guidance with system acquisition, tech refresh actions, and system engineering lifecycle documentation.

• Assist in complying with Federal policy guidance and drives cost efficiencies through shared, common services.

• Assists in CPIC reporting requirements and drives early security awareness and compliance resulting in cost savings.

• Assists in CPIC reporting requirements and drives early security awareness and compliance resulting in cost savings.

Solution Architect

• Ensure solution roadmap aligns with FICAM Roadmap.

• Ensure solution meets requirements of organizational risk management framework.

• Implement solution that is compliant with EA model for IdAM and security as well as organizational FICAM implementation plans.

• Implement solution with sufficient interfaces to take advantage of enterprise IdAM and security services.

• Detail functionality for currently available capabilities and provide POA&Ms demonstrating alignment for future capabilities.

• Clear system with risk management function during planning stage. If system is operational, coordinate roadmap to satisfy RM function.

• Solution is described in terms of functional and technical requirements, which are mapped to service types and components of the relevant EA model.

• Interfaces are defined sufficiently to show interoperability of system with repeatable shared services and standards.

• Ensures flexibility and adaptability of systems to incorporate upcoming capabilities.

• Expedites development by coordinating risk management requirements into system planning and design phase rather than waiting for approval after build is complete.

• Ensures that solutions are engineered or selected to meet all relevant requirements from the planning and design phase.

• Ensures that the solution is designed and sufficiently technically implemented to provide flexibility to interoperate with emerging IdAM and security capabilities without the need for extensive re-engineering.

 

 

[1] Office of Management and Budget, Federal Enterprise Architecture Framework, Version 2, January 29, 2013, available at  http://www.whitehouse.gov/omb/e-gov/fea

[2] National Institute of Standards and Technology, NIST Special Publication 800-64 Revision 2, Security Considerations in the System Development Life Cycle, October 2008. http://csrc.nist.gov/publications/nistpubs/800-64-Rev2/SP800-64-Revision2.pdf

Updated on February 4, 2020