Cloud Security: Striking the balance between risk, speed, and cost
Cloud security, especially at scale, can be a challenging thing to get right. Engineers want the freedom to innovate, organizations want to keep costs down, while security, risk, and compliance are sometimes treated as an afterthought. Managing these conflicting priorities is a struggle for many of the organizations I work with.
Getting this balance wrong has delayed a number of the cloud migrations on which I’ve consulted and increased the security risks during the process. Fundamentally, building an effective cloud security program is about finding a balance that matches your risk profile and works with the culture of your engineering teams. There is no cloud security posture or approach that is right for everybody, but it is possible to build one that works for your organization.
Organizations want to be quick to market, they want to be secure, and most importantly, they want to be efficient with the resources and budgets they have available. From years of advising clients on the cloud, I’ve found that failing to achieve a balance can lead to spiraling costs and increased demands on both security and engineering teams. If the costs become too great, you might find that the pace at which you can move and the safety with which you can do so are threatened.
Here are the two basic principles that I think you need to keep in mind when building a robust and secure multi-cloud program:
Principle 1: Balance velocity with security
The cloud promises speed. It promises to reduce the time to market for new applications, to shorten outages, to speed up bug fixes, and to boost the efficiency of developers. Speed, in turn, holds the promise of lower costs. But if the relationship between velocity and security is not handled well, these promises may not be fulfilled. Upset the balance between velocity and security, and you may find the costs of your cloud migration increasing.
Fig. 1. A diagram showing the trade-off between business velocity, security controls, and cost efficiency.
So, what happens when things become unbalanced?
Too much emphasis on business velocity leads to increased risk and higher cost
My team and I have seen countless cases where organizations have moved to the cloud without adequate input from security teams. Occasionally, we’ve come across cases where business objectives have mandated a shift to the cloud at such a velocity that making it secure by design from the start is impossible. In our experience, this leads to increased risk until sufficient security can be introduced, and the costs of retrofitting security into existing environments can be surprisingly high.
Recently, we helped a European utilities organization understand their security posture across a number of cloud environments that were managed both by in-house teams and by third parties. We found that the security posture of the individual environments varied enormously, which exposed the organization to significant risk. A large migration program was created to bring all existing cloud resources under a single management structure to support centralized security and risk management. This led to significant cost, and delays on other transformation projects in the organization while critical resources were diverted to deliver the cloud migration.
Too much emphasis on security leads to low velocity and higher cost
We’ve also seen the opposite, where too much emphasis on security has hindered migration programs. In one case, I aided a US-based financial services organization in a digital cloud transformation project that was designed to increase business velocity. Before I arrived, the internal security team had insisted on enforcing a broad range of security controls. These controls were built on assumptions rooted in legacy thinking and were tied to their existing on-premises estates. Crucially, they failed to understand the impact of these security controls on engineering teams. As a result, business velocity collapsed, and there was a dramatic increase in the cost of the cloud migration program.
In my experience, security designed without input from engineering teams introduces unintended additional complexity and cost. The most effective security programs my team have supported have all involved close collaboration between security and engineering.
Security exists to support the organization and to ensure that the business objectives are met in a manner that matches the organization’s risk profile. The key to this is early, regular, and effective communication between the engineering stakeholders, leadership, and the security teams within an organization.
Principle 2: Start early and speak to your people
Security is foundational: it doesn’t work when it’s treated as an afterthought or an impediment. It is possible to retrofit security, but the costs and resources required to do so are dramatically increased compared to getting it right at the start. My first recommendation on any cloud migration project is always to ensure that you bring the right stakeholders in at each stage of the design and implementation process. Below are some of the stakeholders I recommend speaking with, and the kinds of topics to cover with each:
Engineering teams
- What are their use cases for the cloud?
- Do they have preconceived ideas as to which cloud services they’re intending to use? If so, are the relevant security teams in a position to support that? (Kubernetes is a common challenge here.)
- Will your intended security controls clash with their ways of working? If so, what compromises can you agree on?
- Can you identify opportunities to design further security controls early into the software development life cycle (SDLC) used by the engineering teams?
- How can you empower the engineering teams to take partial ownership of the security of their products? How can you leverage their subject matter expertise to perform threat modeling, or design in preventive and detective controls and so on?
Attack detection teams / Security Operations Center (SOC)
- Do your intended strategies and controls around logging, monitoring, and attack detection work with their requirements and existing systems?
- What else is required for effective monitoring to be in place when production applications are placed in the cloud?
- Does the SOC have a strategy in place to develop their skills in this area?
Incident response (IR)
- Are their requirements for incident readiness and response adequately designed into the security control framework?
- What else needs to be done to ensure that incident response is possible before you deploy production workloads in the cloud?
- Do your incident responders have the skills needed to respond to a compromise in your cloud environment
Regulatory and compliance teams
- Does your controls framework meet the regulatory requirements for the workloads being deployed?
- Can you leverage security automation, either offered by cloud service providers or embedded in your SDLC process, to provide your regulatory and compliance teams with the necessary data?
On-premises system administrators and network engineers
- Are appropriate controls being implemented in the cloud and on-premises to secure any data in transit?
- Can you agree on a network architecture to connect cloud workloads to any on-premises systems, and deploy a blueprint for this on a per-application basis?
- How will you provide centralized single sign on (SSO) and federated access controls? Will this link into existing Active Directory deployments or similar, or will something new be implemented for the cloud?
With a well-balanced cloud security strategy, you will find that it is possible to lower your risks and keep your costs under control. In my experience, there is no one-size-fits-all model for how to do this, but there are general principles that can guide you to the right choices for your organization. If you balance speed with building appropriate security controls, and involve stakeholders from across your organization, you are well positioned for a successful, secure migration.