CHAPTER THREE

INCORPORATING SECURITY INTO THE SDLC

T
his section describes a number of security considerations that will help integrate
information security into the SDLC. Security considerations are identified in each SDLC
phase, thus advancing the business application and security requirements together to
ensure a balanced approach during development. Figure 3-1, organized by development phase,
provides an overall view of the process.

FIGURE 3-1. THE SDLC – A CONCEPTUAL VIEW

In order to provide clear, concise guidance to the reader, each life cycle phase is described in a
section below that has been organized in this manner:

• Provides a brief description of the SDLC phase.

• Identifies general control gates, or established points in the life cycle, when the system will
be evaluated and when management will determine whether the project should continue as is,
change direction, or be discontinued. Control gates should be flexible and tailored to the
specific organization. Control gates are valuable in that they provide the organization with
the opportunity to verify that security considerations are being addressed, adequate security

11
 is being built in, and identified risks are clearly understood before the system development
advances to the next life cycle phase.
• Identifies and describes major security activities in each phase. Each activity is then further
defined in the following areas:

— Description. The description provides a detailed overview of the activity and highlights
specific considerations necessary to address the task.
— Expected Outputs. Common task deliverables and artifacts are listed along with
suggestions for forward/backward integration of these work products into the SDLC.
— Synchronization. A feedback loop that provides opportunities to ensure that the SDLC is
implemented as a flexible approach that allows for appropriate and consistent
communication and the adaptation of tasks and deliverables as the system is developed.
— Interdependencies. This section identifies key interdependencies with other tasks to ensure
that security integration activities are not negatively impacted by other IT processes.

12
3.1 SDLC Phase: Initiation

FIGURE 3-2. RELATING SECURITY CONSIDERATIONS IN INITIATION PHASE

3.1.1 Description
During this first phase of the development life cycle, security considerations are key to diligent
and early integration, thereby ensuring that threats, requirements, and potential constraints in
functionality and integration are considered. At this point, security is looked at more in terms of
business risks with input from the information security office. For example, an agency may
identify a political risk resulting from a prominent website being modified or made unavailable
during a critical business period, resulting in decreased trust by citizens. Key security activities
for this phase include:

• Initial delineation of business requirements in terms of confidentiality, integrity, and

availability;
• Determination of information categorization and identification of known special handling
requirements to transmit, store, or create information such as personally identifiable
information; and
• Determination of any privacy requirements.
Early planning and awareness will result in cost and timesaving through proper risk management
planning. Security discussions should be performed as part of (not separately from) the
development project to ensure solid understandings among project personnel of business
decisions and their risk implications to the overall development project.

13
3.1.2 Control Gates
General types of control gates for this phase may include:

• A determination of the acquisition strategy to be used throughout the remainder of the

development process;
• A system concept review that verifies that the concept is viable, complete, achievable, and in
line with organizational mission objectives and budgetary constraints;
• A performance specification review that ensures that the initial system design has addressed
all currently identified specified security requirements;
• An enterprise architecture (EA) alignment that harmonizes IT vision, standards, and business
requirements, as well as security alignment with current and imminent security services;
• A financial review that verifies that the system will be aligned with CPIC artifacts and
guidance while balancing the cost implications associated with risk management; and
• A risk management review that conforms to the recommended NIST risk management
framework guidelines to reduce ambiguity in managing system risk. Included in this risk
management review is a review of the information system security categorization results,
which include identified information types, resulting impact levels, and the final system
security categorization.

3.1.3 Major Security Activities

3.1.3.1 Initiate Security Planning

Security planning should begin in the initiation phase by:
• Identifying key security roles for the system development;
• Identifying sources of security requirements, such as relevant laws, regulations, and
standards;
• Ensuring all key stakeholders have a common understanding, including security implications,
considerations, and requirements; and
• Outlining initial thoughts on key security milestones including time frames or development
triggers that signal a security step is approaching.
This early involvement will enable the developers to plan security requirements and associated
constraints into the project. It also reminds project leaders that many decisions being made have
security implications that should be weighed appropriately, as the project continues.
Description:
Identification of Security Roles
Identification of the ISSO is an important step that should take into consideration the amount of
time the individual will devote to this task, the skills needed to perform the duties, and the
capability the individual has to effectively carry out the responsibilities.
Identifying the ISSO early in the process provides the individual key insights into risk-based
decisions made early in the process and provides the other team members access to the ISSO
for support in integrating security into the system development.
Stakeholder Security Integration Awareness
The ISSO provides the business owner and developer with an early understanding of the security
steps, requirements, and expectations so security can be planned from the beginning. Topics
may include:

14
 • Security Responsibilities
• Security Reporting Metrics
• Common Security Controls Provided (if applicable)
• Certification & Accreditation Process
• Security Testing and Assessment Techniques
• Security Document & Requirement Deliverables
• Secure Design, Architecture, and Coding Practices
• Security Acquisition Considerations
• Major activities with development schedule and resource impact such as active testing,
accreditation, and training
Initial Project Planning
Developing an initial project outline for security milestones that is integrated into the development
project schedule will allow proper planning as changes occur. At this stage, activities may be
more in terms of decisions followed by security activities.
• Supporting documents (slides, meeting minutes, etc.)
Expected Outputs: • Common understanding of security expectations.
• Initial schedule of security activities or decisions.

A series of milestones or security meetings should be planned to discuss each of the security
Synchronization: considerations throughout the system development.

A project schedule should integrate security activities to ensure proper planning of any future
Interdependencies: decisions associated with schedules and resources.

Implementer’s Tips
• Security planning in the initiation phase should include preparations for the entire system life cycle, including the
identification of key security milestones and deliverables, and tools and technologies. Special consideration should be
given to items that may need to be procured (e.g., test/assessment tools).
• Many of the project initiation artifacts (meeting minutes, briefings, role identification) can be standardized and provided to
developers for proper level-of-effort planning.
• An in-person meeting allows attendees an important opportunity to gauge understanding and awareness.
• If the agency identified the same individual ISSO for multiple systems, a planned approach will increase their ability to
multi-process, such as assigning common systems or common organizations with ownership.
• Consult with agency Records Management, Privacy, and Freedom of Information Act (FOIA) officials early in the
development life cycle to ensure compliance with applicable laws and agency policy.

3.1.3.2 Categorize the Information System

Security categorization, which corresponds to step 1 in the NIST Risk Management Framework,
provides a vital step towards integrating security into the government agencies’ business and
information technology management functions and establishes the foundation for security
standardization among information systems. Security categorization starts with the identification
of what information supports which government lines of business, as defined by the EA and
described in NIST Special Publication 800-60, Guide for Mapping Types of Information and
Description: Information Systems to Security Categories. Subsequent steps focus on the evaluation of
security in terms of confidentiality, integrity, and availability. The result is strong linkage between
mission, information, and information systems with cost-effective information security.
Federal Information Processing Standard (FIPS) Publication 199, Standards for Security
Categorization of Federal Information and Information Systems, provides a standardized
approach for establishing security categories for an organization’s information and information
systems. NIST SP 800-60, the companion guideline to FIPS 199, provides a process roadmap

15
 and information taxonomy to categorize information and information systems. The security
