Application security is not new. It has been around since the early 2000s and in a similar environment, where Code-Red, Nimda, and other viruses were causing global havoc. Securing the software development lifecycle was initially a Microsoft initiative developed due to the growing number and impact of vulnerabilities in its products and code. The model has significantly evolved since, though the principles remain the same: catch security bugs early on in the development cycle to cut your costs of repairing them. As a result, you can reduce the damage to customers and vendors alike. What is the SDLC, SSDLC, or SDL? It stands for Secure Development Lifecycle, which is how you apply security to the lifecycle of developing a product or a system. To apply or “bake” security into the development lifecycle, you need to consider the type of methodology you want to use for development. For example, whether Waterfall or Scrum, you need to apply the same principles but different methods. It is also very dependent upon the organization's risk appetite as a whole, particularly as it applies to the specific system. The risk appetite will define how many resources one should invest into this process. It can be pretty cumbersome on development and security professional resources for any R&D effort. An organization can apply a Secure Development Lifecycle to each stage of development. Let’s start with a Waterfall example. For every cycle stage, you need to use a specific security activity.
Project Inception
At the initial stage, when the project is in its inception, perform security threat modeling, which will be done at the stage when the product is merely a series of boxes and arrows.
Design Phase
Following that, you have the design phase, where you can apply security design templates to ensure that there have been no security controls "mistakenly" forgotten in the process. You can find a link to free secure design templates here.
Code Review
Once the code has been developed or is in design, you can perform code reviews.
Penetration Testing
When the system is complete, you can perform penetration testing on the application level after it has been tested and is stable and ready to go live.
Secure Deployment
Before going live to production, you need to validate secure configuration and maintenance to ensure that while the system is online, it will handle a new vulnerability or threat appropriately when encountered, reducing the risk of exploitation.
Some of these steps can save the company much money when appropriately performed at the correct time. Their benefits are enormous to improving the system's overall security and correctly estimating and handling the project delivery timelines.
One of the simplest examples to demonstrate the value of incorporating security will be the design phase. A security design issue that you only discover later during deployment may be challenging to fix. It might require a complete system makeover or going live with a known partially addressed or completely unaddressed issue.
Secure design review, when done appropriately, should only take several hours to several days depending on the complexity of the system and the risks associated with it, but its benefits are immense. Unfortunately, not everyone can perform this activity. You will need a professional security consultant who understands the technology side and the requirements from architecture, infrastructure, code, and the associated threats. The next step is performing secure source code reviews on the code under development. These reviews can be done by an automated tool or a security consultant, though hiring an expert using an automated tool will yield the best results for the time spent. The output of code review tools for security usually requires an expert to interpret and decide on the best approach to the solution. It may not be easy for just any developer to understand the output. Many attack vectors and vulnerabilities associated are beyond day-to-day coding operations. So, you may require an expert to help resolve false positives, understand their impacts, and comprehend where false negatives can exist, e.g., issues an automated tool cannot identify. It would help if you also consider the best value for the time invested. Next, you will have penetration testing, when the perfect scenario will be on a system running on pre-production or staging environments and is ready to be deployed. Penetration testing should be by a dedicated team of people with the skillset, understanding, and experience to perform it well. When the system is ready to be deployed, you need to perform a secure deployment. That means removing all redundant and unnecessary interfaces, configuration files, backups, and hardening the server and system configurations to ensure that the production environment is robust for this stage. You can also apply SDLC to Scrum, for faster-moving development cycles. In this case, you will need to have a security person as part of the Sprint team and decide on the key activities they will need to perform for every Sprint. This decision depends on the scope of the specific Sprint. In any case, and independently of your chosen development methodology, the steps are the same. You will need to review the design and code, test, and securely deploy the application. Alternatively, when working in Scrum methodology, you can have a security Sprint every few Sprints, where security is the primary focus. But, again, you need to make sure that the significant issues such as design and threat modeling have are understood and handled early on to reduce the total cost of the project and significant architectural changes in later stages of development. The key point to understand is that “baking” security into the development lifecycle cannot be a developer decision or even a security one(though it can be your initiative). Instead, the decision must come from management or R&D management because these processes take effort off development and put them into security. So, what happens when you take these resources out of R&D for developing new functionalities and into security? For example, you may run into a problem where you’re facing a strict timeline for a project, and security is holding it back (as is the case when something critical pops up). In such a case, you may miss the deadline, and if management does not support the process, then things will be left behind, unhandled. Having management on board with this process is vital in whatever development methodology you use. Another thing to consider is that you will have to have a dedicated security consultant (or internal employee) who understands development, code, security, and the business.
Komodo Consulting is a high-end cybersecurity firm specializing in Penetration Testing, Red-Team Exercises, and Application Security.
Have a query? Get a 30-minute Free Consultation. Talk to a cybersecurity expert.
Like in this blog post: https://www.komodosec.com/post/the-top-7-advanced-cloud-security-challenges