ITL Bulletin for December 2003

[InfoSec News <isn () c4i org>]

Forwarded from: Elizabeth Lennon <elizabeth.lennon () nist gov>

SECURITY CONSIDERATIONS IN THE INFORMATION SYSTEM 
DEVELOPMENT LIFE CYCLE
Shirley Radack, Editor
Computer Security Division
Information Technology Laboratory
National Institute of Standards and Technology
Technology Administration
U.S. Department of Commerce

When do you have to pay attention to the security requirements of your
information system? From the very earliest stages of planning for the
development of the system to its final disposal is the advice of the
National Institute of Standards and Technology (NIST).  By considering
security early in the information system development life cycle
(SDLC), you may be able to avoid higher costs later on and develop a
more secure system from the start.

NIST's Information Technology Laboratory recently issued Special
Publication (SP) 800-64, Security Considerations in the Information
System Development Life Cycle, by Tim Grance, Joan Hash, and Marc
Stevens, to help organizations include security requirements in their
planning for every phase of the system life cycle, and to select,
acquire, and use appropriate and cost-effective security controls. The
guide discusses the selection of a life cycle model by the
organization and the responsibilities of the organization's managers
and staff members for conducting the system development process. While
NIST SP 800-64 describes security and a generic system development
life cycle for illustrative purposes, the basic concepts can be
applied, with tailoring, to any SDLC model or acquisition method the
organization is using.

The appendices to the guide contain sample documents to help federal
organizations during the system acquisition process. These include a
standard format for requests for proposals (RFPs); specifications,
tasks, and clauses that can be incorporated into RFPs to acquire
information security features; and examples of contract language for
specific information security measures. This ITL Bulletin summarizes
NIST SP 800-64, which is available at
http://csrc.nist.gov/publications/nistpubs/index.html.

The System Development Life Cycle (SDLC)

The system development life cycle starts with the initiation of the
system planning process, and continues through system acquisition and
development, implementation, operations and maintenance, and ends with
disposition of the system. Specific decisions about security must be
made in each of these phases to assure that the system is secure.

Initiation Phase

The initiation phase begins with a determination of need for the
system. The organization develops its initial definition of the
problem that could be solved through automation.  This is followed by
a preliminary concept for the basic system that is needed, a
preliminary definition of requirements, and feasibility and technology
assessments. Also during this early phase, the organization starts to
define the security requirements for the planned system. Management
approval of decisions reached is important at this stage.

The information developed in these early analyses will be used to
estimate the costs for the entire life cycle of the system, including
information system security. An investment analysis should be
performed to determine the appropriate strategy for achieving the
system requirements, while taking mission needs and budget constraints
into account.  Expenditures for security should be considered before
the system is built. It is difficult to add functionality into a
system after it has been built, and it is usually more cost-effective
to include preventive security measures from the start rather than to
deal with security breaches later on.

During this initiation phase, the organization establishes the
security categorization and conducts a preliminary risk assessment for
the planned information system.  Categorization of the information
system using federal standards and guidelines aids system security
planners in defining information system security according to levels
of impact, and in selecting a baseline of initial security controls
for those impact levels.  Security categories are then used in
conjunction with vulnerability and threat information in assessing
risk to an organization.

* Federal Information Processing Standard (FIPS) 199, Standards for
Security Categorization of Federal Information and Information
Systems, should be used by federal organizations to determine the
security category for the information system. FIPS 199 defines three
levels of potential impact on organizations or on individuals should
certain adverse events occur. These are events that could 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 to assess the risk that an
organization incurs when operating an information system and to select
appropriate security controls. FIPS 199 is available as a
pre-publication final document at http://csrc.nist.gov/.

* A preliminary risk assessment should be performed to develop a brief
initial description of the basic security needs of the system,
including needs to protect the integrity, availability, and
confidentiality of system information. The preliminary risk assessment
should define the threat environment in which the system will operate
and the potential vulnerabilities. This assessment should be followed
by an initial identification of required security controls that will
protect the system in its operational environment. A detailed risk
assessment is developed in the next phase.

Acquisition / Development Phase

In this phase, the organization should conduct a requirements
analysis, which draws on and expands the work done in the Initiation
phase. This in-depth study of the organization's need for the system
should analyze the security aspects of the system requirements.

* A formal risk assessment identifies threats to and vulnerabilities
in the information system, the potential impact or magnitude of harm
that a loss of confidentiality, integrity, or availability would have
on agency assets or operations, and the security controls that are
needed. This analysis builds on the initial risk assessment performed
during the Initiation phase, but is more detailed and specific. The
risk assessment brings together important information about the
protection of the information system, and it generates information
required for the security plan. This risk assessment should be
conducted before the approval of design specifications. The assessment
should consider existing controls and their effectiveness, as well as
the impact that the new system might have on other systems to which it
will be directly or indirectly connected. Enterprise security
architectures can help minimize the vulnerabilities that might be
introduced by the new system.