categories are based on the potential impact on an organization should certain events occur that
jeopardize the information systems needed by the organization to accomplish its assigned
mission, protect its assets, fulfill its legal responsibilities, maintain its day-to-day functions, and
protect individuals. Security categories are to be used in conjunction with vulnerability and threat
information in assessing the risk to an organization by operating an information system. FIPS
Publication 199 defines three levels (i.e., low, moderate, or high) of potential impact on
organizations or individuals should there be a breach of security (a loss of confidentiality,
integrity, or availability). The security categorization standards and guidelines assist
organizations in making the appropriate selection of security controls for their information
systems.
• Security Categorization - Essential to the security categorization process is documenting the
research, key decisions, and supporting rationale for the information system security
categorization (this is included in the System Security Plan).
• High-Level Security Requirements
Expected Outputs:
• Level of Effort Estimates - Initial level of effort can be derived from applying the resulting
security categorization to the minimal security controls in NIST SP 800-53, and assessment
procedures in NIST SP 800-53A, Guide for Assessing the Security Controls in Federal
Information Systems.

The security categorization should be revisited if there are significant changes to the information
Synchronization: system or when the business impact analysis is updated.

• Business Impact Analysis: Agency personnel should consider the cross-utilization of security
categorization and Business Impact Analysis (BIA) information in the performance of each
task activity. Since these activities have common objectives, agencies should mutually draw
on these activities for each information system and use the results to ensure accuracy.
• CPIC and EA: Just as no IT investment should be made without a business-approved
architecture, 3 the security categorization at the start of the security life cycle is a business-
enabling activity directly feeding the EA and CPIC processes as well as migration and
upgrade decisions.
• System Design: Understanding and designing the system architecture with varying impact
levels in mind may assist in achieving economies of scale with security services and
Interdependencies: protection through common security zones within the enterprise. This type of approach
requires a solid understanding of an agency’s information and data types gained through the
security categorization process.
• Contingency and Disaster Recovery Planning: Contingency and disaster recovery planning
personnel should review information systems that have multiple data types of varying impact
levels and consider grouping applications with similar system-impact levels with sufficiently
protected infrastructures. This ensures efficient application of the correct contingency and
disaster protection security controls and avoids the over protection of lower-impact systems.
• Information Sharing and System Interconnection Agreements: Agency personnel should
utilize aggregated and individual security categorization information when assessing
interagency connections.
Implementer’s Tips
• To enable an appropriate level of mission support and the diligent implementation of current and future information
security requirements, each agency should establish a formal process to validate system-level categorizations in terms of
agency priorities. This will not only promote comparable evaluation of systems, but also yield added benefits to include
leveraging common security controls and establishing defense-in-depth.
• Agency personnel should review the appropriateness of the provisional impact levels in the context of the organization,
environment, mission, use, and connectivity associated with the information system under review, to include: the

3
FEA Consolidated Reference Model Document, Version 2.1, December 2006.

16
 agency’s mission importance; life cycle and timeliness implications; configuration and security policy-related information;
special handling requirements; etc., and make adjustments if necessary.
• Even though information system security categorization may result in moderate- or high-impact system identification, the
individual SP 800-53 security controls prescribed for confidentiality, integrity, and/or availability may be set at the high
water mark identified for the individual security objective if the controls are truly independent and if cost or other concerns
are a significant driver. For the latter, a risk management approach to the selection of security controls should be
followed and any justifiable variances documented in the information systems security plan.
• Agency personnel should be aware that there are several factors that should be considered during the aggregation of
system information types. When considering these factors, previously unforeseen concerns may surface affecting the
confidentiality, integrity, and/or availability impact categorization at the system level. These factors include data
aggregation, critical system functionality, extenuating circumstances, and other system factors.

3.1.3.3 Assess Business Impact

An assessment of system impact on the agency lines of business correlates specific system
components with the critical business services that are provided. That information is then used to
characterize the business and mission consequences of a disruption to the system’s
components. An initial draft of this product early in the life cycle alerts system stakeholders to key
Description: IT and security decisions. This task should also take into account the availability impact level
identified during the security categorization task. Refer to NIST SP 800-34, Contingency
Planning Guide for Information Technology Systems, for a business impact assessment
template.
• Identify lines of business supported by this system and how those lines of business will be
impacted;
• Identify core system components needed to maintain minimal functionality;
Expected Outputs: • Identify the length of time the system can be down before the business is impacted (initial
idea of the needed Recovery Time Objective); and
• Identify the business tolerance for loss of data (initial idea of the needed Recovery Point
Objective).
• This should be reviewed periodically and updated as major development decisions (such as
new functionalities) occur or the system’s purpose and scope change significantly.
Synchronization:
• As the system matures, the BIA should be augmented with more detail on major IT
components.
• The BIA is a key step in the contingency planning process. The BIA enables improved
characterization of the system requirements, processes, and interdependencies and uses
this information to determine contingency requirements and mitigating solutions.
Interdependencies:
• The FIPS 199 Security Categorization activity’s similarity in terms of inputs and purpose
positions it as a complementary activity that provides checks and balances to ensure that all
business drivers are adequately addressed.
Implementer’s Tips
• Some of this information can be derived from the original business case for the initiative.
• For larger and more complex developments, consider holding a stakeholders meeting to brainstorm possible linkages and
impacts.
• Reuse data and information for multiple purposes when applicable. Categorization decisions can be reused for business
impact assessments (BIA), disaster recovery (DR), contingency planning (CP), and continuity of operations (COOP)
decisions. Categorization should be reflective of DR priorities. If not, there is potential that categorization was not
conducted at an appropriate level or DR priorities are incorrect.
• The results of a BIA can be used to develop requirements or objectives for service-level agreements (SLAs) with
supporting service providers.

3.1.3.4 Assess Privacy Impact

Description: When developing a new system, it is important to directly consider if the system will transmit,

17
 store, or create information that may be considered privacy information. This typically is identified
during the security categorization process when identifying information types. Once identified as
a system under development that will likely handle privacy information, the system owner should
work towards identifying and implementing proper safeguards and security controls, including
processes to address privacy information incident handling and reporting requirements.
Many agencies have employed either a one- or two-step model to address privacy
considerations. The one-step model requires all systems on the agency’s system inventory to
develop a privacy impact assessment that outlines criteria for privacy information determination
and documents security controls employed to properly protect the information. In contrast, the
two-step model differentiates by processing all systems through a threshold analysis, which is
focused on whether a privacy impact assessment should be performed. A positive answer would
then result in the execution of a more detailed evaluation of privacy data and proper security
controls in the form of a privacy impact assessment.
The resulting document of either process would then be incorporated into the system security
plan and maintained appropriately.

Privacy Impact Assessment providing details on where and to what degree privacy information is
Expected Outputs: collected, stored, or created within the system.

Should continue to be reviewed and updated as major decisions occur or system purpose and
Synchronization: scope change significantly.

