Have you heard about cases where data was exposed from a database to the Internet? Or about open storage account containing private documents? Every time it happens, most people think – "How did it happen? Those are basics!"Are those basics right in your projects? Are you sure? Let's talk about security!
Why protecting business information should be your priority
Everyone wants to be secure. Why do we care about security in IT? Is it because it is good practice? (Which it is.) Is it about passing the next audit? Security in IT is not a gimmick. It is a way for organisations to mitigate risk. Not threats to IT infrastructure. Not threats of IT systems breach. It is about reducing business risk. Here's a guide on how to do it without losing agility and speed of delivery.
First, let's answer the question: who takes care of security in DevOps? Is it a security department? Is it a cyber-security consultant sitting in another office? No. Security is everyone's business! Remember it and repeat it as a mantra every time someone says it isn't. Have you heard about Security Operations in DevOps, or DevSecOps before? Let's talk about it.
What is DevSecOps?
DevSecOps is about the integration of Security in DevOps. It is a process of monitoring security across all of our development and deployment cycle. "Sounds nice, let's do it!" But what does it mean in practice? Where should you begin?
Start with education
Training and education are the fundamentals.We have to be realistic. We can't make every person on our team a security expert. It is hard. What we need is some level of awareness.We need to train DevOps teams in the security of code, good practices, and threat modeling. Your team needs to know the platform security model and features, and how to apply them.There is plenty of security-related training. What to choose? For our consultants, we use Pluralsight as a great source of training in this area (check them out as they have some free offers for Azure users). Even with proper training, it is hard to assume that everyone on a team will be an expert. They need guidance.
Security planning
How can you know what areas of security exist in your product? How to build a backlog of work related to them? There is a process for it. It is called threat modeling. Threat modeling is a process to help you think about the security of your product. It feeds work items into your DevOps team's backlog. You don't have to re-invent it. Here is one called STRIDE from Microsoft. Use it as a starting point. There is a tool to help you use it. Here is an example of it in action for IoT projects.
Keep what is secret well hidden
A common problem with security is keeping secrets safe. There are many types of confidential data: client secrets, certificates, passwords. A common mistake is to store them with code in a repository.What's wrong with it?Many people can read the code repository. If they can get your secrets, your security is gone. Someone will mine Bitcoin at your cost using your cloud infrastructure.How to deal with it? Keep your secrets in a dedicated service – Azure Key Vault. Instead of keeping it in the code, integrate Key Vault with your CI/CD process. Here is a guide on how to do it. Pass it on to your development team. The best way to avoid leaking secrets is not to have them in the code in the first place. How to do it? Integrate tools like CredScan into your DevOps pipeline. It makes it a part of a process.
Secure your code
Even with training, it is hard to assume that there will be no mistakes in code. How do we reduce the risk of it? How to ensure that we keep track of it and that the product code follows best practices? Use tools like SonarQube or its open source equivalent. It scans your code for potential security and quality issues. No experts needed.Another common problem? External libraries.How to know if those are secure? Get WhiteSource bolt to help. It is free to use and scans and identifies known security issues in open source libraries.
Build security into CI/CD pipelines
When code is ready and verified, it is time for build and deployment. Automation is a beautiful thing – it makes deployments fast!It also creates a new area where you should pay attention to security: your CI/CD pipelines! Have you thought about how to secure one? It is good practice to think about it before someone gains access to it.Your integration pipeline is also a place where you can include security in your process. When something is not right, you can fail to build and instead bring it to the developer's attention.How? Use Azure Policies verification as a part of your build process (Azure Policies is part of the platform and is free to use). If someone tries to create a storage account with open access, it will fail the build before it happens.Do you need something more advanced? Use tools like Pester to build your tests and verification templates.
Bonus: more resources!
That is it for a start – the five typical steps that are part of DevSecOps. The goal is to put security as a practice into your DevOps, to make security everybody's business.There are many ways to achieve this objective. Here is a good summary of a different approach to DevSecOps gathered in a single document (registration required).Make sure to also check out some extra references:
- OWASP DevSLop project
- Microsoft's DevSecOps tools website
- Practical DevOps training site
DevSecOps is an emerging practice. What does it mean? With DevOps, we have plenty of standard solutions and patterns to follow. With DevSecOps, tools and methods are still in development.You should join this movement NOW. It will benefit the security of your products in the long run. And with better security, comes less business risk!
Author
