Cloudentity Blog

You may have seen my posting on East/West is the New North/South.  The bottom line is that traditional API Gateway models simply don’t provide the level of security we need in modern microservice architecture.  The problem is that only 20% of the traffic (that is the inbound traffic up until the gateway) is secure, everything inside the data center is “trusted.”

In computer technology we talk about security breaches and how to prevent them, but honestly, we have different kinds of breaches and different reasons to want to prevent them. Sure we hear the stats like “60% of small companies that suffer a cyber-attack are out of business within six months” but what is it about those attacks that cripple and destroy companies? And how can we create better security policies and implement those policies so we don't suffer attacks?

The Cloudentity stack is very powerful and very flexible, which means it's hard to tell the story from one person's point of view.  This short (1:15) video gives a quick view from four different people's perspectives.

We talk about network traffic in two ways – North/South traffic is the traffic heading in and out of your network. East/West traffic is the traffic from one server to another inside your network.  So why do we focus so much on North/South and almost forget about East/West?

As I mentioned in Identity and Security Starts at Home, the era of Zero Trust means we can’t trust traffic coming from inside the house.  Internal systems can be compromised and if your internal security is just IP whitelisting or trusted certs, a “trusted app” can do a lot of damage by probing the internal network.

 Authorization has come along way since setting bits in the file system. With the advancements in Machine learning, big data and behavioral profiling its time for authorization to take its next generational leap and move into a flexible risk based access control model that works in concert with legacy access control policies.

The term "API" is tricky.  It stands for Application Programming Interface, but a lot of people seem to think it means “All Powerful Incantation.” You always see decision makers sigh in relief when they find out a product they’re looking at has an API, they’re not sure what it means but they know their developers will be able to do magic with it.

Trouble is, an API isn’t a single thing.  It’s the classic elephant where blind men each get hold of a different part of the elephant… “It’s a snake!” “It’s a tree trunk!” “It’s a wall!” To front-end developers it’s a collection of resources. To a SysOps engineer it’s a firewall. To an engineer it’s an abstraction. And to an Information Security officer, it’s a big mess.

Security management has historically been focused on the User attempting to access a resource. But in the increasingly complex world of CI/CD methodologies and microservices, it’s no longer “Users” and “Resources” we need to secure. Applications need to talk to each other, resources need to move from development through production and be managed by automated systems, and the systems themselves have become consumers and contributors.

We tend to think of “Identity” as a static thing. I’m “me” and I can prove it! Only my “identity” is extremely fluid. Identity, in the IAM world of Identity Access Management, isn’t just me proving I’m Michael Bissell, but it’s me proving that I’m allowed to do things, and therein lies the challenge.

To be honest, most companies still use their IdP (Identity Provider) as a way to login with AuthN, plain old Authentication. They think they’re doing AuthZ (Authorization), but in reality, you have a fractured Identity strategy any time you have a system that has to make a second call to a database after I log in, just to figure out what I get to do.

I started my career back in the days when we hosted servers in the basement of the office. At the time, we never really thought much about security until we deployed the code (which pretty much meant FTPing a bunch of files to a server). Security was handled at the router first – block malicious traffic from getting in the door. Then we locked down the firewall on the server itself (no, you can’t telnet from outside the building).