We talk a lot about perimeter security, zero trust, etc. And there's a good reason for it. Malware attacks don't just happen by themselves – they have help, intentionally or not.At this point, centering security around the user is table stakes. If you're focusing on it now – you're just in time. But get ready, because there's a not-so-new kid on the block. Applications got a bit more complex. With deployment in the cloud, it got better and worse at the same time. Better because with the cloud, you benefit from economy of scale. In case of any flaws or identified security threats, the solution is the same for you and all other users, and you have a cloud vendor working on it around the clock. Worse because the skills around it are still rare and in demand, and the speed of movement is much, much faster. Everyone wants to deliver and do it fast. "Move fast and break things" was good for Facebook when they started, but let's face it - you are in serious business (and so is Facebook).Recently, OWASP has updated its TOP10 list. If you don't know it, OWASP TOP 10 is a list of top security problems in applications.
OWASP TOP 10 changes
Let's take a look at changes from 2017 (that's like, ages ago) to 2021 in this ranking. Broken Access Control (A01:2021) moved from the middle of the rank (5th in 2017) to becoming the TOP 1 issue on the list. That is a serious "win" for not getting your access rights right (sic!) in your apps. We have a new contender at an already high, 4th place - Insecure Design (A4:2021). Security starts at the beginning and has to be there throughout the process.(A05:2021) Security misconfiguration was also going through the training over the last couple of years and moved from 6th to 4th place in this ranking. And last but not least, pay attention to the significant move in the second part of the group - (A06:2021) Vulnerable and Outdated Components moved from 9th place in 2017 to 6th in 2021. That's a significant effort on its side and gain in the ranking. If those were racehorses or cyclists, that would be a moment of joy for their teams. But they are not - those are results of the security process not being in place in organisations. It is time to give security some love, and for security guys to hug their development teams instead of pointing out mistakes (HugOps are still around us). There is no other way to address those issues in fast release cycles than embedding security checks and measures from the beginning. DevSecOps allows you to shift security left. Instead of focusing on the user, you secure the code at the point of origin – during development.
How to minimise risk to app security?
How does DevSecOps relate to the things pointed out in OWASP TOP10 in 2021? A few picks (not a complete list) from our side.
Broken Access Control (A01:2021)
You can verify the configuration of your cloud resources (storage accounts, databases, network ports, and access rights) at the time of deployment, and with every update going through your CI/CD pipeline. It does not plug all the holes (application access control is another topic) but definitely helps.
Cryptographic failures (A02:2021)
Verify in the integration and deployment pipeline if cryptographic material (keys, certificates, secrets) is stored in the right way, not exposed in the configuration files, and protected with the appropriate access rights.
Injection (A03:2021)
Deploy code analysis tools to scan your code repository and pick those possible points of injection early in the dev cycle.
Insecure Design (A04:2021)
Not something to be automated, but adding security design decisions to your ADRs and verification of final deployment against your Azure environment policies will definitely help with this one (it will also bring awareness and need of threat modeling to the table).
Security misconfigurations (A05:2021)
This one is obvious - instead of doing it once and manually, you have it as part of your overall CI/CD process. Evaluate configuration against policies in your cloud, automated infrastructure code checks and testing, enforcement of standards of access control (did we say that already?), and cryptographic material (We've definitely said that already) - you name it.
Vulnerable and Outdated Components (A06:2021)
Plug components verification and dependencies vulnerabilities check into your CI/CD pipeline and have it checked for you. It is a standard component of the DevSecOps process now. Check Google's Dependency Check tool if you haven't heard about it yet.
Identification and authentication failures (A07:2021)
We should really stop talking about it already - go for Identity as a Service service (example - Azure AD B2C) and (almost) forget about it. Why almost? Still do checks if it is used, and used properly in your apps (A04:2021 - it has to be done right at the design process, A02:2021 - protecting your keys is crucial and A01:2021 - nothing will work if you fail to do access checks in your code).These are just a few points where introducing security to your DevOps process can immediately bring benefits and improve your position against threats from OWASP TOP 10. Believe us, once you go down this rabbit hole, there is only more to discover. You've been warned. That's the practical take, but where does DevSecOps come in? Let's go with the top-down approach.
Where is business headed?
It's not that the business landscape has changed to include technology. Technology becomes the business. Organisations (you) are shifting their focus to technology, to deliver additional (or new) value to customers. Consider the example of our client in the manufacturing space. Before, customers would buy their products (water pumps) and ordered an aftersales service if needed. In most cases, the interaction ended once the sale was complete. Recently, they decided to turn the pumps into IoT-enabled devices. Customers can control them via a phone app or an online portal. It doesn't just strengthen the customer-provider relationship – it's better customer service. Rather than go with the "sell and forget" approach, they can provide their products on an as-a-service basis and deliver more value to customers with self-service capabilities, alerts, etc. Why does it matter? Because technology is the key to adding value to your business offering. Your customers expect it.
What does it have to do with security?
You need technology to deliver more value to your users. And you need it to grow your business. But you also need to make sure it doesn't put your business at risk. On the other hand, there is pressure to do it faster, do more iterations, and validation of the products. Let's go back to our manufacturing example. When you have a factory, the real value is not in the production line but in what comes out of it. Still, your product can only be as good as your production line. So you have to look after it too. It's the same with developing apps or tech products for your users. To end up with a good quality product you need a solid production line. This is where DevOps comes in. DevOps makes your development process repeatable, measurable, and transparent. It improves your product quality.
The importance of web application security
Application vulnerabilities put you, your business, and your customers at risk. Just last April this happened to Experian. It was possible to use their API to access people's credit scores without any authentication. And a bit closer to the ground, a Swedish supermarket chain Coop was forced to close over half of its stores following a cyberattack on the software they used. Stuff like this happens all the time. If you're curious about the scale, you can check out this list on HaveIBeenPwned. And that's just the ones they know about. So, how to make sure your product is secure? You secure your production line. You implement DevSecOps.
What is DevSecOps?
It's the practice of secure coding. In the simplest terms, it allows you to look for security vulnerabilities in your source code before you release the finished product. By implementing safeguards into your development process, you minimise the risk of your app or service – and business as a result – being compromised. DevSecOps standardises your deployment when it comes to security, and limits manual checking by using automated testing and quality control. This way, you're not risking that, for example, someone will leave an admin password in your app code (it happens more often than you'd think).
What's the cost of adding DevSecOps to development?
The better question would be: what's the cost of not doing it? According to this report by Google, nearly half of respondents didn't know if there were any security issues with their products. This means their app security was pretty much left to chance. So here's the question: can you afford to bet your business or customer data on a coin toss? Consider that an average breach now costs around $4.24 million. And with automated detection, you can shave off $3.8 million off it. Surely it's worth the investment.
What are the next steps?
If you're not yet securing your code, this is the time to start. Over the next few articles, we'll go over some practical methods for implementing the practices in GitHub and Azure DevOps, but the principles apply regardless of the technology you use. In the meantime, you can start by reviewing these resources:
Author
