[Entity]

No:
Information Technology Standard

IT Standard: Updated:

Issued By:
Secure System
Development Life Cycle Owner:

1.0 Purpose and Benefits

While considered a separate process by many, information security is a business
requirement to be considered throughout the System Development Life Cycle (SDLC).
This Secure System Development Life Cycle Standard defines security requirements
that must be considered and addressed within every SDLC.
Computer systems and applications are created to address business needs. To do so
effectively, system requirements must be identified early and addressed as part of the
SDLC. Failure to identify a requirement until late in the process can have major
repercussions to the success of a project and result in project delivery delays,
deployment of an inadequate system, and even the abandonment of the project.
Furthermore, for each phase through which a project passes without identifying and
addressing a requirement, the more costly and time-consuming it is to fix problems
that occur because of the omission.
Information security must be adequately considered and built into every phase of the
SDLC. Failure to identify risks and implement proper controls can result in inadequate
security, potentially putting entities at risk of data breaches, reputational exposure,
loss of public trust, compromise to systems/networks, financial penalties and legal
liability.

2.0 Authority
[Authority Needed]

3.0 Scope
[Scope Needed]
4.0 Information Statement
Security is a requirement that must be included within every phase of a system
development life cycle. A system development life cycle that includes formally defined
security activities within its phases is known as a secure SDLC. Per the Information
Security Policy, a secure SDLC must be utilized in the development of all applications
and systems.
At a minimum, an SDLC must contain the following security activities. These activities
must be documented or referenced within an associated information security plan.
Documentation must be sufficiently detailed to demonstrate the extent to which each
security activity is applied. The documentation must be retained for auditing purposes.
1. Define Security Roles and Responsibilities
2. Orient Staff to the SDLC Security Tasks
3. Establish a System Criticality Level
4. Classify Information
5. Establish System Identity Credential Requirements
6. Establish System Security Profile Objectives
7. Create a System Profile
8. Decompose the System
9. Assess Vulnerabilities and Threats
10. Assess Risks
11. Select and Document Security Controls
12. Create Test Data
13. Test Security Controls
14. Perform Certification and Accreditation
15. Manage and Control Change
16. Measure Security Compliance
17. Perform System Disposal
There is not necessarily a one-to-one correspondence between security activities and
SDLC phases. Security activities often need to be performed iteratively as a project
progresses or cycles through the SDLC. Unless stated otherwise, the placement of
security activities within the SDLC may vary in accordance with the SDLC being
utilized and the security needs of the application or system. Appendix A: Security
Activities within the SDLC provides a sample correlation of security activities to a
generic system development life cycle. Appendix B: Description of Security Activities
provides a description of the above security considerations and activities.
Finally, it is important to note that the Secure SDLC process is comprehensive by
intention, to assure due-diligence, compliance, and proper documentation of security-
related controls and considerations. Designing security into systems requires an
investment of time and resources. The extent to which security is applied to the SDLC

Secure System Development Life Cycle Page 2 of 4

 process should be commensurate with the classification (data sensitivity and system
criticality) of the system being developed and risks this system may introduce into the
overall environment. This assures value to the development process and deliverable.
Generally speaking, the best return on investment is achieved by rigorously applying
security within the SDLC process to high risk/high cost projects. Where it is
determined that a project will not leverage the full Secure SDLC process – for
example, on a lower-risk/cost project, the rationale must be documented, and the
security activities that are not used must be identified and approved as part of the
formal risk acceptance process.
Note: Data classification cannot be used as the sole determinate of whether or not the
project is low risk/cost. For example, public facing websites cannot be considered low
risk/cost projects even if all the data is public. There is a risk of compromise of the
website to inject malware and compromise visitor’s machines or to change the content
of the website to create embarrassment.

5.0 Compliance
This standard shall take effect upon publication. Compliance is expected with all
enterprise policies and standards. Policies and standards may be amended at any
time; compliance with amended policies and standards is expected.
If compliance with this standard is not feasible or technically possible, or if deviation
from this policy is necessary to support a business function, entities shall request an
exception through the Chief Information Security Officer’s exception process.

6.0 Definitions of Key Terms

Term Definition

7.0 Contact Information

Submit all inquiries and requests for future enhancements to the policy owner at:
[Entity Address]

8.0 Revision History

This standard shall be subject to periodic review to ensure relevancy.

Date Description of Change Reviewer

Secure System Development Life Cycle Page 3 of 4

9.0 Related Documents
NIST Special Publication 800-30, Guide for Conducting Risk Assessments

NIST Special Publication 800-53, Security and Privacy Controls for Federal
Information Systems and Organizations