• A FIPS 199 Security Categorization is the initial step in identifying types of information such
as privacy information.
• Security controls identification and assessment would reflect whether additional controls are
Interdependencies: needed to protect the privacy information.
• This will have an impact on the System Security Plan, Contingency Plan, and Business
Impact Assessment that may need to be captured in these documents.
Implementer’s Tips
• Governance for Privacy Information: Privacy Act of 1974, 5 U.S.C. § 552A
• The E-Government Act of 2002 strengthened privacy protection requirements of the Privacy Act of 1974. Under the terms
of these public laws, federal government agencies have specific responsibilities regarding collection, dissemination, or
disclosure of information regarding individuals.
• The September 29, 2003, OMB Memorandum, “OMB Guidance for Implementing the Privacy Provisions of the E-
Government Act of 2002,” puts the privacy provisions of the E-Government Act of 2002 into effect. The guidance applies
to information that identifies individuals in a recognizable form, including name, address, telephone number, Social
Security Number, and e-mail addresses.
• OMB M-06-16 and OMB M-07-17.

3.1.3.5 Ensure Use of Secure Information System Development Processes

Primary responsibility for application security, during early phases, lies in the hands of the
development team who has the most in-depth understanding of the detailed workings of the
application and ability to identify security defects in functional behavior and business process
logic. They are the first level of defense and opportunity to build in security. It is important that
their role not be assumed or diminished. Communicating and providing expectations is key to
planning and enabling an environment that protects down to the code level. Considerations to
Description: plan for include:
Secure Concept of Operations (CONOPS) for Development. A concept of
operations document for secure development should be established for the
environment and a contingency plan should be in place for the code repository as
source code is the predominant work product of software and system development and
should be preserved in the event of interruption to the development environment.

18
 Standards and Processes. System development should occur with standard
processes that consider secure practices and are documented and repeatable. To
accomplish this, appropriate security processes for the assurance level required by the
system should be determined and documented. Thus, systems with a high assurance
requirement may need additional security controls built into the development process.
Security Training for Development Team. Additional security training may be needed
for key developers to understand the current threats and potential exploitations of their
products as well as training for secure design and coding techniques. This enables the
developers to create more secure designs and empowers them to address key issues
early in the development processes.
Quality Management. Quality management, which includes planning, assurance and
control, is key to ensuring minimal defects within and proper execution of the
information system. This reduces gaps or holes that are sometimes left open for
exploitation or misuse (whether intentional or not) causing vulnerabilities in the system.
Secure Environment. The system development environment should meet minimum
FISMA compliance criteria as expressed in SP 800-53. This is to include workstations,
servers, network devices, and code repositories. Development environments must be
accredited as would any other operational system or environment. A secure
development environment lends itself to developing secure software and systems.
Secure Code Practices and Repositories. Special attention should be placed upon
code repositories with an emphasis on systems that support distributed code
contribution with check-in/check-out functionality. Role-based access should apply to
accessing the code repository, and logs should be reviewed regularly as part of the
secure development process. Code should be developed in accordance with standard
practices. A necessary part of the aforementioned CONOPS is the establishment and
retention of secure coding patterns and components. Secure coding patterns embody
code level examples and accompanying documentation that illustrate how to meet
specific functional requirements while simultaneously achieving security mandates.
These patterns can then be reused by developers to ensure that all software
components are developed in an assured fashion, having been vetted and adopted by
the organization. When possible, completed software components that have passed
security certification should be retained as reusable components for future software
development and system integration.
As a team, system developers and security representatives should agree on what steps can and
should be taken to ensure valuable and cost-effective contributions to a secure development
environment.
• Plans for development phase security training.
Expected Outputs: • Planned quality assurance techniques, deliverables, and milestones.
• Development and coding standards including development environment.
Lessons learned from completed products and security testing should be evaluated for
Synchronization: appropriateness in adjusting development processes and standards to prevent embedding
weaknesses.
• IT development standards should contain appropriate methodologies that add value to the
process and do not detract from security.
Interdependencies:
• System development training and orientation should include basic and specialized (to
environment) security awareness, training, and education.
Implementer’s Tips
• Understanding modern application security defects and attack methods is essential to protecting the system against them.
Providing application security training to the development and testing teams will increase understanding of the issues
and techniques and should enable the development of more secure systems. If developers are aware of what to look for
and what to test during the development phase, the number of security defects developed and released to quality
assurance (QA) should be reduced. In addition, if the QA test team is well educated in the area of application security,

19
 they are more likely to identify a security issue before the product is moved on to the next phase of testing. Such training
should result in greater confidence in the overall security of the production system. Providing training in application
security will also emphasize the importance of application security to the team.
• Any weakness known by the development team should be addressed as soon as possible. It is unwise to assume that
complicated attacks requiring significant knowledge of the internal workings of the system are unlikely from malicious
attackers. On more than one occasion, system owners have been surprised to find that attackers were able to “discover”
information that the system owners assumed to be hidden.
• To reduce the possibility of security defects in the system, security-focused additions should be investigated and
incorporated into the existing coding standards or development guideline document. These standards should account for
all types of software development languages used, such as C++, Java, HTML, JavaScript, and SQL.

20
3.2 SDLC Phase: Development/Acquisition

FIGURE 3-3. RELATING SECURITY CONSIDERATIONS IN THE DEVELOPMENT/ACQUISITION PHASE

3.2.1 Description
This section addresses security considerations unique to the second SDLC phase. Key security
activities for this phase include:

• Conduct the risk assessment and use the results to supplement the baseline security controls;
• Analyze security requirements;
• Perform functional and security testing;
• Prepare initial documents for system certification and accreditation; and
• Design security architecture.
Although this section presents the information security components in a sequential top-down
manner, the order of completion is not necessarily fixed. Security analysis of complex systems
will need to be iterated until consistency and completeness is achieved.

3.2.2 Control Gates

General types of control gates for this phase may include:

21
 • An Architecture/Design Review that evaluates the planned system design and potential
integration with other systems as well as incorporation of shared services and common
security controls, such as authentication, disaster recovery, intrusion detection, or incident
reporting.
• A system Performance Review that evaluates whether the system is delivering, or capable of
delivering, to the documented expectation of the owner and whether the system behaves in
a predictable manner if it is subjected to improper use. (For example, the ability of the
system to maintain availability and data integrity at the expected extreme resource loads.)
• A system Functional Review that ensures functional requirements identified are sufficiently
detailed and are testable.
• Mid-Project Status & Financial Review is important to detect major shifts in planned level of
effort to ensure cost-benefit ratios are monitored and effective decisions are continued.
• A follow-on review of risk management decisions may be needed if, due to the
aforementioned reviews, the system and/or its security controls and/or its requirements
change.

3.2.3 Major Security Activities

3.2.3.1 Assess Risk to System

