CHAPTER 6:
PLAN, INITIATE AND IMPLEMENT AUTHORIZATION – PREPARING FOR AUTHORIZATION
There are no secrets to success. It is the result of preparation, hard work, and learning from failure62 .
Colin Powell, Former Secretary of State
In this chapter:
Understanding the information and the information system
Registering the information system
Negotiating the authorization approach
Implementing the security controls
While many may have a different opinion, we believe that this phase is one of the most important – and challenging – parts of the actual authorization process. That doesn’t mean that all the activities done up to this point are unimportant. They are extremely critical, since they provide the overall structure that supports the authorization process.
But here is where the rubber meets the road, at least in terms of actually certifying and accrediting an information system. If the activities in this phase are done correctly, you should breeze through the actual accreditation decision and be able to maintain an information system security environment during system operation. Done inadequately, you may have a significant amount of re-work and considerably more expense.
Process 1 or plan, initiate, and implement authorization, begins with acquiring or developing the information necessary to understand the information system and to use that information to prepare for the authorization activities to follow. You should use this information to scope the level of effort (LOE) required to certify and accredit the information system. The LOE can vary with the scale of the information system – from a simple standalone, a large data center running dozens of applications on varied platforms, to a complex, multilevel secure network.
So what, exactly, are the steps you will be following in this phase? Take a look at the following diagram. Each of these steps will be discussed in detail.
Figure 8: C&A process 1
UNDERSTAND the information and the information system
Regardless of where the information system is on the system life cycle continuum, understanding the system and its information is the first and most basic requirement. Based on this understanding, you can determine the certification and accreditation actions, such as:
Scope and level of effort
Documentation
Plan and schedule
Cost
System security categorization.
Who is involved?
The primary responsibility for providing the content necessary to understand and characterize the information system and the information is the information system owner, or in the case of developmental systems and certain operational systems, the program manager (PM). The information system owner/PM will recognize that an information system requires an authorization to operate.
Direct supporting roles in Step 1 include the designated accrediting authority/ authorizing official (DAA/AO), the information assurance manager/ information system security manager (IAM/ISSM), the information owner, the certifying authority (CA) and potentially, the senior information assurance officer (SIASO).
The DAA/AO should be informed that an information system is entering into the authorization process.
The IAM/ISSM will be primarily involved in assembling the documentation and starting the process for organizing and planning the authorization effort together with the information system owner/PM.
The information owner will be able to provide critical information about the sensitivity and criticality of the information to be processed by the information system.
The CA should be notified early, since he/she can assist in establishing the level of effort and also assist in understanding the information system and its security safeguard requirements.
The SIASO represents leadership, provides funding and facilitates access to resources.
Other indirect supporting roles include the risk executive, system and/or network administration staff, contracting officials, facilities personnel, and staff in other security disciplines, such as physical and personnel security.
Scope and level of effort
While the authorization process itself remains essentially the same for any information system, the skills needed to perform the authorization, where to focus the implementation and testing, and supporting documentation may vary substantially.
The scope and level of effort required for certification and accreditation of an information system is determined by analyzing the system’s mission, information, and availability as follows:
Criticality to the responsible organization’s mission.
Sensitivity as related to confidentiality, integrity, and availability of system information.
It is a reasonable assumption that the more critical an information system is to the organization and the more sensitive the information, the more secure the information system should be. More security generally means a greater level of effort – for design, development, implementation of security controls, and for the authorization process itself.
Authorization should be integrated into the overall information system development effort as seamlessly as possible. The closer the integration into the SLC, the lower the potential level of effort and associated costs will be for authorization.
Information obtained from documentation
In this case, documentation doesn’t refer to the authorization documentation itself. It refers to the data that the authorization team collects as part of understanding the system and preparing for the authorization effort. The type and detail of the available documentation may vary depending on the stage of the information system life cycle.
Information about the information system is typically documented in the system identification section of the systems security plan (SSP), which we will discuss in more detail later, included in attachments to the SSP63 or referenced in other standard documents generated as part of the SLC. Preparation of the SSP will be discussed in detail in Chapter 10 and templates are available on the accompanying CD.
Currently, the SSP is used only in federal agencies, the Intelligence Community and for special systems. DOD uses the system identification profile (SIP) and the DIACAP implementation plan (DIP) in lieu of the SSP. These will be described in the chapter on C&A in the US DOD.
Developmental systems
As soon as possible in the life cycle of an information system, the security classification, information sensitivity, security access considerations, and the confidentiality, integrity, and availability requirements of the information system should be determined. This information should be available in documents such as:
Systems requirements specifications (SRS)
Mission needs statement (MNS)
Operational requirements document (ORD)
System concept of operations (CONOPS)
Initial capabilities document (ICD)
Capabilities development document (CDD)
Capabilities production document (CPD)
System threat analysis.
63 Since much of the information required in the SSP exists in other documents, it is often sufficient to reference the original document rather duplicate the content in the SSP.
Operational systems
If the information system is already operational, it may already have been accredited – whether under the rescinded DITSCAP or through the earlier federal process under NIST SP 800-37. In this case, there will already be a large amount of documentation that can be reviewed and potentially reused. Other information that can be useful in understanding the operational information system includes:
Federal and organizational security instructions and policies
Configuration management documents
System capabilities
System architecture and network diagrams
User manuals
Risk assessment
Physical security procedures
Personnel security procedures
Operating procedures
Interconnectivity and data flow
Level of sensitivity and type of information processed
Services provided
Operations supported
Organizational mission statement.
Plan and schedule
A detailed schedule and plan will assist you in keeping the authorization project on track. It should highlight the big picture and identify executable milestones, tasks and deliverables. If the information system is still in development, it also helps to consider general project information such as estimated costs, key personnel, milestones, specific tasks and deliverables, responsible individuals or offices for each task and deliverable, as well as targeted and actual, completion dates for the overall project.
The overall system development project schedule can also provide insight into changes in costs and resource allocation. This will help to adjust the authorization plan to periods when you may not be able to totally control timelines due to tasks external to the authorization effort, such as developmental testing or debugging.
The authorization schedule itself will work best if it is drafted in as much detail as possible during the very early stages. This notifies key participants about specific activities and may influence the make-up of the authorization team.
The schedule should be reviewed and updated by the authorization team throughout the authorization project. The benefits beyond the obvious ones of monitoring progress and keeping the authorization project on track, is that a completed schedule can also serve as a tool for developing the level of effort and costs for the authorization project.
Cost
Don’t forget to consider the costs for authorization early in any information system project. Let’s look at a lesson learned from one information system project.
An aerospace company contracted for the development of a complex command and control system. In the concept phase, they developed end-to-end scenarios for performance and target capability.
They then used these end-to-end scenarios as the basis for developing and fielding the information system. Their structured development practices enabled them to deliver the system on-time and within budget. However, their planning included all of the engineering, but NOT the authorization costs.
This became very significant, since the information system could not become operational until authorization was completed. Authorization became an unfunded requirement for the system, including those costs related to security controls implementation and authorization testing. The funding for re-engineering the security portion of the information system and conducting the authorization was taken from management reserves and profit – to the order of $15 million. If all of the authorization requirements had been considered from the beginning, the engineers estimated that the cost would have been approximately 1/10th.
The lesson learned here is that the cost for authorization should be calculated into the budget from the system development and design stage.
System security categorization for information
System security categorization for the information processed by the information system is a prerequisite for initiating and executing the authorization process. Security categorization provides the basis for determining the level of security required for the information system based on the need for confidentiality, integrity, and availability. It will also identify additional protections that may be needed (i.e. privacy and critical infrastructure protection (CIP)). Thus, it assists in determining authorization scope, level of effort and schedule.
Traditionally, NIST, DOD, and the Intelligence Community (IC) have had different ways to express the system security categorization. DOD refers to mission assurance category (MAC) – a combination of availability and integrity – and confidentiality level (CL), which refers to the information sensitivity/classification.
The IC looks at protection levels (PL), which are associated with the confidentiality requirements for the information based on classification and levels of personnel clearance and access, and level of concern (LOC) for availability and integrity.
NIST focuses on the level of impact, which was assigned as high, moderate or low based on an assessment of the needs of the information system for confidentiality, integrity and availability.
One thing should become immediately clear: despite the differences in nomenclature used by each sector, system security requirements are based on the requirements of the information and the information system for confidentiality, integrity, and availability.
To be consistent with the majority of users within the federal government, we will refer to the processes in the NIST Special Publication 800-60, Volume I: Guide to Mapping Types of Information and Information Systems to Security Categories, August 2008. This special publication provides the instructions needed to comply with the Federal Information Processing Standard (FIPS) 199 process for determining system security categorization. FIPS 199 establishes security categories for both information and information systems. The security categories are based on the potential impact to the information and/or an information system and the organization should the system be compromised.
The following table illustrates the NIST SP 800-60, Volume I, process roadmap for determining and assigning the security category and using this to identify the security controls essential to protect the information system and its information. This process assumes that the information system has already been categorized by type, life cycle status, and accreditation boundary (described in Chapter 5) in sufficient detail to initiate the information analysis.
Table 15: Process roadmap
|
Process |
Activities |
Roles |
|
Input: information system identification (described in Chapter 5) |
Type of information system (e.g. general support system, major application, or even outsourced or platform IT). Life cycle status (e.g. concept, design, development, deployment, operation, or removal from the inventory). Accreditation boundary (e.g. identification of responsible DAA). |
CIO, PM, system owner |
|
Subtask 1: identify information type(s) |
Determine business and mission area(s). Identify all of the information processed by the information system(s). Document the information types. |
Information owner, PM, IAM |
|
Subtask 2: select initial impact level |
Determine the security category based on the requirement for confidentiality, integrity, and availability based on FIPS 199 criteria. Document the initial impact level. |
Information owner, IAM or IAO |
|
Subtask 3: review initial impact level |
Review the initial impact level based on consideration of mission, environment, system use, legal requirements, and interconnection. Adjust as required. Document the adjusted impact level. |
CIO, SIASO, PM, information owner |
|
Subtask 4: assign system security category |
Determine system security category based on the high water mark for confidentiality, integrity, and availability. Assign the overall information system impact level. Document the system security category. |
CIO, SIASO, IAM or IAO, information owner |
|
Output: final security categorization |
Used to determine the necessary security controls required to effectively protect the information and the information system. Use standardized security controls available in the respective security control catalogs. |
CIO, IAM or IAO, AO, developers, SMEs |
Subtask 1: Identify the information type(s)
The first step in this process is to identify all of the applicable information types transmitted, stored, or processed on the information system. The basis for the identification of information types is Office of Management and Budget’s (OMB) Business Reference Model (BRM) described in the October 2007 publication, Federal Enterprise Architecture (FEA) Consolidated Reference Model Document, Version 2.3.
The BRM reference model is translated into information types in NIST SP 800-60, Volume I, which is used in tandem with NIST SP 800-60, Volume II: Appendices to Guide to Mapping Types of Information and Information Systems to Security Categories, August 2008.64 NIST SP 800-60, Volume II, categorizes the specific information types in the federal government and provides a methodology for identifying these information types and assigning provisional security impact levels. While these information types and the associated processes described here focus on the federal government and its information, these same documents can also guide other, non-government organizations in defining their own information types.
NIST SP 800-60, Volume I, organizes federal information into two broad categories: mission-based information types and management and support information types. The information system owner is responsible for identifying to the authorization team the information types stored in, processed by, transmitted by, or generated by an information system.
64 It is important to note that NIST SP 800-60 does not cover information processed by National Security Systems. The guidelines for categorizing this information will be a future issue as part of the authorization transformation.
Mission-based information types are, by definition, specific to individual government agencies or to specific sets of government agencies and focus on services for citizens. The approach to establishing mission-based information types at an agency level begins by determining the agency’s primary business and mission areas.
In the case of mission-based information, the responsible individuals, in coordination with management, operational, and security stakeholders, should compile a comprehensive set of lines of business and mission areas conducted by the agency. In addition, the responsible individuals should identify all of the applicable sub-functions necessary to conduct agency business and accomplish the agency’s mission.
There are 26 information mission areas sub-divided into 98 supported information types. Details on each of these information types are provided in Volume II, Appendix D, Examples of Impact Determination for Mission-based Information and Information Systems.
For example, mission area 16 is applicable when law enforcement is the agency’s primary mission. Sub-functions of the law enforcement mission might include criminal investigation and surveillance, criminal apprehension and incarceration, citizen protection, crime prevention, and property protection. Each of these sub-functions would represent an information type.
A lot of federal government information and associated supporting information systems are not employed directly to provide direct mission-based services, but are primarily intended to support delivery of services or to manage resources.
The management and support information types are composed of 13 lines of business subdivided into 72 sub-functions.
The service support functions focus on the day-to-day activities that provide the critical policy, programmatic, and managerial activities that are essential to federal government operations. The direct service missions and constituencies that are ultimately supported by the service support functions are significant in determining the security impacts associated with the compromise of information associated with the delivery of services.
The management and support information types also include those back office support activities which enable the federal government to function effectively. There are five government resource management information lines of business and sub-functions associated with each.
Many federal agencies have their own internal support systems. Others may obtain some of their support services from other organizations. As a result, there are some agencies whose mission is to primarily support other federal agencies in the conduct of their direct service missions.
Other information types not identified in the guidelines: It is likely that NIST SP 800-60, Volumes I and II, cannot list all of the information types associated with the functions of the federal government. Organizations that identify information that cannot be directly associated with any of these information types are still able to use the guidelines to develop provisional impact levels for their unique information types.
Subtask 2: Select the provisional or initial impact level
Once the information type has been identified, the organization has established the foundation for determining the provisional or initial impact level. The provisional impact level refers to the level assigned to the information based on the confidentiality, integrity, and availability security objectives of an information type derived from NIST SP 800-60, Volume II. This occurs prior to making any organizationally specific adjustments.
In step two, the initial security categorization for the information type is also established and documented. NIST SP 800-60, Volume II, Appendix C suggests provisional confidentiality, integrity, and availability impact levels for management and support information types, and Volume II, Appendix D provides examples of provisional impact level assignments for mission-based information types.
In those cases where an information type processed by an information system is not categorized by the NIST SP 800-60 guidelines, the organization will have to make its initial impact determination for each information type received by, processed in, stored in, and/or generated by each system for which they are responsible based on the FIPS 199 categorization criteria depicted in the table below. There are three factors that must be considered:
Confidentiality: Confidentiality of information is most frequently associated with its sensitivity or classification level. In most cases, information will be categorized for confidentiality purposes as public (open to anyone), sensitive (limited exposure of information, such as personal health information), or classified (confidential, secret, top secret). Without exception, the confidentiality level for classified information is considered high. Use the following questions to guide your determination:
• Would the loss of confidentiality of the information through an unauthorized or unintentional disclosure result in a limited, serious, or catastrophic effect on the organization?
• How could an unauthorized or unintentional disclosure resulting in the loss of confidentiality occur?
• Would an unauthorized or unintentional disclosure violate any laws, regulations, or policies?
Integrity: The loss of information integrity is most frequently associated with unauthorized (or unintentional) modification or destruction. An undetected loss of integrity has the potential for catastrophic results. These could be either direct (e.g. modification of a financial entry, medical alert, or criminal record) or indirect (e.g. facilitation of unauthorized access to sensitive or private information or denial of access to information or information system services). In most cases, the most catastrophic impact would occur on time-critical information, such as the information required in making a rapid battlefield decision.
Some results of an integrity loss could be: reduced public confidence in an organization, the creation of confusion or doubt about the quality of the information, or the intentional or unintentional influence upon a decision making official. Use the following questions to guide your determination:
• Would the unauthorized or unintentional modification or destruction of information result in a limited, serious or catastrophic effect on the organization?
• Would the unauthorized or unintentional modification or destruction of information violate any laws, regulations or policies?
Availability: For many information types and information systems, the availability impact level will depend on how long the information or the information system remains unavailable to authorized users. The undetected loss of availability can be catastrophic for many information types. For example, the permanent or even temporary unavailability of financial or resource management, contingency planning, security management, inventory control, or logistics management information could be serious, or even catastrophic, for almost any agency. Use the following questions to guide your determination:
• Would intentional or unintentional acts affecting information or information system availability result in a limited, serious, or catastrophic effect on the organization?
• Would intentional or unintentional acts affecting information or information system availability violate any laws, regulations or policies?
Using the questions above and the FIPS Publication 199 table, an organization can assign an initial impact level for confidentiality, integrity, and availability. For example, information on a public web server may be assigned a low confidentiality impact rating, a moderate integrity impact rating, and a high availability impact rating. Classified research and development information might be assigned a high confidentiality and integrity impact rating, but a low availability impact rating.
Table 16: FIPS Publication 199
This leads us to Step 3, which requires the organization to review and potentially adjust the provisional or initial impact ratings.
Subtask 3: Review the provisional/initial impact levels and adjust
In this step, organizations should review and adjust the initial impact levels for each information type and information system in order to arrive at a finalized statement of impact. This review should consider such items as the agency’s mission and its importance to national security or required government functions, system or policy life cycle implications, configuration and security policy related information, special handling requirements, environmental considerations, and any other organizationally-unique specifications.
It is important to consider the impact for an information or information system type throughout its life cycle. For example, contract information may have a moderate or even high confidentiality impact level during the life of the contract, but may have only a low impact level once the contract execution period is completed. Policy-related information may have moderate confidentiality and integrity impact levels during the policy development process, low confidentiality and moderate integrity impact levels during the policy implementation period, and low confidentiality and integrity impact levels once the policy has become obsolete.
Rarely do information systems process a single type of information, nor will all of the information types processed by an information system always have the same security impact levels. The compromise of some information types might cause more damage than the compromise of other information types within the same information system. As a result, system security impact levels must be assessed in the context of system mission and function, as well as on the basis of the aggregate of the component information types.
In addition to the mission-related information processed by the information system, the associated configuration and security policy enforcement information should also be considered in terms of impact level. Configuration and security policy information includes such things as password files, network access rules, hardware and software configuration settings, and documentation affecting access to or the integrity of the information system’s data, programs, and/or processes. At a minimum, a low confidentiality and integrity impact level will always apply to this set of information due to the potential for corruption, misuse, or abuse of system information and processes.
As mentioned earlier, classified information will always have a high confidentiality impact. However, there are also other types of information that may have a higher confidentiality impact level based on the organization’s mission. These include information types, such as Trade Secrets Act information, information protected by the Privacy Act, Department of Energy Safeguards Information, Internal Revenue Service Official Use Only Information, and Environmental Protection Agency Confidential Business Information.
Another consideration that might affect the impact level of information may be the existence of other, compensating security safeguards. For example, research and development information may be classified, but knowledge of and access to the information could be very strictly limited to only a highly select set of individuals. In this case, the integrity impact – and the associated security requirements – might be reduced to moderate based on the additional access restrictions.
Once all of these additional considerations are applied, the organization may adjust the impact levels for confidentiality, integrity, and availability to either a higher or lower level. Once the final impact levels are determined, the organization will proceed to step four: assigning the overall system security category.
Subtask 4: Assign system security category
The last step in this process is assigning the system security category based on the confidentiality, integrity, and availability impacts determined for the information or the information type aggregate. For federal agencies, the security category is the prerequisite for identifying and assigning the security controls, or the safeguards deemed essential to addressing the requirements of the information and the information system. The individual activities in step four include:
Review identified security categorizations for the information or the aggregate of information types.
Determine the system security categorization by identifying the high water mark for confidentiality, integrity and availability based on the aggregate of the information types.
Adjust the high water mark for each system security objective, as necessary, by applying the factors discussed in the section above.
Assign the overall information system impact level based on the highest impact level – or high water mark – for the system security objectives.
Document all security categorization determinations and decisions.
It is a well known fact that information systems consist of information and the software applications that allow that information to be processed, transmitted, and stored. These applications are essential for the information system to conduct its essential business functions and operations. These applications must also be protected and could be subject to security categorization as well. However, in the interest of simplification, federal agencies will provide at least a minimum categorization of low for the information system operations. This is necessary to protect the system-level processing functions and information critical to the operation of the information system itself.
According to FIPS 199, the general formula for determining the security category is:
Security category (SC) information type = {(CONFIDENTIALITY impact), (INTEGRITY impact), (AVAILABILITY impact)}, where the acceptable values for impact are LOW, MODERATE, HIGH, OR NOT APPLICABLE65.
Here are a few examples of how the assignment of information security category might work.
System 1: A public web server
A federal agency provides public information on a publicly accessible e-Government website. Since the information on the web server is public, there is no confidentiality impact associated with its loss or exposure. However, since the information is part of the agency’s public information project, a loss of integrity might be considered moderate. Availability is important, but not critical, so any impact to availability might also be considered moderate. Using the formula above, the security category for this information would be expressed as:
SC public information = {(CONFIDENTIALITY not applicable), (INTEGRITY moderate), (AVAILABILITY moderate)} where the high water mark for the overall security categorization = MODERATE
System 2: A financial organization
An agency processes highly sensitive financial information. Since this information also involves personal privacy information, a loss of confidentiality and integrity would be considered high. Availability of this information is important, but not necessarily critical, so the impact to availability might be considered moderate. Using the formula for security categorization, the security category for this information would be expressed as:
SC financial and personal information = {(CONFIDENTIALITY high), (INTEGRITY high), (AVAILABILITY moderate)} where the high water mark for the overall security categorization = HIGH
Determining the security category of an information system processing multiple types of information is often more difficult and requires additional analysis. For an information system, the overall security category for the information system will be based on the highest values for confidentiality, integrity, and availability that have been determined for each type of information resident on the information system. Here is an example:
System 3: A medical management system
An agency is responsible for processing information about medical care provided to a specific group of recipients. This information is personal and confidential and its integrity is essential to providing the correct medical care to its constituency. The agency also uses the information system to process routine administrative information associated with the day-to-day operations of the agency. The agency determines that for the patient information there is a high potential impact from the loss of confidentiality, integrity and availability. It also determines that for the agency’s administrative information, the impact of the loss of confidentiality, integrity, and availability are low. Using the formula for security categorization, the security category for this information would be expressed as:
SC patient information = {(CONFIDENTIALITY high), (INTEGRITY high), (AVAILABILITY high)}
SC administrative information = {(CONFIDENTIALITY low), (INTEGRITY low), (AVAILABILITY low)} where the high water mark for the overall security categorization = HIGH
In this case, the resulting security category for the information system using the high water mark would be expressed as:
SC medical management system = {(CONFIDENTIALITY high), (INTEGRITY high), (AVAILABILITY high)} where the high water mark for the overall security categorization = HIGH.
There are other factors that might influence the final assignment of system security category. These include factors such as: information aggregation, system interconnectivity, and extenuating circumstances.66
Information aggregation: In some cases, information may not be sensitive in isolation, but an aggregation of the information could reveal sensitive patterns and plans, or facilitate access to sensitive or critical systems. In general, the sensitivity of a given data element is more likely to be greater in a given context than in isolation (e.g. association of an account number with the identity of an individual and/or institution). The availability and sophistication of data aggregation and inference tools are all increasing rapidly, causing a different level of threat environment.
If a review of the information aggregation reveals increased sensitivity or criticality, then the system security impact levels might need to be adjusted to a higher level than necessary for a discrete
66 Extenuating circumstances might include an elevation in the threat environment or in the geographical location.
type of information. This could be explained in a statement that discusses the aggregation and how it affects the security category.
System interconnectivity: Impact of a compromise of the confidentiality, integrity, and availability of some information types may be low in the context of a system’s primary function, but may be much more significant when considered in the context of:
other systems to which the system is connected, or
other systems which are dependent on that system’s information.
Extenuating circumstances: There are times when a security category needs to be elevated based on reasons other than its information or the information system. Examples of extenuating circumstances include:
Increased visibility of the information system and its information.
An elevation in the threat environment, for example, an information system in a high threat area.
An extremely large number of other systems is reliant on its operation.
Additional notes on security category
It is important to note that the use of the high water mark for assigning a security category is unique to the process in NIST SP 800-37. The assignment of security category by this method is scheduled to change in NIST SP 800-37, Revision 1, which is currently in draft, and will be discussed in greater detail in Chapter 17.
In the Department of Defense, there is no equivalent to the process used by the federal agencies in assigning a security category. Although the current DOD process is detailed in Chapter 10, let’s have a quick overview here. The process for determining the confidentiality impact is similar – except that in the DOD, information is either public (equivalent to low), sensitive (equivalent to moderate), or classified, which is always high.
The primary difference, however, lies in the assignment of an impact level for availability and integrity. In the DOD, these are currently combined into the Mission Assurance Category (MAC) and the impact levels are assigned as below:
MAC I – information and information systems determined to be vital to the operational readiness or mission effectiveness. Any loss of integrity or availability is unacceptable. MAC I systems require the most stringent protection measures.
MAC II – information and information systems important to the support of the operational readiness or mission. Loss of integrity is unacceptable; loss of availability would be difficult and tolerated only for a short period of time.
MAC III – information and information systems handling information necessary for the conduct of day-to-day business. Loss of integrity and availability could be tolerated without significant impacts to mission effectiveness or operational readiness.
The determination of the security category, whether it is NIST’s confidentiality, integrity, and availability consideration or DOD’s combination of MAC and confidentiality, is the critical prerequisite to identifying the appropriate security safeguards for that information and information system.
The final output: Identification of the security controls baseline
When you consider that 99% of all information system incidents are the result of known vulnerabilities, configuration errors, or operator actions, information system security controls are critically important. Controls have three distinct purposes: threat reduction, vulnerability reduction, and asset value enhancing.
For federal information systems, excluding the Department of Defense, the security controls for information systems are contained in NIST Special Publication 800-53, Recommended Security Controls for Federal Information Systems. (See the accompanying CD.) Once the overall impact level of the information system is determined, an initial set of security controls can be selected from the corresponding low, moderate, or high baselines listed in Appendix D or NIST SP 800-53 based on the security category of the information system.
The security controls for DOD information systems are currently listed in Enclosure 3 of DOD Instruction 8500.2, Information Assurance Implementation.
Aligning these predefined sets of security controls to the information and the information system are based on the security categories defined by MAC and confidentiality level.
Whether using the security controls list provided in NIST SP 800.53 for federal agencies or the DOD security controls provided in DODI 8500.2, each provides a baseline or starting point for federal or DOD agencies in addressing the necessary safeguards and countermeasures required for their information systems. The controls for both federal agencies and the DOD are aligned to three control categories: management controls, operational controls, and technical controls.
Management controls address those security activities that focus on the management of risk and information system security, such as the establishment and maintenance of an information systems security program. Management vulnerabilities are often rooted in the lack of appropriate or comprehensive policies and procedures. Examples include the security program management, appointment and training of security personnel, and budgeting for security.
Operational controls refer to those security activities that are primarily implemented and executed by people, rather than information systems. Operational controls frequently cross over into management; however, these are often implemented to improve the security of a particular information system or system of systems. They often require technical expertise and rely on the management activities, as well as the technical controls. Operational vulnerabilities are weaknesses in the operational procedures that people execute with respect to an information system. Examples include configuration management, disaster planning, and security training.
Technical controls are those that are primarily implemented and executed by the information system through hardware, software, and/or firmware mechanisms. These controls are often dependent upon the proper functioning of the information system for their effectiveness. Also, technical controls must be consistent with the overall security management of the organization. Technical vulnerabilities are weaknesses in hardware, software, system architecture, and modes of communication. Examples of technical controls include identification and authentication mechanisms, file and system access controls, and anti-virus protection.
Selecting the initial baseline
Both NIST SP 800-53 and DOD 8500.2 provide a mechanism for determining an initial baseline set of controls based on the determined security requirements for the information and the information system. The initial baseline controls are defined as the minimum security controls recommended for an information system based on its defined security requirements.
NIST categorizes security controls into the three classes of managerial, operational and technical and then further categorizes the controls within each class into 17 families, or control focus areas. Each security control family contains dozens of specific security controls. Federal agencies select a subset of minimum security controls from the master catalog found in NIST SP 800-53 according to the security categorization for the information system as high, moderate or low.
DOD also categorizes its controls into management, operational and technical classes, but then further categorizes the controls into eight subject areas, each containing multiple individual security controls for a total of 157 controls. The initial security control baseline is determined based on the combination of mission assurance category and confidentiality level.
The initial baseline set of controls serves as the starting point for an organization to identify the protection mechanisms and safeguards essential for their information system. Because the initial baselines are only intended to serve as the minimum basic standard for protection, supplements to the initial baselines may be necessary in order to achieve the desired level of risk mitigation. The initial baselines can be supplemented or compensated based on organizational assessments of risk and the resulting determination of the need for additional security safeguards.
Supplementing the initial baseline
Organizations should supplement the minimum initial baseline as appropriate, to define, develop, and implement security controls. In addition to the baseline security controls, NIST SP 800-53 provides supplementary enhancements for the minimum baseline controls. In DOD, supplementary guidance or supplementary requirements are specified by the individual DOD entities and not in the basic DOD instruction.
In most cases, the supplemental guidance provides additional detail about the basic controls or specific considerations for implementing the minimum security controls in the context of an organization’s operational environment, specific mission requirements, or assessment of risk. In addition, applicable laws, executive orders, directives, policies, regulations, standards, and guidance documents are taken into consideration, when appropriate, for the particular security control.
The control enhancements or supplementation guidance must not contradict or negate the baseline controls. Nor should they degrade interoperability or functionality of the information system.
Control enhancements, or supplementary guidance and requirements, are intended to:
build in additional, related security functionality to an existing control;
increase the security strength of an existing control;
add specific controls to meet unique organizational requirements.
In addition to control enhancements or supplementary guidance, some organizations may find it necessary to identify and implement compensating security controls. A compensating control is a management, operational, or technical control employed by an organization in place of a recommended control defined in NIST SP 800-53 or DODI 8500.2. The compensating control must provide an equivalent or comparable protection for the information system.
A compensating control can only be used under the following conditions:
The organization has selected a compensating control from another security control catalog or within the same control catalog, and the control represents an upgrade in the stringency requirement.
The organization provides a complete and convincing justification describing how the compensating control provides an equivalent or comparable protection for the information and the information system.
The organization assesses and formally accepts the risk associated with employing the compensating control.
Like the baseline control enhancements or supplementary controls, compensating controls must be documented in the system’s security plan and approved by the DAA or authorizing official for the information system.
Identifying common or inherited controls
The final action in determining the appropriate set of controls, which will then be implemented by the organization, is the identification of common or inherited controls.67 Common or inherited controls are the result of a state in which the security control, along with its validation results and compliance status, is shared across two or more information systems for the purpose of authorization.
The use of common or inherited controls reduces the complexity of controls implementation and testing, and eliminates validation test redundancy (and the associated costs). Identifying the specific
security controls which may be shared is a cooperative effort between the originating and the receiving information systems. It is most effectively accomplished as an organization-wide effort involving the senior leadership of the organization and the security authorization team.
Many of the security controls designed to protect an information system and its information may be excellent candidates for inheritance or as a common control. Examples include contingency planning, incident response, security training and awareness, physical and environmental safeguards, and intrusion detection.
Common or inherited security controls can be applied to:
all organizational information systems;
a group of information systems at a specific site;
common information systems, subsystems, or applications (i.e. common hardware, software and/or firmware) deployed at multiple operational sites.
Common or inherited security controls have the following properties:
The development, implementation, and validation of the common/inherited security controls may be assigned to responsible organizational officials or organizational elements, who may not be the information system owners whose systems will implement or use the common security controls; and
The results from the validation of the common/inherited security controls can be applied to support the security certification and accreditation processes of other information systems within the organization where the controls have been applied.
Organizations may also assign a hybrid status to a security control in the specific situation where one part of the control is common or inherited, and the other is deemed to be system specific. For example, an organization may view disaster and recovery planning as a master template for all organizational information systems, while individual system owners may tailor the plan as appropriate for system-specific requirements.
While the concept of common/inherited controls is relatively straightforward, the application within an organization takes planning, coordination, and communication. Initially, it may take some time to introduce the concept and to get the benefits. And there is one final consideration: because of the potential dependence on a common/inherited security control by many of an organization’s information systems, failure of a common/inherited control could result in an increase in agency-level risk.
Figure 9: Common/inherited controls
The diagram above depicts a standard network configuration where common/inherited controls might be applied. Here is an enclave hosting three information systems behind a firewall, which is on the boundary of the network. The firewall provides boundary level protection to all of the systems in site two. The overall network would reflect that the boundary defense control(s) are satisfied in part by the shared firewall. All of the systems sharing the firewall, including the network itself, would document this relationship in the system security plan. The status of the boundary defense control for firewall protection, all test results, and supporting materiel would be passed from the network to the sharing systems.
Benefits of common/inherited controls
Partitioning the security controls into common/inherited and system-specific security controls can result in significant savings to the organization in terms of control development and implementation costs. Partitioning can also result in a more consistent application of the security controls across the entire enterprise.
Equally significant savings may be realized in the actual certification and accreditation process. Rather than assessing common/inherited security controls for every individual system, the process can draw upon the results from the most current evaluation of the common/inherited controls at the enterprise level.
Finally, an organization-wide approach to reuse and sharing of validation results can greatly enhance the efficiency of the authorization process.
OUTPUT FROM STEP 1: UNDERSTAND THE INFORMATION SYSTEM
IDENTIFY THE SYSTEM SECURITY CATEGORY
DEVELOP THE LIST OF ASSIGNED BASELINE, SUPPLEMENTARY, COMPLEMENTARY, AND COMMON/INHERITED CONTROLS
REGISTER the information system
Registration of the information system is a critical step in ensuring that the information system is recognized in the organization’s system inventory. Registration can be as sophisticated as the formal entry in a comprehensive agency-level database or as simple as an entry in a spreadsheet on a laptop.
Depending on your organizational preferences, you may be asked to register the system prior to the security categorization process. And that is how it is done in the NIST SP 800-37. However, most system registrations require an understanding of the information system and some indication of the impact level and protection requirements for that system. So, as a result, we have put system registration after the security categorization process.
Who is involved?
The primary responsibility for information system registration lies with the owner of the information system, often also the program manager (PM). The PM or system owner is supported in this process by the information assurance manager (IAM).
The registration process
The actual process of registration varies widely according to the organization. But regardless of the process, there is one overwhelming rational for registration. To ensure that information systems are protected and subjected to the certification and accreditation process, the organization must be aware of the existence of its information systems. Otherwise, there is no assurance that the enterprise itself can be adequately protected. Information system registration also provides organizations with an effective management and tracking tool, which provides the essential foundation for security status reporting to meet FISMA and OMB compliance requirements.
Registration begins with the system description and concludes with the preparation of the initial draft of the system security plan (SSP). All of the information collected so far now serves to prepare the preliminary SSP:
Authorization team
Risk assessment
System description, including the system architecture
Accreditation boundary
Security category and protection requirements
Scope and level of effort.
It’s all about the money!
But one of the primary reasons for registering an information system is funding. For all information system initiatives, federal agencies are required to report the percentage of resources needed to information assurance (IA) activities for the budget year.
Registration, whether formal or informal, is done in accordance with existing organizational policy. It requires the information generated in Step 1, UNDERSTAND the information system, to inform the governing organization of:
the existence of the information system;
the key characteristics of the system; and
any security implications for the organization as a consequence of system operation.
Each federal agency has its process for information system registration. And at the highest level within DOD, information systems are registered in the Department of Defense Information Technology Portfolio Repository (DITPR). At the same time, each DOD service has its own information system database:
Army Portfolio Management Solution (APMS)
Air Force Enterprise Information Technology Data Repository (EITDR)
Department of the Navy Application Database Management System (DADMS).
Some of the registration requirements are mandated under the Federal Information Security Management Act (FISMA) and the requirement to make an annual report of system security status to the Office of Management and Budget (OMB). These include the assignment of a unique OMB identification number for the information system. This number will remain part of the information system security reporting throughout the information system life cycle.
Information that might be included in the system registration includes, but is not limited to:
Registry number
Information system name
Information system acronym
System description
Mission criticality
System life cycle stage
Program management information
Designated accrediting authority information
Security information:
• Security category
• Security costs
• Authorization status
• Date of accreditation
• Accreditation expiration date
• Privacy impact assessment
• Security controls validation test
• Annual security controls review
• Plan of action & milestones
• Contingency plan
• Security training
• Risk assessment
• Accreditation vehicle (e.g. DOD, NIST, etc.).
OUTPUT FROM STEP 2: REGISTER THE INFORMATION SYSTEM
SYSTEM ENTERED IN ORGANIZATIONAL INVENTORY
NEGOTIATE the authorization approach
At this point, the information system has been defined, the accreditation boundary established, the security requirements have been identified and the system has been registered in whichever way is mandated by the organization. You’ve done a lot of work to set your system up for the actual process of executing certification and accreditation.
The next step is a careful negotiation among all key participants – considering all the mission/business requirements of the agency, the technical considerations with respect to information security, and the programmatic costs to the agency.
Participants in the negotiation process include those involved in the information systems development, acquisition, operation, security certification, and accreditation.
The objective of this step is to arrive at an agreement regarding the actions required to adequately address system threats and vulnerabilities, and produce an acceptable level of residual risk. These actions should include incorporating security features into the system design, as well as administrative procedures implemented in the operational environment.
Negotiations will often include the DAA, as well as the CA, PM and user representative. The negotiation process looks at all information system data collected to date and concludes with an agreement regarding the level of effort. The parties to the negotiation have the authority to tailor the authorization process to meet the characteristics of the information system and its operational requirements, security policy, and prudent risk management.
Negotiation is NOT a consideration of which security requirements to implement and which are not applicable. This determination has already been made during Step 1. The real purpose of the negotiation step is to ensure that all participants in the authorization process understand their roles and responsibilities and that the approach and level of effort are properly and clearly defined.
Negotiations associated with system type
In Chapter 5, we discussed types of information systems and some of the accreditation considerations, particularly in connection with determining the accreditation boundary. The type of information system also influences how the authorization process might be approached. This determination is another part of the negotiation. So, to refresh your memory, here are the primary types of information systems:
Major applications (MAs)/AIS applications68
The approach to the accreditation of major applications or AIS applications can either streamline or complicate the accreditation process. So, let’s look at how you can negotiate to avoid unnecessary complication and facilitate accreditation.
Typically, a major application (MA) or AIS application is developed and deployed under the auspices of a designated program office and has an assigned program manager. In this case, the baseline authorization of the MA should be centralized and managed from a central integration and test facility or at a representative intended operating site. This eliminates the need to conduct the testing of the common system components (e.g. hardware, firmware, and/or software) at multiple sites. At the conclusion of the baseline IA controls implementation, testing, and certification, the test results,
68 In prior documentation, such as the DITSCAP, this might also be referred to as type accreditation.
the CA’s recommendation, and the accreditation results can be centrally documented in a baseline system security plan (SSP).
Of course, it is not possible to centrally implement and test the security controls for all possible types of deployments or locations, so the authorization process for an MA or AIS application should focus on a typical operating environment. The first level of negotiation will focus on identifying this “typical operating environment” and the associated security design, implementation, and testing requirements. Once completed, this type of accreditation then becomes the official authorization to deploy identical copies of the information system and will be documented in the accompanying SSP.
It should not be necessary for each site to repeat the baseline authorization requirements, since the results of the centralized effort will accompany the system to each site where it will be deployed. In this case, negotiation regarding authorization requirements should concentrate on identifying, implementing, and testing ONLY those security controls associated with the specific system installation and configuration at the target site.
In every case, the site’s information system inventory and associated system security plan (SSP) must be modified to include the documentation on the MA/AIS application. The SSP must identify the specific uses of the system, operational constraints, and operational considerations of including the new MA/AIS application within the existing site or enclave. It will also include the baseline IA requirements/controls necessary to protect the information intended for processing by the MA/AIS application in its target deployments. The receiving organization must ensure that the required documentation, security operating procedures, configuration requirements, and system administrator/user training is included with the system deployment.
General support system (GSS) or enclave
The authorization of a GSS or an enclave can be extremely complicated, particularly if a large number and/or variety of information systems are included within the accreditation boundary. The negotiation process will center on the optimal approach to implementation, testing, and accreditation considering the number of information systems, applications, and unique operational characteristics.
When conducting the authorization of a GSS/enclave, it is very helpful if there is an active configuration control board (CCB) with jurisdiction over and knowledge of the entire GSS/enclave. Their role can be critical in ensuring that all included systems and applications maintain the integrity of the baseline security posture.
A single GSS/enclave SSP can be prepared – but it should include an appendix or a reference to the accreditation documentation for each system or application included in the SSP. Additionally, the GSS/enclave SSP must include the following:
Site security architecture description.
List of all information systems and applications.
Description of how the overall GSS/enclave complies with the identified security requirements.
Data flow map.
Information system topology diagram.
External connections.
Identification of security controls that are the specific responsibility of the GSS/enclave.
The authorization plan
Information systems security should be as important as system functionality. Therefore, the negotiations should focus on developing an authorization plan that adjusts to the needs of the information system in all phases of its life cycle. The authorization plan should document the tailoring and define the activities negotiated to fit your information system.
In Chapter 5, we discussed how to look at scope, level of effort, and resources. These should be included now in the final authorization plan as it is customized to the requirements of your individual information system. At a minimum, the final negotiated plan should include:
Accreditation schedule and milestones
Level of effort
Authorization team members and their respective roles and responsibilities.
Negotiation ends when the initial SSP is prepared and all responsible organizations and individuals adopt the authorization plan and concur that the required objectives have been reached.
OUTPUT FROM STEP 3: NEGOTIATE THE AUTHORIZATION APPROACH
RESPONSIBLE ORGANIZATIONS AND INDIVIDUALS AGREE TO THE AUTHORIZATION PLAN
INITIAL SSP PREPARED
IMPLEMENT the security controls
By this step in the process, you have negotiated an authorization plan specific to your information system and have developed your initial system security plan. If you did your work in defining your information system type and the information properly, you will have also identified the security controls needed to properly secure your information system.
Implementation of the security controls is a function of a number of roles, not all of which will be direct members of the IA program or the authorization team. Individuals external to the direct authorization effort, such as the facilities manager, the personnel security manager, network and system administrators and many others are crucial to ensuring that all required security controls and safeguards have been correctly implemented.
While all of these preparatory steps are crucial, the actual implementation of the IA requirements/controls is really where “the rubber meets the road.” Both NIST and DOD have provided implementation guidance for the security controls specific to their environments.
For federal information systems, implementation guidance can be derived from the NIST SP 800-53 and the associated testing guide, NIST SP 800-53A. DOD has been a little more direct in providing implementation guidance, which can be found on the DIACAP Knowledge Service website at https://diacap.iaportal.navy.mil.69 Detailed information on implementation guidance for IA requirements/controls is available on the accompanying CD.
Implementation factors
There are several factors to be considered when determining how security controls are best implemented within your environment:
Technology-related factors
Infrastructure-related factors
Public access-related factors
69 Access to this site is restricted to authorized members of the DOD. The entry portal to the site provides information on the criteria for access and the required credentials and permissions.
Each of these will be discussed in more detail in the following sections.
Technology-related implementation factors
Frequently, the type and level of implementation of a security control will be influenced – or even determined – by the existence of or lack of certain types of technologies. Here are some of the considerations:
Security controls dependent upon specific technologies (e.g. wireless, cryptography, VoIP) are only applicable if those technologies are employed or are planned for employment within the information system. If these technologies are not present, the security control cannot be implemented and will be identified as not applicable.
Security controls may be specific to the security capability addressed by the control and the associated components of the information system. For example, audit-related security controls would typically be implemented on those elements of the information system that provide auditing capability (e.g. servers) and not necessarily applied to every user-level workstation. Access controls are not typically applied to devices, such as printers, faxes, or other components of the overall information system that provide only a limited functionality. NOTE: Organizations should, however, carefully assess the individual components of their information system to determine which security controls are applicable to the various components in their security environment. As technology continues to advance, increased functionality present in devices associated with the information system, such as personal digital assistants and cell phones, may require the application of additional security controls in accordance with the organization’s identified risk.
Infrastructure-related implementation factors
The infrastructure in which the information system is deployed will influence the level and type of security control that is implemented.
Security controls designed for the organizational facilities (e.g. physical security controls, such as locks and guards; environmental controls for temperature, humidity, fire protection, and power) are considered only in those situations where the facilities provide protection to, support, or are related to the information system. In most cases, implementation of these security controls is NOT the responsibility of the individual(s) responsible for the information system itself. However, responsibility for confirming the implementation is the responsibility of the authorization team.
Infrastructure-related security controls are generally not applicable to major applications/AIS applications.
Public access-related implementation factors
Not all federal or DOD information systems allow public access, but if they do, there are special considerations. These information systems must frequently allow the maximum access, while concurrently provide a level of security essential to the protection of the function of the systems and the information contained within. Security controls for public access information systems must be carefully considered and applied with discretion.
Considerations include:
Security baseline controls may not be applicable to information systems where users are accessing the system through a public interface. For example, both federal and DOD baseline control sets require identification and authentication for access, but these same security controls cannot be applied to publicly accessed systems.
Publicly-accessed information systems may require additional levels of implementation of boundary protection security controls. Public interfaces are often more exposed to attacks than information systems with a more restricted set of users.
Scalability-related implementation factors
When determining security implementation requirements, organizations should also consider the size of the organization or the information system being protected – or both. For example, the IT contingency plan for a large organization with a moderate, or high impact information system could be quite lengthy and complex. In contrast, a contingency plan for a smaller organization or a standalone information system would likely be considerably shorter and contain much less implementation detail.
Common/inherited control-related implementation factors
Security controls can be designated by the organization as common controls or inherited controls. In this case, they may be managed by an organizational entity other than the information system owner. This does not, however, affect the responsibility of the organization with regards to the implementation of the baseline controls. Every control must either be addressed or identified as not applicable. Here are some considerations:
Identifying common or inherited controls is a cooperative effort between the organization’s “originating” and “receiving” information system(s). The identification of common controls is most effective when accomplished as an organization-wide activity. By centrally managing the identification, implementation, and assessment of common controls, security costs can often be amortized across multiple information systems.
Some controls may be assigned a hybrid status, i.e. one part of the security control is common, while another part of the security control is determined to be system-specific. For example, the organization may have a master template for a disaster recovery plan, while individual information system owners may need to tailor the plan, where appropriate, for system-specific issues.
Risk-related implementation factors
With the diverse nature of today’s information systems, organizations must consider risk in determining the cost-benefit relationship of implementing security controls. In some cases, the risk determination may point to the need to identify and employ compensating controls.70 In all cases, the organization must assess and formally accept the risk associated with employing a compensating control.
Implementation guidance
By its very nature, implementation guidance for the security controls must be relatively generic – it cannot provide the level of detail needed to address every possible design, configuration, or deployment possibility. More often than not, the implementation guidance itself is not specific and will refer to one or more policy or technical implementation documents.
The examples below indicate the type of implementation guidance one might expect to find.
Operational or management control
Disaster recovery planning falls in the family of operational and/or management controls. The implementation guidance might be written in this way:
A disaster recovery plan will exist that provides for the resumption of business or mission essential functions within 24 hours of activation. Disaster recovery procedures will include business recovery plans,
70 A compensating control can be defined as a management, operational, or technical safeguard employed by an organization in lieu of a control recommended in the basic controls requirements publications.
system contingency plans, facility disaster recovery plans, and proof of plan acceptance and testing.
In most cases, references will be provided for further information. In this case, one might be referred to DOD Directive 3020.26, Defense Continuity Program, or to NIST SP 800-34, Contingency Planning Guide for Information Systems, which can be found on the accompanying CD.
Technical control
There are a number of technical controls designed to address a variety of operating systems and/or applications. The implementation guidance might look like this:
User interface services will be physically or logically separated from data storage and management services. This is called “Partitioning the Application.” Separation may be accomplished through the use of different computers and/or services, operating systems, network addresses, or a combination of these methods as appropriate.
The Defense Information Systems Agency (DISA) has published an extensive library of Security Technical Implementation Guides (STIGs), to include a DISA Web Server STIG. This STIG provides technical level instructions on exactly how to partition an application in order to meet the generic implementation guidance provided by the security control itself.
STIGs and other similar technology implementation guides are updated regularly to reflect changes in information technology. As a result, whenever one of these guides is used, be sure to check the originator to ensure that you are following the most current guidance.
Results of implementation: Evidence or artifacts
Artifacts, or evidence, provide visible proof of the security control implementation. These can be an intentional product of the implementation process, e.g. developed specifically to provide proof of implementation, such as a policy or set of procedures.
Artifacts can also be generated as a by-product of the development, deployment, and operations of the information system(s). Artifacts,71 or evidence of compliant implementation, can be:
Information system standard operating policies, such as written data backup procedures, together with the actual backup media.
Documentation, such as the hardware and software inventories maintained by the configuration management board or by an automated configuration management system.
Plans, such as the disaster recovery or continuity of operations plan.
Test results, such as the results of a vulnerability scan from a common scan application, such as Retina or Nessus.
Technical implementations and the associated operating guides, such as the implementation of an authorized instant messaging capability.
Milestones from the plan, initiate, and implement authorization activities
Before proceeding to the next phase, the verification and accreditation activities within a specific authorization requirement, let’s take a final look at what you should have achieved in this phase.
You have categorized your information and your information system.
The baseline security controls have been identified based on your security categorization.
You have determined whether additional, supplementary security controls are required.
Your information system has been registered with your organization in accordance with its specific requirements.
71 More specific information on artifacts will be provided in the security controls section of the accompanying CD.
You have negotiated and obtained agreement on the type of system you are accrediting, the scope of the authorization process, and the security requirements of the information system.
The initial SSP has been created, which documents the negotiated agreement.
The hard work of implementing the controls has taken place and you have either collected or generated your necessary artifacts and evidence of compliant implementation.
It is now time to move on to the next phase – the validation of your security controls implementation and the process of obtaining the authorization to operate.
|
Further reading |
|
NOTE: There are many excellent books on the various aspects essential to secure security program management, network and system architecture, etc. therefore it is impossible to include them all here. |
|
Ashbaugh, Douglas A. Security Software Development: Assessing and Managing Security Risks. Auerbach Publications: October 2008. |
|
Howard, Patrick. Building and Implementing a Security Certification and Accreditation Program: OFFICIAL ISC2 Guide to the CAPcm CBK. Auerbach Publications: December 2005. |
|
Tipton, Harold F. and Krause, Micki. Information Security Management Handbook, Sixth Edition. CRC Publications: May 2007. |
References
National Institute of Standards and Technology (NIST) Special Publication 800-37, Guide for the Security Certification and Accreditation of Federal Information Systems, May 2004.
National Institute of Standards and Technology (NIST) Special Publication 800-53, Recommended Security Controls for Federal Information Systems, December 2007.
National Institute of Standards and Technology (NIST) Special Publication 800-60, Vol. I, Guide for Mapping Types of Information and Information Systems to Security Categories. August 2008.
FIPS Publication 199, Standards for Security Categorization of Federal Information and Information Systems. February 2004.
FIPS Publication 200, Minimum Security Requirements for Federal Information and Information Systems. March 2006.
Department of Defense Instruction (DODI) 8500.2, Information Assurance Implementation, 6 February 2003.