- 06 Aug
Secure your SDLC
Sacumen Application security has gained in recent times due to numerous well highlighted security incidents. As per NIST,92% of the vulnerabilities are Application security related, not networks. Enterprises and Product companies are looking at ways to ensure that their applications or products have the right application security controls built in so as to be ready to face the ever evolving Threat landscape. Secure SDLC is what is prescribed! Here is how the Secure SDLC process would go.
- Requirements Gathering – Time to capture what you want. This is the most important phase where Security needs to be incorporated. Unfortunately in real world, it is not the case. How can Security be incorporated in any product or application when the Security requirements were never documented in your Requirements document. Security is not an “implied” phenomenon but an explicit one and the same thinking need to be applied at all stages of your SDLC. Security requirements should be documented in detail in your Requirement document covering not just the standard application security models but also the requirements unique to your industry. For example, an application processing Credit card data will have its unique application security requirements related to PCI DSS compliance.
- Design – Time to lay out the blue print of your expected solution. This is where you can perform a Risk assessment of your application or product by performing a process called “Threat Modelling”. This can be applied even before writing a single line of code. Threat Modelling helps to abstract your application functionalities to understand the top risk for your application. This is done by identifying the Threats and vulnerabilities that may exist based on the nature of your application. Once the risks have been identified, the appropriate countermeasure can be identified and implemented during the Implementation phase.
- Implementation – It’s Building time. Apart from the functional implementation, the Security requirements captured in your Requirements document and the Countermeasures identified for Risks will need to be implemented during this phase. This is the phase where Developers should continuously be performing the Source code scanning using the SAST (Static application Security Testing) tools. These tools are typically plugged into your IDE and used for development..
- Testing – It’s Testing time. By this time if you have followed the above three stages properly, you will have a smooth flow. But in real world this is the phase where attention starts coming in for Security and this may be late if the Secure SDLC processes were not applied. This is phase where testers use DAST (Dynamic application security testing) tools to find the vulnerabilities in code. The vulnerabilities are reported to Developers to fix and typically these vulnerabilities number run in hundreds. This leads to phase where Clients face 2 major challenges:
- Firstly the Client is left with the dilemma of which vulnerabilities to fix. “Fix All” may not be the option available based on the timelines and resource availability. A “Risk based” approach is needed to assess and rank the vulnerabilities based on impact and probability.
- Secondly as the pressure to close those vulnerabilities in defined timelines mounts, developers face an uphill task. One major challenge for developers arises due to lack of knowledge or capabilities to fix those security vulnerabilities. Addressing Security vulnerabilities need a good understanding of the nature of the vulnerabilities and the appropriate solution. Availability of reusable libraries and specialized application security members will help
The Cost to fix the vulnerabilities during this stage is 15 times the cost needed to fix during Design phase (IBM Systems Science Institute).
- Deployment – Time to have your application put to Real use . This phase typically is handed over to the Deployment team. Security is addressed mainly in ensuring that the servers on which applications are deployed are hardened. It is therefore recommended that a penetration testing is performed on application ideally during the Testing phase rather than performing it after the application is live. Also an assessment of various infrastructure components (Web servers, DB, Application servers, Load balancers) should be done to ensure that the support infrastructure are security compliant. The Cost to fix the vulnerabilities during this stage is 100 times the cost needed to fix during Design phase (IBM Systems Science Institute).
Securing your SDLC is a continuous process and not a one time activity. Secure SDLC processes would give you the confidence in your applications to be ready to face both external and internal threats. Secure SDLC starts from Requirements phase and not from Testing phase. Let your application security be your enabler and differentiator!
About the Author:
Nitesh carries a deep passion for the information security space. Nitesh is the Founder and CEO of Sacumen, a focused and niche Security Product engineering and Services Company. Nitesh has spent more than a decade in the Security space and carries multiple prominent security certifications such as CISA, CISM, CGEIT, CISSP, CSSLP, CEH, ISO 27001 LA, CCSK and HCISSP. Nitesh is on a mission to transform the perspective of IT security from a FUD (Fear, Uncertainty and Doubt) perspective to having IT security being harnessed as an enabler and differentiator.
Sacumen is a Security Product Engineering and Services Company. Sacumen was born to address the pressing needs of Enterprises and Product companies looking for a trusted, focused and niche Security services partner to help them develop innovative security products and solutions. Sacumen is focused on providing services to develop innovative solutions in the areas of Identity and Access Management, Application security, API Management and security, Authentication, and Security product engineering.