Agencies should consult NIST SP 800-30, Risk Management Guide for Information Technology
Systems, for guidance on conducting risk assessments.
The purpose of a risk assessment is to evaluate current knowledge of the system’s design, stated
requirements, and minimal security requirements derived from the security categorization process
to determine their effectiveness to mitigate anticipated risks. Results should show that specified
security controls provide appropriate protections or highlight areas where further planning is
needed. To be successful, participation is needed from people who are knowledgeable in the
Description: disciplines within the system domain (e.g., users, technology experts, operations experts).
The security risk assessment should be conducted before the approval of design specifications as
it may result in additional specifications or provide further justification for specifications.
In addition to considering the security perspective of the system being developed/ acquired,
organizations should also consider how the system might affect other systems to which it will be
directly or indirectly connected. This may mean that there are inherited common controls to
leverage or additional risks that need to be mitigated. In these cases, an enterprise review may be
needed to provide a more comprehensive view of threats and vulnerabilities.
A refined risk assessment based on a more mature system design that more accurately reflects
the potential risk to the system, known weaknesses in the design, identified project constraints,
Expected Outputs: and known threats to both business and IT components. In addition, previous requirements are
now transitioning into system specific controls.
Since this risk assessment is completed at a more mature stage of system development, there
Synchronization: may be a need to revisit previously completed security steps, such as BIA or Security
Categorization. Development rarely goes as planned, and requirements have a way of changing.
• Security categorization provides the initial risk assessment information based on information
types.
Interdependencies:
• Additional security controls or compensating controls may be planned or modified based on the
risk assessment to ensure required protection for information and information systems.

22
 Implementer’s Tips
• Within any organization, the threat from internal sources remains the highest probability of occurrence. Improprieties by
employees [system developers] who are also privileged system users are a real threat, especially since such employees
may have active accounts within the system. Practices should include independent audits of the system and its
supporting processes. Continuously monitoring internal sources and using integrity-based tools to ensure configuration
audit and control may be of use by providing an automated central audit log collection, correlation, and analysis tool.
• It is a good idea to monitor the National Vulnerability Database (http://nvd.nist.gov) for known component vulnerabilities
and build in controls to mitigate them. These would then need to be tested.
• When dealing with a system having multiple owners (sometimes across different domains), it is important to identify and
address shared and inherited risks.
• Depending on the rigor needed and the complexity of the system, it may be important to follow the data flow/information
sharing beyond the first interface. Failure to do so may result in inheriting unknown risks.
• Other inherited risks may be evaluated through the supply of materials for the system. Supply chain risk should be
understood and evaluated to mitigate potential use of fraudulent, pirated, unlicensed or intentionally compromised
material.

3.2.3.2 Select and Document Security Controls

The selection and documentation of security controls corresponds to step 2 in the NIST Risk
Management Framework. The selection of security controls consists of three activities: the
selection of baseline security controls (including common security controls); the application of
security control tailoring guidance to adjust the initial security control baseline; and the
supplementation of the tailored baseline with additional controls based on an assessment of risk
and local conditions. An organization-wide view is essential in the security control selection
process to ensure that adequate risk mitigation is achieved for all mission/business processes and
the information systems and organizational infrastructure supporting those processes. .
The security control selection process should include an analysis of laws and regulations, such as
FISMA, OMB circulars, agency-enabling acts, agency-specific governance, FIPS and NIST
Special Publications, and other legislation and federal regulations that define applicable specifics
to the security controls selected.
As with other aspects of security, the goal should be cost-effective implementation that meets the
Description: requirements for protection of an organization’s information assets. In each situation, a balance
should exist between the system security benefits to mission performance and the risks associated
with operation of the system.
The security controls allocated to individual information systems are documented in the system
security plan as described in NIST Special Publication 800-18. Security plans provide an overview
of the security requirements for the information systems 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 are important because
they document the decisions taken during the security control selection process and the rationale
for those decisions. They are approved by appropriate authorizing officials within the organization
and provide one of the key documents in security accreditation packages that are instrumental in
authorization decisions.

• System Security Plan - specification of security controls that identify which, where, and how
Expected Outputs: security controls will be applied.

• Security controls and associated specifications should reflect appropriate levels of protection to
the system in line with the security control selection criteria.
Synchronization: • Significant decisions should consider any possible secondary risks that may result should the
decision influence previously considered security controls and protections identified during the
risk assessment.

23
 • Once formulated, security control requirements will be incorporated into the system security
plan.
Interdependencies:
• The risk assessment is a primary tool to identify if the tailored security controls are effective to
address an organization’s risk tolerance.
Implementer’s Tips
• Addressing security requirements in a matrix format allows the developers and security engineers to review
implementation per major system component and can facilitate gap analysis, ensuring proper risk analysis and control
implementation.
• Information security requirements should be stated in specific terms. For complex systems, iterations of the requirements
analysis may be needed. If so, planned reviews should occur at major SDLC milestones.
• Any new functional requirement may have security implications. Introducing additional risk or weakening existing security
controls is more likely if a specific security analysis is not performed for each added functional requirement. Then it is
possible for undocumented risk to enter the system.
• More detailed “attack prevention” requirements will also help to ensure that security controls and methods are tested prior
to release. If a documented requirement exists, then it is assumed that a test case will need to be developed and
executed.
• Security controls are not one-dimensional and should be addressed as appropriately on multiple components throughout
the system. For example, if your system is composed of SQL servers, Web Sphere, and a mainframe, then assessments
may need to be planned for all, some, or none, depending on the system. Documenting this during this stage decreases
the level of effort during testing.
• Agencies should initiate disposition planning during this phase and plan for disposal/transition throughout all phases of the
life cycle. This activity is best done as part of the requirements phase so full resource requirements for disposal are
understood and planned for. Disposition procedures can provide value throughout the life cycle, as hardware and
software becomes obsolete or damaged in other phases.

3.2.3.3 Design Security Architecture

With the increase in shared service providers and the centralization of some key security services
within agencies, it is becoming more important to plan these services and understand how they will
be integrated into the system.
An enterprise alignment of the system should ensure that the initiative fits the agency’s future
plans and does not conflict or unnecessarily provide redundant services. In addition, as the system
matures and more decisions are made as to services utilized, the EA should be reviewed for
optimal integration.
At the system level, security should be architected and then engineered into the design of the
system. This may be accomplished by zoning or clustering services either together or distributed
for either redundancy or additional layers of protection. Security designing at the system level
should take into consideration services obtained externally, planned system interconnections, and
the different orientations of system users (e.g., customer service versus system administrators).
Description: Another example would be a system auditing strategy that should be developed to enable an
accurate trace or reconstruction of all priority and high-risk work flows. The audit strategy should
include various audit records from several different components including (but not limited to) the
Web application, databases, mainframe, and Web servers. The goal should not be to capture as
much audit information as possible but to capture only what is needed to provide enough
information to investigate potential security breaches and system failures.
This activity may be performed when reviewing from an IT development view the known
bottlenecks and single points of failures.
Minimal security requirements as well as requirements and constraints determined early in the
process should provide the architects with a set of assumptions and constraints to build around.
This activity can provide the most value for the system in lowering the total cost of ownership by
planning the systems core components in a secure way.
• Schematic of security integration providing details on where, within the system, security is
Expected Outputs:
implemented and shared. Security architectures should be graphically depicted and detailed

24
 to the extent the reader can see where the core security controls are applied and how.
• Listing of shared services and resulting shared risk.
• Identification of common controls used by the system.
• The security architecture becomes a key component of the system documentation that should
be reviewed and maintained as major changes or significant control gates (milestones) are
Synchronization: reached.
• Significant results from assessments, security testing, and reviews should be examined for
potential feedback on effectiveness.
• Enterprise Architecture should provide insights into other like systems or services where
integration is optimal.
• System security plans will document the summary of the security architecture approach or
strategy.
Interdependencies:
• Security requirements analysis will provide the majority of the information at the detailed level.
This will enable the architect to review the information, apply it theoretically at the system
level, and determine if the controls will work as intended or if there are gaps or unnecessary
redundancy.
Implementer’s Tips
• Security architecting can provide effective compensating controls when there are issues with implementing minimal
security requirements with the system’s design specification. Security architectures will also identify common controls
that the system will inherit as well as who has responsibility for those common controls.
• Demonstrating the logic behind the security of this system will help in determining the need for additional controls.
• Risks accepted by the system that may have downstream, adverse affects on the enterprise can be identified and raised
as issues during the architectural review. Enterprise risk culminating from all individual system risk should be expressed
and tracked through the agency Enterprise Architecture process.

3.2.3.4 Engineer in Security and Develop Controls

During this stage, security controls are implemented and become part of the system rather than
applied at completion. Applying security controls in development should be considered carefully
and planned logically. The intent is to integrate the controls so that challenges with system
performance are known early. Additionally, some security controls may limit or hinder normal
development activities.
For new information systems, the security requirements identified and described in the respective
system security plans are now designed, developed, and implemented. The system security plans
Description: for operational information systems may require the development of additional security controls to
supplement in-place controls or the modification of controls that are deemed to be less than
effective.
During this task, decisions are made based on integration challenges and trade-offs. It is important
to document the major decisions and their business/technology drivers. In cases where the
application of a planned control is not possible or advisable, compensating controls should be
considered and documented.
• Implemented controls with documented specification for inclusion into the security plan.
Expected Outputs: • List of security control variations resulting from development decisions and tradeoffs.
• Potential assessment scenarios to test known vulnerabilities or limitations.

Security control application may undergo changes as a result of functional and user testing.
Synchronization: Changes should be documented.

• Security requirements analysis should be reviewed and updated if change is needed.

Interdependencies: • Security architecture strategy should be reviewed and updated if change is needed.
• Specific configurations should be documented or referenced in the system security plan.

25
 Implementer’s Tips
Documenting security deviations from initial security requirements at this stage will encourage solid risk planning and reduce
time later in backtracking business justifications. In addition, it demonstrates evidence of risk planning.

3.2.3.5 Develop Security Documentation

While the most prominent document is the System Security Plan, documentation supporting it may
include:
• Configuration management plan
• Contingency plan (including a Business Impact Assessment)
• Continuous monitoring plan
• Security awareness, training and education (SATE) plan
• Incident response plan
• Privacy impact assessment (PIA)
Development of these documents should consider the maturity of the security services being
Description: documented. In some cases, these documents may contain only known requirements, common
controls, and templates. Filling in these documents should begin as early as possible during the
project.
At this stage, it is important to solidify the security approach, the proper scope, and an
understanding of responsibilities. For example, the DR plan may be covered by the connected
General Support System, and SATE may be outsourced to a shared service provider. In this case,
the plans may focus on the system specifics and may reference key points from an in-place
service-level agreement.
Documenting as the system development progresses can provide cost savings and enhance
decision-making capabilities through a comprehensive approach that allows early detection of
gaps.

Expected Outputs: • Additional security documentation supporting the system security plan.

These documents will need to be updated toward the end of user acceptance testing to ensure
Synchronization: that they are accurate.

• System security documentation should align with:

o Security requirements analysis
Interdependencies: o Security architecture
o Business impact assessment, and
o Security categorization.
Implementer’s Tips
• Security operations should not be driven by documentation of compliance but based on system need and described in
compliance with security guidance.
• For major systems that are large in size, complex in design, or politically sensitive, it is best to assign a point of contact
POC) to each document and initiate development with a meeting on the document’s scope, expectations, and level of
granularity.

