Uncategorized The System Development Life Cycle: A Phased Approach to Application Security – Security Intelligence
Thinkstock
The system development life cycle (SDLC) is a formal way of ensuring that adequate security controls and requirements are implemented in a new system or application. Integrating technologies and practices into the development of new system and application deployments provides an opportunity to design security into the solution on the front end of the process, rather than retrofitting it after the solution is deployed.
To achieve this integration, the SDLC process for system and application deployments should be clearly outlined, with defined and enforced checkpoints that incorporate security reviews prior to moving to the next project phase. Without formally implementing the SDLC and generating the requisite deliverables, it is much more difficult to effectively manage the development process and ensure that security-related issues are adequately addressed.
What is the difference between the system development life cycle and the software development life cycle? The system development life cycle involves end-to-end people, processes and technology deployments, which includes software, infrastructure and change management. The software development life cycle focuses exclusively on software components, such as development planning, technical architecture, software quality testing and the actual deployment of the software. Put simply, the system development life cycle is more holistic and comprehensive.
The SDLC typically reflects the phased activities described below.
Prepare a formal project request to initiate all system development and integration activities. The request should include the project objectives, users of the system or application, criticality in terms of confidentiality, integrity and availability, and key time frames for completion.
Perform a feasibility study to determine whether the project request should be approved for development. The feasibility study should incorporate:
Information security teams should initiate their own involvement with the project during this phase to ensure that appropriate security concerns have been incorporated into the feasibility study.
Develop business and operational requirements specifications to ensure that the project requirements necessary to support business objectives are understood. Users and development teams generally lead this process. Business requirements should address:
Operational requirements should address:
This document should also describe the type of development activity that the project represents. Common project types include maintenance, enhancement, new system and emergency change. Criteria should be defined for when a development activity may be assigned to these categories.
Information security teams should be involved throughout the business and operational requirements phase to ensure that security concerns are properly addressed and reflected in the requirements document. The risk assessment methodology is largely performed during this phase, providing early security perspectives to the project team.
Transpose the business and operational requirements into functional requirements to reflect the anticipated user experience associated with the system or application. Functional specifications reflect the user’s perspective that has been translated into the preliminary design. For maintenance and enhancement activities, the focus is to document what is changing using a before/after description.
Functional specifications should include:
During the functional specifications process, information security teams should generally play a supportive role, supporting the project team’s effort to capture the preliminary design and functional description of the system or application. Functional specifications should include security-related information such as technical features (e.g., access controls) and operational practices (e.g., awareness and training). Information security teams should review and provide feedback on this document prior to the detailed design phase.
Develop detailed design specifications that translate functional specifications into a logical and physical design. Detailed design specifications are developed during the design phase of the SDLC and describe how the system or application is designed to satisfy the requirements documented in the functional specifications.
Detailed design specifications should include the following:
During the detailed design phase, once again, information security teams should support the project team’s effort to design the system to achieve the desired solution. Security professionals should participate in project meetings for major design reviews, including a security design review, and at the request of the project team. As part of the detailed design process, information security teams should assess whether security requirements have been adequately addressed and whether adequate testing plans are in place. They should also review the detailed design specifications prior to the next phase.
The development phase is where the system or application’s security features are developed, configured and enabled. Use the program specifications to describe the program logic and processing requirements. Program specifications are developed as part of the development phase prior to the commencement of programming. These specifications provide the thought process required to determine the steps to code the programs.
Information security teams should retain the right to perform source code reviews for critical aspects of the system or application, including user authentication, authorization and financial transactions. Source code reviews should have an enhanced focus on code provided by third parties, including offshore development organizations.
Unit testing aims to identify program problems within a standalone environment. Unit test criteria should include:
During the system testing phase, all program development for the project is completed and testing is performed to ensure that all functionality works as required. The system test environment is typically shared among all programmers with strictly controlled changes to the environment. System test criteria should include:
Where possible, system or application security testing should be executed using an automated testing tool. This will support the creation of test harnesses and procedures that can be used for regression testing during future enhancements.
During the system testing phase, information security teams should be heavily involved in reviewing the security tests being written by the project/test team and validating the security testing results. Security teams may also elect to perform a penetration test to validate that the development team did not overlook common security vulnerabilities.
Where an existing system or application is in place, parallel testing ensures that the functions within a simulated production environment are equivalent to the existing process.
The cutover/installation plan documents the transition from an old system or application to a new one. This plan should address any migration of production data that has not been performed. It should also address the installation activities and coordination with system users. Fallback procedures should be defined in the event of an erroneous transition.
A post-implementation review ensures that the system or application is operating at a satisfactory level. This review involves soliciting user feedback on the overall effectiveness of the project and achievement of the requirements, timelines, etc. This information provides valuable insight for future projects and identifies potential shortcomings in the SDLC.
Security teams should participate in the post-implementation review to confirm that the security capabilities deployed are satisfactory. At this time, the documentation of all security decisions made in support of the system or application is finalized and variances to the existing security policies and standards are noted. Where variances are permitted on a temporary basis, tracking is initiated to ensure that variances are resolved in accordance with an agreed-upon schedule.
The project management process should ensure conformance with all aspects of the SDLC. In this context, conformance refers to ensuring that the documents itemized above are created and then reviewed and approved prior to the project moving on to the next phase of the SDLC. Any modifications to a document, once approved, should be reviewed and all impacted groups should agree on the change.
Defect checking tools should be used to monitor and track identified defects during all testing phases. This provides the basis for making informed decisions regarding the status and resolution of any defects.
The SDLC ensures that project development is sufficiently integrated to provide adequate security in the resulting system or application. The SDLC should be documented and project development activities should conform to them; all should be guided by written standards and procedures for each phase. These standards should address design, programming, testing, implementation, documentation and maintenance and be flexible while incorporating security checkpoints to validate the adequacy of controls within the system or application.
Brian Evans, CISSP, CISM, CISA, CGEIT, FAIR is a Senior Managing Security Consultant with IBM Security Services who assists clients in building and managing …
read more
Thinkstock
Analysis and insights from hundreds of the brightest minds in the cybersecurity industry to help you prove compliance, grow business and stop threats.
