Sacred Cow Gored? Check.

As only a certified security high priest can do, Gene Spafford has started a linkfest o' love spawning numerous backslapping from some of my favorite people in the blogosphere. I hate enjoy to be the contrarian, so while I agree with the general senitments posited in Solving the Wrong Problems, this quote which several folks latched onto really gets me by the webgoat

We know how to prevent many of our security problems — least privilege, separation of privilege, minimization, type-safe languages, and the like. We have over 40 years of experience and research about good practice in building trustworthy software, but we aren’t using much of it.

We do know to prevents these things? Really? In a real world deployment? With real users? Real use cases? Real integration to an acutal business? Where are these examples exactly? I agree we know many of the pieces of the solution, but I would argue that in addition to focusing and investing in the wrong things, the real problem is security engineering is horrible. Principle of least privilege is exhibit a. Sure RHEL "supports" SELinux. How many times is it actually used? What is option B if the sys admin can't get through the config and so on...I know security people love to blame everyone else for security problems, but the state of usability and engineering in general on the security mechanisms themselves is a major contributing factor to the poor security posture we see in the real world. One of the sacred cows that need to gored is the notion that we in the People's Republic of IT Security have it all figured. We don't. We need to, but we have a looong way to go before your average security mechanism installs and configs as simply as say JBoss.

This is why federation has been so successful and why I look it as a reference model for how security mechanisms should be engineered. Let's review why..

1. It solves a real world problem
2. Does not require that you remap your entire organization, all business processes, and replace all technologies to function
3. Go production with browser based SSO on existing apps in 15 days or less.
4. Low cost
5. Enables business and work to get done

No matter how many times you want to quote Saltzer and Schroeder, there are very,very few security technologies in the real world that meet the above criteria. So while I am with Dr. Spafford in spirit, the security community has more work to do than anyone else to engineer from design time to run time. So I totally agree with the majority of Spafford's post, the industry is focusing on the wrong things, and people do get overly attached to our chosen solutions, the real security architects need to stand up and build better stuff. But a big part of this is admitting that a lot of the security sacred cows don't function well when they meet the real world. Napoleon mentioned that mud is the fifth element. You better account for it. If you don't have a security architecture strategy that can be deployed in the real world then you don't have a security architecture. Let's quit passing the buck on engineering and build and DEPLOY better stuff.

Comments

[Gene Spafford]

There's some validity to this argument. We have not done a very good job from a usability standpoint. But as others have pointed out, it is also partly caused by a lack of willingness to invest without imminent threat.

As an example, we continue to do most of our programming in C and its kin. That is also where the bulk of our operational code (for interactive systems) lies. Yet, that really is not a good language to build in -- it is difficult to map to specification systems, it allows too many preventable mistakes (e.g., buffer overruns), and the semantics doesn't support comprehensive testing. There are better language systems, but they aren't used. Why? Largely inertia and cost.

Lots of other examples out there if we look. But they require a more fundamental and sweeping change than perhaps you were contemplating in your post. We simply don't have the impetus, as a society, to make those changes. Yet.

However, I won't claim that all problems are solved. There is much more to understand (including interfaces for the average user). But we do know how to prevent lots more than we are right now.

[Gunnar]

"But we do know how to prevent lots more than we are right now."

Could not agree more.

[Christofer Hoff]

G-Money...(that's your street name, in case you didn't savvy)

I think a distinction needs to be made wherein Spaf didn't say we knew how to "operationalize" the solutions to these problems or that the solutions even existed in tangible form, but rather that we know "what" we need to do.

I think, as you allude, the next (and hardest) step is how.

/Hoff