System Development Life Cycle (SDLC) Framework

The SDLC framework is a multi-step outline that describes the life cycle of an information system.

 The five phases of the SDLC are:

• INITIATION
• ACQUISITION AND DEVELOPMENT
• IMPLEMENTATION
• OPERATIONS AND MAINTENANCE
• DISPOSAL

Security that is integrated into this life cycle becomes:

• More consistent
• More useful
• More effective
• More cost efficient

1. Initiation Phase

This is where the need and purpose for the information system is defined and documented.  It is important to involve key stakeholders and/or business partners in this phase, whether they are internal or external to the group defining the system.

The requirements for the information system must be established, but at this point, some of them will be in general terms.  This includes:

• System Characterization
• Beginning to outline the Risk Assessment process

The ongoing process of collecting system knowledge begins here with:

• Inventory and Asset Management
• Site Security Plan
• Risk Assessment
• Configuration Management

2. Acquisition and Development Phase

In the previous phase (Initiation), system characterization was done, an impact category was assigned, the risk assessment process began with impact assessments and some general security requirements should have defined.

Risk management is at the core of this phase. It begins with assessing risk and laying the foundation for defining security requirements in the following steps:

Risk Assessment

• Threat Identification
• Vulnerability Identification
• Risk Analysis
• Control Recommendations
• Documentation

Risk Mitigation – security controls that mitigate risk

• Baseline of controls (selected by impact category in the previous phase)
• Tailoring of controls
• Supplementing controls

Security Plan

The phase continues with Security Planning, which is the process of documenting the requirements for security protection as they are being developed or changed. This began in the last phase and continues in this phase with the same key areas:

• Inventory/Asset Management (I/AM)
• Site Security Plan (SSP)
• Risk Assessment (RA)
• Configuration Management (CM)

There are other parts and components of security planning that are not listed above. (for more in depth information, visit the Security Planning section)

The next phase is Implementation, where controls are put into action and tested and the process of authorization (known as C&A) takes place.

3. Implementation and Assessment Phase

This phase involves integrating the defenses into the information system though the following steps:

• Security controls are enabled
• Configuration baseline is established
• Testing

The Federally required process of Certification & Accreditation revisits every step of the SDLC Framework to make sure they have been accomplished adequately and offers a credible statement of such.

As in each of the previous phases, security documentation must have any changes updated into them, specially in the following areas:

• I/AM (Inventory/Asset Management)
• SSP (Site Security Plan)
• RA (Risk Assessment)
• CM (Configuration Management)

4. Operations and Maintenance Phase

In this phase, configuration management continues with monitoring for configuration changes and establishing a change control process.

Continuous Monitoring maintains a constant vigil on some of the most critical components of information security and feeds the results back to the appropriate process: incident handling, change control, patch management, and more.

Any changes to controls or process must be documented in these key areas (among others):

• I/AM
• SSP
• RA
• CM
• Security Assessment Report (SAR)

5. Disposal Phase

Without correctly finishing up, all the previous defensive measures can be wasted. The following steps are taken to ensure correct disposal:

• Information preservation
• Media Sanitization
• Hardware and software disposal

Documentation must be updated. Of special interest at the this stage is Inventory and Asset Management, but you must give some concern to how retired equipment, software or information might affect other aspects of security. The starting list is:

• I/AM
• SSP
• RA
• CM
• SAR

Processes and Controls

Here are some processes across the SDLC Framework and related security controls:

INITIATION Phase

• Characterize the system
  •  Need, purpose, function, data, flows…
  • CA-3 System Interconnections
  • CM-8 Component Inventory
  • RA-2 System Categorization
  • PE-16 Delivery and Removal

ACQUISITION AND DEVELOPMENT Phase

• Risk Assessment
  • RA-5 Vulnerability Scanning
  • SI-2 Flaw Remediation
• Security Control Implementation
  • ALL CONTROLS (Baseline)
• Configuration Settings
  • CM-6 Configuration Settings
• Security Plan
  • PL-2 Security Plan (+all PL family controls)
  • RA-4 and PL-3 Update Documentation

IMPLEMENTATION AND ASSESSMENT Phase

• Configuration Baseline
  • CM-2 Configuration Baseline
• Testing
• C&A
  • CA-2 Security Assessment
  • CA-4 Certification
  • CA-6 Accreditation
  • CA-5 POA&Ms
• RA-4 and PL-3 Update Documentation

OPERATIONS AND MAINTENANCE Phase

