The system description

First you will want to get a system description. At a minimum the system description should include:

Network and dataflow diagrams

Next gather a set of diagrams that describe the agency’s networks or systems as a whole – hopefully an enterprise diagram or organizational network diagram. Usually the CIO or CIO’s office completes a network diagram of the agency’s system assets. Depending on the size, complexity, and locations of the agency’s systems this could be one or multiple drawings. It could also include more than network drawings, but system data-flow, and data center physical layout diagrams.

If you are working with an information system with a specific mission function (many times referred to as major application or minor application), it is critical that you obtain or develop a data flow diagram. The data flow diagram provides an architectural view of the systems, how they interact, and the graphical representation of how data flows from component to component of the system. This will provide a graphical representation of the software and systems functions.

These diagrams will allow you to do a few things. First, you will be able to better assess the common controls you will be able to inherit for your system (you may also be given a completed common control SSP). This will help us throughout the process as we decide what controls to implement and monitor. Next, you will be able to more easily establish managerial, physical, and logical boundaries around your system.

The federal C&A process allows for great flexibility in the process of setting security authorization boundaries, so we are not required to physically and logically delineate our systems – although we have found it to be easier to manage the systems and security by doing so.

The system inventory

The next set of information you will need is a system inventory. The system inventory should include a comprehensive list of all firmware, hardware, and software. At a minimum for all firmware, hardware, and software you should include:

It is possible that the system is in the initiation or early stages of development and you have not acquired any firmware, software, or hardware. This is not a problem, but you should still be able to describe the components based on what tasks the components will perform. For example, you may not be able to give the actual technology that will be used to implement a web solution you are developing, such as Microsoft^® IIS. However, you should be able to identify that you will be using a web server. You should document this information so that you will be able to more easily identify the technology-specific security requirements later.

Now that we have a base understanding of the system, we can set the authorization boundary. The authorization boundary should be based on the following criteria:

Step 1: Categorizing the information system

Once you have established the authorization boundary and ensured you have selected the proper accreditation vehicle, the next step is to categorize the information system. To do this, you will need to know what type of information/data will be stored, processed, transmitted, reviewed, disseminated, and managed by the system.

It is also very important to understand the information system’s current or future mission. You will use the information/data types and mission to derive the security categorization using NIST Special Publication 800-60 and FIPS 199 as your guides.

To support the analysis, it is useful to collect the following documents before conducting the security categorization:

The security categorization is a fairly straightforward process if you have enough information to perform the security categorization analysis. The security categorization analysis is also a very important step that will determine the baseline controls for your information system going forward. To determine the baseline controls, you will use NIST Special Publication 800-60.

NIST Special Publication 800-60 provides the mission-based, management, and support information types used as the foundation for assigning appropriate FIPS 199 impact levels. The FIPS 199 impact levels are based on the security objectives for confidentiality, integrity, and availability. FIPS 199 impact levels will be used to establish the actual security categorization, and correspondingly, the baseline control requirements. NIST Special Publication 800-60 is broken down into two volumes:

Volume I outlines the step by step process of categorizing an information system and Volume II provides all of the information types and recommended categorizations. Let’s look at the process for properly categorizing an information system.

Before we begin, remember that you will only be performing the categorization on the information/data that is processed, transmitted, stored, disseminated, reviewed, or managed by the system you are analyzing. The rule of thumb is that you will never evaluate any information or data types outside your systems authorization boundary.

Federal Information Processing Standard (FIPS) 199 requires organizations to categorize their information systems as low-impact, moderate-impact, or high-impact for the security objectives of confidentiality, integrity, and availability. The potential impact values assigned to the respective security objectives are the highest values (i.e. high water mark) from among the security categories that have been determined for each type of information resident on those information systems.

The generalized format for expressing the security category (SC) of an information system is:

SC information system = {(confidentiality, impact), (integrity, impact), (availability, impact)},

where the acceptable values for potential impact are low, moderate, or high.