3.2.3.6 Conduct Testing (Developmental, Functional and Security)

Systems being developed or undergoing software, hardware, and/or communication
modification(s) must be tested and evaluated prior to being implemented. The objective of the test
Description:
and evaluation process is to validate that the developed system complies with the functional and
security requirements. Testing of security controls is based on technical security specifications for

26
 those controls supplemented by the assessment procedures detailed in NIST SP 800-53A, Guide
for Assessing the Security Controls in Federal Information Systems.
The process focuses on specificity, repeatability, and iteration. For specificity, the testing must be
scoped to test the relevant security requirement as it is intended for use in its environment. For
repeatability, the testing process must be capable of the execution of a series of tests against an
information system more than once (or against similar systems in parallel) and yield similar results
each time. For iteration, each system will be required to execute functional tests in whole or in part
a number of successive times in order to achieve an acceptable level of compliance with the
requirements of the system. To achieve this, functional testing will be automated to the degree
possible, and the test cases will be published, in detail, to ensure that the test process is
repeatable and iterative. The use of automated testing tools and integration of the NIST Security
Content Automation Protocol (SCAP) should be accomplished prior to the commencement of
security control test and evaluation activities. Any security functionality not tested during the
functional or automated testing will be carefully examined to ensure compliance with the
requirements during the explicit security control test and evaluation.
Only test or “stub” data should be used during system development. Absolutely no operational,
security-relevant, or personally identifiable information (PII) should reside within any system or
software during development.

Expected Outputs: Documentation of test results, including any unexpected variations discovered during testing.

All test results are returned to developers for configuration-managed updates. Unexpected results
Synchronization: may require the customer to clarify the nature of the requirement.

• Security requirements analysis may be impacted and require updating.

Interdependencies: • Changes may impact the security architecture and require updating.
• The system risk assessment may need updating to accurately reflect current mitigations.
Implementer’s Tips
• In an effort to reduce redundant functional and security testing activities, it is recommended that functional test plans
include general security features testing (to the greatest extent possible).
• Preliminary testing of basic security controls during functional testing may reduce or eliminate issues earlier in the
development cycle (e.g., mandatory access controls, secure code development, and firewalls). Preliminary testing is
considered development-level testing, not certification and accreditation (C&A) testing but if no changes occur, reuse test
results to the maximum extent possible in the C&A.
• For systems of high visibility and sensitivity, independent development testing may be recommended.
• Preliminary testing enables cost and schedule risk mitigation.
• Preliminary testing may be done at component or security zone level to ensure that each component or security zone is
secure as an entity.
• Capture the process and results of all security testing that occurs throughout the life cycle for evaluation, issue
identification, and potential reuse.
• Source code should be periodically reviewed using automated tools or manual spot check for common programming
errors that have a detrimental impact on system security including: cross-site scripting vulnerabilities, buffer overflows,
race conditions, object model violations, poor user input validation, poor error handling, exposed security parameters,
passwords in the clear, and violations of stated security policy, models, or architecture as part of the software
development QA process.

27
3.3 SDLC Phase: Implementation / Assessment

FIGURE 3-4. RELATING SECURITY CONSIDERATIONS IN THE IMPLEMENTATION/ASSESSMENT PHASE

3.3.1 Description
Implementation/Assessment is the third phase of the SDLC. During this phase, the system will
be installed and evaluated in the organization’s operational environment.