* The security functional requirements analysis considers the system
security environment, including the enterprise information security
policy and the enterprise security architecture. The analysis should
address all requirements for confidentiality, integrity, and
availability of information, and should include a review of all legal,
functional, and other security requirements contained in applicable
laws, regulations, and guidance.

* The security assurance requirements analysis addresses the
activities and assurance needed to produce the desired level of
confidence that the information security will work correctly and
effectively. This analysis, based on legal and functional security
requirements, should be used to determine how much and what kinds of
assurance are required. The goal is to achieve cost-effective
assurance that meets the requirements for protecting the
organization's information assets.  Tests and evaluations, such as the
following, can provide information about system quality and support
confidence in the system.

The Common Criteria for IT Security Evaluation, contained in
International Organization for Standardization/International
Electrotechnical Commission (ISO/IEC) 15408, is used to evaluate
information security products to support user confidence that the
products meet defined security claims. NIST and the National Security
Agency jointly manage the National Information Assurance Partnership
(NIAP), which develops comprehensive security requirements and
security specifications for key technologies and evaluates the
security features of products in accordance with the Common Criteria.
Commercial testing laboratories conduct the evaluations after being
accredited by NIST's National Voluntary Laboratory Accreditation
Program (NVLAP). A list of evaluated products is available at
http://niap.nist.gov/cc-scheme/ValidatedProducts.html.

NIST conducts the Cryptographic Module Validation Program (CMVP),
which also uses independent, accredited laboratories to perform
conformance testing of cryptographic modules for conformance to
Federal Information Processing Standard (FIPS) 140-2, Security
Requirements for Cryptographic Modules, and other federal
cryptographic algorithm standards. Established jointly by NIST and the
Communications Security Establishment (CSE) of the Government of
Canada, the CMVP tests products to assure that the federal
cryptographic algorithms have been correctly implemented in the
modules.  Federal agencies that have determined that they need
cryptographic methods to protect their information must use validated
products. A list of validated products is available at
http://csrc.nist.gov/cryptval/.

Third-party and other evaluations can be used, but the objectivity of
these evaluations must be considered.  Government organizations may
conduct their own evaluations.  The results of these evaluations may
or may not be published and are normally not considered to be
endorsements by federal agencies. Other sources of evaluations include
trade, professional, and commercial organizations.

* Consideration and reporting of development cost enable organizations
to determine how much of the development cost can be attributed to
information security over the life cycle of the system. These costs
include hardware, software, personnel, and training. The best source
of this data is the risk assessment, which identifies the controls
that will mitigate vulnerabilities, and includes a cost-benefit
analysis of recommended controls based on consideration of the
possibility of an incident and its potential impact. When the controls
have been selected, the cost of each can be determined. OMB Circular
A-11, Part 3, requires that federal organizations report this
information for their major acquisitions.

* The security plan ensures that the planned or existing security
controls are fully documented. The security plan also provides a
complete description of the information system, and provides
references to key documents supporting the organization's information
security program:  the configuration management plan, contingency
plan, incident response plan, security awareness and training plan,
rules of behavior, risk assessment, security test and evaluation plan,
system interconnection agreements, security authorizations and
accreditations, and the plan of action with milestones.

* A study of security controls focuses on the controls described in
the security plans to assure that they are designed, developed, and
implemented. Additional controls may be needed for information systems
currently in operation.

* A security test and evaluation plan should be developed for the
security controls that can be evaluated prior to deployment. The
controls must be tested and evaluated for correct implementation and
effectiveness. Controls of a non-technical activity, such as
management and operational controls, cannot be tested and evaluated
until the information system is deployed.

* Other planning processes, studies, evaluations, and contract
specifications associated with the development and acquisition
process, involving appropriate staff members, help to assure that the
security requirements of the system are identified and achieved. The
IT security experts should work with the contracting office to select
the most advantageous type of contract. A team or group of
participants from functional areas such as legal, human resources,
information security, and physical security can provide useful
perspectives in reviewing the plans.  Involvement of appropriate staff
early in the planning process can help to reduce life-cycle costs and
make it easier to change requirements early on.

Implementation Phase

In this phase, the system is installed and evaluated in the
organization's operational environment.

* Inspection and acceptance of the delivered system is necessary to
verify that the functionality described in the specifications has been
included in the deliverables.  Testing can be done by the organization
or by an independent contractor to assure that the system meets the
specifications, and that the security features are operating.

* Security controls are integrated at the site where the system is to
be deployed for operation. Security control settings and switches are
enabled in accordance with vendor instructions and available security
implementation guidance.