• Configuration Control
  • CM-3 Configuration Control
  • CM-4 Monitoring Configuration Change
• Continuous Monitoring
  • CA-7 Continuous Monitoring
  • SI-2 Flaw Remediation
  • RA-5 Vulnerability Scanning
  • SI-4 Network Monitoring
  • SI-7 Integrity
  • CA-5 POA&Ms
• RA-4 and PL-3 Update Documentation

DISPOSAL Phase

• Media Sanitization
  • MP-6 Media Sanitization
• RA-4 and PL-3 Update Documentation

Implementation

In addition to the IMPLEMENTATION Phase of the SDLC, smaller pieces of the general implementation process are scattered across other parts of the framework.

Here is map showing some of the implementation related processes, including links to those sections:

INITIATION Phase

• Characterize the system

ACQUISITION AND DEVELOPMENT Phase

• Risk Assessment
• Security Control Implementation
• Configuration Settings
• Security Plan

IMPLEMENTATION AND ASSESSMENT Phase

• Configuration Baseline
• Testing
• C&A

OPERATIONS AND MAINTENANCE Phase

• Configuration Control
• Continuous Monitoring

DISPOSAL Phase

• Media Sanitization

Patch and Vulnerability Management

NIST 800-40 “Creating a Patch and Vulnerability Management Program” describes the functions and processes that a patch and vulnerability management program should cover in order to maintain effective security.

Importance of patch management

As operating systems, applications and utility tools continue to manifest exploitable flaws, rapid application of security patches becomes critical to security. Attackers can reverse engineer patches and develop exploits that penetrate the vulnerability made public when the patch is released. Most organizations do not perform the patching task well enough to minimize the timeframe of vulnerability. They often do not have adequate inventory records and miss patching some systems. They often do not have formalized procedures for testing and deploying patches promptly.

Description of the patch and vulnerability group (PVG)

The composition and structure of the PVG will vary with the system being defended, the mission and information involved and the structure of the organization, but there are elements likely to be common and which should be considered. Team members may come from both the operations and the information security areas and should represent skills for system administration, firewall configuration and management, intrusion detection, vulnerability scanning, patch management, and change control.

Functions of the PVG

• Inventory – creating and maintaining an accurate inventory of information system components is an essential pre-requisite to performing good patch and vulnerability management. Use existing IT inventory if possible and prioritize your target list by system, FIPS impact level, network location, high priority resources and whether or not they are supported by the central organization.
  See security controls PM-5 and CM-8.
• Monitoring
  • Monitoring security advisories, vulnerabilities and threats
    See security control SI-5
  • Monitoring your network and systems for vulnerabilities and evidence of incidents
    See security controls CA-7, SI-4, AU-6, RA-5
• Prioritize remediation actions according to the significance (threat/vulnerability matchup), the extent of the threat and the risk involved with taking the remediation action.
  See security controls CM-4 and RA-3
• Create a DB of remediations to ensure integrity and availability and to maintain a history.
• Testing the remediation before applying it is wise if possible
  • Authentication check
  • AV/malware scan
  • Application in a lab environment
  • Check for dependencies and ripple effects
  • Monitor the experience of others in the community
  • Make a balanced decision on the risk of taking the action versus the risk of not taking the action
    See security controls SI-3/7, SA-11, CM-4
• Remediation usually takes the following three forms:
  • Patching
  • Configuration changes
  • Removal of software or hardware
    See security control SI-2
• Verifying – this is often performed by vulnerability scanning, but can also involve examining patch logs, files and configuration settings, and doing penetration testing.
  See security controls RA-5, AU-6, CA-2/7
• Training – there may be training or some other form of knowledge distribution required after the vulnerability is closed
  See security control AT-3

NIST stresses the use of automated tools to accomplish many of these functions.

Metrics

Performance measurement of the progress made in the patching program should be considered in order to ensure security requirements are being met. This should include some of the following types of metrics:

• Susceptibility to attack – number of services running, number of vulnerabilities identified, number of patches required.
• Patching response time – this can be divided up into sub-categories such as; identification time, testing time, application of the patch time and possibly others.
• Cost – this too can be broken down into many sub-categories. It may be particularly effective to attempt to measure the cost saved by applying patches in terms of the cost of potential impact to business functions and loss if they had not been applied.

Continuous Monitoring