NIST Special Publication 800-53A, Guide for Assessing Security Controls in

Information Systems & Organizations: Building Effective Assessment Plans

Secure System Development Life Cycle Page 4 of 4

Appendix A: Security Activities within the SDLC

The table below shows the placement of security activities within the phases of a sample
SDLC. The actual placement of security activities within the system development life cycle
may vary in accordance with the actual SDLC being utilized in a project and the particular
security needs of the application or system. The NIST publications in the third column of
this table are recommended documents to provide guidance in the placement and
execution of security tasks within the system development life cycle. These documents are
available from the NIST website (http://csrc.nist.gov/publications/PubsSPs.html).

Figure A-1: Placement of Security Activities within SDLC Phases

NYS PMG Security Activity NIST
SDLC Phase Publications
System Initiation  Define Security Roles and  SP800-12
Responsibilities  SP800-14
 Orient Staff on the SDLC Security  SP800-35
Tasks  SP800-27
 Establish a System Criticality Level  SP800-47
 Classify Information (preliminary)  SP800-60
 Establish System Assurance Level  SP800-63
Requirements  FIPS 199
 Establish System Security Profile
Objectives (preliminary)
 Create a System Profile (preliminary)
System  Establish System Security Profile  SP800-23
Requirements Objectives (iterative)  SP800-30
Analysis  Classify Information (iterative)  SP800-36
 Decompose the System (preliminary)  SP800-53
System Design  Create a System Profile (iterative)  SP800-55
 Decompose the System (iterative)  SP800-64
 Assess Vulnerabilities and Threats  FIPS 140-2
(preliminary)
 Assess Risks (preliminary)
 Select and Document Security
Controls (preliminary)
System  Create test data  SP800-35
Construction  Assess Vulnerabilities and Threats  SP800-36
(iterative)  SP800-37
 Assess Risks (iterative)  SP800-51
 Select and Document Security  SP800-53
Controls (iterative)  SP800-53A
 Test security controls  SP800-55
System  Measure security compliance  SP800-56
Implementation  Document System Security Profile  SP800-57
 Document Security Requirements and  SP800-61
Controls

Appendix A Page 1 of 2
 NYS PMG Security Activity NIST
SDLC Phase Publications
System  Perform System Certification and
Acceptance Accreditation
 SP800-64
Operations &  Measure security compliance  SP800-26
Maintenance: (periodic)  SP800-31
 Manage and control change  SP800-34
 Perform System Certification and  SP800-37
Accreditation (iterative)  SP800-53A
 SP800-55
Disposition  Preserve information  SP800-12
 Sanitize media  SP800-14
 Dispose of hardware and software  SP800-35
 SP800-36
 SP800-64

Appendix A Page 2 of 2
Appendix B: Description of Security Activities

1. Define Security Roles and Responsibilities

Security roles must be defined and each security activity within the SDLC must be clearly
assigned to one or more security roles. These roles must be documented and include the
persons responsible for the security activities assigned to each role. Appendix C: Security
Roles within the SDLC provides guidelines for defining security roles and assigning
security activities to roles.

2. Orient Staff to the SDLC Security Tasks

All parties involved in the execution of a project’s SDLC security activities must understand
the purpose, objectives and deliverables of each security activity in which they are
involved or for which they are responsible.

3. Establish System Criticality Level

When initiating an application or system, the criticality of the system must be established.
The criticality level must reflect the business value of the function provided by the system
and the potential business damage that might result from a loss of access to this
functionality.

4. Classify Information
As per the Information Security Policy, all information contained within, manipulated by or
passing through a system or application must be classified. Classification must reflect the
importance of the information’s confidentiality, integrity and availability.

5. Establish System Identity Credential Requirements

All applications or systems which require authentication must establish a user identity
credential. The identity credential must reflect the required confidence level that the
person seeking to access the system is who they claim to and the potential impact to the
security and integrity of the system if the person is not who they claim to be.

6. Establish System Security Profile Objectives

When initiating an application or system, the security profile objectives must be identified
and documented. These objectives must state the importance and relevance of identified
security concepts (Appendix D: Security Concepts) to the system and indicate the extent
and rigor with which each security concept is to be built in or reflected in the system and
software. Each security concept must be considered throughout each life cycle phase and
any special considerations or needs documented.

The purpose behind establishing system security profiles and monitoring them throughout
the lifecycle is to be actively aware of the relative priority, weight and relevance of each
security concept at each phase of the system’s life cycle. Entities must verify that the
security profile objectives adequately consider all federal, state and external security
mandates for which the system must be compliant.

Appendix B Page 1 of 4
7. Profile the System
The system or application being developed must be iteratively profiled by technical teams
within the SDLC. A system profile is a high-level overview of the application that identifies
the application’s attributes such as the physical topology, the logical tiers, components,
services, actors, technologies, external dependencies and access rights. This profile must
be updated throughout the various phases of the SDLC.

8. Decompose the System

The system or application must be decomposed into finer components and its mechanics
(i.e. the inner workings) must be documented. This activity is to be iteratively performed
within the SDLC. Decomposition includes identifying trust boundaries, information entry
and exit points, data flows and privileged code.

9. Assess Vulnerabilities and Threats

Vulnerability assessments must be iteratively performed within the SDLC process. Threat
assessments must consider not only technical threats, but also administrative and physical
threats that could have a potential negative impact on the confidentiality, availability and
integrity of the system. Threat assessments must consider and document the threat
sources, threat source motivations and attack methods that could potentially pose threats
to the security of the system.

Threat assessments must adhere to all relevant state and federal mandates to which the
entity must comply and follow industry best practices including the documentation of the
assessment processes. Threat assessments and the underlying threat modeling
deliverables that support the assessment must also be fully documented. Appendix E:
Threat and Risk Assessment Resources includes a list of recommended resources for
performing threat assessments.

10. Assess Risk

Risk assessments must be iteratively performed within the SDLC process. These begin
as an informal, high-level process early in the SDLC and become a formal, comprehensive
process prior to placing a system or software into production.

All realistic threats and vulnerabilities identified in the threat assessments must be
addressed in the risk assessments. The risk assessments must be based on the value of
the information in the system, the classification of the information, the value of the
business function provided by the system, the potential threats to the system, the
likelihood of occurrence, the impact of the failure of the system and the consequences of
the failure of security controls.

All identified risks are to be appropriately managed by avoiding, transferring, accepting or

mitigating the risk. Ignoring risk is prohibited. Risk assessments must adhere to all
relevant state and federal mandates that the entity must document and be compliant.

Appendix B Page 2 of 4
The risk assessments must be periodically reviewed and updated as necessary whenever
the underlying threat assessment is modified or whenever significant changes are made to
the system. Appendix E: Threat and Risk Assessment Resources includes a list of
recommended resources for performing risk assessments.

11. Select and Document Security Controls

Appropriate security controls must be implemented to mitigate risks that are not avoided,
transferred or accepted. Security controls must be justified and documented based on the
risk assessments, threat assessments and analysis of the cost of implementing a potential
security control relative to the decrease in risk afforded by implementing the control.

Documentation of controls must be sufficiently detailed to enable verification that all

systems and applications adhere to all relevant security policies and to respond efficiently
to new threats that may require modifications to existing controls.

Residual risk must be documented and maintained at acceptable levels. A formal risk
acceptance, with executive management sign-off, must be performed for medium and high
risks that remain after mitigating controls have been implemented.

Security control requirements must be periodically reviewed and updated as necessary

whenever the system or the underlying risk assessment is modified.

12. Create Test Data

A process for the development of significant test data must be created for all applications.
A test process must be available for applications to perform security and regression
testing.

Confidential production data should not be used for testing purposes. If production data is
used, entities must comply with all applicable federal, state and external policies and
standards regarding the protection and disposal of production data.

13. Test Security Controls

All controls are to be thoroughly tested in pre-production environments that are identical, in
as much as feasibly possible, to the corresponding production environment. This includes
the hardware, software, system configurations, controls and any other customizations.

The testing process, including regression testing, must demonstrate that all security
controls have been applied appropriately, implemented correctly and are functioning
properly and actually countering the threats and vulnerabilities for which they are intended.
The testing process must also include vulnerability testing and demonstrate the
remediation of critical vulnerabilities prior to placing the system into production.

Appendix B Page 3 of 4
Appropriate separation of duties must be observed throughout the testing processes such
as ensuring that different individuals are responsible for development, quality assurance
and accreditation.

14. Perform Accreditation

The system security plan must be analyzed, updated, and accepted by executive
management.

15. Manage and Control Change

A formal change management process must be followed whenever a system or application
is modified in order to avoid direct or indirect negative impacts that the change might
impose. The change management process must ensure that all SDLC security activities
are considered and performed, if relevant, and that all SDLC security controls and
documentation that are impacted by the change are updated.

16. Measure Security Compliance

All applications and systems are required to undergo periodic security compliance
assessments to ensure they reflect a security posture commensurate with the definition of
acceptable risk. Security compliance assessments must include assessments for
compliance with all federal, state and external compliance standards for which the entity is
required to comply.

Security compliance assessments must be performed after all system and application
changes and periodically as part of continuous system compliance monitoring.

17. Perform System Disposal

The information contained in applications and systems must be protected once a system
has reached end of life. Information must be retained according to applicable federal and
state mandates or other retention requirements. Information without retention
requirements must be discarded or destroyed and all disposed media must be sanitized in
accordance with applicable federal and state standards to remove residual information.

Appendix B Page 4 of 4
Appendix C: Security Roles within the SDLC

Responsibility for each security activity within the SDLC must be assigned to one
or more security roles. To accomplish this, the default definition of an SDLC role
may be expanded to include security responsibilities and/or new security roles may
be defined to encompass security activities. In all cases, the assignment of security
activities to roles, and the identification of persons given responsibility for these
roles, must be clearly documented.

For the purpose of utilizing a consistent definition of roles across various SDLC’s, it is
highly recommended that entities utilize as guidelines the National Institute of
Standards and Technology (NIST) publications . Of specific relevance to the definition
of roles and SDLC frameworks are:

 NIST Special Publication 800-37 Rev. 2 Risk Management Framework for

Informtion Systems and Organizations: A System Life Cycle Approach for
Security and Privacy

Appendix C Page 1 of 1
Appendix D: Security Concepts

The makeup of a system and software from a security perspective is its security
profile and includes the following security concepts, which must be considered and
documented as part of a Secure SDLC process.

Figure D-1: Security Concepts

Concept Description
Confidentiality Protect against unauthorized information disclosure
Integrity Protect against unauthorized, unintentional or incorrect
modification of software or data.
Availability Ensure the availability of systems and information.
Authentication The process of establishing confidence in the identity of users or
information systems.
Authorization Establish access rights to resources.
Auditing/ Build a historical record of user actions and of critical system
Logging processes.
Session Ensure that a session maintains the confidentiality and integrity of
Management the information exchanged between a system and an authenticated
user.
Errors and Ensure that unintended and unreliable system behavior is securely
Exception handled. This helps ensure protection against confidentiality,
Management integrity and availability threats.
Configuration Ensure that the configurable parameters that are needed for
Parameters software or a system to run are adequately protected.
Management
Least Privilege Assign only the minimum allowable rights to a subject that requests
access to a resource for the shortest duration necessary.
Separation of Ensure that multiple conditions are met before granting
Privilege permissions to an object.
Defense in Layer security defenses in an application to reduce the chance of a
Depth successful attack.
Failing Securely Ensure the confidentiality and integrity of a system remains intact
even though system availability has been lost due to a system
failure.
Economy of Keep the system implementation and design as simple as possible.
Mechanisms
Complete Require access checks to an object each time a subject requests
Mediation access, especially for security-critical objects.
Open Design Use real protection mechanisms to secure sensitive information; do
not rely on an obscure design or implementation to protect
information (otherwise known as “security through obscurity”).
Least Common Avoid having multiple subjects share mechanisms to grant access
Mechanisms to a resource.
Psychological Ensure that security functionality is easy to use and transparent to
Acceptability the user.

Appendix D Page 1 of 2
Concept Description
Leveraging Promote the reusability of existing components. Reuse proven and
Existing validated code and standard libraries rather than creating custom
Components code.
Weakest Link Identify and protect a system’s weakest components.
Single Point of Eliminate any single source of complete compromise.
Failure

Information concerning these concepts is publically available at the US Department of

Homeland Security (DHS) Office of Cyber Security and Communications sponsored
website at https://buildsecurityin.us-cert.gov.

Appendix D Page 2 of 2
Appendix E: Threat and Risk Assessment Resources

In order to assure alignment with business compliance mandates, and help assure
efficient and effective delivery of security services, the use of industry-recognized
standards related to risk-based frameworks and secure system development life cycle
practices are recommended.

In particular, the use of NIST standards is highly recommended, especially for entities
required to comply with federal security mandates. The following NIST publications
provide recommended guidance for implementing risk management frameworks and
performing threat and risk assessments.

 NIST Special Publication 800-39 , Managing Information Security Risk:

Organization, Mission & Information System View
 NIST Special Publication 800-37 Rev. 2 Risk Management Framework for
Informtion Systems and Organizations: A System Life Cycle Approach for
Security and Privacy
 NIST Special Publication 800-30, Guide for Conducting Risk Assessments
 NIST Special Publication 800-53, Security and Privacy Controls for Federal
Information Systems and Organizations
 NIST Special Publication 800-53A, Guide for Assessing Security Controls in
Information Systems & Organizations: Building Effective Assessment Plans

NIST publications are available at the National Institute of Standards and

Technology website (http://csrc.nist.gov/publications/PubsSPs.html).

Appendix E Page 1 of 1