Security layers to deploy Zero Trust
Backstory
As negative as this sounds, many believe Zero Trust is an effective model to deal with the massive complexity of security that needs to be in place for all of our digital interactions. Just say NO. Then sort out the exceptions.
Our security expert had been spending a lot of time helping companies optimize security across their infrastructure. He wanted a diagram to show people the layers that need to be in place for security at every level. From the moment users interact with any device to the delicate underbelly where the data is kept.
He was already on to the idea that this had to be represented in some sort of nested structure. He also suggested this nested structure sit on top of the three founding principles like pillars.
Defense In Depth – aka Zero Trust Security – requirements paper
What could go wrong?
The domain expert had an epic amount of information that he was representing on a single page. He identified 8 layers. Each layer had numerous internal layers showing the different hurdles that security needs to address. Complicating this, one of the layers (applications) had two defining aspects. And, all of these layers-within-layers were to be shown operating on top of three founding principles. I couldn’t imagine how I might represent all this.
Strategies to avoid what could go wrong.
Design a 3D representation that could contain all this information. Find a 2D view that would work in a single graphic.
Use consistent graphical treatments and typography to show the different levels of security – Trust Gates versus Checkpoints.
Using callouts, and color-coding, to add all the geeky details without crowding the structure.
What worked?
The graphic has been downloaded hundreds of times and collected many thumbs up by security-minded folks on LinkedIn where it is repeatedly published by Dan Williams, system engineer at CrowdStrike and Security Industry Influencer who likes Infographics.
Zero Trust Security Infographic pdf.
Notes to self
It’s often a challenge, pulling the vision out of someone else’s head, into yours, and then on to some form of presentation. This was no exception. My colleague had an idea of some physics-defying structure that he wanted me to build in an impossibly small space.
Relax into iterations. At one point, after a lot of trial and error, I had a model that I felt nicely solved the container problem. A tower-like structure that could coherently house the endless amount of content. The security expert send it back to me and said it needed to appear more nested, it was looking like a tower.
This is a common situation between a designer and a client. It’s important to push back when you start becoming someone’s crayon. Then again, it’s just as important to know when you need to listen. If my representation wasn’t working for the domain expert – then it wasn’t a solution. Back to the drawing board.
By working together we reached a solution that neither could have gotten to alone.