######### Overview

The National Institute of Standards and Technology (NIST) defines the
systems lifecycle as \"the period of time beginning when the software
product is conceived and ending when the resultant software products are
no longer available for use.\"[^1] The systems development lifecycle
breaks this period 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.

It is SSA\'s policy to integrate security into the systems development
lifecycle for each application 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.

This chapter provides basic information on how SSA integrates security
into the systems development lifecycle. It applies to the development of
new application systems, as well as to modifications to existing
applications, whether development occurs in-house or under contract.

######### Responsibilities

SSA has determined that the best method to use for implementing security
controls is a team approach that crosses organizational lines. As a
result, most of the following organizations are involved in each step of
the systems security lifecycle to some extent. Additionally, other
components will be brought into the process if their expertise is
required. Thus, the following statement of responsibilities indicates
each participant\'s primary or lead areas, and is not intended to limit
participation throughout the systems development period.

**SSA Information Systems Security Officer**

The SSA Information Systems Security Officer (SSAISSO) is responsible
for:

-   setting national SSA security policy as it relates to the systems
    development lifecycle;

```{=html}
<!-- -->
```
-   evaluating the functionality of each application area to determine
    what security controls must be implemented;

```{=html}
<!-- -->
```
-   working with other components to develop security functionality;

```{=html}
<!-- -->
```
-   evaluating systems controls and determining whether or not those
    controls provide the proper level of security; and

```{=html}
<!-- -->
```
-   as the owner of the audit and integrity review systems, ensuring
    that those systems meet the audit and integrity review requirements
    of the agency.

**Office of Systems Requirements**

The Office of Systems Requirements (OSR) is responsible for:

-   developing functional requirements that will provide the level of
    control required by the SSAISSO;

-   developing a Validation Plan that includes validating security
    controls;

-   working with other components, including the SSAISSO, to determine
    the best method for implementing security controls; and

-   validating new systems functionality to ensure that security
    controls are effective.

**Office of Systems Design and Development**

The Office of Systems Design and Development (OSDD) is responsible for:

-   developing security controls in conjunction with the development of
    application functionality and

-   recommending alternative control methods if a needed control cannot
    be implemented.

**Office of Telecommunications and Systems Operations**

The Office of Telecommunications and Systems Operations (OTSO) is
responsible for:

-   implementing access control requirements;

-   maintaining the access control system; and

-   reporting security problems to the SSAISSO for necessary action.

**All Major SSA Components**

All major SSA components are responsible for:

-   determining the systems access requirements for their employees, and
    communicating those requirements to the SSAISSO;

-   reporting security problems to the SSAISSO for necessary action; and

-   determining and defining any additional user needs related to
    security and communicating those to the SSAISSO.

**Regional and Component Security Officers**

The Regional and Component Security Officers are responsible for:

-   reporting security problems to the SSAISSO and

-   recommending solutions for those security problems.

**Users**

Systems users are responsible for:

-   reporting security problems to their security officer for resolution
    and

-   assisting in defining security requirements for their operations,
    when appropriate.

######### Security and the Systems Development Lifecycle

There are three important aspects of computer security in relation to
the systems development lifecycle:

1.  Security must be considered from the first phase of the systems
    lifecycle.

2.  Development of computer security is an iterative process. The
    identification of vulnerabilities and the selection and
    implementation of safeguards continue as the system progresses
    through the phases of the lifecycle, including after the system has
    been released into production.

3.  All computer security considerations should be documented in the
    standard systems development lifecycle documents.

By making security an integral part of the systems development
lifecycle, we ensure that the security implications of new systems
functionality, or changing agency conditions or goals, are considered
and resolved in a systematic way. We also increase awareness of security
concerns by involving all components responsible for the development of
the application in the process of identifying vulnerabilities and
developing safeguards, from the systems security officers down to the
final users of the system.

######### Systems Planning and Development

1.  Evaluating the Security Implications of New or Changed Systems
    Functionality

```{=html}
<!-- -->
```
a.  Identifying Systems Changes that may Require Security Changes

> New or changed systems functionality is requested by the user
> community through OSR. As the OSR security staff becomes aware of
> these requests, they pass information on the changes to the SSAISSO,
> the Office of Operations, OSDD, OTSO, and any other components with an
> interest in the security of the system. For example, the Office of
> Disability Operations would have an interest in the security
> functionality built into disability systems.

b.  Analyzing the Security Implications

> Analysts from each involved security staff examine the information
> available about the proposed systems functionality. All major SSA
> components participate in examining the functionality to determine
> which positions require what access for a particular application.
>
> OTSO\'s primary concern is to ensure that access control requirements
> can be implemented properly. The OSDD audit and integrity review
> staff\'s interest is that audit and integrity review requirements can
> be implemented.
>
> The SSAISSO provides the security policy perspective, as well as
> determining audit and integrity review requirements in consultation
> with other involved components. The SSAISSO also examines the
> functionality to determine whether or not additional internal
> controls, such as a two PIN process, are required.
>
> The involvement of OSR is broader, since they must receive the user
> needs statement for security, audit, and/or control and develop the
> formal functional requirements documents for each security functional
> area.

