What holds us back from making things better in security? The disconnect between security people and developers.When those two worlds "meet" (although "collide" may be a better word to describe it), usually it is more about open guns and finger-pointing than fruitful collaboration.What can be the reason? 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, we 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.
Netflix and the paved road of secure development
We all know Netflix (or at least we 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 the "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.
Cybercrime is an industry
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:
[caption id="attachment_188086" align="alignnone" width="952"] (Image source)[/caption]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.An 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.We covered some of these basics before. Check out these articles for actionable tips for enabling secure development:
- What to do after a ransomware attack?
- When was the last time you changed your password?
- Do clouds dream about disaster recovery?
- 4 steps to find out if your company is affected by Solorigate
- Why is cybersecurity important?
Shifting to the left: Closing the DevSecOps loop
Today, in line with our "shift left" approach to these latest articles, we 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? Our 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. Usually, 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 real work in security should start much earlier. So, how to make it happen?
Agile security feedback loop in secure development
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 organisation has been granted access to it.
What happens?
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.
Level up: monitoring at scale
Now, let's connect the dots here. 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 organisation). Others may need closer monitoring (e.g. granting access to a user from outside of your organisation). 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:
- How to strategically use the OODA Loop and SCRUM within a SOC
- An OODA-driven SOC Strategy using: SIEM, SOAR and EDR
- Azure DevOps Service security monitoring using Azure Sentinel
Author
