Development, security, and operations
Security has often caused friction within the Devops space. Security wants to be involved as they have the responsibility of securing the whole estate. Developers, on the other hand, like to have freedom and move forward with technology. In most cases, innovation happens within Devops. The business highlights problems and developers present shiny new ideas.
In most cases, this is great however can leave Security on the back foot. Security is often brought in at the wrong stage and is left trying to piece square pegs in circle holes.
Devops start to develop processes that are heavily automated, however, if Security has not been involved manual breakpoints are created: Firewall blocks, user access, non-compliance resources being blocked (Stack coverage), etc…
They could work hand in hand, but they don’t. In comes DevSecOps.
Rather than Security being involved at each stage, and treating them like children, they should instead let those birds fly.
Security should define policies, procedures, and processes that developers must follow. Automation should be heavily used for enforcement of these, when available.
The idea of “shift-left” should be driven by the culture change so that a shared responsibility for Security is clear. Friction is generated when stopping points are created for “manual security approval or checks”. There are some use cases where this is valid, however, we should aim to reduce it.
If you have implemented those governance tools and policies, there should be no need for manual checks. There is a need however for Security to be involved in DevSecOps but again from the sidelines. Security should be reviewing the “concepts” as a whole and fully understand the CI/CD process.
Things change, so the security design you put in place will need to be correct. For example, if your company runs IaC, you may have a tool that scans the templates before they are deployed. This security scanning tool may look for misconfiguration or apply baselines to ensure only secure resources are deployed.
This is great, however, what if the developers start using pipelines for application and container builds? The security scanning tool here may not be enough. Sure it’s good at scanning config templates, but what if you are now deploying images?
If the culture is healthy and both sides are moving towards DevSecOps, then the developers themselves should start to flag these concerns. Again, it’s not up to Security to always be watching, but for the developers to start taking on more responsibility for security also. It shouldn’t matter if it’s not their job. If they are deploying a new pipeline or the process changes, they need to work alongside Security as a team.
A lot of this will be picked up by running threat modelling.
Threat Modelling
Microsoft:
Attackers might exploit weaknesses in:
- Development process: Attackers might find weaknesses in the application design process, for example, using weak or no encryption for communications. Or attackers might find weakness in the implementation of the design, for example, code doesn’t validate input and allows common attacks like SQL injection. Additionally, attackers might implant back doors in the code that allows them to return later to exploit in your environment or in your customer’s environment.
- IT infrastructure: Attackers can compromise endpoint and infrastructure elements that the development process is hosted on using standard attacks. Attackers might also conduct a multistage attack that uses stolen credentials or malware to access development infrastructure from other parts of the environment. Additionally, the risk of software supply chain attacks makes it critical to integrate security into your process for both:
- Protecting your organization: From malicious code and vulnerabilities in your source code supply chain
- Protecting your customers: From any security issues in your applications and systems, which might result in reputation damage, liability, or other negative business impacts on your organization
Microsoft has some really good documentation here: Innovation security — Cloud Adoption Framework | Microsoft Docs
There are some good tools out there, but for myself, I always find it best to look at everything from a red team point of view. Look at the model, or the CI/CD life cycle and see what you would destroy/steal and how. Write these scenarios down, and start to expand on how you would secure them.
If the developers start to use tools outside of your environment, your list may grow.
Platform Threats
Let’s say you use Azure DevOps to host (Repo) and run CI/CD pipelines. What you’ve done here is put all your eggs in one basket. Is this wrong, no but for threat modelling, we may need to split them out. Treat the platform, repo and pipelines as separate. If you managed backlogs through the same tool, add these to the list.
With the platform, you often can run through the most known controls:
- Permissions will need to follow the least privilege access with services broken out per role (Write, Execute etc..).
- Manage access using groups rather than defined per user.
- IDP management — Login Criteria (conditional access).
- External guests should be blocked or limited.
- Granular RBAC access should be granted for the Service Connection used (Platform > environment).
- Enable Auditing for visibility and incident response.
- Network security — Reaching the platform and how.
most vendors will have a best practice: Security best practices — Azure DevOps | Microsoft Docs
Repo Security
Repos security is a big concern as this is your config or code. Although it may be mere config files, they are still “trusted” and therefore an attack vector.
Think of this:
You host configuration files on Github. An attacker gains access to this repo. Thankfully, you’ve separated out the rules so that the attacker can’t execute the pipeline and only has access to the repo. They also don’t give any sensitive information away as they are just config files that are used to create resources.
They are stuck, right?
Wrong, what if they change the configuration files for their benefit? What if for that PaaS SQL service they set the admin password? What if they make sure your storage is public facing? They know the naming convention, so they just need to wait for developers to run the pipeline. Once done, if the environment’s controls aren’t blocking, they may have created an access point to exploit.
Obviously, there are more complex and severe scenarios, but hopefully, you get my point. Snyk does a really nice cheat sheet for repo security. This again is for Azure, but many translate.
Changing The Culture
This is the hardest stage. It’s easy to implement tools and processes, but it’s hard to adopt a change in culture. Especially with regards to Security. Often, we are seen as the bad guys as our firewalls block everything, or the EDR/AV breaks all those important things.
With DevSecOps, you have to start to accept that you can’t do it all. Often as a department, we are spread thin and the role of Security is never truly defined. We do bits and bobs and can have our day ruined by an attacker or vendor (0-day) at any minute.
With DevSecOps, we set the boundaries, make it clear and let the developers do their thing. With this “freedom” comes a healthy understanding that they aren’t just “developing anymore”. They take on the responsibility of doing it securely. Deadlines have to be met, but there are no shortcuts anymore.
You can’t just create a new pipeline and not implement the security scanning. They can’t just disable the criteria that is blocking the deployment. This by the way should be on your threat model.
By no means does security get a break (sorry), but they shouldn’t have to be as involved anymore. Remember, if you’ve set the policy environment controls correctly, it shouldn’t matter what they do. Regardless of its IaC, manual creation or CLI, the environment should enforce standards to match company policy. This is where time should be spent, to make sure A. it’s working and B. what’s it picking up and why?
Defining Roles and Responsibility
This leads us nicely to defining those roles. Culture is nice but they really do need to be set in stone. Everyone needs to know what part they play.
- If you have shifted left, do they own the tools are well?
- Where do developers need to flag issues?
- Who changes the criteria if needed?
- Who changes the environment policies?
- Who owns each automation aspect (Resource creation; Infra, Networking, Security).
All of this needs to be documented and clear. Exception processes will also need to be created as use cases will emerge. It’s good to get ahead and define the process early. That includes criteria, risk acceptance and where to record.
DevSecOps isn’t just going to be an easy fit. With innovation comes new ideas and perhaps tools or way of working. Each new aspect with regard to security needs to be documented and understood. This may include manual effort. Remember, automation is great, but it might not be viable to automate everything.
Hopefully this should get some ideas flowing and help you understand what DevSecOps is or could be.
If you enjoyed reading my content and want to support, why not consider signing up and becoming a member. It’s $5 a month, for unlimited access to all stories on Medium. Join now! 🙂
Need help? Why not also check out my Fiverr or UpWork.
Regardless, thank you for reading!
amoran.io 
Leave a Reply