RMF Phase 3

Implementing Security Controls

Abstract

This chapter introduces phase 3 of the RMF, which is when the selected security controls are implemented.

Table of Contents

Chapter Overview and Key Learning Points

In this chapter each of the security controls defined in the previous phases are developed and implemented in the system. The implementation of each control is fully documented in the systems documentation in a way that explains not only the controls implementation but also the plan that will be used to maintain the control. The chapter concludes with an exercise that re-enforces the chapters material.

Phase 3, Task 1: Security Control Implementation

This task coincides with the development/acquisition and implementation phase of the SDLC and is the responsibility of the information systems owner and common control provider with the assistance of the information owner, information systems security officer, and information systems security engineer.

The implementation of the system’s required security controls is based on the guidance provided by NIST SP 800-53A, Guide for Assessing the Security Controls in Federal Information Systems and Organizations. This document describes the requirements that are used to assess the security controls implemented in the information system. By ensuring that the required security controls are implemented to the same standard required when the system is assessed ensures that the system’s security controls are developed correctly and are validated as compliant during security control assessment.

SP 800-53A defines three different assessment methods used to assess or evaluate an information system: examine, interview, or test, with each assessment focusing on a different evaluation technique. Generally speaking, examinations involve reviewing system, business unit or organizational policy, and documentation. Test events, on the other hand, are assessed by evaluating the system or system output. Finally, interview events are conducted by talking with information system users, administrators, or other staff members. Information system owners, information systems developers, ISSO, and ISSE staff members should carefully evaluate the requirements of the specific control or enhancement to ensure that the assessment technique to be used is at the same standard used to implement the system. At times, an assessment of the examine technique could rely on system documentation as well as information system output, a method that could be considered a technical evaluation.

When implementing the controls in the catalog, information system developers and security personnel can review the requirements of 800-53A to ensure that the control or enhancement is implemented correctly based on the security requirements and assessment technique. Controls and enhancements can require compliance assessment and validation by one, two, or even all three of the assessment techniques. Using SP 800-53A to assess security controls is covered in greater detail in the next chapter. It is important that the developer and implementer understand the standard that is used to evaluate these controls once the information system is being assessed. Additionally, the information system owner can use 800-53A to conduct self-assessments of the control in this task to more quickly make corrections, should the control not meet the documented requirements. A good deal of detail can be gained by reviewing one of the controls. Reviewing the control AC-2 from SP 800-53A highlights the main points that are required to correctly implement any of the controls from the controls catalog.

In reviewing the assessment objective, it is easy to match the items in section (i) with the requirements for AC-2 1-i in SP 800-53. The assessment of item (ii) is required to validate that the organization has defined a variable for item j for this control and item (iii) ensures that the control is implemented according to this variable assigned by the organization.

The potential assessment methods determine how this control will be evaluated by the security control assessor in the next task based on the type of assessment, whether examination of documentation, interview of staff, or testing of technical security controls. While described in greater detail later in this task, it can’t be overstated that evaluation of the security controls during information system development using self-assessments is much more cost effective and efficient than modifying the system after the assessments in the next task, as controls that are identified as not meeting the minimum requirements can be adjusted or corrected early in the design process. If available, an even better option is to use security control assessors who are determined by the authorizing official to be independent. The assessment results from the information system self-assessments can then be used for the system’s authorization package in the security assessment report. In the case of the control AC-2, system developers can use SP 800-53A to determine whether or not this control is to be assessed by reviewing policy and documentation indicated by the examine assessment technique and by interviewing organizational personnel with account management responsibilities. It is wise to ensure that the system is developed in a manner that meets the conditions for each of the controls required by the control selections made in task 2.

For example, based on the organization’s information security architecture and the availability of organizationally approved common controls, the system owner and control provider should develop methods of ensuring that the security controls they are responsible for are implemented correctly, provide adequate security, and are consistent with the organization’s enterprise architecture and information security architecture. The enterprise’s architecture will provide a framework and mechanism to allocate specific security controls to common control providers, the information system itself, and its component subsystems. The availability of a defined antivirus product, intrusion detection system, and other security mechanisms and services provide good examples of how a security control may be integrated with the organization’s information security architecture. These services or products would then be selected and allocated, after being approved as common controls and services, to specific systems and components that require that specific capability.