Continuous monitoring is about keeping an ongoing watch on how well your security controls are doing their job. NIST introduced this idea back in 2004 when they were also evangelizing about the Authorization process, then known as Certification and Accreditation (or C&A). By law (FISMA), NIST supplies federal organizations with security guidance, which can be mandatory or discretionary and flexible. C&A (now known as Authorization) is one of the mandatory pieces, requiring federal organizations to completely assess their security functionality every three years. It took most government organizations a lot of time and effort to get this process up and running, so at first, they tended to think of it as a massive project that reached a crescendo every three years, then faded into the background until the next rising, three years later. NIST wanted them to understand that security must be done in an ongoing fashion and created the “continuous monitoring” process.

Continuous monitoring preaches that only through a constantly ongoing assessment of the effectiveness of security controls, can you reach a dynamic understanding of how well your security is working. This dynamic, as real-time as possible, viewpoint of your security status is what is needed to make good decisions about handling risk and to back them up with documentation. When continuous monitoring is done correctly, it should also make the Authorization (C&A) process less onerous, less costly and more effective.

WHICH CONTROLS SHOULD BE MONITORED?

NIST tells us that we should monitor the controls that are most important, the controls which are most “volatile” (they change often), and POAM items (already identified weaknesses). It also makes sense to monitor controls that involve monitoring and controls that are already being closely monitored. Some controls are already (by their design) being continuously monitored and all that is needed is good documentation and reporting.

Most important controls: when computer security was just beginning, some of the first protections were perimeter protection (firewalls), malware protection (anti-virus), security updates (patch management), access control (logins) and configuration management (inventory, configuration settings, change control…). These things are still of primary importance and should be considered as some of your important controls.

Controls that change often: malware protection sits on a highly fluid foundation of changing threats and constantly updated methods of detecting them, vulnerability scanning and patch management are different versions of the same process and also change constantly. Information flow and system interconnections deal with areas that are fluid and may require constant tweaking. Configuration baselines should be fairly static, but current configuration settings may be constantly changing.

POAM items: represent security control failures for the most part. Security control CA-5 “PLAN OF ACTION AND MILESTONES” requires plans for remediation of weaknesses to be tracked and this becomes a “key document” in the Authorization (C&A) process. Since open POAMs may represent a vulnerability, they should be closely watched and any temporary compensating measures should also be monitored. As a POAM item is being fixed and closed, some attention through the change control process and impact analysis may be needed and a new assessment may be needed.

Controls that involve monitoring: network and system monitoring, audit record monitoring and analysis, incident monitoring, POAMs, change control monitoring, inventory monitoring, access control monitoring, and information disclosure monitoring are some of the monitoring controls to consider.

Controls that are already being closely monitored: patch management, malware protection, vulnerability assessment, network and system monitoring, and POAMs. These controls are often monitored closely and may simply need documentation and reporting to plug them into the Authorization process.

As you go through the list of security controls, looking for good candidates to monitor, you’ll notice the same controls coming up over and over again under different categories. Some of these include: patch management (SI-2), network and system monitoring (SI-4), malware protection (SI-3), and several configuration management controls (inventory CM-8, configuration settings CM-6, change control CM-3, impact analysis CM-4).

ALL controls are important and must be monitored in some fashion but some controls are more important than others and need to monitored at different levels and with different frequency. Define the importance level of each control for your organization and determine what monitoring frequency is needed.

REPORTING

Ensure that the dynamic scope of the continuous monitoring is preserved and not lost by the documenting and reporting component. Feedback obtained from continuous monitoring should be supplied to the Authorization process. Key documents in the security plan should be updated more frequently. This includes mainly the Security Plan, the Security Assessment Report and the POAM, but can include other documents as well. The reporting frequency should be specified and documented as a requirement.

SUMMARY

Using continuous monitoring to create a dynamic viewpoint of the security status of the system enables better risk decisions and makes them more credible by backing them up with good documentation. This requires ongoing assessment of security controls throughout the SDLC framework. The Authorization process can be made more consistent and more cost effective (cheaper). Many of these controls are already being monitored anyway, but may not be being documented correctly. Document them and use the results.

Holistic Information System Security

Too often, we think about and plan our information security in terms of protecting pieces of the system. We use firewalls and Anti-Virus (AV) software and intrusion detection and integrity checking and many more techniques to provide needed protections to various pieces. But we may not be paying enough attention to the gaps between the pieces or how the pieces fit together.

System Development Life Cycle (SDLC) is a term most often used to describe all the phases of designing and building a system, from inception to implementation to retiring the system at end of life. The point of studying SDLC is to make sure that all the pieces are being taken into account and there is an awareness of the timeline and flow of system development.

