Rip van Security

Gunnar Peterson asks a question:

...how do you primarily rely on network security as we have done for the Web's life, when the Cloud abstracts the network away?

Gunnar points out IT security has been using firewalls and SSL as primary security for every network acccess software change since 1995.

In 1999 when SOAP emerged as a firewall-friendly protocol designed for the explicit reason to go through the firewall, that should have been a wake up call to Information Security that the "firewall + SSL" security architecture was past its prime, but here 10 years later we are still hitting the snooze button.

Here many years after we lost email for everybody but aging geeks and banks, IT security continues to snooze like Rip van Winkle. While the world changes around it:

Think about the Mainframe as the quintessential Push Program: top down design, centralized control, procedural programming, and resource centric. Delivering security services to a Mainframe is fairly straightforward, the terminals are dumb, the communication links are "internal", and then its a matter of loading users into RACF and assigning privileges.

The first difference here is the amount of a priori knowledge required to pull this off

Then there is the resource-centricity- RACF is RESOURCE Access Control Facility, but what about the user? What if there are multiple namespaces for resources? Where does the Resource domain begin and end in a Cloud, a Pull Platform which is demand driven not provider-driven?

Now, lets look at the constituents of the Pull platform, its dominated by uncertainty. Demand is uncertain, its people centric, there is constant innovation, new code rolling out all the time. There is no "design" there is emergent set of behaviors and structures.

And what about the developer? Linus Torvalds famously wrote back in 2001 arguing that Linux is not designed:

Don't underestimate the power of survival of the fittest.

And don't EVER make the mistake that you can design something better than what you get from ruthless massively parallel trial-and-error with a feedback cycle. That's giving your intelligence _much_ too much credit.

Linus's immediate point back then was that Sun was doomed. And he was right. Sure, Sun is still around, but its market share has shrunk while Linux's market share has boomed. Linus wasn't saying to ignore obvious principles like layering or bits of technology that work, like sockets. He does say in the same thread that a lot goes on beyond the formal specs, in actually implementing things to solve real problems.

Gunnar again:

"My view is that as technology is deployed we need security mechanisms that form fit to those new technologies, instead what we have is security technologies that form fit to auditor's excel spreadsheets."

Yeah, not only do ISPs and businesses try to build higher forts alone, but IT security professionals all protect their jobs first. As long as they can check the boxes auditors want, they keep their jobs.

Meanwhile, the black hats have a thriving underground economy and they constantly copy what works in stigmergic learning that constantly produces emergent behaviors.

There's no way forts at the "perimeter" are ever going to fight that. White hats will win only if we're all in it together. Not even just all the target organizations (which means just about every organization), but we even need to get beyond IT security professionals as a class that can fit security technologies to new information access technologies.

IT professionals need to find a way to do what Linus did: create a thriving ecology of participants who create emergent behavior. Behavior that will fit itself to the new technologies.

It's not a technology problem. It's a sociology problem.

If somebody finds a way to turn IT security into a game with points for players who nuke the most bots, problem solved. And people could even make money selling games like that.

But that's me. It looks like Gunnar may agree with my general point:

We hear a lot about Role based Access Control as a model to deliver security in companies, but the problem with RBAC in distributed systems like Access Control Lists before it, is that its practically impossible to know at design time what all the subjects, all the objects, all the roles and all the sessions need to be and how they should be mapped together. RBAC can play an important role as a local authorization policy enforcement tool, but its very limited as a platform security construct, because we are building the platform at the same time we are using it.

But do please read Gunnar's whole Thinking Person's Guide to the Cloud Part 1; he goes into detail about specific technologies; how some change the picture; how others address pieces of the problem; what's left to do. Maybe Gunnar can wake up Rip van Security.

-jsq