Key security activities for this phase include:

• Integrate the information system into its environment;

• Plan and conduct system certification activities in synchronization with testing of security
controls; and
• Complete system accreditation activities.

3.3.2 Control Gates

General types of control gates for this phase may include:

• System Test Readiness Review

• C&A Review

28
 • Final Project Status and Financial Review
• Deployment Readiness Review
• Authorizing Official (AO) Decision
• IT Deployment or Connection Approval.

3.3.3 Major Security Activities

3.3.3.1 Create a Detailed Plan for C&A

Because the Authorizing Official (AO) is responsible for accepting the risk of operating the system,
the AO can advise the development team if the risks associated with eventual operation of the
system appear to be unacceptable. Specifications can impose excessive burden and costs if the
acceptable residual risks are not known. The involvement of the AO is required for this
determination of acceptable residual risks. It is easier to incorporate requirement changes during
the planning stage of a system acquisition than during the solicitation, source selection, or contract
administration stages.
The development team and the AO should also discuss the forms of evidence that the AO needs
to make a decision. This evidence may include system test results and other data. In addition, the
Description: acquisition initiator and the accrediting official should discuss how changes to the system and its
environment would be addressed. The possibility of establishing a security working group should
be discussed. Such a group may consist of personnel such as users, program managers, and
application sponsors; system, security, or database administrators; security officers or specialists,
including the C&A representatives; and system or application analysts.
To ensure proper testing and reduce the likelihood of scope creep during testing, the security
accreditation boundary should be clearly delineated. This will form the basis for the test plan to be
created and approved prior to implementation performance.
At this point, the certification package should be close to completion, and any agency-specified
initial review for conformance has commenced.
• Initial Work Plan: A planning document that identifies key players, project constraints, core
Expected Outputs: components, scope of testing, and level of expected rigor. The certification package should
be close to completion, and any initial agency-specified conformance reviews initiated.

ISSO provides the system owner with completed documentation required to initiate and conduct
Synchronization: C&A. The AO is notified.

Security Controls Assessment Plan will derive the foundational information from this planning
Interdependencies: document/session.
Implementer’s Tips
• Holding a planning session or completing a preliminary project plan four - six weeks prior to testing will allow enough time
to obtain resources and plan appropriately.
• Holding a quick initial review of the certification package will help bring to light potential challenges.
• Active testing will impact development and should be planned well ahead of this meeting.
• Involving the AO in the planning process as early as possible (even in phase 1) will establish expectations for C&A and
eliminate surprises prior to reaching the C&A control gate.

29
3.3.3.2 Integrate Security into Established Environments or Systems
System integration occurs at the operational site when the information system is to be deployed for
operation. Integration and acceptance testing occur after information system delivery and
Description: installation. Security control settings are enabled in accordance with manufacturers’ instructions,
available security implementation guidance, and documented security specification.

• Verified list of operational security controls.

Expected Outputs:
• Completed System Documentation.

• Issues encountered during installation should be evaluated for inclusion into the contingency
plan based on the potential for reoccurrence.
Synchronization:
• ISSO should review installed system to ensure that controls are in place and properly
configured and provide the verified list to system owner and AO.
Interdependencies: Changes should be updated to the core security documents.
Implementer’s Tips
• Clean out test and development environment to ensure that all test data is removed.
• Extreme care should be exercised when integrating information systems into operational environments or systems so that
critical operations are not disrupted.

3.3.3.3 Assess System Security

Systems being developed or undergoing software, hardware, and/or communication
modification(s) must be formally assessed prior to being granted formal accreditation. The
objective of the security assessment process is to validate that the system complies with the
functional and security requirements and will operate within an acceptable level of residual security
risk. Testing of security controls is based on the assessment procedures detailed in NIST SP 800-
53A, Guide for Assessing the Security Controls in Federal Information Systems.
Description: Prior to initial operations, a security certification must be conducted to assess the extent to which
the controls are implemented, operating as intended, and producing the desired outcome with
respect to meeting the security requirements for the system. In addition, periodic testing and
evaluation of the security controls in an information system must be conducted to ensure
continued effectiveness. In addition to verifying security control effectiveness, security certification
may uncover and describe actual vulnerabilities in the information system. The determination of
security control effectiveness and information system vulnerabilities provides essential information
to authorizing officials to facilitate credible, risk-based security accreditation decisions.

• Security Accreditation Package, which includes the Security Assessment Report, the POA&M,
Expected Outputs: and the updated System Security Plan.

• Certifier provides written Certification Package results to system owner, ISSO, and system
administrator.
Synchronization:
• Assessment results are shared with system owner, ISSO, system administrator, and
developers.
Interdependencies: All previous steps.
Implementer’s Tips
• All documents should be in final state for review to ensure a current picture of the system at review time.
• Copying Certification Package to CD/DVD or other electronic media also helps to ensure configuration control and a
current archive.
• Assigning a core team of representatives from the major stakeholders to meet throughout testing will assist in
communication and reduce surprises.
• Clearly articulating the C&A process to all parties and agreeing on the level of rigor and scope of testing are very important

30
 in ensuring a smooth certification effort.
• Prioritize continuous monitoring by risk and cost-effectiveness.
• Reuse as many prior and relevant assessment results as possible.

3.3.3.4 Authorize the Information System

OMB Circular A-130 requires the security authorization of an information system to process, store,
or transmit information. This authorization (also known as security accreditation), granted by a
senior agency official, is based on the verified effectiveness of security controls to some agreed-
upon level of assurance and an identified residual risk to agency assets or operations (including
mission, function, image, or reputation). The security authorization decision is a risk-based
Description: decision that depends heavily, but not exclusively, on the security testing and evaluation results
produced during the security control verification process. An authorizing official relies primarily on:
(i) the completed system security plan; (ii) the security test and evaluation results; and (iii) the
POA&M for reducing or eliminating information system vulnerabilities, in making the security
authorization decision to permit operation of the information system and to accept explicitly the
residual risk to agency assets or operations.
• Security Authorization Decision, documented and transmitted from Authorizing Official to
Expected Outputs: System Owner and ISSO
• Final Security Authorization Package

• System inventories and reporting statistics should be updated to reflect the accredited status.
Synchronization:
• CPIC activities should also reflect if the system is accredited.

• Update security and budget documentation with resulting status.

Interdependencies:
• Certification statement for the information system.
Implementer’s Tips
Authorizing officials need to make risk decisions not only for the information system, but for the risk extended to the
organization as a whole by placing the system into operation.

31
3.4 SDLC Phase: Operations and Maintenance

FIGURE 3-5. RELATING SECURITY CONSIDERATIONS IN THE OPERATIONS/MAINTENANCE PHASE

3.4.1 Description
Operations and Maintenance is the fourth phase of the SDLC. In this phase, systems are in place
and operating, enhancements and/or modifications to the system are developed and tested, and
hardware and/or software is added or replaced. The system is monitored for continued
performance in accordance with security requirements and needed system modifications are
incorporated. The operational system is periodically assessed to determine how the system can
be made more effective, secure, and efficient. Operations continue as long as the system can be
effectively adapted to respond to an organization’s needs while maintaining an agreed-upon risk
level. When necessary modifications or changes are identified, the system may reenter a previous
phase of the SDLC.

