CHAPTER 8:
OPERATE & MAINTAIN – MAINTAINING AUTHORIZATION
The world is not your problem; the problem is your unawareness.81
Baghwan Shree Rajneesh, Indian Spiritual Leader
In this chapter:
Monitor the security controls: situational awareness Conduct the annual review and security reporting Maintain the authorization
Wikipedia defines situational awareness as “the perception of environmental elements within a volume of time and space, the comprehension of their meaning, and the projection of their status in the near future. It is also a field of study concerned with perception of the environment critical to decision makers in complex, dynamic areas.” More simply, situational awareness is knowing what’s happening around you and understanding its importance and relevance to your environment.
Figure 16: C&A process 3
This chapter revolves around the operation of the information system and ensuring that you maintain situational awareness at all times about the status of your system security.
The previous phase ended with the authorization to operate an information system. The post-authorization phase begins with the requirement for continuous monitoring of the security controls and security status reporting – all culminating in the maintenance of the authorization to operate. This phase continues until:
The information system is removed from service.
A major change is planned and/or implemented for the information system.
An updated security control compliance validation is required.
The operate and maintain phase consists of activities required to operate and manage the information system at an acceptable level of risk. Maintaining a secure information system must be an ongoing process. It requires you to continuously weigh the risk of operation against system functionality, the operating environment, and available resources. In order to be effective, you must always maintain what the DOD calls “situational awareness.”
MONITOR the security control status: situational awareness
Effective information system security programs must also include an aggressive continuous monitoring program to check the status of the security controls in the information system on an ongoing basis.
Continuous monitoring of the security control status, also called situational awareness, is a proven technique to address the security impacts on information systems resulting from changes to the hardware, software, firmware, or operational environment.
Continued authorization to operate is contingent upon the sustainment of an acceptable security posture, which is accomplished through ensuring continued compliance with assigned security controls. The information system security manager (ISSM)82 has the primary responsibility for maintaining situational awareness and initiating actions to improve or restore IA posture. The primary tasks involved in monitoring support of situational awareness include:
Continuous change and configuration management.
Ongoing security control verification.
Change and configuration management
The ISSM and system owner should continuously monitor the information system and its environment for security relevant events and configuration changes to the system or information environment that might negatively impact the security posture. The ISSM and/or the owner of the information system also continuously and periodically assesses the quality of the security controls implementation against performance indicators such as security incidents, feedback from external inspection agencies (e.g. Inspector General, Government Accountability Office), exercises, operational evaluations, etc. Additionally, the ISSM, independently or at the direction of the CA or authorizing official, may schedule a re-validation of any or all IA controls at any time.
What is a security relevant event?
Defining what constitutes a security relevant event often presents a challenge to an organization. Security-relevant events may include:
Expiration of a security control re-validation period. Certain security controls may have assigned re-validation periods in which the control must be re-validated.
Security events defined by the security control. The ISSM must also remain particularly cognizant of the security controls related to configuration and vulnerability management, performance
monitoring, and periodic independent evaluations, e.g. penetration testing.
Significant changes to an information system. Configuration changes to the system or information environment could impact the security posture of the system. Examples include, but are not limited to:
• Installation of a new or upgraded operating system, middleware component, or application.
• Modifications to system ports, protocols, or services.
• Installation of a new or upgraded hardware platform or firmware component.
• Modifications to cryptographic modules or services.
• Changes in laws, directives, policies, or regulations.
• IAVAs or patch alerts.
Situational awareness is the end result of continuous monitoring. It involves documenting the proposed or actual changes to the information system and subsequently determining the impact of those proposed or actual changes on the security of the system.
Information systems will typically be in a constant state of change as a result of upgrades to hardware, software, or firmware or modifications to the surrounding environment in which the system is deployed. Documenting information system changes and assessing the potential impact those changes may have on the security of the system is an essential aspect of continuous monitoring, situational awareness, and maintaining the security authorization. This critical process is referred to as configuration management (CM) or change management.
Configuration management processes
Having formal configuration management (CM) processes in your organization will ensure that you can manage change in your information systems – SECURELY! In fact, without CM you probably wouldn’t even notice when your information system has undergone a security-relevant change.
CM can be defined as the process of establishing and maintaining the technical integrity of an information system throughout its life cycle by systematically identifying, controlling, and accounting for all changes made to that system. A mature CM process is critical to your organization’s ability to effectively manage and track system changes.
A configuration management plan (CMP) is essential to this process. Chapter 10 outlines the major elements of a CMP and provides a description of the content that should be included in the plan. In addition, we also provide a high-level introduction to CM and CMPs, including what CM is, what a CMP is, and why and when a CMP should be developed. The section also describes, in depth, the configuration control process (CCP), which is the most important element of the CMP. A template for a CMP can be found on the accompanying CD.
What is a configuration management plan?
A CMP should be a living document that identifies CM roles and responsibilities, resources, and all of the formal processes and procedures needed to ensure that proposed changes to an information system are evaluated and approved prior to implementation. This includes activities, such as system-wide upgrades, replacements, and deployments.
A well-written CMP should include and address CM roles and responsibilities, communications, the system configuration baseline, configuration control processes, and CM resources. A sample configuration management plan is included on the CD.
Why have a configuration management plan?
Many organizations may already be doing some form of CM for their information systems and may question the need for a formal, documented plan. There are two reasons for developing and maintaining a CMP:
It is the law! OMB A-130, the Handbook for Information Assurance Security Policy, and other federal laws and regulations, require you to develop a CM process and document it in a CMP.
A documented CMP will really help your organization to implement and mature your CM processes.
A well-developed CMP will ensure:
Changes to the configuration are identified and evaluated to determine the impact to system security before implementation. Ideally, this process will start at the system concept and development and be carried out until the information system is replaced. Since each change is tracked from initial system development through completion, a thorough history of changes is created for that system. For example, an information system running on an older version of the Windows® Operating System (OS) may require an upgrade to a more recent version because of existing vulnerabilities in the older version. Upgrading to the more recent version of the Windows® OS will change the system’s configuration. The need for a version upgrade is a configuration change that must be evaluated in terms of impact on the security, system performance, and functionality, as well as that of the overall enterprise.
Configuration changes are documented, ensuring that version control is maintained. Upgrades and additions are easily implemented as a result of the hardware and software controls in a formal CM process. As part of the CMP, system documentation can easily be checked to verify whether the designed configuration allows the system to achieve its objective. For example, if an information system design needs to be modified to implement a more stringent password policy for users, it could be determined that this change must be included in a planned update. Prior to the new version’s implementation, all changes should be documented to ensure that version control is maintained.
The configuration is verified against the initial baseline ensuring that all changes have been maintained and documented for any new parties involved in the CM process. Information on the system, including the manufacturer, model type, and software version, is recorded and tracked, ensuring access to the most recent system information.
When should you develop a CMP?
Ideally, you would create your CMP at the beginning of the system life cycle (SLC). This ensures that a CM process has been established to control, track, and maintain all changes that are made to the information system throughout the SLC. Your CMP should be a living document and be reviewed and updated as needed – at least annually.
It is possible to develop a CMP after your information system has already been deployed. In this case, you should maximize the re-use of existing system documentation (i.e. system security plan, system configuration documents, system maintenance records, vendor manuals, system configuration diagrams, and security-related information) in the development of the CMP.
Ongoing security control verification
Organizations should rely on the configuration management process, the most recent assessments, the results of previous security validation tests, and knowledge of the organization’s operational requirements – all of which may influence the selection of security controls to be monitored and the frequency of the monitoring process. Top priority for control monitoring should be directed at those security controls that have the greatest potential for change after implementation, have the highest criticality for the system’s security, or the controls that have been identified in the organization’s plan of action and milestones. Security control volatility is one measure of how frequently a control is likely to change over time after implementation.
For example, security policies and implementing procedures or the physical facility itself are not likely to change from one year to the next and thus might be considered security controls with low volatility. Access control mechanisms, intrusion detection mechanisms, or other technical security controls that are subject to the effects of frequent changes in hardware, software, and/or firmware components may be considered security controls with high volatility.
In most cases, organizations will likely choose to apply greater resources or pay additional attention to security controls deemed to be of higher volatility, and there may be a higher return on investment for assessing controls of this type. Security controls identified in the POA&M may also be a top priority in the continuous monitoring process, since these controls have been deemed to be ineffective to some degree (or in the worst case, non-existent).
In summary, organizations must make informed judgments regarding the application of their limited resources when conducting continuous monitoring activities. There is a responsibility to ensure that security expenditures are consistent with the organization’s mission and other requirements.
CONDUCT the annual review and security reporting
The results of continuous monitoring should be reported to the authorizing official and senior agency information security officer regularly or as needed. The continuous monitoring results should also be considered when identifying possible updates to the information system security requirements or the plan of action and milestones. This is important since the authorizing official, senior agency information security officer, information system owner, and security assessor may be using these plans to guide future security assessment activities.
The Federal Information Security Management Act (FISMA) (section 3544(b)(5)) requires each agency to perform “periodic testing and evaluation of the effectiveness of information security policies, procedures, and practices, to be performed with a frequency depending on risk, but no less than annually” for all of their information systems. This review includes the testing of all of the management, operational and technical security controls.
Not less than annually, the program manager/system owner and/or the ISSM will provide a written statement to the authorizing official, based on the review of all of the security controls for continued compliance. Annual security control reviews can consist of one or a combination of: performing security self-assessments, formal security tests and evaluation (ST&E), vulnerability testing, management directed audits, and any continuous monitoring such as intrusion detection.
Consistently, audits of federal agencies highlight deficiencies in this area. Specifically, the annual review of the security controls was often found to be inadequately conducted, and annual self-assessments of security controls were not always completed. In addition, testing itself was sometimes inadequate or conclusions reached did not always reflect the actual status of the control environment. Without adequate security control testing, audits found that management lacked assurance that security controls were operating as intended.
Even when using a self-assessment to review the security controls, you should not rely only on discussions of controls, instead of physically verifying their effectiveness. While this approach may be sufficient for low-risk systems, it certainly does not provide adequate assurance that security controls are correctly implemented and operating as intended on systems with higher risk, such as the financial and SCADA systems.
In some of the organizations we have supported, there were occasionally discrepancies between the certification agent’s assessment and the actual security documentation for the systems reviewed. NIST guidance, such as the NIST SP 800-53A, can be used to perform a self-assessment consisting of a table-top exercise, but the results of the assessment should contain explanations as to how the assessment team arrived at its conclusions and which of the system security controls were examined.
We receive a lot of questions about the annual review requirements: how should it be done, are all security controls subject to testing, who should execute the review, and what annual review determinations can be made?
The following activities should be conducted as part of the annual security control testing:
Direct the system developer/maintainer and the component ISSO/SSO to identify a sub-set of internal controls to test annually. The object is to validate each of the controls at least once every three years using standard testing procedures and techniques.
Ensure the testing is conducted.
Submit information regarding any findings in the quarterly POA&M update.
The depth and breadth of an annual system review depends on several factors, such as:
the potential risk and magnitude of harm to the system or data;
changes in the information system or its operating environment;
the relative comprehensiveness of the most recent past review; and,
the success of the remediation of system security weaknesses identified in the POA&M for that information system.
For example, if a system recently underwent a successful authorization process – including a security controls assessment – then a relatively simple update or maintenance review may be sufficient, provided that the original security assessment results and the POA&M have been adequately documented.
As a result of the annual review and the status of the security controls, the agency can make several possible determinations for action:
There is no change in the authorization status, no corrective action is required, and the system can remain in operation to the authorization termination date.
There is no change in the authorization status, the system owner/PM is directed to initiate security improvements, and the system can remain in operation to the authorization termination date.
The authorization status is downgraded to an interim authority to operate, the system owner/PM is directed to either develop a POA&M or amend an existing POA&M, and the authorization to operate is set to 180 days or less pending weakness remediation.
The authorization status is downgraded to a denial to operate and the system operation is halted pending weakness remediation.
MAINTAIN the authorization
Current federal and DOD regulations mandate that systems be re-authorized every three years – also called the authorization termination date (ATD) – or when significant changes are made to the system configuration. Program managers and system owners should establish a process to monitor system re-authorization dates.
If the system is not significantly altered, the system owner can begin the process for re-authorization in a timely fashion. With good planning, the process can be complete before the three-year anniversary of the system accreditation has passed.
Potential changes in accreditation status can also be triggered by the annual reviews, as well as the scheduled termination of an authorization, and changes to the system security status may be event-driven. An authorizing official may downgrade or revoke an accreditation decision any time risk conditions or concerns so warrant.
Certain events may also prompt a requirement for re-authorization. In this case, the level of effort required for re-certification and re-authorization can depend on the scope of the change and the degree to which the security control compliance status has been maintained.
The re-authorization process may require the organization to execute many of the same steps needed for the original authorization; however, organizations should seek to maximize re-use of any portions of the security documentation that remains valid.
Below are examples of events that might precipitate a system re-authorization.
A change in criticality or sensitivity level of the information processed.
A breach of security or violation of system integrity that reveals a significant flaw in security design, system security management, policy, or procedure.
A change in the threat environment impacting overall system risk.
A change in the system security mode of operation.
A change in the operating system, security software, or hardware that affects the authorized security countermeasure implementation.
Milestones from the operate and maintain activities
Before proceeding to the next phase, the remove the information system from operation activities, let’s take a final look at what you should have achieved in this phase:
You have established a process for continuous monitoring.
A configuration management process is in place.
A sub-set of the security controls has been selected for the annual review.
The annual review is being conducted and the results are documented in the SSP and POA&M as required.
Quarterly and annual FISMA reports are being prepared as required by law and the agency.
The authorization to operate is maintained, unless a re-authorization is required.
References
ISO10007:2003, Quality Management Systems – Guidelines for Configuration Management. International Organization for Standardization, June 2003.
ISO/IEC 27001:2005, Information technology – Security techniques – Information security management systems – Requirements. International Organization for Standardization, October 2005.