Since the potential impact values for confidentiality, integrity, and availability may not always be the same for a particular information system, the high water mark concept is used to determine the impact level of the information system for the express purpose of selecting an initial set of security controls from one of the three security control baselines. Thus, a low-impact system is defined as an information system in which all three of the security objectives are low. A moderate-impact system is an information system in which at least one of the security objectives is moderate and no security objective is greater than moderate. And finally, a high-impact system is an information system in which at least one security objective is high.

Once we have completed the security categorization we can move onto the next steps of registering the information system and selecting the security controls.

Step 2: Registering the information system

Registering the information system is the process of officially identifying and entering the information system in the system inventory. It establishes a relationship between the information system undergoing security authorization and the parent or governing organization that owns, manages, and/or controls the system. It is usually performed by the information system owner.

Registration of the information system requires that you have:

Registration, either formal or informal in accordance with organizational policy, uses information in the system identification section of the security plan to inform the parent or governing organization of:

Information system registration provides organizations with an effective management and tracking tool for security status reporting in accordance with the requirements of FISMA and OMB policy. Registration is also essentially the kickoff of the authorization process. It allows all stakeholders, including the information security engineering team, to start planning on providing information systems security engineering (ISSE) support throughout the information system’s development life cycle (SDLC).

Implementation tip: System registration is different in every federal agency (or DOD component). Sometimes it is executed completely outside the security program and performed as part of an information systems acquisition. It can also be tracked through the federal capital planning and investment control process (CPIC).

In most cases, the information system will be assigned a unique identifier during the registration process or it may reuse the OMB-300 number assigned to the system. Often, the registration process requires you to use an organizationally specific workflow tool and requires the system owner to submit the system through the change control board (CCB).

Step 3: Selecting the security controls

After the security categorization process and system registration is completed, the list of appropriate baseline security controls can be specified for each information system. Selection of security controls for an information system is one of the most important tasks in the authorization and security engineering process. The security control selection process, as described in NIST Special Publication 800-53, consists of three activities:

The following figure depicts the security control selection process.

Security controls are typically characterized as system-specific, common, or hybrid (combination of system-specific and common).

System-specific controls are usually under the direct control of individual information system owners and their associated authorizing officials. They are generally not inherited as common controls, but are the specific technical, operational, and managerial implementations unique to the information system. Frequently, system-specific controls are technical in nature and are implemented at the system level. For example, you may have a common control (e.g. a policy) that requires your system to uniquely identify and authorize each user. In order to meet this requirement, your system uses a pin and biometric device to authenticate the users. The implementation of the common control policy would be the system-specific control.

Organizations may also assign a hybrid status to security controls in situations where one part of the control is deemed to be common, while another part of the control is deemed to be system-specific. For example, an organization may view the IR-1 (Incident Response policy and procedures) security control as a hybrid control, with the policy portion of the control determined to be common and the procedures portion of the control deemed to be system-specific. In another example, a hybrid control would implement the CP-2 (contingency planning) security control as a master template for a generalized contingency plan for all organizational information systems with individual information system owners tailoring the plan, where appropriate, for system-specific issues.

Many of the security controls needed to protect an information system (e.g. contingency planning controls, incident response controls, security training and awareness controls, personnel security controls, physical and environmental protection controls, and intrusion detection controls) may be excellent candidates for common security control status. By centrally managing the development, implementation, and assessment of the common security controls designated by the organization, security costs can be amortized across multiple information systems. When it comes to common controls the organization is responsible for:

The identification of common security controls should be an organization-wide activity and should consider the totality of the organization’s mission/business processes and the information systems supporting those processes. For each of the security control baselines defined in Special Publication 800-53 (low, moderate, and high impact), organizations should determine which security controls in each of the baselines are to be designated as common controls. The organization assigns responsibility for the development, implementation, and assessment of the selected common controls to specific organizational entities. The ultimate objective of the organization is to have accountability for every security control supporting the organization-wide protection strategy.

Since common security controls can provide protection for multiple information systems at different FIPS 199 impact levels, it is important for organizations to consider the most appropriate and cost-effective impact level for the common controls to be deployed to best accommodate the information systems using the controls. If the organization chooses to implement common controls at an impact level that falls below the highest impact levels required for individual information systems, then the system owners and authorizing officials for those systems should take appropriate actions to supplement those controls as required for any protection deficits that result at the system level.

