Secure coding in Azure DevOps
I covered security in GitHub last time. But some of you likely use Azure DevOps for building your products, so let’s...
What holds us back from making things better in security? The disconnect between security people and developers.
When those two worlds “meet” (I wanted to write “collide”, which is a better word to describe it), usually it is more about open guns and finger-pointing than fruitful collaboration.
Why is that? (Again – my opinion.) It goes back to when we started this whole ‘IT’ thing and created a divide between functions. There were the server guys, there were the networking guys, there were the “devs“, and in the end, “SECURITY“. The last one was mostly seen as an obstacle to doing the work (which, frankly speaking, was many times).
What has changed?
It doesn’t work this way anymore. Time to put an end to it. It’s time for security guys to show some empathy toward app developers, and for developers to start having fun from doing security in their work.
This time, I will propose to you a way to close all of it into a kind of a loop to bridge those disconnected worlds. But before that, let’s talk about the “paved road” concept.
We all know Netflix (or at least I assume we do). Netflix is delivering content to people all around the world… through apps. You can imagine that their version of the disconnect between developers and security was similar but on a global scale.
They could fight it, trying to force people to do what security wished them to, but then they would face what we all know – on a global scale. Instead, they used “paved road”.
What if instead of forcing things, we made them easier to do? That was a question, and the answer was “Wall-E” (they had to name it after the movie).
Wall-E delivered what they wanted from the security point of view, in a simple to use and consume way for developers. Spoiler alert: in the process, they found out that a lot of problems are solved with proper authentication (identity for the win!).
You can read the whole story here (Netflix Tech Blog). Now, let’s talk about closing this loop on your end.
It’s no longer a theory nor a guess, but a fact. Microsoft have recently released a new edition of their Digital Defense Report. In it, they show the average prices in the “cybercrime-as-a-service” world:
So there you have it. There are people out there who are in the business of taking your business down. Even blockchain doesn’t solve that. Technology is sound when it comes to its security properties. Still, to break app security, just target people and their ops.
Latest example – it took a phishing e-mail to steal keys and $55M from a DeFi app (Hacker steals $55 million from bZx DeFi platform). Why did this person even have access to those keys and why weren’t they in a vault as part of their DevSecOps cycle?
Technology will change but problems stay the same, so the only way to change it is to change the way we do things. As per the report mentioned earlier, 98% of threats can be mitigated by ensuring the basics are covered.
I covered some of these basics before. Check out these articles for actionable tips for enabling secure development:
Today, in line with my “shift left” approach to these latest articles, I will focus on the developer side of things – and how to incorporate security into DevOps and connect it with something that many people think can’t be connected – Enterprise Security Operations!
Think: how many times have you seen DevOps pipelines connected to SIEM/SOAR and Security Operations Center? My guess, the chance is close to zero.
Isn’t that just DevSecOps? Yes, there is that too. But that’s just half of the story.
Let’s consider a typical development process (of course, this is majorly simplified). It goes through Commit, Deployment, Testing, and Security Check at the end:
Typically, developers and security analysts work separately. In many cases, it’s not until the code is already in production that it’s being scanned for vulnerabilities. That’s how standard Security Operations Centers were designed to work – monitoring services that are already in place.
The trouble is that by the time that happens, your code has already been exposed to threats for some time.
The point is that real work in security should start much earlier. So, how to make it happen? Here’s a concept that’s been on my mind recently.
A thing that often happens, although it’s a bad idea even as a concept, is that repositories often store secrets like credentials or access keys.
Imagine you have a private repo like that, containing some sensitive information. Now, someone from outside of your organization has been granted access to it.
Typically – nothing.
But with a monitoring service, you can set up an alert that is issued every time a new person gets access to the repo. Following the alert, the administrator can get an option to approve or deny access to the repository, creating an additional security checkpoint. In the simplest terms, it works a little like this:
Now, let’s connect the dots here (I like this phrase, as it was the name of the first company I’ve established). Let’s connect our developers’ pipelines with security analysts’ operations.
The real difficulty is not in the setup – it’s in the scale.
For your code to be secure, you need to have these security checks implemented and running every time they’re necessary, in every development process. This is where you put to work a cloud-based SOAR platform such as Azure Sentinel. It can gather all signals not just from your infrastructure, but also from the development environment. And you know what? Azure DevOps or GitHub pipelines are just another signal source for it.
And you don’t have to figure it out on your own – Azure DevOps rules are part of the Azure Sentinel community repo. Go and grab it. The same applies to GitHub.
Check out the latest additions for GitHub Actions for security and compliance, and think how much value it would give if you could pipe it to your security team to process and act on its output. And speaking of, if you are using GitHub you should check out this guide to securing its operations.
Acting is key. Ideally, you won’t just stop at alerting. You want to act on it, and Azure Sentinel allows you to do it with its playbooks, which they just released as templates in a staggering amount of 200+. Who can build those playbooks for you? Those are Azure Logic Apps, so you can ask your friendly developers to do it. It is what they do for a living.
If you don’t want to do it on your own, a service like Managed SOC can help you by notifying the right people about actions they need to take. You can think big, and we will handle the technology here.
What is important is to tune this whole loop correctly. Not all security incidents are equal.
Some incidents can be treated as minor in severity (e.g. granting access to another user within your organization). Others may need closer monitoring (e.g. granting access to a user from outside of your organization). And, of course, there are some you wish to avoid entirely.
Aggregating these incidents at scale allows you to quickly see and distinguish between their different types. Once you know what you’re dealing with, you can introduce the right safeguards to protect your environment.
And so, for granting internal access, you may wish to introduce a checkpoint for resource admin approval. Granting external access may require a permissions review. The most severe tier of incidents may result in an automated lockdown and escalation to your security team.
This is just an example of why monitoring your code at the source matters. And scale matters too.
As a final note, here are some great resources that explain the security loop concept in a bit more detail:
Read similar articles