So, you probably have two questions right off the bat.
The first: Why on earth am I shaving a Yak?
The second: What’s technical debt?
Good news… They are the same thing…kind of, let me explain.
What is technical debt?
Let’s start with the easier question – What’s technical debt? We’ll get the Yak shaving soon enough.
Technical debt is a term that was coined to define the accumulation of technical decisions that create future complexity. To be clear, it’s not something that anyone ever sets out to create. Technical debt much like financial debt or owing a favour to that one person you never want to owe a favour to, is something that tends to just; happen. You need to get a project across the line or find a solution and then an indeterminate amount of time later, you find that it was not actually the optimal solution. This is technical debt; you need go back and fix something at some point. This involves extra time, money, approval and brain space…. all things that are rare commodities!
Now. Shaving a Yak. Have a think about it: How would you shave a yak? And why? The whole process just seems painful, tedious and unnecessary. So why would you shave a yak? Well, there you have it, “Yak shaving” a series of seemingly un-related tasks you must complete before addressing your actual problem.
For example,
- You want to Enable MFA for all users because it improves your security posture and is required for Essential 8 Maturity Level 1.
- Some users are excluded due to legacy conditional access policies in the environment
- You need to audit and clean up the old policies
- Some policies are tied to deprecated user groups
- You need to restructure and update the group membership for the tenant before enforcing MFA
Congratulations, you’re now busy shaving a yak!
The hidden cost of technical debt
Now we say hidden cost because no one likes to admit that the cost of technical debt is painfully obvious. If you’ve been around the block a few times you’ll know of the one application, server, network device or business server that just seems to need a little bit extra love (or to be decommissioned 😉).
When your yaks start to need extra love, they become the dreaded “Yak Diva” and at that point the work will only ever increase!
That’s the cost of technical debt
- The process might be just a bit harder, slower or more manual
- The patching might be just a bit slower
- It has more bugs than other services you support
- You need to build workarounds as it’s just not quite good enough
- You can’t scale to meet the security controls required of a modern solution
Any of the above make it harder, more time consuming and then more costly just by its own nature, when you start combining these…it becomes a real problem.
Where can you find your Yak (technical debt)?
Well, I know where I find mine….in Azure, not because Azure has more problems than other cloud platforms…it’s just because I’m an Azure specialist so I find my Yaks in an Azure Data Centre! It would be confusing if I found them in AWS, sometimes I find customers Yaks too, but you deal with them the same way.
Some of my favourite spots to catch Yaks include
- Legacy IAM models
- Everyone has Global Administrator access so you’re always shaving the yak trying to introduce least privilege.
- You argue about what the right permissions are to get the job done and wonder why you can just go back to the “good old days”
- Redundant security controls
- Having loopholes in conditional access policies due to complex deny/exclusion rules so your policies have more holes than swiss cheese.
- Running duplicate EDR solutions together when you can just use Defender which just increases complexity and yak shaving in the environment.
- Poor defined security policies
- Poorly defined security policies which lead to inconsistent configurations and enforcement of controls, and no one knows what it secure and what is not.
- A lack of standardisation across the environment which leads to different kinds of yaks with similar problems
- “Outdated” network designs
- A focus on VPN’s and protecting the network edge which means you cannot leverage Zero Trust security tools like Just-In-Time and Just-enough access
- You are stuck using insecure edge network devices which attract CVE’s faster than a Yak attracts flies!
Paying down the debt – How to get a smaller yak
Sadly, I am yet to find a solution to get rid of the yak entirely, its nature of the yak…always there…. waiting for a shave. However, you can make your yak smaller (and therefor easier to shave) but taking some simple steps.
Assessments and Priorities – Assessing the problems with your yak is important, if you don’t understand where the risks are you’re not going to be able to resolve them efficiently. There are tools like the Microsoft Secure Score and Compliance Manager to help you gauge your security maturity (particular against other companies of a similar size and verticals), you can also conduct architecture reviews to help identify high risk issues which are in need or urgent attention.
Small wins – Shaving a yak is hard, there is no getting around that, fortunately, by getting small wins on the board you will start to see and difference and gain momentum. Gradual improvements over time and a tried-and-true method of uplifting a security environment and showing that you methods are working. You can phase out legacy tools with the solution offered under the Microsoft E5 stack, you can start phasing in Zero Trust principles like MFA or segmenting privileged access in your environment. You don’t need to shave the yak all in one go.
Standardise – The second most powerful suggestion I can give you for having smaller yaks is to standardise. The less variance and complexity there is across the environment the easier it will be to look after your yak. It is important to note that some environments are complicated by nature, and you need to find the middle ground between standardisation and allowing the business to function. Azure Policy can be a great tool to manage these settings at scale.
Stakeholders buy-in and business alignment – This is the most powerful suggestion; you need to make sure you’re that your work aligns with the business goals. The last thing you want to do is have stakeholders and executive buy in expecting a lovely Yak with some nice bangs and you give them a yak with a mullet!
Alternatively, you don’t want to work towards resolving issues well down in the weeds on Identity Management when your stakeholders have much larger concerns around overly permissive networks or endpoints not have security baselines applied via Intune.
How I avoided shaving my Yak (a small case study)
Now of course, I have tried to shave my share of Yaks and like to think I am proficient with it, but what I really like doing is not having to shave the Yak in the first place. Here is my story, The Yak has been anonymized to protect its identity.
Scenario: A national financial institution needed to provide MFA functionality to a core business application and provide access to remote users. Remote access required a legacy VPN solution which was end of life and needed to be replaced, adding the MFA functionality would have required tens of thousands of dollars of development/integration work from the vendor and an 18 month change window to implement with customers. Thats a lot of yaks to shave, code updates, testing, integrations, regulatory approval, customer communications, change windows and barber fees!
Solution: Skip the shave and deploy an Azure Application Proxy to provide security, identity aware access to the application with a VPN.
Steps to implement:
Pre-requisites:
- Entra ID Premium P1 or P2.
- An on-premises server to install the Entra ID Application Proxy Connector.
Install the Application Proxy Connector:
- Deploy the connector on a Windows Server that can reach the internal web app
- Register the connector in the Azure Portal.
Publish the Internal App:
- In Entra ID, navigate to Enterprise Applications > New Application > On-premises application.
- Enter the internal URL and configure external access.
Apply Conditional Access & Security Controls:
- Require MFA for external users.
- Restrict access based on user roles and device compliance.
Test & Roll Out:
- Ensure users can access the app securely via the external URL.
- Decommission the VPN access for this application
Outcome:
- Eliminated VPN reliance for applicated
- Enforced security policies via Entra ID
- Simplified user access while maintaining application security
Instead of sacrificing time, gold and sanity at the Altar of the Legacy Vendor, you simply led the yak around the mountain. An Azure Application Proxy was found, the VPN rode off into the sunset, the yak – unshaved – continued to wander along the path never to be seen again, blissfully unaware of the chaos it almost caused.
If you need help because you’re stuck shaving Yaks don’t hesitate to reach out!
And last but not least – the Yak tax!