Continuing with the example used previously, many organizations require the use of a specific antivirus product, with a defined update capability and schedule, on all information system components that are capable of having the product applied to them. This standardization assists the information systems security engineer and information systems security officer in designing the system in a manner that is in compliance with the organization’s information and security architecture, as well as meeting the requirements for those controls that mandate an antivirus product be applied to the system and updated on a regular schedule. By evaluating the organization’s information and security architecture, those responsible for security control implementation can leverage organizationally defined and tested products and services on the systems that they are developing. In addition, as the organization has a known level of expertise, trained staff and possibly the availability of volume discounts or enterprise license pricing for the use of these products, which may also result in project cost savings.

The controls that were selected in earlier phases of the RMF must now be allocated to and implemented by the specific components of the information system that will provide protection for the entire system. Control allocation is an important and sometimes time-consuming task that requires the coordination of different organizations in the enterprise offering common controls for inheritance, the system owner, data steward, and other individuals supporting system design and development.

At times, controls are allocated to not one single component but to most, if not all, of the components and subsystems of the information system. A good example of this is any one of the controls that require system auditing; these controls would be implemented on each of the components of the information system as well as the subsystems that are present in dynamic systems where auditing is possible. Other times, a control will only be implemented in specific components or subsystems and is not required to be implemented across the entire system. For example, a system may have subsystems that do not have wireless capabilities while the larger information system has the capability for wireless; in this case, the wireless controls are levied against the larger system and would not be implemented in the dynamic subsystem without wireless capabilities. The organization’s architecture, information and security, system categorization, common control providers, and control allocation all help to achieve a suitable balance between system- and organization-provided security control protections. Evaluation of the organization’s architecture and controls that are being provided by common control providers helps determine which of the required controls can be inherited, which will be provided by the information system, and which will be a combination of the two, or a hybrid control.

The development of hybrid controls is the result of evaluating an organizationally provided common control and determining that it does not provide adequate protection. The system owner then reinforces the control with additional protection measures to be maintained by the information system owner and supporting staff. Responsibility and maintenance of the control is then shared between the system owner and common control provider. In an earlier chapter, an example of a hybrid training control was presented. In that case, the organization provides annual general information security training to all computer users in the organization. It was determined that the system will implement mobile devices requiring security training not covered by the annual training. The information system owner can accept the annual information security training provided by the organization and develop specific training for the security of mobile devices. The security training requirements are then shared between the organization’s common control provider and information system owner.

Implementing security controls at the information system level is best accomplished by following best practices, system and software engineering methodologies, security engineering principles, and secure coding techniques. Identifying and implementing security controls early in the system’s development ensures that the system will function as designed when all the required security controls are in place. Additionally, identifying controls and related costs early in the process assists in determining the cost of system development and operations and maintenance (O&M) to ensure that funding is correctly allocated for the system. In some cases, the costs required to properly secure the information system and the information it contains may be prohibitive and cause the system’s development to be delayed or canceled altogether.

When developing information systems, it is important to ensure that all required security controls, policies, and requirements are correctly integrated and implemented. There are a number of places to turn for assistance when implementing technical controls for an information system; for example, the United States Government Configuration Baseline (USGCB), a program managed by NIST and formerly called the Federal Desktop Core Configuration (FDCC), defines specific requirements for implementing an extensive number of security controls on many common desktop environments, including many versions of Microsoft Windows and Red Hat Linux. A system’s desktop solution may include one or more of these baselines. It may also require additional controls not covered by the USGCB and may mandate organization-specific settings to ensure that the system is in compliance with all requirements, including local policy, resulting in an information system that is compliant and as secure as possible.