* OMB Circular A-130, Appendix III, requires that the system be
certified and accredited before it is operational. Information about
the certification and accreditation process is available from
http://csrc.nist.gov/sec-cert/. Federal agencies should periodically
test and evaluate the security controls in their information systems
to assure effective implementation, using established verification
techniques and procedures. Security certification gives organization
officials confidence that the appropriate safeguards and
countermeasures are in place. Security certification also uncovers and
describes the known vulnerabilities in the information system. This
information helps officials make decisions about security
accreditation, which is an authorization for a system to operate.  
Granted by a senior organization official, accreditation is based on
the verified effectiveness of security controls to some agreed-upon
level of assurance and an acceptance of identified residual risk to
agency assets or operations.  The decision is risk-based and is
supported by testing and evaluation results produced during the
security control verification process.

Operations / Maintenance Phase

In this phase of the SDLC, information systems are operating, and may
undergo enhancements and modifications.  Hardware and software may be
added or replaced. The system is monitored for continued performance
in accordance with user requirements, and needed system modifications
are incorporated. The operational system is periodically assessed to
determine how it can be made more efficient and effective. Operations
continue as long as the system can be effectively adapted to respond
to the organization's changing needs.

* Configuration management and control procedures are critical to
establishing an initial baseline of hardware, software, and firmware
components for the information system and subsequently to 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 impact on the security of the system.  System changes
should be documented, and their potential impact on security should be
assessed regularly.

* Controls must be continuously monitored through periodic testing and
evaluation to assure that they are effective in their application.
Monitoring of security controls verifies the continued effectiveness
of those controls and reports on the security status of the system's
information

Disposition Phase

This phase provides for disposal and/or contract closeout of the
system (for contracts that were employed during the earlier phases).
Disposal of the system may involve a separate contract. Government
resources and assets must be protected when information systems are
transferred, disposed of, or no longer usable. For some systems, there
may not be a definitive end to the SDLC since the system may evolve or
transition to the next generation of technology, as a result of
changing requirements. System security plans should be modified to
evolve with the system.

* Information should be retained to conform to current legal
requirements and to accommodate future technology changes that might
make the system's data retrieval method obsolete. The environmental,
management, and operational information about a system may be relevant
and useful in developing the security plan for the follow-on system.
The data processed by the system should be preserved for use in a
follow-on system or archived in accordance with applicable regulations
and policies.

* Data should be deleted, erased, and written over as necessary, and
the media that stored the data should be sanitized. Degaussing,
overwriting, and media destruction are some of the methods that may be
used.

* Disposal of the hardware and software should be completed at the
direction of the information system security officer.

More Information

The following Special Publications (SPs) provide help to organizations
in planning, developing, operating, maintaining, and terminating
secure information systems.  These publications are available in
electronic format from the NIST Computer Security Resource Center at
http://csrc.nist.gov/publications.

For a complete list of references, consult NIST SP 800-64.

NIST SP 800-12, An Introduction to Computer Security: The NIST
Handbook, provides guidance on the fundamentals of information system
security.

NIST SP 800-18, Guide for Developing Security Plans for Information
Technology Systems, discusses developing and updating security plans.

NIST SP 800-23, Guidelines to Federal Organizations on Security
Assurance and Acquisition/Use of Tested/Evaluated Products, discusses
the concept of assurance.

NIST SP 800-30, Risk Management Guide for Information Technology
Systems, discusses the risk-based approach to security and provides
guidance on conducting risk assessments.

NIST SP 800-31, Intrusion Detection Systems (IDS), and NIST SP 800-41,
Guidelines on Firewalls and Firewall Policy, provide information on
using and deploying IDSs and firewalls.

NIST SP 800-35, Guide to Information Technology Security Services,
covers evaluating, selecting, and managing security services
throughout the life cycle.

NIST SP 800-42, Guidelines on Network Security Testing, describes
available security testing techniques, their strengths and weaknesses,
and the recommended frequencies for testing as well as strategies for
deploying network security testing.

NIST SP 800-53, Recommended Security Controls for Federal Information
Systems, provides recommended security controls based on system impact
level (available as a draft at
http://csrc.nist.gov/publications/drafts.html.

Information about Federal Information Processing Standards (FIPS),
including FIPS- approved algorithms and cryptographic modules that
must be used by federal agencies, is available at
http://csrc.nist.gov/publications/fips/index.html.

Office of Management and Budget documents that cover life cycle
planning issues include OMB Circular A-11, Part 3, "Planning,
Budgeting, and Acquisition of Capital Asset, and OMB Memorandum 00-07,
"Incorporating and Funding Security in Information Systems
Investments."

Disclaimer
Any mention of commercial products or reference to commercial
organizations is for information only; it does not imply
recommendation or endorsement by NIST nor does it imply that the
products mentioned are necessarily the best available for the purpose.



-
ISN is currently hosted by Attrition.org

To unsubscribe email majordomo () attrition org with 'unsubscribe isn'
in the BODY of the mail.