Fresh Thoughts #29: Security Should Be Shaker, Not Silk
- Newsletter
The minimal elegance of Shaker furniture doesn't always come to mind when thinking of security... but when security is done right, it should.
The first time I wrote a firewall ruleset, it was like fine woven silk.
Every network flow was a series of intricately crafted threads.
Woven into a series of permit and deny instructions.
It was beautiful.
I showed it to my manager and got a terse reply. "What's that?"
I explained.
And without a beat, he turned to the Security Director and asked...
"Should the ERP server - 24.57 - have access to the domain controller?"
"…Yes."
Turning back to me - "Well… does it?"
"Erm…" My intricate vision of beauty suddenly looked like an unfathomable rat's nest.
"Let me check."
…30 minutes later and 2 pages of notes.
"Yes, it does."
Time for an ear bashing….
"You should have answered in 30 seconds… not 30 minutes.
Those firewall rules don't even come close to passing the '3 am rule'.
You can barely understand them at 3 pm.
How on earth are you going to figure out what's wrong when you're sleep deprived and get a call-out in the middle of the night?"
Ear-bashing accepted. I knew he was right. 😬😳
It was time to learn - "So how should I write it?"
Then came the explanation that has guided me ever since.
"Form follows function.
- Start with a deny-all - that's the last line of the config.
- What do you want to permit?
- What is the exception to this permit rule?
- Any more than 2 levels of exception, and it's too complex. Make it simpler. Use better partitioning.
That's it."
As a lifelong design enthusiast, I spotted the Louis Sullivan quote and saw the Shaker simplicity in the approach.
Security must be as simple as possible to be effective at 3 am - or any other time of sleep-deprived pressure. Intricate is the last thing that's needed.
Having a process that requires at most 3 things to be remembered. And that can be picked up by anyone - and quickly understood. That's what a good security configuration looks like.
I remembered this early lesson recently when the Fresh Security team was working with a customer to configure a phishing simulation.
The email quarantine rules were an intricate web of permits and denies, spread across multiple screens. It was the crafted silk of a former employee.
The undocumented configuration had been left for a few months - "in case it broke something." Unfortunately, it broke the phishing simulation.
Then came the inevitable question... "Should we disable all the security rules?"
Not only did the configuration not pass the 3 am test, but it had rotted quickly.
With no way to understand it, the rules had gone from functioning security to significant liability in weeks.
The only reasonable option to maintain business operations was to delete it - and start again. This time with a much simpler set of design rules.
August 23, 20222 Minutes Read
