IWS - The Information Warfare Site
News Watch Make a  donation to IWS - The Information Warfare Site Use it for navigation in case java scripts are disabled

Integrating Security into the Systems Development Lifecycle

1.0 Identification Data
1.1 BSP Number
00013
1.2 BSP Title/Name
Integrating Security into the Systems Development Lifecycle
1.3 Version Number
1
1.4 Adoption Date
TBD
1.5 Approving Authority
CIO Council Security Practices Subcommittee (SPS)
1.6 Responsible Organization
Social Security Administration, Office of Financial Policy and Operations, Office of Information Systems Security
1.7 Level of BSP
1.8 Security Processes or other Framework(s) Supported
BSP Security Process Framework: Technical Security (SPF 6) and Security Program (SPF 1)

This BSP also supports the goals of PDD-63 by ensuring that appropriate security controls are in place for every automated system.

1.9 Reserved
1.10 Points of Contact
Government BSP Owner:

Post this contact information with the publicly accessible BSP.

  • Jack Garnish
    Social Security Administration, Office of Financial Policy and Operations, Office of Information Systems Security
    6401 Security Blvd, Baltimore, MD 21235
    Telephone: 410-965-2765
    Fax: 410-966-0527
    E-mail: jack.garnish@ssa.gov

Vendor Partner:

  • None
2.0 What This BSP Does
2.1 BSP's Purpose
This BSP should be useful to Agencies that develop in-house software and do not yet have a policy on integrating security into the systems development lifecycle.

Reasons for Implementing this Policy

The systems development lifecycle breaks the systems development process down into phases during which discrete systems products are developed. This approach to systems development leads to well documented systems that are easier to test and maintain, and for which an organization can have confidence that the system's functions will be fulfilled with a minimum of unforeseen problems.

2.2 Requirements for this BSP
Since this BSP integrates a vulnerability assessment and appropriate safeguards into the systems development process, it supports the implementation of all appropriate security/protection requirements.
3.0 What This BSP Is
3.1 Description of BSP
This BSP provides an entire extract from the SSA Systems Security Handbook, sample language that may be useful during the process, and a model policy statement.
3.1.1 Inputs:
  • Sample language that can be used as a model in developing language for manuals/instructions used by systems designers throughout the SDLC
3.1.2 Output:
A sample policy document based on SSA’s policy integrating security into the systems development lifecycle (SDLC) process is provided.
3.2 Relationship to Other BSPs
To be identified
4.0 How To Use This BSP
4.1 Implementation Guidance
  • Study your agency’s software development process. Obtain copies of the materials used by systems design and development during the SDLC. Talk to your systems development staff about how the process works. Develop some ideas of how you think security can be integrated into this process.
  • Think about the security structure at your agency. Is it highly centralized, or do you have a decentralized structure with security officers throughout the agency whose expertise can be used in integrating security into the SDLC? Your security structure will influence the details of the process that you implement.
  • Meet with your management. Discuss the reasons why integrating security into the SDLC will benefit your agency.
  • Meet with systems staff to discuss the details of how best to integrate security into your agency's SDLC.
  • Develop a draft policy. Work with systems staff on the integration of procedures into the SDLC documentation that will support this policy.
  • Continue to work with your system’s staff to keep your policy up-to-date, and to keep pace with changes in your systems development lifecycle. Remember that this is an iterative process that will evolve as conditions change in your Agency.

To work properly, this implementation has to be a cooperative venture between security and systems personnel. Keep those contacts open.

Please note:

A formal security plan is required by the Computer Security Act of 1987 for all systems containing sensitive information. At SSA, we have a Sensitive Systems Security Plans and Certification program that operates in parallel to the security in the SDLC process. Depending on your Agency needs, you may want to make sensitive system planning a part of your SDLC. We recommend the following references:

Computer Security Act of 1987, P.L. 100-235 (1988)

Office of Management and Budget (OMB) Circular No. A-130, "Management of Federal Information Resources"

NIST Special Publication No. 800-18, "Guide for Developing Security Plans for Information Technology Systems" dated December 1998.

4.2 Implementation Resource Estimates
Resources required: time and patience. The amount of staff time required to implement this policy will vary depending on conditions within your Agency.

Integrating security into the systems development lifecycle is important for the following reasons:

It is more effective.  Meaningful security is easier to achieve when security issues are considered as a part of a routine development process, and security safeguards are integrated into the system during its design.

It is less expensive.  To retrofit security is generally more expensive than to integrate it into an application.

It is less obtrusive.  When security safeguards are integral to a system, they are usually easier to use and less visible to the user.

4.3 Performance Goals and Indicators (Metrics)
Not applicable
4.4 Tools
None..
4.5 Training Materials
None.
Appendices
A Reference List
Federal Information Processing Standards (FIPS) Publication (PUB) 73, Guidelines for Security of Computer Applications, June 1980

SPEC PUB 500-153, Guide to Auditing for Controls and Security: A System Development Life Cycle Approach, April 1988

SPEC PUB 800-14, Generally Accepted Principles and Practices for Securing Information Technology Systems, September 1996