2.  Security Teams Consult

Subsequent to each component having an opportunity to examine
information on the system, the various security teams discuss the
specific controls needed for the system. These discussions can be formal
meetings, such as the Security Kickoff meetings for access control and
the Audit Planning and Audit Steering Group meetings, or informal
discussions by phone. These discussions ensure that the controls
recommended for the system meet the needs of all of the involved
components.

3.  User Needs Statements Prepared

Based on the Team discussions, user needs statements are prepared. These
statements form the basis for the functional requirements documents
prepared by OSR. Included in the user needs statements are:

a.  Access Controls

Matrices showing which positions should have access to which systems
functions are prepared by each component whose employees require access
to the system. These matrices are submitted to the SSAISSO for review
prior to being sent to OSR for inclusion in their systems documentation.

b.  Audit and Integrity Review

Audit and integrity review user needs statements are prepared by the
SSAISSO in consultation with the Office of Operations and OSR to ensure
that these needs statements reflect both operational and systems
constraints. The user needs statements are submitted to OSR under cover
of a memorandum from the SSAISSO.

c.  Other Controls

The need for additional controls is stated by the SSAISSO in memoranda
to OSR describing the additional controls needed in sufficient detail
that OSR can prepare functional requirements based on the information
provided.

4.  Functional Requirements and Validation Plan

The Functional Requirements documents and the Validation Plans for
security functionality are written by the OSR security staff. The
SSAISSO reviews the functional requirements prior to release to OSDD for
development.

Access control matrices are reviewed by OSR and then forwarded to OTSO
for the necessary Top Secret profile modifications.

5.  Development and Validation of Security Features

Security functionality is developed in conjunction with all other system
functionality. If changes are made to the application system that effect
the types of security controls that are needed, then the security
controls are also changed.

After development is complete, the security functions, along with all
other system functionality, are validated in accordance with the
Validation Plan that was prepared by OSR during the requirements
definition process. A Validation Checklist is completed to document
completion of each validation task. If any requirement is not met, the
software must go back to the programming staff for corrective action. At
the end of the validation process the validated system is certified for
release to production. The Systems Release Certification document
contains this certification and the documentation supporting the release
of the software to production.

######### Systems Implementation and Operation

1.  As each new system is implemented, security officers in the
    operational components watch for potential security problems with
    the application, and report those problems to the SSAISSO for
    resolution.

2.  A compilation of lifecycle products for the system is maintained and
    available for review by auditors, and provides complete information
    on the development of the application, including the security
    functions.

3.  Periodically, each application system is subject to a
    recertification process, during which the application, including
    it\'s security functions, is examined to ensure that it still meets
    SSA\'s objectives.

**The SSA Systems Security Development
Lifecycle**![](media/image1.wmf){width="1.042361111111111in"
height="0.8444444444444444in"}

![](media/image2.wmf){width="1.9006944444444445in"
height="1.479861111111111in"}![](media/image3.wmf){width="1.3208333333333333in"
height="1.1409722222222223in"}

![](media/image4.wmf){width="1.0402777777777779in"
height="0.84375in"}![](media/image5.wmf){width="0.9548611111111112in"
height="0.7722222222222223in"}![](media/image6.wmf){width="0.9625in"
height="0.7784722222222222in"}![](media/image7.wmf){width="2.097916666666667in"
height="1.6958333333333333in"}![](media/image8.wmf){width="0.83125in"
height="0.18125in"}

**F. References**

**NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY**

Federal Information Processing Standards (FIPS) Publication (PUB) 73***,
[Guidelines for Security of Computer Applications, June
1980](http://csrc.nist.gov/fips/fips73.PDF)***

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](http://csrc.nist.gov/nistpubs/800-14.pdf)***

**OTHER**

President\'s Council on Management Improvement and the President\'s
Council on Integrity and Efficiency, *Model Framework for Management
Control over Automated Information Systems.* Washington, DC: GPO, 1988

**SOCIAL SECURITY ADMINISTRATION**

**SSA SOFTWARE ENGINEERING TECHNOLOGY MANUAL**

SSA Software Engineering Technology Manual (SET) Part 2, section 06.5
*Consider Control, Audit, Security and Privacy (CASP) Requirements*

> SSA Software Engineering Technology Manual (SET) Part 2, section
> 08.2.3 *Establish Control Mechanisms*
>
> SSA Software Engineering Technology Manual (SET) Part 2, section 10.7
> Determine the Control, Audit, Security and Privacy (CASP) Requirements
>
> SSA Software Engineering Technology Manual (SET) Part 2, Section
> 12.3.5 Establish Security Table(s)

SSA Software Engineering Technology Manual (SET) Part 2, Section 14.8.4
*Initiate Security Requirements*

SSA Software Engineering Technology Manual (SET) Part 3, chapter 03,
*Internal Control and Security*

[^1]:     ^?^FIPS PUB 101, *Guideline for Lifecycle Validation,
    Verification, and Testing of Computer Software*, June 1983, p.4.