The state of security of an information system benefits from using an SDLC point of view. We don’t build businesses in an instant and the same is true of information systems. The development of a business is spread out across a framework of time and so is the development of an information system and furthermore, the development of an information system is often spread out across the development of the business.

Think about the way we develop a business. We get an idea to build a lemonade stand on the sidewalk in front of our house and sell lemonade to people who walk by. Once we have the idea firmly in hand, we start to accumulate the resources we’ll need. We’ll need a couple of our friends to help and they will need cell phones to talk and text with each other. We’ll need some materials to build the stand and some materials to make advertising posters. We’ll need a desk and a chair and a computer to run a spreadsheet to keep track of expenses and revenues.

This is also how adult world businesses start up. They need to lease/rent office space and get phone systems. They need to hire staff. At some point, they will need to plan for an information system, but they may need staff and space and some rudimentary level of resources before the information system. And there are information system security controls involved with every one of those steps.

Consider the following security controls:

• PM-11 MISSION/BUSINESS PROCESS DEFINITION
• PL-2 SYSTEM SECURITY PLAN
• RA-2 SECURITY CATEGORIZATION
• PS-3 PERSONNEL SCREENING
• CM-8 INFORMATION SYSTEM COMPONENT INVENTORY
• PE-16 DELIVERY AND REMOVAL
• PL-5 PRIVACY IMPACT ASSESSMENT
• CA-3 SYSTEM INTERCONNECTIONS

Most if not all of these controls should be considered right at the beginning of a business or enterprise. The point of studying the SDLC is to integrate security planning during business planning and before decisions are being made that may affect purchasing and implementing information system components.

Interconnection Security

The most fundamental reason to interconnect systems is to share data, but that can be accomplished at a variety of levels. A system interconnection can be limited and simple, using email to transfer data between systems, or it could allow two databases to share data. It can be a connection that is only used when needed or one that is active all of the time. It can allow full interactivity and collaboration amongst users and can perform network infrastructure functions such as data backup and more. Likewise, interconnections can use different forms of connection media, from dial-up to leased lines to authenticated and encrypted VPNs.

Any form of data sharing or interconnection creates an environment of shared risk and requires a fresh assessment of the new risk environment. The two sides of the interconnection may have different security requirements and corresponding differences in their security controls and configurations. How sensitive data is protected may be different and the users may operate under different rules of behavior.

For organizations involved with the US Federal Government, security controls are guided by NIST SP 800-53 and guidance for the security of interconnections is provided in NIST SP 800-47 “SECURITY GUIDE FOR INTERCONNECTING INFORMATION TECHNOLOGY SYSTEMS”. OMB Circular A-130 Appendix III requires federal agencies to obtain written authorization for all interconnections (prior to connecting) that is based upon an assessment of acceptable risk and security controls that are in accordance with NIST guidance.

Security control CA-3 INFORMATION SYSTEM CONNECTIONS requires an authorization of all connections outside the accreditation boundary and ongoing monitoring of the connection. Based on a determination of need, a document called the “Interconnection Security Agreement” (ISA) may be required and is often accompanied by a “Memorandum of Understanding” (MOU). The need is usually determined by the similarity and commonality of the information systems. For a connection to an outside, non-federal organization, the ISA is likely to be required. For a connection to another federal agency that operates under NIST guidance and has a robust Assessment and Authorization (aka C&A) process, the need may not be great or the document may be less rigorous. On the other hand, it is possible to require close scrutiny and documentation of a system that resides on the same network inside the same agency if the security requirements and protections are very different.

In order to maintain security, when an interconnection is created between information systems, the level of security protections and risk involved must be assessed and compared from both sides of the connection. Even if both sides have done their own security well, one side may have risks involved (threats and vulnerabilities) that the other side does not, or may not have protections in place because of an absence of risks. Once the connection is established, the risks become shared and new protections may be required. This also requires a high level of knowledge sharing and transparency between the groups involved.

Depending upon the organizational environment, it may be necessary to create a joint planning team, layout the business case for the interconnection and if there is a federal agency involved, collect assessment and authorization (C&A) documentation. In ANY case, requirements will need to be determined and should consider the following areas:

