1 Raindrop

Bob Gourley: The Law of the Rodeo

From "Threats in the Age of Obama", I really enjoyed Bob Gourley's spin on applying the Law of the Rodeo to Infosec:

So is is possible to engineer perfectly secure systems?  Consider the law of the rodeo:  "There's not a horse that's never been rode, and not a rider that's never been throwed."  I like the analogy since it reminds us that all computer evil can be mitigated.  But it always fights back.  Good and evil will continue a fast paced rodeo dance long into the future. 

To engineer secure systems for the future we need to continually assess where we are and what the near term future holds for our technologies.  

He goes on to describe a list and how it may change. I would have some different ideas for candidates on the list, because I see bigger opportunities and threats as we move closer to identity, information and apps/data; and less about infrastructure, but the law applies just as well, even better in some ways at those layers of the stack.

Service Oriented Security Indications for Use

From the current IEEE Security & Privacy Journal, Service-Oriented Security Indications for Use. In which I go a little deeper into the diagnosis of the 13 year and counting infosec design fail, and delve into some prescriptions as well. Thanks to Alex for reminding me to add another line on the chart, but I missed th pub date on this one.

Risk Reification - Generational Differences

One thing I have noticed in consulting and especially training, is that people who are right out of school in the early 20s, who literally "grew up digital" have a very different set of assumptions about risk and mitigating it. In fact in my experience its a 180 from how most of us in the profession look at it.

I remember Kim Cameron telling a story about reification where young people would see a physical folder and recognize it as "oh that looks just like what I see in my OS", if what I have seen so far training programmers and security people, is a reflection of overall reality, we might just be in for a great change. When digital risks are presented to someone with say a lot of experience they sort of look as the computer and data as an abstract thing. Separate from their world. When the facebooker generation are presented with the notion that someone may want to steal/alter/tamper with their identity and data - its like "whoah! ru serious?!? srsly how do i stop them?!?" Its not a reach at all to get them to see digital assets as assets and value in digital assets.

So the two things I can see coming out of this is that the increased awareness of digital asset existence and value, should lead to an increased ability to try new mechanisms. We likely don't need to be limited to robotic (cue robot voice and body movements): "We must stick to only. Username. And password. And NW Fierwall. That. Is. The only thing our users. Are Capable of."

It will be interesting if this proves true, because if it is its a game changer on many fronts

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.

The He Got Game Rule

Guess what? The single most important book for security pros to read is not written by Ross Anderson, Gary McGraw, or Bruce Schneier, in fact it does not even mention security at all. No this is not some paean to a goddess of risk either. In fact its a book on integration.

@jeremiahg reminded me of this with his fine harvesting of this quote from BSI-MM: 

The best SSG members are software security people; but software security people are often impossible to find. If you must create software security types from scratch, start with developers and teach them about security. Do not attempt to start with network security people and teach them about software, compilers, SDLCs, bug tracking and everything else in the software universe. No amount traditional security knowledge can overcome software cluelessness.

About 6 years ago, a security manager at a client was asking me for some help. His dept had received some increased funding for security projects, and he needed some talent, but was having no luck. I read the job reqts and saw the problem immediately. The job requirement was filled with asking for years and years of security experience. What possible good would those skills do when the strategic problems at hand were integrating SAML into Weblogic apps, threat modeling in the SDLC, and building a STS??? Its hard to imagine a less applicable skillset than Network Address Translation rules on teh fierwall.

I call it the He Got Game rule. When Spike Lee was making the movie He Got Game about a burgeoning NBA basketball star, he had a choice. He could cast a Hollywood actor like Robin Williams and try to teach him to play realistic looking basketball. Or, they could cast a basketball talent like future NBA all star Ray Allen and teach him how to act. Spike Lee chose ray Allen because he quickly came to the conclusion that it was much easier to teach a basketball player how to act than to teach an actor to play basketball. Its the same in security, its much simpler to teach motivated developers how to threat model, how WS-Trust protocol works, and so on, than it is to teach even motivated security people who are operationally focused on how Websphere, Apache, Directories and other core software technologies are built.

So back to the book recommendation, if you are a security pro, and you think you can increase your hoop skills, first realize you have a high barrier to cross. Second, understand that the main problem we face in security is not clueless users, "bad" developers, or insufficient security protocols. These are simply constraints to design with. the real problem is security integration. So if your background is infosec and you want to step, then the book to read is "Enterprise Integration Patterns" by Gregor Hohpe and Bobby Woolf.