If over 70% of your organization’s systems are rated moderate or below, it may also be cost effective to develop a separate physical and logical network for your higher categorized assets. For example, if your organization has a primary operations data center and a backup operations data center, it may be more cost effective to build separate rooms with separate logical connections to the rooms for those systems. This will allow your organization to implement more stringent logical, physical, and personnel controls without having to make major investments to protect your less important or lower categorized systems.

It is also important to tailor and supplement the control baseline based on your organization’s mission. In many cases, additional security controls or control enhancements will be needed to address specific threats to and vulnerabilities in information systems or to satisfy the requirements of applicable laws, executive orders, directives, policies, standards, or regulations.

Risk assessments at this stage in the security control selection process provide important inputs to determine the sufficiency of the security controls in the tailored baselines – that is, the security controls needed to adequately protect organizational operations and assets, individuals, other organizations, and the nation.

Documenting an organization’s protection strategy begins with the enterprise architecture description and the results of the security categorization process for the information and information systems supporting organizational mission/business processes. The security controls allocated to individual information systems and to the supporting infrastructure are documented in the respective security plans as described in NIST Special Publication 800-18.

Security plans provide an overview of the security requirements for the information systems and supporting infrastructure within an organization and describe the security controls in place or planned for meeting those requirements. The plans also describe the rationale for security categorization, tailoring, and supplementation activities, how individual controls are implemented within specific operational environments, and any use restrictions to be enforced on information systems due to high-risk situations.

Security plans provide a description of the risk mitigations that are deemed necessary to reflect the information system trustworthiness which is required to help ensure mission and business success. They are important because the plans document the decisions taken during the security control selection process and the rationale for those decisions. Security plans should be approved by the appropriate authorizing officials within the organization, since they are one of the key documents in security accreditation packages that are instrumental in authorization decisions.

Step 4: Implementing the security controls

Implementing security controls is the point where the information systems security engineering (ISSE) process is aligned with the respective phase of the SDLC. The earlier the information system is in the SDLC, the number of controls you will be able to implement will be limited by the maturity of the system. However, you should be considering the requirements for the later implementation of controls even at this early date.

If you are in the initiation stage of the SLDC, you should be designing many of the controls into your system architecture. You should use your system security plan (SSP) to assign planned controls along with dates based on your proposed operations schedule.

As you get closer to the full operation and authorization of the information system (and or continued maintenance on an existing information system), you will need to implement many more operational and managerial controls, such as patching, personnel training, personal background investigations for users (this may also be a common control). By the time your system is ready for the independent testing all controls will have been “baked into the solution” and you will have adequate documentation to backup the design and implementation.

As you implement the security controls, you should remember a few important things:

Once you have completed the implementation of all of the required managerial, operational, and technical controls to the information system, ensure you complete an internal functional quality and security test of the information system and all of the security controls. Document any findings in both your SSP and create a plan of action and milestones (POA&M) for any security controls that are not in place or working as planned.

Step 5: Identify and select the independent security control assessor (assessment team)

The authorizing official (AO) must select a security control assessor that will be independent and impartial in regards to the system development or operation. Often, organizations have a list of approved assessors (internal or external) that are not currently providing system development or operational support to the agencies’ systems.

When selecting an assessor you should look for some of the following criteria:

In small organizations with limited budgets that cannot afford to use a completely independent assessor, the AO should assign separate teams to implement and to carefully review each control together with a government official, such as the ISO. They may also choose to assign one or two individuals to perform independent verification and validation (IV&V) of selected security controls.

Step 6: Develop the security control assessment plan

The security assessor or team should develop a security assessment plan for each engagement. The following items should be considered by assessors in developing plans to assess the security controls in information systems:

Some of the actions you should take in developing the security control assessment plan include:

Step 7: Prepare for the test

After the test plan is approved, your next step should be a formal kickoff meeting with the system stakeholders. This is also where you should request any outstanding documentation that you may have not been given at this point. At a minimum you should ask for:

