Integrating Security into the Systems Development Lifecycle
|Integrating Security into the Systems Development Lifecycle|
|CIO Council Security Practices Subcommittee (SPS)|
|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.10||Points of Contact|
Post this contact information with the publicly accessible BSP.
|2.0||What This BSP Does|
|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.|
|A sample policy document based on SSAs 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|
To work properly, this implementation has to be a cooperative venture between security and systems personnel. Keep those contacts open.
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)|
|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