Key security activities for this phase include:

• Conduct an operational readiness review;

• Manage the configuration of the system ;
• Institute processes and procedures for assured operations and continuous monitoring of the
information system’s security controls; and
• Perform reauthorization as required.

32
3.4.2 Control Gates
General types of control gates for this phase may include:

• Operational Readiness Review

• Change Control Board Review of Proposed Changes
• Review of POA&Ms
• Accreditation Decisions (Every three years or after a major system change).

3.4.3 Major Security Activities

3.4.3.1 Review Operational Readiness

Many times when a system transitions to a production environment, unplanned modifications to
the system occur. If changes are significant, a modified test of security controls, such as
Description: configurations, may be needed to ensure the integrity of the security controls.
This step is not always needed; however, it should be considered to help mitigate risk and
efficiently address last-minute surprises.

Expected Outputs: Evaluation of security implications due to any system changes.

• System Administrator and ISSO confirmation to System Owner that system is operating
normally and compliant with security requirements.
Synchronization:
• Should a last minute change occur that fundamentally changes the level of risk to the system,
the system owner should consider recertification - this is rare.
• An operational readiness review supplements the C&A process to ensure that changes are
Interdependencies: reviewed for risk potential.
• Any change to security controls should be updated in the security documentation.
Implementer’s Tips
• When an application is enhanced or changed, regression testing helps to ensure that additional vulnerabilities have not
been introduced. For example, adding source code can often introduce errors in other areas and may negatively impact
existing and stable functions.
• Changes that include additional data fields should be noted and analyzed to determine if the security posture of the
system has degraded or introduced a need for additional controls.
• Ensure users are adequately trained on security awareness and practices for the new IT system prior to deploying the
system in a production environment.

3.4.3.2 Perform Configuration Management and Control

An effective agency configuration management and control policy and associated procedures are
essential to ensure adequate consideration of the potential security impacts due to specific
changes to an information system or its surrounding environment.
Configuration management and control procedures are critical to establishing an initial baseline of
hardware, software, and firmware components for the information system and subsequently for
Description: controlling and maintaining an accurate inventory of any changes to the system. Changes to the
hardware, software, or firmware of a system can have a significant security impact.
Documenting information system changes and assessing the potential impact on the security of
the system on an ongoing basis is an essential aspect of maintaining the security accreditation.
These steps, when implemented effectively, provide vital input into the system’s continuous

33
 monitoring capability. As such, it facilitates the agency’s ability to identify significant changes that
alter a system’s security posture and control effectiveness to ensure proper assessment and
testing occurs.
Note: The Security Content Automation Protocol (SCAP) is a method for using specific standards
to enable automated vulnerability management, measurement, and policy compliance evaluation
(e.g., FISMA compliance). Agency Configuration Management procedures should integrate this
activity to ensure repeatability and consistency. This is an iterative process that requires periodic
review of profile changes.
• Change Control Board (CCB) decisions
Expected Outputs: • Updated security documentation (System Security Plan, POA&M)
• Security evaluations of documented system changes
• System updates should be included into the system security documentation at least annually or
with significant change.
Synchronization:
• CM system documents should provide input into the Continuous Monitoring plan for the
system.
• Security architecture should provide key details on component-level security service, which in
turn provides a benchmark to evaluate the impact of the planned change. For example, if you
are upgrading database software to a new version that has less auditing capability, the
Interdependencies: security architecture or security control documentation should provide insight into whether
that component needs that level of auditing capability. Resulting analysis would identify
whether further review is needed before implementing.
Implementer’s Tips
• Security significance is not always easy to identify when looking at CM artifacts. The reviewer should keep in mind any
changes that would directly or indirectly impact confidentiality, integrity, and availability.
• Some system enhancements that add new data may require a review of impact to the system security categorization and
associated security controls.
• Abbreviated CM processes that allow for unique emergency situations should be identified for emergency purposes.
These situations should always be followed up with a full review when time permits.

3.4.3.3 Conduct Continuous Monitoring

The ultimate objective of continuous monitoring is to determine if the security controls in the
information system continue to be effective over time in light of the inevitable changes that occur in
the system as well as the environment in which the system operates.
A well-designed and well-managed continuous monitoring process can effectively transform an
otherwise static security control assessment and risk determination process into a dynamic
process that provides essential, near real-time security status information to appropriate
organizational officials. This information can be used to take appropriate risk mitigation actions and
make credible, risk-based authorization decisions regarding the continued operation of the
Description: information system and the explicit acceptance of risk that results from that decision.
The ongoing monitoring of security control effectiveness can be accomplished in a variety of ways,
including security reviews, self-assessments, configuration management, antivirus management,
patch management, security testing and evaluation, or audits. Automation should be leveraged
where possible to reduce level of effort and ensure repeatability.
Included as a part of continuous monitoring is reaccreditation which occurs when there are
significant changes to the information system affecting the security of the system or when a
specified time period has elapsed in accordance with federal or agency policy.
• Documented results of continuous monitoring
• POA&M review
Expected Outputs:
• Security reviews, metrics, measures, and trend analysis
• Updated security documentation and security reaccreditation decision, as necessary

34
 Continuous monitoring should be adjusted as risk levels fluctuate significantly and security controls
Synchronization: are modified, added, and discontinued.

Continuous monitoring provides system owners with an effective tool for producing ongoing
Interdependencies: updates to information system security plans, security assessment reports, and plans of action and
milestones documents.
Implementer’s Tips
• Agencies should strive to implement a cost-effective continuous monitoring program. Where available, a continuous
monitoring program should make use of common services for more frequent monitoring, as well as system-specific
monitoring for critical security controls.
• Realizing that it is neither feasible nor cost-effective to monitor all of the security controls in any information system on a
continuous basis, agencies should consider establishing a schedule for security control monitoring to ensure that all
controls requiring more frequent monitoring are adequately covered and that all controls are covered at least once
between each accreditation decision.
• Continuous monitoring processes should be evaluated periodically to review changes in threats and how this could affect
the ability of controls to protect a system. These threat updates may result in updated risk decisions and changes to
existing controls.
• Take credit for activities already underway that count for continuous monitoring. AV DAT file updates, routine
maintenance, physical security fire drills, log reviews, etc., should all be identified and captured in the continuous
monitoring phase.
• Prioritize continuous monitoring by importance of control to mitigating risk, validation of POA&M items that become closed,
and single control points of failure.
• Look at a monitoring cycle that will coincide with the system certification life span and capture test procedures and results
for reuse upon recertification.
• Continuous monitoring activities can provide useful data to support security performance plans and measures of security
return on investment (ROI).
• Defining agency-specific criteria for triggering a reaccreditation helps to ensure decision makers are informed and all
stakeholders have a common understanding. Some latitude should be given in criteria to allow for unique situations.

35
3.5 SDLC Phase: Disposal

FIGURE 3-6. RELATING SECURITY CONSIDERATIONS IN THE DISPOSAL PHASE

3.5.1 Description
Disposal, the final phase in the SDLC, provides for disposal of a system and closeout of any
contracts in place. Information security issues associated with information and system disposal
should be addressed explicitly. When information systems are transferred, become obsolete, or
are no longer usable, it is important to ensure that government resources and assets are protected.