Step 8: Conduct the security controls assessment test

At this point, you should have a good idea how the actual testing is going to take place based on your test plan, meetings, and any information provided by the system stakeholders. However, here are with some things to remember to do a few days before the actual SCA test:

What follows is a list of some of the things to remember before you arrive onsite for the SCA test:

Remember that the controls assessment is used to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for the information system. The assessor’s job is to help the authorizing official make a truly risk-based authorization decision on the information system being assessed using unbiased, factual reporting.

You are there to help in the authorization process, not hinder the operational mission of the organization. Ensure you provide specific recommendations on how to correct weaknesses or deficiencies in the controls and reduce or eliminate identified vulnerabilities as you proceed through the assessment. Speak with technical POCs and provide suggestions on how they can fix, remediate, and mitigate issues found.

After the test is completed, it is important to provide a high-level report to the stakeholders on any issues, findings, and recommendations from the security control assessment. This should be done in the same or a similar format that you will use for the final assessment report. It is also useful to develop and deliver an executive out-brief in the form of a handout or slideshow. We usually do this prior to sending the final report – there is not as much confusion and it also allows the stakeholders to provide any last minute information that might be needed in the final report.

Step 9: Update the system security plan

Now that the assessment is complete, the security plan should be updated to reflect the actual state of the security controls. Particularly when the plan was developed early in the life cycle, the system owner or whoever completed the SSP may have believed the system met or exceeded certain control requirements. After completion of the test, however, this may no longer be true. As a result, the SSP should contain an accurate list and description of the security controls implemented (including compensating/ supplemental controls) and a list of identified vulnerabilities (i.e. security controls not implemented or not implemented correctly).

Step 10: Develop the POA&M

The POA&M describes the specific measures that are planned to correct any weaknesses or deficiencies in the security controls noted during the security control assessment and to address the remaining known vulnerabilities in the information system.

The actual POA&M document identifies:

It is also possible that the POA&M includes information on the type of POA&M (such as enterprise or system-specific), the level of risk, any ongoing maintenance costs related to the POA&M, who discovered the weakness, and comments related to the POA&M.

Step 11: Security authorization decision

Now that the SSP has been updated to reflect the results of the final security assessment report (SAR) from the SCA test and a current POA&M has been developed, you now have the documents required for a complete authorization package. This package will be sent forward to the AO for an authorization decision.

The AO’s risk based authorization decision should be based on the content of the security authorization package as it relates to:

The AO’s decision will result in the development of an authorization decision document. The authorization decision document contains the following information:

The security authorization decision indicates to the information system owner whether the system is:

The terms and conditions for the authorization provide a description of any specific limitations or restrictions placed on the operation of the information system that must be followed by the system owner.

Step 12: Continuous monitoring and ongoing risk acceptance

Once a system has been authorized for operation, it now needs to be entered into the organization’s continuous monitoring program. This allows an organization to maintain the security authorization of an information system over time in a highly dynamic environment of operation with changing threats, vulnerabilities, technologies, and mission/business processes.

Continuous monitoring of security controls should take advantage of automated support tools to facilitate near real-time risk management for information systems. An effective continuous monitoring program includes:

We cannot stress how important the use of strict configuration management and control processes are to the continuous monitoring of your systems. In order for continuous monitoring to work, you need to become situationally aware of your systems and environment. Although automated tools can make this process much easier to manage, nothing replaces a strong and strictly enforced configuration management process. You need to know when and what changes are happening to your environment on an ongoing basis. If you are aware of changes going on in your environment, you can properly perform security impact analysis of these changes.

Your organization should develop a change control board (CCB) if one does not already exist. Both the authorizing official and the security team play an important role in the CCB and should have voting roles. You can also use the CCB to provide the system owner with guidance on updating security authorization packages or when a change is significant enough to require the system to undergo a new authorization process.

Step 13: Decommissioning the information system

This is the last step in the authorization process for information systems in federal agencies. At the end of an information system’s life, it is very important to properly decommission the system. Decommissioning an information system allows you to formally remove the system registration from the organization’s inventory or registration system.

Some things you should remember when decommissioning your system: