Secure by Default: How to Build Your Cloud Architecture From the Back
Why you should fully integrate secure by default thinking into every architectural decision.
In 2022, many organisations are still not taking a secure by default approach to technical and procedural decision-making when designing or procuring new solutions and integrations. Security is often seen as a task for the end of the deployment process and something that should only be applied right before the newly designed solution goes live to consumers.
As security is commonly split off into its own distinctly separate department within an organisation that functions by itself, collaboration between these teams and other technical departments exposes a breakdown in communication that can have serious ramifications when it comes to launching a new solution.
In this blog we’ll look at the principles that organisations should follow from both a technical and cultural perspective to both bolster the design methodology and fully integrate secure by default thinking into every architectural decision.
What are Secure by Default Principles?
The principles of secure by default (sometimes referred to as ‘secure by design’) that we’ll cover in this blog span across technical and operational decision-making, ensuring that security awareness is factored into every design authority meeting, change request and even every conversation at the coffee machine.
Using these principles is not supposed to force teams to only think about security and disregard user experience, performance or cost effectiveness; it should simply be a default forethought when considering any architecture or deployment alteration. We’ll dive into the following principles that are key to achieving this objective:
- Cloud services provider choice
- Setting the right trust model
- Governance before deployment
Build From the Back
Before we go into the principles, I want to emphasise a football strategy that I always send my brain to when designing a new greenfield solution: building from the back.
When José “The Special One” Mourinho arrives at a new club, the first position he immediately focusses on in the squad he’s been provided is the goalkeeper to minimise the chance of goals being conceded. He will then analyse the defenders to ensure they’re both rigid enough to prevent threats and are communicating effectively with each other, including the goalkeeper behind them.
Only when he’s satisfied with his defensive and reactive capabilities within his team, will he then start focusing on his more proactive midfield and forward options. If a football team like Manchester United scores three goals but concedes five, all of the potent attacking options the club has at its disposal are irrelevant because the team is considered fragile and widely open to threats at the back of the pitch.
Even if you don’t understand or even like football, hopefully the example of how José Mourinho builds his teams from the back immediately translates to how and when security decisions and considerations should be made. Start with the threats, then build from there.
How to Choose the Right Cloud Service Provider For You
Top of the list for secure by default principles will always, by default, be the choice of cloud service provider—this is because of the shared responsibility model. The different providers have slightly different interpretations of the model but they can always be summarised down to the concept that you as the consumer are responsible for security in the cloud, and your provider is responsible for security of the cloud and its underlying components. Additionally, the core security controls the main providers have can be easily compared as they all have strong encryption methods, APIs, strong IAM capabilities and posture management toolsets to name a few.
The major cloud service providers (Amazon Web Services, Microsoft Azure and Google Cloud Platform) offer a range of security solutions; choosing the most suitable largely rests on existing architecture, current and future cloud adoption strategies and specific use-case requirements.
Microsoft Azure, for example, might suit customers requiring a unified security ecosystem behind a single pane of glass that fully protects and monitors identity, productivity, infrastructure and other components.
AWS, with a near universal set of integrations with external open-source solutions for security tooling, is great for customers who've already embraced open source and want to have security components such as SIEM and vulnerability facilitated by fully separated services.
The choice of cloud service provider is the bedrock for nearly all security decisions and to effectively design architecture that is both secure and integrates into the customers strategic objectives, so you need to make sure it’s the right choice to suit the needs of your organisation.
How to Set Up the Right Trust Model
It’s vital that when formulating a solution that the trust model that the customer follows is understood meticulously. The customer could follow a strict zero-trust methodology for resource and user control, meaning every user request or packet of information is scrutinised for authenticity and relevance. Networks could be diligently segmented into a logical separation that allows applications to function with the required connectivity, and user connectivity could be intensely guarded on every login request. Or the customer might have a more robust attitude to network security, but a more open attitude to user device security by implementing a bring your own device (BYOD) model, for example.
The point is the potential combinations for what the customer’s trust model could be is almost endless so it’s vital that consultants understand it so that the new solution can be securely designed to integrate with the customers model, whilst also offering some improvements to bolster the model and enable the customer to potentially alter the model, perhaps to a zero-trust focused one in the future.
An early understanding of the customers current and future state with regards to trust model is an imperative principle for any consultant wanting to ensure that what they’re designing is secure by default, but isn't overriding or undermining the customer’s over-arching way of working when it comes to trust.
Governance Before Deployment
Finally and perhaps the most important set of thinking that should be in every consultant's mindset is governance before deployment. Generally, governments do not implement new laws or guidelines without ensuring police and courts have the power to enforce them, so why would you as a consultant implement a service without rules to restrict its attack surface? The simple principle with this one is that you should always design and implement security policies and guardrails before making the solution you’ve designed a live service. Having appropriate policies around IAM, network control, management enforcement and code ownership to name a few examples is likely going to be included in any acceptance-into-service guidelines the customer has, and having them in place and tested prior to go-live on a solution makes a new deployment both more efficient and more security aligned from the outset.
The same concept can apply to the CI/CD pipeline through the use of DevSecOps methods such as static and dynamic code analysis or pre-execution threat modelling which all empower developers and security engineers to, by default, implement security factors into code deployments with minimal overhead.
Enterprise customers that are now closely following gold standard security practices have developed their own security frameworks to ensure all employees and resources are aligned on security posture and configuration characteristics throughout the organisation. Study these controls carefully as it’s safe to assume they’re a set of best practice principles, however there may be a set of proprietary controls that require a very specific and non-conforming approach.
When you have the knowledge of these customer-specific controls it will begin to naturally factor into your design decisions when considering the controls for your solution, and you as a consultant will have to work in parallel with other teams to ensure effective and suitable governance is in place prior to deployment.
In Summary
You’ll notice that even though most of the topics covered in this blog have covered different tech areas, they all revolve around the idea of consultant mindset. The technical solution is always vital but the secure by default mindset is the most vital component when becoming a consultant who always without fail designs solutions that meet industry security standards, customer strategic expectations and policy guidelines during the design process—and not after it.
When more individuals in an organisation embrace this continuous mindset, it will begin to drive the organisational mindset of switching to a secure by default stance for every design decision, architectural change or product procurement. As that mindset develops it is nurtured into a methodology that is more normalised across IT teams within an organisation—security will gradually over years become less arduous and feared as it is by some organisations now, and it will simply be there without them knowing, by default.
