How control gates can help secure the software development life cycle
Connecting state and local government leaders
Two of the most challenging issues for software development are security and privacy. Use of control gates is one way to evaluate and adjust security aspects of the project in a timely manner with management’s full attention. They can be viewed as an accountability tool for executive sponsors and project managers.
This article, the second in the series on Securing the Software Life Cycle, explores how control gates or decision points can be used to mitigate risk in software projects. Its focus is on products and artifacts that can be used by managers and other key decision-makers who are critical to the process of integrating security requirements into the software development life cycle (SDLC).
We’ve all heard stories of projects that failed after millions of dollars had been invested. Much of this failure can be attributed to poor planning, incomplete or "creeping" requirements and lack of effective control gates. Two of the most challenging issues for software development are security and privacy. It is imperative to ensure that no decision at an SDLC control gate is made without an assessment of the security status. Use of control gates is one way to evaluate and adjust security aspects of the project in a timely manner with management’s full attention. Control gates also help ensure that security requirements are upheld within the SDLC process and eliminate any "plausible deniability" by executive sponsors regarding security controls or lack thereof. Control gates can be viewed as an accountability tool for executive sponsors and project managers.
In project management, a control gate may be viewed as a point in time when the system development effort will be evaluated and when management will determine whether the project should continue as is, change direction or be discontinued. Another explicit definition describes control gates as "executive control points." These are "like ‘gates’ between phases and major stages of the project that represent major project ‘milestones’. At these gates, the project manager presents certain predetermined ‘deliverables’ to the project sponsor, top management or ‘executive’, whoever has the authority to approve further project funding."
The concepts of pre-determined deliverables and executive-level involvement emphasized in the latter definition cannot be over-emphasized. Regardless of which process is used, it is critical that we identify where security input must be included so that the 'go" or "no go" decisions at selected phases and stages are made with full knowledge of the security implications. Considerations include addressing confidentiality, integrity and availability of the system in development, and impact to the organization’s reputation, resources and revenue should security be compromised.
In summary, control points may be viewed as strategic decision points inserted into the SDLC and associated project plan designed to assist project sponsors and their supporting management team in determining project status. Use of effective control gates is especially critical for complex projects of long duration.
What are the basic characteristics of a security-supportive control gate? That is, one that offers an audit trail about actions taken in the interest of security along the software development path. Credible control gates should always require attestation in writing by executive sponsors and other management personnel responsible for project decision-making. They must also be inserted as milestones in the formal project plan prior to its formal acceptance. Security control gates must be present and operate in tandem with generally defined control gates appended to each phase of the SDLC. Security-related artifacts used to support decisions specific to the security aspects of a given project must be both definable and assessable by some agreed-upon metric.
We’ll now look at each phase of the SDLC and offer suggestions for artifacts that may be used, but let’s first look at some key roles normally involved in the process. The list below is not all-inclusive. Specific participants are dependent upon type of organization, available resources and other variables. To see a list of roles and responsibilities recommended for a typical government project, see the National Institute of Standards and Technology’s Special Publication 800-64.
Key roles and responsibilities in the control gate decision-making process
Executive sponsor (authorizing official). This individual requests that the project be initiated and has approved preparation of a project proposal, aligning functionality with the overall business goals and objectives. This is usually the senior decision-maker with authority over other designated project managers involved with software development.
Project managers. These are individuals charged with day-to-day management of the project team, including requests for and allocation of resources (human, financial, facilities, equipment, training, etc.). They are also responsible for providing regular status on the project to the executive sponsor.
Chief information officer. This individual is charged with lead responsibility for overall information technology strategy, planning and deployment within an organization. The CIO acts as an expert resource for executive sponsors, management and the organization at large on all matters regarding information technology architecture and deployment.
Chief information security officer. This individual is charged with lead responsibility for developing and implementing an enterprise information security program, including policies and procedures. This person is also responsible for coordinating security requirements for projects under development and advising executive sponsors, management and the organization at large on matters of security compliance and performance.
End-user representatives. These individuals are usually operational managers whose job functions include use of the target system in a manner that supports objectives such as developing products, delivering services or conducting research, quality control or oversight activities. Representatives speak for their respective constituencies and their associated areas of responsibility.
Capital planning and budget representatives. These are individuals within the enterprise charged with lead responsibility for managing budget operations and acquisition/contracting functions.
Configuration management/change control board participants. These individuals represent an oversight body charged with managing proposed changes to information systems. This includes approving or disapproving both architectural and technical (code) modifications.
Security Control Gates and Integration of Security Artifacts
Let’s now look at some common phases of the SDLC with specific focus on control gates and security components that help establish the security posture of the project at each stage.
1. Planning and initiation
The main deliverable or control gate resulting from work in this phase is an approved set of requirements that define the system functionality to be developed. All security requirements must be included as part of the deliverable expressed as a set of security controls. Regardless of the SDLC applied, at some defined point in time, concurrence must be achieved on what is to be delivered prior to proceeding. Risk associated with this phase is very high if effective control gates are not applied. Failure to identify and incorporate security controls in the requirements may result in a need to retrofit them after the fact or a failure to incorporate them at all.
|
Questions (“go/no go”) to be addressed by executive sponsor and project manager |
Candidate control gates (for executive sponsor and management’s attestation) |
Security components (for security attestation) |
|
· Is this project consistent with and supportive of the overall goals and objectives of the organization? · Can the project be supported with resources currently available or projected to be available in the timeframe desired? · Can the project be achieved based on technology available in the marketplace? |
· Project proposal · Feasibility study |
· Security team budget, staffing and training · Security team roles and responsibilities |
2. Analysis and requirements development
The main deliverable or control gate resulting from work in this phase is an approved set of requirements that define the system functionality to be developed. All security requirements must be included as part of the deliverable and expressed as a set of security controls. Regardless of the SDLC applied, at some defined point in time, concurrence must be achieved on what is to be delivered prior to proceeding.
|
Questions (“go/no go”) to be addressed by executive sponsor and project manager |
Candidate control gates (for executive sponsor and management’s attestation) |
Security components (for security attestation) |
|
· Have all stakeholders participated in the process of developing the requirements? · Have the agreed upon security controls been included? · Do we have a final requirements document which reflects the functionality agreed upon? · Do we have the supporting acquisition documents in place to procure contract support consistent with the project schedule? |
· Statement of project scope · Finalized project plan · Requirements document · Acquisition plan with supporting artifacts (if required) |
· Description of security functionality · Description of security resources required and timeframes for security deliverables · Preliminary risk assessment · Security control requirements/security plan · Description of security requirements and tasks to be completed by contractor (if required) Note: The contractor plan should be concurred with by the CISO to ensure that all security aspects of the planned contractual activity are compliant with current security policy and procedures and do not introduce unacceptable risk into the project. |
3. Design
In this phase, after all prior control gates have been approved, the system is finally ready for development. Based on the SDLC employed, this may be an iterative rather than sequential process with use of prototypes. However, control gates must still be in place to support decision-making at critical points in the process.
|
Questions (“go/no go”) to be addressed by executive sponsor and project manager |
Candidate control gates (for executive sponsor and management’s attestation)) |
Security components (for security attestation) |
|
· Is the system design consistent with the enterprise architecture, including the security components of that architecture? · Does it address the agreed upon requirements? · Have risks identified been mitigated or eliminated? · If not, has the executive sponsor agreed to accept the risk? |
· Detailed system architecture/System design documentation · Updated requirements document based on final design · Contract award (if required) |
· Approve security architecture · Updated risk assessment · Updated security control documentation · Contractor security functions, tasking and deliverables |
4. Implementation
In the implementation phase, the target system is built and tested. All resources are allocated, and the executive sponsor has high confidence in its success based on control gate information delivered and approved to date.
|
Questions (“go/no go”) to be addressed by executive sponsor and project manager |
Candidate control gates (for executive sponsor and management’s attestation) |
Security components (for security attestation) |
|
· Does the system correctly implement the functionality defined by the agreed upon requirements? · Have security controls been properly implemented? · Are there any performance issues? · Have users been adequately trained? · Have risks identified been mitigated or eliminated? (Repeated in this phase) · If not, has the executive sponsor agreed to accept the risk? (Repeated in this phase)
|
· System test readiness review · End-user training evaluation · System authorization documentation |
· Security control test review · Security components training evaluation
|
5. Maintenance
In this phase, while using the system, we are reassessing its status based on user feedback, technology changes, policy changes, new threats and vulnerabilities and a multitude of other management and business issues. Issues of performance, adequacy and relevancy have priority in discussions related to the system.
|
Questions (“go/no go”) to be addressed by executive sponsor and project manager |
Candidate control gates (for executive sponsor and management’s attestation) |
Security components (for security attestation) |
|
· How is the system performing? · Does system functionality need to be changed? · Does system architecture need to change? · Has the system risk profile changed? · Is the system still needed? |
· Operational readiness review · Change control board review · System audit documentation (Status of findings/corrections) · System re-authorization request
|
· Security control review · Response to security-related audit findings · Updated risk assessment |
6. Disposal
|
Questions (“go/no go”) to be addressed by executive sponsor and project manager |
Candidate control gates (for executive sponsor and management’s attestation) |
Security components (for security attestation) |
|
· How should we proceed with sunsetting the system? · Have we identified all functions that must be supported after system disposal? · What, if any, security risks are associated with the disposal process? |
· Change control board review of system disposal/transition plan
|
· Security review of system disposal/transition plan · Media/sanitization plan (if required) |
Summary
Subsequent to discussing how we “bake” security into the SDLC, we’ve now looked at securing the software life cycle and how to best insert deliverables in the project life cycle that are designed to support management “go/no go” decisions regarding proceeding from one phase to the next. Looking forward, we will address other aspects of building a strong security presence within established organizational processes.
NEXT STORY: iPhone overcoming IT security skepticism