 |
VOOZH | about |
|
VOOZH | about |
We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.
Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.
Follow TNS on your favorite social media networks.
Become a TNS follower on LinkedIn.
Check out the latest featured and trending stories while you wait for your first TNS newsletter.
Once upon a time, IT resources lived in castles (also called “data centers”) and were protected by moats (firewalls) and knights (your friendly security specialists). In these days of yore, the assumption was simple: everything in the castle was warm and fuzzy; everything outside the castle walls was hostile wilderness.
This worked well in the long-ago time, before the 1990s. Though zero trust, as either a practice or theory, didn’t evolve until much later, it was in the ‘90s that the cracks started to show in the castle walls.
This context is important because although zero trust is often discussed in terms of cloud native systems, the need for zero trust and the move away from perimeter-based security started much earlier.
When the entire IT system lived in one central data center, network security was much easier.
“The perimeter type of approach, the historical approach, was working fairly OK,” said Jonas Iggbom, director of sales engineering at Curity, an IAM and API security technology provider. “It was one point of entry that the firewall could control.”
With all of the IT assets on a segment of the network that was protected by a firewall, and limited access points that could be strictly patrolled, the system worked acceptably well. There were still limitations — if the firewall was ever breached, there was no security inside the network, so breaking through the firewall once gave attackers near-complete control over the system.
The problem first started with laptops and road warriors. What should the IT security think of the files on their salespeople’s 20-pound laptops? What about when you access your corporate email from a Blackberry?
“Should we treat it as if it was inside?” asked Leonid Belkind, chief technology officer and co-founder of Torq, a security automation company. “The reality of businesses being digital — adopting mobility, allowing people to work from everywhere, from every device — is that this deteriorated this whole approach of a very clear ‘who’s outside, who’s inside.’”
Then came the cloud, he noted, in the form of both Software as a Service (Saas) and Infrastructure as a Service (IaaS).
The castle was sliding into ruins before the rise in containers or microservices or anything that we would call cloud native now. It requires a completely different approach to security.
At first, the shift in security strategy went from protecting one, single castle to a “multiple castle” approach. In this scenario, you’d treat each salesperson’s laptop as a sort of satellite castle.
SaaS vendors and cloud providers played into this idea, trying to convince potential customers not that they needed an entirely different way to think about security, but rather that, by using a SaaS product, they were renting a spot in the vendor’s castle.
The problem is that once you have so many castles, the interconnections become increasingly more difficult to protect. And it’s harder to say exactly what is “inside” your network versus what is hostile wilderness.
Zero trust assumes that the castle system has broken down completely, so that each individual asset is a fortress of one. Everything is always hostile wilderness, and you operate under the assumption that you can implicitly trust no one.
It’s not an attractive vision for society, which is why we should probably retire the castle and moat metaphor. Because it makes sense to eliminate the human concept of trust in our approach to cybersecurity and treat every user as potentially hostile.
Ninety-six percent of security decision-makers consider zero trust critical to an effective security posture, according to a survey published by Microsoft in July 2021. But while support for the idea of zero trust is close to universal, vanishingly few companies are implementing it effectively.
Tech decision-makers overwhelmingly believe a zero trust approach to security is critical to their organization.
Sixty-five percent of companies use shared logins and 42% use shared SSH keys, according to a 2022 survey by strongDM; both practices run absolutely counter to zero trust principles. Zero trust requires not just rethinking your security program but also re-architecting your application to make the new strategy possible.
Implementation starts with granular authentication systems, which means forcing any users, human or server, that want to access a resource to prove that they are who they say they are.
Once you’ve authenticated a user, the next step is to follow that up with authorization or enforcement: Is that user allowed to perform the action it wants to perform? According to Iggbom, authentication is fairly widely adopted, but far fewer organizations follow that up with zero trust authorization systems.
Most systems would previously have been set up so people could authenticate into a castle — a group of actions. One of the things that sets zero trust apart is that it requires extreme granularity, allowing users to access or alter only the very specific resource they’ve requested access to, at the specific time they’ve requested that access.
