I hit an obstacle on my way to extending the common resource tagging models with context to describe security and risk attributes.
I couldn’t get past that while I feel this should be a settled engineering practice, it isn’t.
Suspecting bad assumptions lurking around, I spoke to some engineers practicing DevOps with titles like DevOps Engineer, Principal Site Reliability Engineer, Lead Infrastructure Engineer, etc.
What I found is that even when Security teams want to work with engineers to lay the foundations or enhance the security of Cloud deployments, they’re often unable to for a variety of reasons.
Some of the reasons I’m hearing from DevOps practitioners are that the Security team:
- is under a lot of pressure due to a centralized organizational structure
- may have an unclear mandate within the organization or working with delivery teams
- is challenged by the vast surface area to cover
- is frequently interrupted by both routine and urgent operational work
- got behind on establishing Security foundations and can’t catch up
DevOps practitioners empathize with those problems and can see the tsunami of 10x more components and rate of change on the horizon.
In response to those problems, DevOps practitioners fill that gap the best they can by:
- treating the Security team as a major stakeholder and pulling requirements from them
- acting as a trusted extension of the Security team, providing technical advice to the Security team and security practices to platform users
- designing and implementing libraries and tools that codify official security policy for platform users
- (some are) using free security assessment tools to identify security problems
These behaviors shift security ‘left’ in the software delivery lifecycle and unlock the #DevSecOps hashtag. Security is shifted ‘left’ because robust Security principles and practices are incorporated early in the development and delivery process instead of detecting problems and resolving them after deployment (only to be overwritten by the next deploy, continuously).
And what DevOps practitioners don’t love about filling the gaps and understanding Cloud security is:
- most people still aren’t comfortable with their Cloud security posture
- there still Security expertise gaps; that gap may be unfunded or may be filled by relying on an external security assessment service, which is:
- done infrequently – roughly annually when it’s done at all
- may or may not provide valuable and actionable advice
- understanding the output of many security tools can be difficult (c.f. Research: Problems with top free security assessment tools)
- CI/CD systems operate with high-privileges and engineers can make any changes they want through that automated delivery process
The last point isn’t a problem with understanding the security of the system. Rather, it’s lack of comfort with the risk that automated delivery methods can introduce and lack of sufficient controls around those methods.
Takeaways
My biggest takeaways from this research are that:
- Centralized security teams are generally unable to participate deeply in the design and implementation of Cloud deployments
- DevOps practitioners can and do shift security concerns left because they care about security are able to implement scalable, albeit limited solutions
- Security teams value and trust DevOps practitioners to extend their reach and implement Security policy
- We are still early in the development and integration of security practices into automated delivery processes, especially to Cloud platforms
I realize there are exceptions to these takeaways, particularly from mega-Tech companies with elite security practices. I’m not saying those organizations don’t model security attributes and assess their security posture and risk continuously. I’m sure some do.
The objective of this research was to try and discover why ‘regular’ organizations are inventing bespoke models and custom integrations for an important, cross-cutting function that everyone has. And help you collaborate across teams better.
To me, it looks like we’re in the process of (re-)establishing the language to describe and encode the security attributes of our Cloud deployments.
Interestingly, no one mentioned using a Configuration Management Database during these conversations. I wonder what we can learn from that, as well as CMDBs.
Stephen
#NoDrama