Full consideration should be given to include technologies that have been evaluated by the organization or an outside standards association to help reduce cost and speed development. There are times when other organizational information systems will implement some of the same technology components that are being used in this system’s development. In those cases, information and security professionals can evaluate the body of evidence from the this system’s implementation and determine what portions of this system’s configurations and settings can be reused for the system under development. In some cases, not only can the existing system’s settings be reused, but the policies and security and implementation documentation can be reused by integrating them into the developing information system. This process can dramatically increase the speed of system development by leveraging existing artifacts while maintaining system security and compliance.

In other cases, technology components may be evaluated by trusted outside organizations, including government labs or common criteria labs. Common criteria labs (http://www.commoncriteriaportal.org/) provide independent evaluation of many information technology products, offering specific profiles for certified products, which allow system developers and security professionals to better understand the security status of a product before implementing or assessing the protections it provides. This, too, can speed system development and reduce costs. While the common criteria is a well-known and well-understood assessment process, other lab organizations can also provide trusted third-party evaluation of technical products. These other labs may have varying degrees of transparency and the process they use may be unknown to the system developers. The organization should therefore determine which of the third-party labs will be used to evaluate technology, or have existing documentation leveraged to facilitate secure system development. In the case of outside third-part evaluations, the authorizing official determines the level of reassessment required by independent security control assessors.

Those systems that are critical to the organization’s mission, or could cause catastrophic harm if compromised, may have high assurance requirements to ensure that specific security controls are implemented correctly and are operating as mandated. These systems may have controls that require enhanced continuous monitoring, auditing, and configuration management requirements to ensure that they maintain security and compliance standards. Examples of these kinds of systems include high impact systems or those critical systems that are vulnerable to specific and credible indications of threat or advanced cyber-attack. The enhanced requirements should therefore be implemented and documented fully at this point so that the enhanced control’s effectiveness can be assessed in the next phase of the RMF.

While it is not recommended, common control selection may have been deferred earlier in the system’s development using the RMF; if this is the case, the system owner must now make determinations on the selection of controls that will be inherited from common control providers, enhanced as a hybrid control, or implemented entirely by the information system owner. When the information system owner decides to inherit a control from a common control provider, the two must coordinate to ensure that the control is approved for inheritance by both the common control provider and the supporting organization. The system owner should determine the common control’s lifetime, its approval status, and if approved, when its approval is set to expire. The system owner then determines how the common control will be documented in the systems security plan: either by referencing the common control provider’s body of evidence or by documenting the control fully in the information systems security plan. The system owner and the common control provider determine the best way to implement the inherited control in the information system. This can be simple or complex, depending on the information system and the common control provider’s complexity.

When implementing security controls, it may be advisable to turn to vendor- or third-party-provided security documentation. Many vendors offer security and hardening guides for the technologies they develop and support. Additionally, government agencies produce checklists and security guides that assist system developers and owners in properly securing their systems and maintaining compliance with required controls. The Department of Defense, through the Defense Information Systems Agency (DISA), produces numerous security checklists and security technical implementation guides (STIG) for many of the common technology platforms available. These guides are available at http://iase.disa.mil/stigs/. The National Security Agency (NSA) also produces security configuration guides for a wide variety of software platforms at http://www.nsa.gov/ia/mitigation_guidance/security_configuration_guides/index.shtml.

In addition to government agencies, there are a number of civil organizations that produce documentation that assists information system owners in securely developing their information systems. A great source is the Center for Internet Security’s security benchmarks, available at http://benchmarks.cisecurity.org. There is also a good deal of security documentation available at the Sysadmin, Audit, Networking and Security (SANS) website at http://www.sans.org/security-resources/. These and other resources should be used to ensure that the system being developed is in compliance with all required security controls and policies, as well as best industry and business practices.

Security control assessments can be done throughout the RMF and SDLC. This allows system engineers and security officers to validate the effectiveness of security controls and the accuracy of the systems developed, as well as the correctness of published test procedures. Issues discovered during these initial assessments can be quickly resolved by making the needed corrections to the information system or system’s documentation, or by forwarding a description of the issues to the authorizing official as soon as possible for prompt resolution, if needed. This early detection of security-relevant issues, including weaknesses and deficiencies, facilitates the most cost-effective way to initiate corrective actions. Well-documented initial security procedures and assessment results can also be used during the security assessment phase, further reducing the cost of system assessment and increasing the efficiency of the authorization process. Independent security control assessors (SCA) can use these early assessment results to provide a baseline for their evaluation. They are responsible for providing the AO with documentation of the system’s current compliance with the required security controls; these documents are part of the next task of the RMF. If these control assessments and the test procedures developed to support them are complete, accurate, and can be validated, they may be used in the final security assessment report (SAR).

Phase 3, Task 2: Security Control Documentation

The documentation of the security controls required for the system describes how each of the controls is implemented and its categorization as common, hybrid, or system-specific. This documentation serves as the formal plan and explanation document regarding the overall function and security implementation of the system, including all required inputs and outputs. The security control documentation further defines the control’s traceability to the control requirement, required organizational, or regulatory settings and the system’s implementation of the control. When documenting the system, the system owner balances the level of effort with the purpose, scope, and impact the system will have on the organization’s business function, mission, or operations. The documentation should describe security control implementation, required settings, test procedures and, in applicable documentation or references, to the appropriate body of evidence for common and hybrid controls. The implementation standard should also include documenting planned inputs, expected behavior, and expected output.

During this phase, security engineers, system engineers, and other security and technology professionals determine if each of the required security controls that are allocated as system-specific or hybrid are in place and protecting the system as designed and that the system documentation and requirements match the configuration of the system and its components. This confirmation is done through a semi-formal test process, whereby the actions required to verify the control are documented and added to the system test procedures. This process should cover each of the controls listed in the system controls’ traceability matrix (SCTM). The SCTM should have a column or other area indicating whether the control is tested by a process detailed in the test procedures or is a documented operational or managerial control. For these controls, the SCTM should indicate the specific document, including paragraph or section, that meets that specific control. Controls with a technical evaluation requirement should be identified in the SCTM, which should indicate where the test procedure is located in the test procedure document. The test procedure document should detail how to test the control and the expected results or system output. References to the required bodies of evidence are used in the SCTM for tracing requirements for common and hybrid controls; this must also be thoroughly documented.

This task includes updating the systems security plan to indicate the details of each of the required controls’ implementation. While there are no strict requirements for the format of these control statements, it is beneficial to the system owner to have a section for each of the required controls, including the required control enhancement. This greatly enhances the readability and organization of the documentation, especially when being evaluated by the security control assessor. At times, it may be possible to include closely related controls into a single section by requiring updates to occur in only one place. This serves to reduce documentation redundancy and decrease the possibility of errors being introduced when controls or system documentation is updated. If this is not done, it may be possible to update the required security documentation in one location while omitting needed updates in a different section. In any case, it is helpful to include the security control’s identification in the section’s title: “Information Security Awareness and Training (AT-1, AT-2, AT-3, AT-4).”

This method of documentation helps ensure that security control assessors can quickly identify the location of the information system’s method of implementing each control. While other methods of documentation are acceptable, it often takes longer for the assessor to determine where in the security plan each of the security controls is documented, due to the ambiguity in the some documentation styles. This section header is followed by specific details on how each of the controls and the required enhancements listed are implemented in the information system or supported in associated documentation. This is also the place to document security control inheritance or the implementation of hybrid controls.

Chapter 11 Lab Exercises: Selecting Security Controls

In this phase, the controls identified in phase 2 of the RMF are implemented in the system as it moves from design to development. The planning for the controls that was accomplished up to this point are now put into action.

1. The development team has determined that the system will use the Windows 7 operating system for desktop clients. Where could the team turn to for configuration settings for this platform?

2. The developers have determined that some of the controls that will be inherited from the physical security common control provider are not stringent enough for the system that is being developed. What could the developers do to resolve this issue?