The SDLC
The Software Development Life Cycle (SDLC) is a process formulated to output reliable and high-performing software in the shortest possible production time, and at a lower cost. It consists of several phases, namely Planning, Design, Implementation, Testing, and Deployment.It’s not unheard of (by any means) for an organisation to spend millions on a project over a year or more, only to have to reject the whole thing due to fundamental security concerns discovered at the 11th hour. To avoid this incredibly costly and onerous waste, implementing a more Secure SDLC (S-SDLC) is vastly cheaper and a more effective risk control than hope alone!Most large organisations that are working on developing software – from scratch, or through any significant modification – follow the SDLC rather than other process frameworks that tend to be more intensely iterative, and more suitable for small teams.Each phase has its own discrete processes and characteristics to ensure reliable and smooth project control, and there are certainly aspects of security enhancement that are to be taken at each juncture. While this informational piece is geared to how you can improve the security of your overall SDLC from an overarching standpoint, it would be remiss not to take this opportunity to include a break-down of each phase of the SDLC and steps that may be taken within each.
Planning Phase:
During this period, we are looking to dictate an approach that encompasses and structures the Security measures that will be taking place at each subsequent stage, as well as for the overall Project. The selection of an appropriate standard like NIST and the option of implementing an Information Security Risk Assessment at this point is highly recommended. A Consultancy like Fort Safe can assist you in the strategy, direction and formation of these pivotal first steps.A big factor during this initial stage is to get the right budget (both in terms of time, and financial expenditure) that will allow for proper security measures to be taken, rather than being forced to add them as an addendum at a later date. This means that not only must you get buy-in from the team to put Security at the forefront of the project, but likely also the executive committee and/or project sponsors involved in the decision-making and sign-off.
Design Phase:
Following the Planning Phase is the Design Phase. The objective in primacy for this Phase is creation of a 10k foot view of the Software Architecture. During the Design Phase, key stakeholders and the development team contemplate the requirements and determine more intimately the Scope of Work of the system and software to be built.At this juncture, there’s a review of the foundational technologies to be used, the capability of the team, and project constraints of budget and time that underpin the nomination of an architectural design that will best meet the requirements of the project’s ultimate outcome. This allows for the creation of the Design Specification Document (DSD) which captures the structure of all system ingredients that are to be developed; what the workflows look like, which database calls will be made, and what external service calls are required via SOA or API.Fort Safe offers several consulting models for the Design Phase to ensure both quality and security:
- Security Architecture Analysis – Ensure you have secure design practices in place
- Threat Modeling – Explore how an attacker could exploit your design
- Security Control Design Analysis – Inspect your software for missing or weak security controls
Implementation:
The next stage is the longest and most involved; the Implementation Phase. Also known as the “Coding” or “Build” Phase, this is where the software is actually built by the Developers against the software design against the DSD. It is here that good Security hygiene should be married into the code itself, and where the developers need to be heralded toward keeping Security front-of-mind.Fort Safe offers a service you can leverage throughout this Phase to ensure the security and overall calibre of your code is maintained: Intermittent Code Reviews – We examine the software as it is being built to see where there may be issues or where security might be optimised without affecting the overall product using Source Code Analysis Tools and our own manual source code review processes.It is important to note, that while these steps are largely described as linear in fashion, there is a cyclical nature in modern Agile environments. These cycles allow for an iterative approach where the process is revisited, bringing the most current incarnation of the software to go through each step of review and additive process.
Verification:
The subsequent phase of the SDLC after Implementation develops that a working outcome is Verification. During this Verification Phase, the Testing begins. Typically, it is conducted by a specialist team to measure the outputs of the Implementation Phase against the specified requirements.The Testers execute functional testing (unit testing, integration testing, system testing, and user acceptance testing), as well as non-functional testing, and Security testing (pentesting and fuzz testing). If they identify a defect, they inform the developers. If the defect is valid, developers resolve it and create a new version of the software. Each new version of the software triggers repeated testing during this stage. The cycle continues until the development team has mitigated all discovered defects and the software is ready for deployment into the production environment. At this time, it is prudent to ensure the level of security is sufficient through detailed and specialist examination. This should ideally be done by an external vendor to make sure there’s no possible conflict of interest.Lastly, Dynamic Application Security Testing should take place. This is ‘live’ testing examining what an application is doing while executed to uncover any potential issues with its runtime actions.
Release & Deployment:
The release stage, also known as “Deployment,” involves releasing the completed software into the production environment and performing post-production activities, such as monitoring. Additional testing occurs in the Production environment. Final deployment takes place once all detectable bugs are discovered and resolved.While we might move the project to the Production environment, before going Live, there are the final fundamental processes that should take place to optimise the chances of a secure product;Penetration Testing – A thorough manual pentest(s) focusing on business logic to find and try to exploit vulnerabilities in running web applications or web services.Now we understand the phases of the SDLC and what might be done during each one to enhance security, we now can look at measures that should be considered for the entire, overarching project. These considerations ideally occur during the Planning Phase, and are determined and committed to before Design commences.
Include A Suitable Security Model
Securing the software you’re building from the beginning. This is the most cost-effective way to minimise the ‘test-patch-retest’ cycle that often negatively affects budget and scheduling goals near the end of the life cycle/project timeline.Building Security In Maturity Model (BSIMM) or the Microsoft Security Development LifeCycle, and of course the NIST Secure SDLC are the primary options we at Fort Safe suggest in most circumstances.Integrate a trusted maturity model into your SDLC to infuse best practices and solid security design principles into the organisation. These models like the Building Security In Maturity Model (BSIMM) act as a measuring stick that pinpoints strengths and weaknesses in your current Security initiative. An assessment leveraging this type of approach can help your firm create data-driven goals.The three models mentioned above are, in our opinion, the best yardsticks available today for measuring how your Software Security Initiative (SSI) stacks up against the rest of your industry peers. These models also provide concrete details to show your executive team and board how your security efforts are making a difference.
Training Your Team
By ensuring that all personnel involved in the project are informed and current with Software security standards, we can reduce the occurence of insecure design and development. Expenditure on (even informal) training of all teams is scalable, and aligns with the overall organisation and the scope of each software development project at hand. The continual merits stemming from a security-aware team extend into all current and future software projects, and can be an enterprise-wide asset. A great starting resource to spring from is Secure Code Warrior to raise the secure coding standard within your teams. We must stress the importance of a well-trained and security-conscious work-force. Any agent of the organisation that interacts with assets/artefacts that the organisation, increases operational risk. To be thorough, Security should be implemented at every level of this lifecycle, from Design through to Implementation, then to User-Acceptance and normal business operation. There is very little point in securely designing your software, and leaving gaps in your user base that can be exploited, undermining all previous efforts and expenditures.
Nominate a Team Champion
To ensure that Software security is incorporated into the SDLC, formally assign responsibility for it. Depending on the size of your organisation, creating a Software Security Group (SSG) is an effective way to educate, assess, and enforce established Security measures across the organisation. This is key to maintaining Change and Risk Management as your organisation scales, without degrading or ignoring security altogether.The SSG should act as the Subject Matter Experts (SMEs) in Software Security, facilitating and conducting third-party security assessments during critical stages within the SDLC. If the required resource isn’t available internally, you should look to hire in a contracted resource, or specialists like Fort Safe to assist with this, either on-site or remotely.
Periodic Code Reviews
Along with secure coding standards and Static Code Analysis, perform a Secure Code Review either internally or through Fort Safe as a condition to passing a release gate. This drastically reduces the number of bugs escaping into the finished product. An effective defect containment and management system also aids in prioritisation and tracking issues to resolution.
Threat Modeling & Architectural Reviews
It is far more cost-effective to identify and remediate design flaws early in the design process than to patch flawed design implementations once the software is deployed. Along with threat modeling, architecture risk analysis is a critical tool to detect design flaws. Flaws are identified by:
- Analysing fundamental design principles
- Assessing the attack surface
- Enumerating various threat agents
- Identifying weaknesses and gaps in security controls
Final Thoughts
With the correct processes and steps, you can ensure your projects ‘shift left’ and don’t end up wasting precious time and resources when found unsafe, or end up compromised when they’re already in production! Abraham Lincoln said, “give me 6 hours to cut down a tree, and I will spend the first 4 hours sharpening the axe.” There is a lot of wisdom to be taken from this. Thinking effectively from the outset, designing accurately and consciously, maintaining a robust security posture and standard in all development and release practices, and keeping users and stakeholders adequately trained, are all crucial ingredients to a safer and more efficient enterprise.With Fort Safe, you’re in capable hands that can help minimise any potential exposure, and that the security of your app is optimal. To find out more about how we can help you run a safer S-SDLC, connect with a Fort Safe consultant today.
