Where We Are and Where We Are Going

Well its getting close to RSA conference, I am looking forward to participating in a Open Group Jericho Forum panel discussion with I believe Hoff and Mogull; Bruce Schneier is probably preparing to be as dazzled as he was last year by all the security products, a year later, I am still gobsmacked that he wrote these words after walking the RSA floor:

Talk to the exhibitors, though, and the most common complaint is that the attendees aren't buying.

It's not the quality of the wares. The show floor is filled with new security products, new technologies, and new ideas. Many of these are products that will make the attendees' companies more secure in all sorts of different ways. The problem is that most of the people attending the RSA Conference can't understand what the products do or why they should buy them. So they don't.

Suffice to say, I had a different take. You know why they weren't buying Bruce? Because the budget for toys and shenanigans is pretty small. It was my first trip to RSA, and I am still stunned that any CIO would sanction the purchase of 90% of the products I saw there. Utterly amazing waste of resources to spend so much money on toys and shenanigans just so "security" people can play cops and robbers on the shareholder's dime, while the enterprise crown jewels - apps, data, and users are left wide open.

In order to add value to the enterprise's that they are supposed to serve, Infosec is in desperate need of transformation, and its really only a question of whether is a revolution or evolution. The Twitteverse has had a few buzzes about where infosec needs to go, I break it down into three categories - Design Time, Deployment Time and Run time. Right now, infosec is overwhelmingly focused on operational run time issues. that is fine, we need to have an operational focus, but it cannot be the only focus. 

Here are a few examples of how I characterize the different roles, responsibilities

Design Time Security

Stakeholders: Business, Business Analysts, Architects, Developers

Inputs: Use Cases/User Stories/Requirements, Arch Documents, Code, Unit Tests

Security Activities: Threat Models, Misuse Cases, Security Mechanism Design 

Deployment Time Security

Stakeholders: Configuration management, Sys admin, DBA

Inputs: Change management processes, policies

Security Activities: Provisioning, Key mgmt, Contracts

Run Time Security

Stakeholders: Operations, Sys admin, DBAs

Security Activities: Monitoring, Audit logging, Network security operations

This  is just an illustrative slice not a complete set, but it gives a flavor of where the industry is somewhat mature today and evolution is required - Run Time; and where a massive change in priorities(revolution)  is needed - Design time. So I won't go all Bruce Schneier slackjawed in amazement at the RSA floor until its about 50% filled with Design time tools and specifically those that integrate with the deployment and run time tools and processes.

"Art is long and life is short, and success is very far off." - Jospeh Conrad

The way out of this is for security to get involved in building better systems, getting involved in the system development, Identity management, and coding. Come to the table with useful tools such as Threat Models and Misuse Cases, and make sure you are there early enough to have an impact. Three places to focus are application development, databases, and identity. Time for security to live in code and config not in Visio drawings.

So Bruce Schneier's comment is not as bad as a "heckuva job Brownie" moment, because he has had many good ideas over the years that have had a positive impact on the industry. But we all have bad ideas too, Charlie Munger likes to say any year where you don't kill one of your best loved ideas is a wasted year. I used to think SOAP was inevitably better from a security standpoint than REST, but no more. Likewise, if you think we are going to see real progress in security solely made by evolving what we are doing, then you should realize you have a great opportunity to kill a bad idea.

"I don't do defense; I do security. When you talk defense, you talk containment and mutually assured destruction. When you talk security, you talk collaboration and networking. This is the future." - Tom Barnett

Time to step up and get involved in the design process, the infosec technical debt clock is ticking.

Comments

[Rob Lewis]

Another quality post. I have read your comments on TAO etc., about the need for more authorization, but you don't mention it here. If we are to re-design, do you think that an authorization component is needed post-authentication, such as granular access controls, and that this is the place to get the stakeholders involved? I'll go further and say that that authorization component should utilize the business rules and the language of business operations to be truly effective.

[Gunnar]

Rob - the post is more about when than what. Authorization is a very good example of a service security should help to deliver. Yet because authZ requires mapping subjects and objects infosec has no shot at delivering unless they are involved early on. Developing authZ later on requires lots of design changes, system testing and so on, so its a non-starter. This is why the products, like access mgmt, that dazzle people on the RSA floor are sold for seven figures, because they can do authN, authZ and more. But then when people try to deploy they wind using them for perimeter authN and *maybe* coarse grained perimeter authZ and thats it, fine as an idea, except they pay 10x more than they should have. The issue used to be that infosec complained that the developers wouldn't let them join in their reindeer games, but with the amount of money spent on toys and shenanigans, infosec can and should buy a seat at the grown up table.

[Rob Lewis]

I realize that your post is about comprehensive process to affect fundamental design change.

In your "The He Got Game Rule" post, Andre comments "most people forget about called "data owners" aka "customers". if only their voices could be heard."

Part of hearing those business stakeholders is dealing in the language of business operations, which are often based on relative trust relationships which effect information release and flows, as opposed to risk and object-centric labelling. This language supports collaboration and networking, even after the fact, and its omission will hamper identity management.

FTI, you may think that developing authZ later on is a non-starter, but that is what we do, with a security sub-system that converts select (or all) network nodes into reference monitors that communicate with each other using the language of the business operations to govern information flows.

[Roland Dobbins]

And again, the perennial elephant in the room that nobody in the infosec world will spare a thought for - DDoS (i.e., the 'Availability' leg of the canonical C-I-A triad).

[Rogan Dawes]

Great post, Gunnar!

@Roland Dobbins: The problem with DDoS is that there is often not a whole lot that folks can do about it. It's only really when you are large enough to be able to get control over an upstream router/device at your ISP that you can start *trying* to deflect the bogus traffic before it hits your own pipe.

Even then, it is difficult to separate legitimate traffic from DDoS traffic.