Rather than obsessing about the latest and greatest threat, its much more strategically important to sort out the logistics, constraints, and economics to distribute and scale out the security mechanisms and processes we have. Specifically how are they impacted by and how do they impact the message flows, endpoints, routing, transformation, and management. These patterns are aptly described and cataloged in Hohpe and Woolf's book and provide an important starting point for meaningful and useful security improvement over time.

Why Getting Involved Early Matters

Lots of people talk about getting involved earlier in the SDLC, EA, and arch phases. One of the reasons why this is important is because security is as much a design problem in the systems we build as it is an operational problem in the systems we run. 

Two good quotes on design

“Design depends largely on constraints.” - Charles Eames

“Design is simply the management of constraints, and the choice of which constraints are nonnegotiable is crucial.” - Dino Dini

This is why being involved early matters - when security is brought in two weeks before go live, there are nothing but constraints, its literally too late to make structural and even most behavioral changes. Getting involved early means two things happen for security. One, there are fewer known constraints, because the jello hasn't hardened yet. Two, security can recognize and adapt to the known constraints at the time.

Minnesec rises from ashes

Celebrate finishing your taxes and your security spirit at Minnesec @ the Happy Gnome on 4/16

Information Security Debt Clock

Due to not keeping pace with software innovations, Information Security has been incurring Technical Debt since 1995. The Information Security Debt Clock tracks the time since the Web security architecture based on Network Firewalls and SSL was first deployed:

Technical Debt occurs when "During the planning or execution of a software project, decisions are made to defer necessary work...The list can grow quite long, with some items surviving across multiple development cycles."

FX on Attack Surface of Modern Applications

This talk by FX is related to today's earlier post, its from 2007, but for security archs its just as relevant today as then. If you think of the attack surface as the set of methods, data, and channels an attacker can use against your system, and then you think of the evolution of software then you can clearly see the way security systems are evolving staying the same in the face of the vulnerabilities.

First thing out to the woodshed, none other than teh fierwall, FX asks

today's firewall is: 

a multiprotocol parsing engine
written in C
running in kernel space
allowed full corporate network access
holding cryptographic key material

...and still considered a security device?

Well played, sir. Sounds like a good thing to have on the front lines, no?

So its easy to see that Information Security has incurred 14 years and counting of design debt, just like the subprime crisis those chickens are going to come home to roost and now its only a matter of whether its a car crash (quick and painful) or a cancer (slow and painful). 

FX makes a couple of other critical points

design systems the right way 

defense in depth is one of the few hopes

get used to the fact that things break --
...
adding another security feature isn't reducing the complexity at all

The last point should give any security arch pause, security people routinely complain that developers make things too complex to secure (see above chart). I think the reality is closer to that the security teams simply don't move fast enough to address new tools/technologies (again see above chart), but in any case the complexity issue is often raised in self defense of security, but here is the kicker, what's the most complex thing in implementations? Aw shucks its very often the authN code, the crypto code, and so on. Which brings us back to defense in depth.

Side note, one of the main reasons in my focusing so much of my time on security was a talk I saw by FX in Amsterdam in 2001 where he showed exploits on a number of lesser known protocols like LDAP and Cisco management protocols. That talk and follow on conversations with him really stayed with me as a new way to think about software and resiliency in a new way.

Integrate First

A recent conversation on sc-l reminded me of one of my favorite design quotes:

"Normally, everything is split up and problems are solved separately. That makes individual problems easy to solve, but the connections between the problems become very complicated, and something simple ends up in a real mess. If you integrate it in the first place, that turns out to be the most simple solution. You have to think ahead and you must always expect the unexpected." 

- Jan Benthem, Schipol airport chief architect

Anyone who has flown through Schipol as opposed to, say, Heathrow can relate to this idea's efficacy. 

So where this applies to security is that as so elegantly stated in Blakley and Heath's Security Design Patterns, security protocols often don't compose, yet applications are built on composition. The reality is the developers need more training on software security, for sure, but we also need much more focus on integration, otherwise our security protocols and mechanisms will solve irrelevant and/or trivial problems - a pseudo-security that breaks things up into small pieces and "solves" one easy problem ignoring a morass of real tricky problems that burn our users, compromise our data. 

For example, the idea that firewalls separate good stuff and bad stuff with an autonomous DMZ in the middle "solves" the lets keep the bad guys out of our system supposedly. Except firewalls are a permittance architecture not a denial architecture you wouldn't have a DMZ at all except you are going to let people in. Other examples, SSL "solves" the communication confidentiality point to point and ignores the rest. Kerberos is a point to point protocol that gives tickets for a domain. 

Now there are several ways to achieve better integration, but unless you think through the tradeoffs early on of say whether a federated, proxy or sts approach is better, it will be too late to implement.