How can we migrate from Software Development Life Cycle to Secure SDLC
Security was always been considered a luxury by most enterprises, the majority being SMBs.
Traditionally many companies are accustomed to Software Development Life Cycle (SDLC) which is a series of steps followed to provide a framework backed by proper analysis, design, implementation, and maintenance. According to the recently released Internet security threat report from the Symantec, US topped the list of most vulnerable countries in terms of cyber threats such as Malware, Spam, ransomware, web attacks, Bots, Phishing and Crypto miners followed by China and India.
Traditionally many companies are accustomed to Software Development Life Cycle (SDLC) which is a series of steps followed to provide a framework backed by proper analysis, design, implementation, and maintenance. After developing and just before deploying the application live into the market, many companies realize the security loopholes and opt for a Vulnerability Assessment and Penetration Testing, traditionally known as VAPT, to find the security vulnerabilities present in the software.
Then there are the Static Analysis Security Testing (SAST) tools which companies use to find the patterns of pre-defined vulnerabilities in the source code and eliminate them. Dynamic Analysis Security Testing (DAST) tools are used to find vulnerabilities in applications using methods of crawling and fuzzing. Most companies do not know the architecture of applications that they own and this gives hackers the advantage to find loopholes in applications unknown to them. There is also the Interactive Application Security Testing (IAST) which is also called the Glass box testing. In this approach, IAST runs as an agent who is allowed to collect and analyze event data from running applications. This data will help you to detect software flaws that SAST and DAST scanners miss out.
According to a recent survey, the cost of fixing a security bug is only 10$ when it is identified at the analysis and requirement stage, whereas if it is identified in the deployment stage then there are instances of changing the complete architecture of the application which results in higher costs of 2000$ or more. It's high time we turn the tables and introduce security in the initial stages of SDLC and continue to induce in every phase.
Start telling your developers to write secure code
Even though you have the best SOC systems in place to defend hackers, they'll be of no use if your developers choose to write a mechanism that stores passwords in plain text instead of Hash codes. India's biggest food delivery company Zomato was hacked in 2017 resulting in the compromising of 17 million accounts usernames and hashed passwords which were sold to dark web for BTC 0.5587. Secure SDLC begins with the training of your developers about basic security coding practices such as restricting the access of the user for a payment application after 5 unsuccessful attempts, validating the input from suspicious data sources etc. It is advisable to have a minimum of 3-4 training sessions in a year on security awareness for your employees along with special training on secure coding practices for the developers
Define security requirements at the planning stage
Identify and document the security requirements right at the initial stage of the development lifecycle. Once the technology, framework and, languages have been decided, train your developers to identify vulnerabilities that the particular technology is susceptible to and eliminate them right away.
Design and Architecture review
In this stage, once your architects and designers confirm the hardware and systems that were going to be used in the development process, perform a threat modelling to understand how each component talk to each other and identify the vulnerabilities at that stage. It will help you to apply a structured approach to threat scenarios to the design and lower the risks.
Coding and Development phase
While coding for features and functionalities of the application many developers have the habit of copying codes directly from the technology stack. A recent survey uncovered that an average of 60 vulnerabilities that get identified result from the 3rd party components per application. In fact, a Facebook internal employee had used just 5 lines of code from a tech overflow group which resulted in a severe vulnerability leading to the infamous hack. Facebook had to pay a huge amount for that bug. Developers should start using CVE (Common Vulnerabilities and Exposures) websites to understand the vulnerabilities that a particular framework carries. It is also important to analyze the version of a software, understand the API's used and review them to see how the code is interacting with libraries. At this stage, it will be helpful to use SAST tools that will identify security vulnerabilities and provide feedback to developers to use secure software patterns and avoid infrequently patched code and also provide an explanation for repairing the potential vulnerabilities. Perform a secure source code review both in static and dynamic formats to ensure optimum security.
This is the most favourite phase of every development cycle; the functional testers work for smoke test cases and help find functionality bugs and report them to developers. They first argue that it's not a bug but a functionality error and then close it. In this phase, it's better to think like a hacker and add abuse test cases that attackers use to get the data or systems that they try to get into. Once you understand the situation from a hacker's perspective, you will be able to put proper mitigation in place. It's a boon for testers that various abuse test cases can be scripted and integrated along with QA testing save a lot of time and man-hours. One of the best practices is to perform the penetration testing manually to find the business logic vulnerabilities present in a system. Combining this practice with DAST tools will help you find the exploitable vulnerabilities such as SQL Injection, Cross-site scripting, remote code execution, session management issues, URL redirections etc. Once the vulnerabilities have been identified it will be easier to fix them as the application would still be in the pre-production stage.
You might be using the best cloud service provider in the market such as Amazon AWS cloud, Microsoft Azure or Google Cloud but you have to read between the lines. These private cloud service providers take care of the perimeter security of their cloud network but the security of the applications inside the cloud is the responsibility of the application owner. If the deployment of the application is not secured and has incorrect configurations, it will result in sensitive data leakages and open vulnerabilities despite security testing from the Big 4. Performing a configuration review for that particular cloud and doing an external pen-testing on all the cloud instances will help you sanitize the cloud.
All the activities mentioned above are ways to instil a security mindset in the employees and induce the security into every phase of application development so that the company can come up with more robust products with minimal vulnerabilities. "Prevention is better than cure" and Secure SDLC is the best way to go about it.
About the author:
Sairaj Mahesh is working as a Cyber Security Evolutionist in WeSecureApp, a New Age Cyber Security Company. He understands the pain points of information security of their clients and designs specific solutions ranging from Penetration testing of the Web & Mobile Applications, Cloud, Infrastructure & Networks to perform a full-fledged Red team Assessment vs Blue team assessment activity in any organization. He works with their technical team who are a combination of experienced, certified ethical hackers and Bug Bounty hunters. His solutions include companies migrating from SDLC to Secure SDLC and adding automation to reduce the cost of security testing over a period of time.