Building security into our applications is widely considered to be an important priority in mature companies. But even still it is often overlooked at earlier stages of the development making the cost of security exponentially higher the later in the process we start to consider it. In this post, we are going to break down the SDLC (Software Development Lifecycle) and look at how we can add security at each stage with helpful resources.
I do want to quickly note that this post is a detailed guide you can refer back to find helpful resources and will be continually updated. That being said, if you are looking for a quick post with fun buzz words and a few ideas then this may not be the post. But if you are here to learn how to secure an application then let’s dive in!
Of course, there is debate over the steps of the SDLC and different project methodologies like Agile, Lean or Waterfall changes how we may view these. But in all of these methodologies, we largely follow the same 5 steps at the start of a project and for each new feature. We will break down each of these stages and look at the specific security requirements to follow.
Stage 1: Planning Planning & Analysis
Defining the requirements of the application, both functional and nonfunctional.
Stage 2: Design
Translate the business needs into technical plans. Just like building a house, you need to make plans before starting the construction.
Stage 3: Implementation
The translation of plans into applications or components, building the walls.
Stage 4: Testing & Integration
Ensuring everything is working both in a functional and non-functional way.
Stage 5: Maintenance
After the application is done, we need to go to production. Ensuring the application is running as expected
When starting a new project it is crucial that before we write any code we plan by defining exactly the requirements of this project, sprint or feature. It is important to remember that planning, like all steps, is not something that is done once at the start of the project, it is repeated at each step, every new feature or sprint. Every time we do our planning we must include security.
Security errors made all the way at the planning stage can be built into the logic of the application and the culture of the company, these are the most costly to correct.
Training / Awareness
Developers do not need to be experts in all vulnerabilities, but they need to know they exist Friendly Neighbourhood Security Engineer
Training is the first step when creating a culture of security-focused applications. This does not mean we must make all developers security experts before we allow them to write their first line of code. But developers cannot write secure code if they do not first at least know what insecure coding is and what fundamentally makes an application vulnerable. One of the best resources for this is the OWASP top 10. The OWASP Top 10 is a standard awareness document for developers and web application security. It represents a broad consensus about the most critical security risks for web applications.
During the planning stage we must also agree (and train everyone) on critical security elements. For example, how are developers going to handle, share and store secrets (digital credentials)? Who has access to the production environments? What is the process of security testing? What tools are we going to use?
“Globally when you want to implement a secure SDLC, you have to train people, from project managers to developers and testers. It is essential because if people don’t understand risks and potential impacts it won’t translate to their work.” Friendly Neighbourhood Security Engineer
It is critical to share the importance of security with the development team. This will make training far more effective and encourage the team to dive deeper into these subjects. What always works well is showing real-life examples of how web applications can be exploited. Some great tools for this are using tools like BeEF which can be used to show how XSS can be used to take malicious actions for instance turning on webcams, accessing additional data or bypassing authentication.
User Abuse Stories (Abuse cases)
User abuse stories are a way we can take a step into the mind of the attacker and begin to understand what their targets might be. If you are familiar with user stories where we need to understand the needs and objectives of our users, a user abuse story is the evil cousin of this, but should follow some of the same principles and paths.
Here we need to consider and discuss how malicious users will try and use our application in different ways to gain access to critical information or access elements of our application they do not have authority to access. User abuse stories do not always have to be from malicious ointment too, they can be the result of curious users who use your application in unexpected ways and end up with information or control beyond what was expected. A user abuse story should have three elements:
- A written description of the story
- Conversations about the story that serve to flesh out the details of the story
- Tests that convey and document details and that can be used to determine when a story is complete
You may be wondering why we have this so early in the process, after all, we have nothing built. It is important to get everyone thinking about security in different ways. If we can consider the unexpected paths of users then we can build security into the application from the very first lines of code and have it in our mind for the entire process.
Security is not the same in showcase websites as it is with banking or military applications so you must adapt security needs to the context of your application. There is no gold standard use case you can adapt to every project or feature. Friendly Neighborhood Security engineer
So we have planned for our application and the team is in sync on security, it’s time to code, right? Not so fast, first, we need a plan. Designing the architecture of your application can be a complicated task that requires specialist skills and just like we cannot expect developers to be experts in security, we cannot expect architects to be security experts also. Software architects need to have a deep understanding of multiple topics so you cannot rely on them being security experts therefore it is important that multiple parties discuss architecture security.
Threat modeling is a process by which potential threats, such as structural vulnerabilities or the absence of appropriate safeguards, can be identified, enumerated, and mitigations can be prioritized. Unlike User abuse stories, here we are not considering the malicious paths of users or attackers but more identifying all the high-value targets that they might be interested in gaining access to.
“You can start implementing security when you know what your risk is” Friendly Neighbourhood Security Engineer
In threat modeling, you need to do several things. First, you need to list potential threats, why would attackers want to exploit your business or application. Perhaps you have a very confidential business and a threat is another organization trying to steal data for competitive advantage. Perhaps you are dealing with financial assets and there is a threat for hackers to exploit the business for financial gain. Perhaps you have valuable user information an attacker might want to exploit.
Once you have listed your potential threats you need to list your assets and then identify which ones are critical. Essentially what would the attackers be targeting as a result of the threats you have identified. This could include:
- Cloud computing accounts
- Third-party services
When you have identified threats and assets, you need to start thinking about, and modeling, how an attacker would access these. It is important to think about as many different scenarios as possible. Is your application public on the internet and can attackers attempt to exploit the public aspects of it? Is your database accessible internally and do you have internal threats to consider? How could an attacker move laterally between systems to gain access to critical infrastructure?
“When every user, packet, network interface, and device is untrusted, protecting assets becomes simple.” John Kindervag
Software architecture is a specialist discipline and can therefore be placed in a silo in a team with little interaction. But unlike other areas, for example code reviews, architectural reviews from a security perspective, should involve many different team members.
Architectural reviews are an opportunity to not only understand more about the inner workings of the application but also put into practice some of the user abuse stories and threat modeling we have done to examine if the architecture contains enough security considerations. An important question that must be considered is what happens if an attacker does gain access to our infrastructure? How can the architectural design contain them and not allow lateral movement?.
Architectural reviews should examine:
- Network security architecture
- Identity and access management
- Infrastructure security
- Cloud security architecture
- Network device configuration
Making the steps to plan your application can feel frustrating when you instinctively want to dive in. But trust me, your future security team will thank you for it later. When the planning stage is done, now is the time to put the code to the text editor and begin. So how can we secure the development stage of the SDLC?
Secure Code Reviews
Secure code review is an examination of application source code. The goal is to identify any existing vulnerabilities, and it has a variety of activities that can be conducted. A manual code review is when a colleague, usually senior, looks at the code of a developer and provides feedback. This is a great process to help improve the overall security early in an application by sharing security knowledge and improving understanding.
What is important is to understand what manual (human) code reviews should focus on and how it is different from automated code reviews (SAST and Secrets Detection). A human reviewer can understand the relevance of a bug or vulnerability in code based on its context which is often where automated tools fall short, this is why both are critical.
One critical function we need to review is that of logic in application code, logic flaws are difficult for an automated tool to discover. Looking at a simple banking app, it is obvious what sending $100 to another user will achieve, what happens if you send -$50. While this is an oversimplified example it illustrates the point of what a senior developer will be able to pick up in a code review.
Static Application System Testing – also known as “white-box testing”, is the most common and earliest category of automatic application security. SAST scans an application’s source code to discover any known vulnerabilities. Because SAST does not require an application to be compiled or running to start detecting vulnerabilities (unlike DAST) it can be implemented very early in the SDLC.
“The drawback with SAST is that these tools cannot always understand what your application is trying to achieve and can result in many false positives. It can take time to analyze these reports so we need to use logic when deciding the frequency we run these tools.” Friendly Neighbourhood Security Engineer
Software Composition Analysis (SCA)
Did you know that 90% of most application code comes from open-source components such as libraries and tools? Taking advantage of SCA projects will speed up application development and help get business applications out faster with a compelling set of features that meet customers’ needs. However, like all things, there are challenges involved with using this form of technology too such as balancing the risk/reward equation as you navigate trade-offs between project agility or quality; vulnerability or security; etcetera.
A vulnerability scanner helps you uncover security weaknesses in the open-source code your software uses. Using a good scanner, you can spot known vulnerabilities and close any loopholes that might allow unwanted access to your system. Data breaches usually occur due to unpatched vulnerabilities; eliminating these will remove attack vectors which are typically how such data is acquired by attackers. You can monitor licenses for compatibility with each other, compliance with internal policies, and if they meet attribution requirements, all of which play an important role in maintaining a healthy open source ecosystem within your company or organization’s products.
Secrets detection is often confused with SAST because both scan through source code. Unlike SAST, which is concerned only with the current version of an application, secrets detection is concerned with the entire history of the project. Version control systems such as git, keep track and store all changes to a project. If previous versions of the source code contain hard-coded secrets within, that were removed in late stages, code reviews and SAST tools will miss these secrets which may end up in a git repository and become compromised. This is why secrets detection is a category on its own.
From the Planning, we should have flushed out in the training section how we are going to store sensitive data like secrets and who has access to them. But the reality is that secrets are so widely used by developers that they will inevitably end up in source code. Even security-focused companies like Samsung, Nvidia and Twitch have had their source code leaked which have contained hundreds or thousands of secrets inside.
What is particularly scary about secrets is that we often know when they are being abused because the malicious actor is correctly authenticated into the system so no alarms will be going off. An organization with a mature security program will have secrets detection in two, potentially three places.
- Detecting secrets front the local machine of a developer
Using pre-commit or pre-push git hooks we can detect secrets before they enter the VCS. This means that remediation and threat level is at it’s lowest
- Detecting secrets on the VCS server
Our git servers are a target to attackers, they are known to contain secrets and expose other security vulnerabilities. This is why this is the most critical area to have detection. Local detection can be bypassed and hard to enforce, therefore detection at this stage is critical and must monitor in real-time all the commits coming in.
- Detection outside the company perimeter
If you are a large organization (more than 100 developers) then there is a risk of exposing secrets that are outside the control of your organization. For instance, an employee leaking corporate code on a personal public repository. In this situation, we can implement secrets detection on common public domains like GitHub.com.
“When we are ready to test, it is too late to implement security, but not too late to test our security” Friendly Neighbourhood Security Engineer
Dynamic Application Security Testing – also known as “black box” testing, doesn’t find vulnerabilities in source code like SAST, instead, it finds vulnerabilities in running applications. It does this by employing fault injection techniques on an app. DAST can identify common security vulnerabilities, such as SQL injection and cross-site scripting. DAST can also cast a spotlight on runtime problems that can’t be identified by static analysis, like authentication and server configuration issues, as well as flaws visible only when a known user logs in.
Congrats you just built and released a secure application! Job done right? Unfortunately not, we now must continue our security vigilance.
“You can have the most secure application in the world, but if you release it into an insecure environment it is all for nothing”.
Infrastructure configurations can be a challenging and ongoing part of application maintenance. As your application scales, so do your infrastructure configurations. All too often we have seen multiple leaks as a result of misconfiguration. We saw this recently when Twitch had a server misconfigured briefly which lead to the unauthorized and ultimately publishing of their entire source code, secrets and all (pun intended). Throughout the maintenance of our application, we must ensure that our configurations follow strict security standards.
- Automate infrastructure where possible
Repeatable deployment provisioning will help reduce the human error component
- Implement infrastructure as a code security tools
We need to implement IaC security tools to make sure we always have automated checks every time we update our infrastructure.
- Detailed and clear policies and documentation
It may not be as sexy as some automated security tools, but we must implement comprehensive documentation and policies that can be passed on to new team members. Mistakes often happen when working in unfamiliar infrastructure so accessible clear documentation is key in reducing some of this.
Incident procedure and review
We have built a secure app and we are maintaining it under the watchful eye of a top-notch team and then, out of nowhere, an unknown IP address is registered in your database, you were breached.
Unfortunately, security is never 100%, and even the most vigilant dedicated teams and companies there is always a persistent threat. Therefore it is vital to have a robust incident review plan and procedure documentation. Time is never on our side in security and a bad situation can be made much worse if there is not an incident procedure document in place.
This document should cover the steps personnel should take if a suspected breach is in place, confirmed and a review process to conduct a postmortem.
Remember when we talked earlier about open-source dependency scanning, this task is one that we must do continually in the maintenance stage also. New vulnerabilities are constantly being discovered in open-source dependencies, just think of the recent log4j example which made a huge amount of the internet vulnerable to known exploits. Updating or patching our dependencies can be a slightly controversial topic. Why? Because we have to run a balance of patching regularly and patching intelligently. Dependencies are often updated, one of the main reasons they are updated is to fix security issues or performance issues, but what we can see by evaluating previous breaches is that it takes roughly 3 months before vulnerabilities in the updates are discovered. So we need to put in a patching plan when we are updating our dependencies, we should patch immediately when there is a known security vulnerability and be on schedule to fit in when tests and releases allow some buffer time when we are updating dependencies without known security issues.
There is a lot to consider when it comes to security and it can be overwhelming. Building security takes some time, especially when you are on a new project or team. But it does not need to be all-consuming. There are great tools and resources throughout this article I would strongly recommend you to check out, many if not free have free tiers to help developing companies. The most important takeaway when building a strong security-focused company, project or application is to build security into your culture, it needs to be a consideration at every stage. If you build this into the fabric of your development then as you mature, there will be far fewer security considerations to fix later on.
This resource will be updated to make sure we include the most relevant resources and information so please keep it bookmarked for future reference.
*** This is a Security Bloggers Network syndicated blog from GitGuardian Blog – Automated Secrets Detection authored by Mackenzie Jackson. Read the original post at: https://blog.gitguardian.com/securing-your-sdlc-software-development-life-cycle/