4 Principles for the perfect landing zone

Over the years, I have worked with many organisations that are giving their business users access to hyper-scale platforms such as Azure and AWS. This gives unprecedented flexibility which unlocks innovation to test products at pace. At first, this is often met with mixed feelings between IT, the business and the exec. On one hand, the "business knows best", and needs to get great new features out to the customers. While on the other, costs can quickly spiral and the security team's overtime pay starts to become a weekly cost. 

It is a tricky tightrope to walk. You really want to get the benefits of cloud, but at the same time, protect your profit margin and most of all, your data. With that in mind, I wanted to share a few principles that I build into all cloud strategies that gives the best of both. 

What is a landing zone?

Before I get into the detail, it is worth giving you an overview of what a landing zone is. If you think about the golden years of IT, organisations had well-defined processes and standards (well, mostly!). When a project was spun up, the right size servers were purchased, OS installed and all the monitoring and security tooling installed to security standards. Then, once live,  any changes to the configuration required various governance steps and change requests that had to be approved. These were built into budgets, roadmaps and business plans. 

Then, along came the cloud. Armed with a credit card, anyone can setup an account with Microsoft or Amazon, spin up some virtual services and present them to the internet. Shadow IT became critical to business processes and very hard to retrofit the safety nets. 

So, the likes of Microsoft and Amazon started recommending Landing zone frameworks. These are effectively agreed guardrails that are automatically deployed when services are provisioned. From the outset, networking, role-based access and monitoring are pre-configured and reported back to make sure they aren't a gaping hole in the security posture of the organisation. They also had a fascinating plus side, in that they started to remove the 'shadow' in 'shadow IT'. Business users could request their very own 'landing zone' that could connect to their existing on-prem applications, paid for by IT and supported. 

 Bring on the principles

So, now that you know a little more about the why... let's get into the principles. 

1. Governance with a lowercase g... The landing zone shouldn't be restrictive or a blocker. Teams should be able to deploy services that meet their requirements, quickly! Agree on the rules of the road, and put in a requirements-led process that enables the services that are needed. 
2. Report, not block - Set up reporting and compliance, and alert teams when the patterns and principles aren't adhered to. Unless under strict regulatory requirements, notify account owners and report against compliance. 
3. Pattern-led service catalogue - Have a governance process that validates patterns, automates the delivery and gives flexible access to the business teams. Each pattern will include critical components such as monitoring, alerting and role-based access, ensuring teams can consume without having the build it themselves. 
4. Don't over-engineer - Coming from an architecture background, this is the hardest one for me to take onboard, but believe me, it works. Start small with your landing zone, agree on the requirements, accept the guardrails and iterate as new applications are deployed to the cloud. You have to get closer to the business and engineering teams for it to be a success... so ditch the silos and roll your sleeves up. 

Following these key principles will help ease the friction between IT Security and the business, while ensuring security controls are baked into the deployments while giving engineering and business teams the freedom to innovate. Remember, it is a journey and will evolve over time, so no need to decide on every setting or decision from day 1! Although a well thought out strategy certainly helps!