• The method and level of the interconnection and potential impact on the security posture on both ends.
• Hardware, software and data involved.
• Users, services and applications involved.
• Security controls
  • Most of the PM family controls should be considered as a prelude
  • CA-3 INFORMATION SYSTEM CONNECTIONS – Requires authorization of all connections outside the accreditation boundary, requires ongoing monitoring, requires risk analysis
  • AC-4 INFORMATION FLOW ENFORCEMENT – authorizations for controlling the flow of information within the system and between interconnected systems
  • SC-7 BOUNDARY PROTECTION – establishes boundary protection devices that monitor and control communications through specified managed interfaces
  • Virus Scanning (SI-3)
  • Intrusion Detection (SI-4)
  • Identification and Authentication (IA) controls
  • Physical/Environmental Security (PE) controls
  • Auditing (AU) controls
  • Incident Handling/Reporting (IR)
  • Assessment and Authorization (CA) controls
• Security process areas:
  • Contingency planning
  • Configuration management (with specific focus on change control)
  • Incident response
  • Data ownership and backups
  • Rules of behavior
  • Awareness and training
• Scheduling
• Cost and budget issues

Once the requirements have been established and a plan has been fabricated, it must be documented and approved. The process continues with implementing the plan to establish the connection, maintaining the connection and eventually, disconnection.

It’s interesting to note that if no interconnection is ever established for an information system (an “air-gap”), security requirements may be significantly lessened. In a way, interconnection security is often a microcosm of the whole world of information security. And cloud security can easily be considered in the same manner.

The NIST PM Security Control Family

The NIST PM control family is a set of security controls that were added to the NIST SP 800-53 catalog of controls in version 3. These controls are fundamental and foundational and need to be established early in the System Development Life Cycle (SDLC). They lay the groundwork for processes that are critical to information security and should be considered pre-requisites for other important security controls. The success of implementing effective security controls across the information system will depend upon the success of implementing these program management controls.

• PM-1 – INFORMATION SECURITY PROGRAM PLAN – this control requires the development of an information security program plan that provides:
  • an overview of the requirements for the security program and a description of the management controls and the common controls
  • enough information about these controls to enable both an implementation of them that is compliant with the intent and a determination of the risk involved
  • roles, responsibilities, management functions, co-ordination across organizational units, and compliance
  • approval by a senior official with both responsibility and accountability for the risk involved
• PM-2 – SENIOR INFORMATION SECURITY OFFICER – a SISO must be appointed.
• PM-3 – INFORMATION SECURITY RESOURCES – ensures that capital planning includes needed resources.
• PM-4 – PLAN OF ACTION AND MILESTONES PROCESS – control CA-5 – Plan of Action and Milestones calls for a POAM and refers to 800-37. PM-4 simply calls for a process that ensures there will be POAMs. This control is related to PM-10 – SECURITY AUTHORIZATION PROCESS.
• PM-5 – INFORMATION SYSTEM INVENTORY – an inventory of information systems is required by FISMA (public law). A component level inventory is called for by control CM-8 – Information System Component Inventory. Having an accurate inventory is an important prerequisite for Configuration Management and Risk Assessment.
• PM-6 – INFORMATION SECURITY MEASURES OF PERFORMANCE – this control requires the use of metrics and refers to 800-55.
• PM-7 – ENTERPRISE ARCHITECTURE – this control requires an architecture that can supply discipline and structure to managing the enterprise. It refers to 800-39 and FEA (Federal Enterprise Architecture). This control is related to PM-8 – CRITICAL INFRASTRUCTURE PLAN, PM-9 – RISK MANAGEMENT STRATEGY, and PM-11 – MISSION/BUSINESS PROCESS DEFINITION.
• PM-8 – CRITICAL INFRASTRUCTURE PLAN – critical infrastructure and key resources must be identified and protected. This control is strongly related to PM-11 – MISSION/BUSINESS PROCESS DEFINITION and PM-9 – RISK MANAGEMENT STRATEGY.
• PM-9 – RISK MANAGEMENT STRATEGY – a consistent, organization-wide risk management strategy defines a methodology for assessing risk, sets the level of risk tolerance, establishes a strategy for mitigation and monitoring. This control supports RA-3 – Risk Assessment and references 800-30 and 800-39. An important pre-requisite is PM-11 – MISSION/BUSINESS PROCESS DEFINITION.
• PM-10 – SECURITY AUTHORIZATION PROCESS – this control supports CA-6 – Security Authorization in establishing an authorization process and references 800-37 and 800-39.
• PM-11 – MISSION/BUSINESS PROCESS DEFINITION – mission and business processes define information protection needs that determine security controls. Risk tolerance is defined based on these definitions, making this control a pre-requisite to PM-9 – RISK MANAGEMENT STRATEGY. PM-11 is also a pre-requisite to RA-2 – Security Categorization, and references 800-60.

References: NIST SP 800 series documents.