Usually, there is no definitive end to a system. Systems normally evolve or transition to the next
generation because of changing requirements or improvements in technology. System security
plans should continually evolve with the system. Much of the environmental, management, and
operational information should still be relevant and useful in developing the security plan for the
follow-on system.

The disposal activities ensure the orderly termination of the system and preserve the vital
information about the system so that some or all of the information may be reactivated in the
future, if necessary. Particular emphasis is given to proper preservation of the data processed by
the system so that the data is effectively migrated to another system or archived in accordance
with applicable records management regulations and policies for potential future access.

Key security activities for this phase include:

36
 • Build and Execute a Disposal/Transition Plan;
• Archive of critical information;
• Sanitization of media; and
• Disposal of hardware and software.

3.5.2 Control Gates

General types of control gates for this phase may include:

• System Closure Review

• Change Control Board
• Security Review of Closure.

3.5.3 Major Security Activities

3.5.3.1 Build and Execute a Disposal/Transition Plan

Building a disposal / transition plan ensures that all stakeholders are aware of the future plan for the
system and its information. This plan should account for the disposal / transition status for all critical
components, services, and information.
Much like a work plan, this plan identifies necessary steps, decisions, and milestones needed to
properly close down, transition, or migrate a system or its information.
Description:
In many cases, disposed systems or system components have remained dormant but still
connected to the infrastructure. As a result, these components are often overlooked, unaccounted
for, or maintained at suboptimal security protection levels thus, providing additional and
unnecessary risk to the infrastructure and all connected systems. A transition plan assists in
mitigating these possible outcomes.

Expected Outputs: Documented disposal/transition plan for closing or transitioning the system and/or its information.

Security documentation should reflect pending plans if security decisions and funding are
Synchronization: reallocated or otherwise impacted because of the disposal decision.

Security documentation such as the security plan and security control requirements may need
Interdependencies: updating.
Implementer’s Tips
• Consult with agency Records Management, Privacy, and Freedom of Information Act (FOIA) officials prior to disposal to
ensure compliance with these laws and applicable agency policy.
• Do not wait for the disposal phase to make a disposal/transition plan. Plan for disposal/transition throughout all phases of
the life cycle. This is best done as part of the requirements phase so full resource requirements for disposal/transition are
understood and planned for. Throughout the life cycle, this can be done as hardware and software become obsolete or
damaged; in other phases, it will require tasks outlined in this phase.

37
3.5.3.2 Ensure Information Preservation
When preserving information, organizations should consider the methods that will be required for
retrieving information in the future. The technology used to retrieve the records may not be readily
Description: available in the future (particularly if encrypted). Legal requirements for records retention must be
considered when disposing of systems.

Expected Outputs: Index of preserved information, and its location and retention attributes.

Synchronization: Records management, Privacy Act, and FOIA requirements should be considered.

Interdependencies: Privacy considerations or activities may be important for FOIA reasons.

Implementer’s Tips
• Close coordination with the organization Freedom of Information Act (FOIA) Office will assist in planning for this activity.
• Organizations can also get practical tips from the National Archives and Records Administration Information System
Security Oversight Office.

3.5.3.3 Sanitize Media

Based on the results of security categorization, the system owner should refer to NIST Special
Publication (SP) 800-53, Recommended Security Controls for Federal Information Systems, which
specifies that, “the organization sanitizes information system digital media using approved
equipment, techniques, and procedures. The organization tracks, documents, and verifies media
sanitization and destruction actions and periodically tests sanitization equipment/procedures to
ensure correct performance. The organization sanitizes or destroys information system digital
media before its disposal or release for reuse outside the organization, to prevent unauthorized
individuals from gaining access to and using the information contained on the media.”
NIST SP 800-88, Guidelines for Media Sanitization, divides media sanitization into four categories:
Description: disposal, clearing, purging and destroying. It further suggests that the system owner categorize the
information, assess the nature of the medium on which it is recorded, assess the risk to
confidentiality, and determine the future plans for the media. Then, decide on the appropriate
sanitization process. The selected process should be assessed as to cost, environmental impact,
etc., and a decision made that best mitigates the risk to confidentiality and best satisfies other
constraints imposed on the process.
Several factors should be considered along with the security categorization of the system
confidentiality when making sanitization decisions. The cost versus benefit of a media sanitization
process should be understood prior to a final decision. For instance, it may not be cost-effective to
degauss inexpensive media such as diskettes.

Expected Outputs: Media sanitization records

Synchronization: None.

Interdependencies: Security categorization provides the identification and associated risk level of system information.
Implementer’s Tips
• Even though clear or purge may be the recommended solution, it may be more cost-effective (considering training,
tracking, and validation, etc.) to destroy media rather than use one of the other options.
• Organizations can always increase the level of sanitization applied if that is reasonable and indicated by an assessment of
the existing risk so that proper sanitization techniques are applied.

38
3.5.3.4 Dispose of Hardware and Software
Hardware and software can be sold, given away, or discarded as provided by applicable law or
regulation. The disposal of software should comply with license or other agreements with the
developer and with government regulations. There is rarely a need to destroy hardware except for
some storage media that contains sensitive information and that cannot be sanitized without
destruction. In situations when the storage media cannot be sanitized appropriately, removal and
Description: physical destruction of the media may be possible so that the remaining hardware may be sold or
given away. Some systems may contain sensitive information after the storage media is removed. If
there is doubt whether sensitive information remains on a system, the ISSO should be consulted
before disposing of the system. Also, the vendor may be consulted for additional disposal options or
verification of risk.
• Disposition records for hardware and software. These records may include lists of hardware
Expected Outputs: and software released (sold, discarded, or donated), and lists of hardware and software
redeployed to other projects or tasks within the organization.

Synchronization: Updating of system and component inventories.

Interdependencies: System hardware and software inventory should be updated accordingly.

Implementer’s Tips
• Do not forget property accountability requirements when disposing of a system. When possible, consider donation of used
IT and/or e-cycling of hazmat parts.
• Title 40 USC advises system owners and custodians that excess equipment is “Educationally useful” and “Federal
equipment is a vital national resource.” Wherever possible, excess equipment and media should be made available to
qualifying schools and nonprofit organizations to the extent permitted by law.
• For cost savings, some agencies maintain reasonably old parts for contingency operations. For example, utilizing retired
laptops for a telecommuting scenario that requires only partial processing for vital Internet or email communications.

3.5.3.5 Closure of System

Description: The information system is formally shut down and disassembled at this point.

• Documentation verifying system closure, including final closure notification to the authorizing
Expected Outputs: and certifying officials, configuration management, system owner, ISSO, and program manger.

Synchronization: None.

• Archival of security documentation as appropriate.

• If continuous monitoring services are provided, notification to providers of closure is needed
Interdependencies: (may include CM, AV, IR, and CCB).
• Inventory updates for FISMA reporting and enterprise architecture.
Implementer’s Tips
• A memorandum articulating formal system closure and proper action taken that includes in the distribution all key
stakeholders provides the simplest approach to formal closure.

39