Recently Michael Zalewski posted a rant about the state of security engineering in Security engineering: broken promises. I posted my initial response to this on Twitter: “Great explanation of the issue, zero thoughts on solutions. Bored now.” I still stand behind that response. As a manager, problems without potential solutions are useless to me. The solutions don’t need to be deep technical solutions – sometimes the solution is to monitor or audit. Sometimes the solution is to do nothing, accept the risk, and make a note of it in case it comes up in conversation or an audit.
But as I’ve mulled over this post over the last two weeks, there is more going on here. There seems to be a prevalent attitude among security practitioners in general, and researchers in particular, that if they can break something it’s completely useless. There’s an old Yiddish saying that loosely translates to: “To a thief there is no lock.” We’re never going to have perfect security, so picking on something for being imperfect is just disingenuous and grandstanding.
We need to be asking ourselves a pragmatic question: Does this technology or process make things better? Just about any researcher will tell you that Microsoft’s SDL has made their lives much harder, and they have to work a lot more to break stuff. Is it perfect? No, of course not! But is it a lot better then it used to be for all involved (except the researchers Microsoft created the SDL to impede)? You betcha. Are CWE and CVSS perfect? No! Were they intended to be? No! But again, they’re a lot better than what we had before. Can we improve them? Yes, CVSS continues to go through revisions and will get better. As will the Risk Management frameworks.
So really, while bitching is fun and all, if you’re not offering improvements, you’re just making things worse.
Reader interactions
8 Replies to “On “Security engineering: broken promises””
> anything less than 100% is a failure
Well nothing is perfect and it is all about managing failures once dedicated resources have been spent on mitigation strategies. That’s why industries prone to being targeted develop incident response capabilities and crisis management too.
And airplanes also have a long tail of unaddressed issues. Large bird strikes for instance. Jet engines are FAA certified for four pounds birds. Both engines of US Airways flight 1549 were taken down by eight pounds ones. Canadian gooses can weigh up to fifteen pounds. Other engineering challenges lie ahead.
In any organization engineering protection is extreme problem it must be wrapped up with the pursuit of perfect that practical goes out the window.
> Some organizations need to take data security that seriously.
Absolutely. I wouldn’t recommend a speed-bump solution to the FAA, but there aren’t that many organizations that need the reliability that FAA does, or integrity that NYSE does, etc.
I’m saying a lot times the amount of resources necessary to make something nearly air-tight are more than probability * impact. Do something too thoroughly and you miss the window of opportunity.
I’m not saying that extreme protection isn’t warranted in any situation, I’m just saying it’s really easy as a security practitioner to get so wrapped up with the pursuit of perfect that practical goes out the window.
I think this comes down to a debate had on this site some while ago around the composition of the security workforce. Personally, my technical education is in compsci, and not a single one of my courses talked about risk management. I did have a lot of education on formal methods to prove or disprove something acted as specified. Very binary thinking. I think who we work with and the mentality they
> There
>So really, while bitching is fun and all, if you’re not offering improvements, you’re just making things worse.
Entirely disagree. This binary view (either with us or against “us”) of things is not helpful, I think you failed to grasp the subtlety in Michal’s thoughts and what he has already contributed to the field.
Besides, solutions take the form of actual code or actions not blog posts. You’re demanding from a blog post what 700 infosec vendors cannot provide you.
This echoes my response to people’s questions about the security of software tokens. Any malware that can log keystrokes can also do session hijacking, so why not go for the less expensive option and invest the savings in anti-malware protection.
I’m getting pretty sick of InfoSec being endless rants about imperfection (irony meter registering yet?). There’s a lot to be said for “good enough”, as long as the limitations are acknowledged.
I think 80% solutions for 30% of the cost are fine, as long as it’s an informed trade-off. Really dedicated attackers are going to break anything, but it doesn’t make economic sense to spend that much effort in the vast majority of situations.
I’m with Mortman: Stop bitching about problems and start offering practical solutions.
—
chort