Security industry needs to be less trusting to get more secure Delegates to Black Hat Europe have been encouraged to turn conventional security thinking on its head by practicing security through distrust. Security pros normally aim to make (computer) systems (reasonably) secure and trustworthy. This means striving to ensure everything (software, hardware, infrastructure) is trusted. This …
But the problem is that paranoia can result in Turtles All the Way Down. Verify apps? Who verifies the verifier? Signatures? Forged by someone who co-opt ed the keys. You can't operate on complete distrust because you eventually end up in DTA Mode and nothing gets done. You ultimately have to trust SOMETHING, and ANY trust can be betrayed.
Yes, this was my thought. I've been working in computer security for years, and the first rule is that there is no such thing as "trustworthy" anything. That's because "secure" as an absolute state isn't a thing that exists. The best you can do is to increase the effort required to compromise a system. You can't make compromising the system impossible.
You've been working in computer security for years, but you're not aware of threat models, partial trust, transitive trust, trusted third parties, or any of a dozen other security concepts that include some trust aspect?
Engineering is impossible without partial trust. "There is no such thing as 'trustworthy'" is a naive ideological statement, not a useful position for security engineering. The first lesson of "Reflections on Trusting Trust" (and more formal studies of trust in systems) may be that every component is suspect; but the second is that it's impossible to get anything done without assigning trust relationships throughout the system.
Rutkowska - a serious, well-known researcher and developer[1] - is perfectly aware of all of this. Her point is that mainstream OSes are very liberal in their definitions of trust boundaries, for example in broadly assigning all processes owned by a given user into a single trust domain. Qubes (which has been available in some form for five years) is built around a more pessimistic trust model, and that's what Rutkowska was generalizing in her Black Hat talk, as far as I can tell from the article.
And yes, obviously it's not a silver bullet, because there are no silver bullets. That doesn't mean it's not an important contribution.
Trust in operating systems is a very complex and difficult area. Reducing it to a slogan is a pointless exercise.
[1] Something I'd kind of hope a practitioner of IT security would know. Following research in the field is important.
Assigning all processes owned by a given user to the same trust domain versus not is basically an extension of concepts like sandboxing Java code. I am running a browser and an email client at the same time, but I don't want the browser to be able to access the email because someone could write some rogue Javascript that exploits a bug (breaks out of the sandbox) and sends copies of my email to persons unknown. Likewise, I don't want a carefully crafted email that exploits a bug in my client to snag my browser history.
I don't want either to have full access to my home directory, but only to specific areas, unless I designate special one-time access (for e.g. attaching something to an email or uploading something to a web site)
There isn't an OS that has such fine grained protection - iOS is perhaps closest of mainstream OSes but that security comes at a price of reduced flexibility. Bringing that extra layer of security to those who chafe under the constraints of iOS is the nut no one has cracked.
To really do the job right and improve on what iOS does while still maintaining full flexibility you'd have to expand the concept of Unix's uid to have a uid primary and any number of secondaries. Each process (or perhaps each thread) would have its own secondary uid and only be able to attain the access rights of the primary uid under specific circumstances. That would allow effectively protecting everything from everything else, of course the devil is in the details over how those "specific circumstances" are implemented.
"The first lesson of "Reflections on Trusting Trust" (and more formal studies of trust in systems) may be that every component is suspect; but the second is that it's impossible to get anything done without assigning trust relationships throughout the system."
Seems to me transitive logic leads to a third lesson, and a grim one at that: "Anything of practical use can and likely will be pwned. Deal with it if you wish to use a computer."
"you're not aware of threat models, partial trust, transitive trust, trusted third parties, or any of a dozen other security concepts that include some trust aspect?"
Whatever gave you that idea? My comment was actually intended to be hinting toward the idea of partial trust, but partial trust requires you to adopt the notion that nothing is trustworthy, and that you must engineer everything so that if security is violated, the damage is minimized as much as possible.
This sounds like Google's "everything is untrusted" network security model, scaled and adapted to the OS component level.
It makes sense to explore this approach at the network level, since perimeter defense and assumed-trust for anything inside the firewall are routinely exploited to devastating effect.
At the machine level, though, the benefits are less clear to me since so many of the best exploits operate in the wetware layer...
What is the biggest example of undue trust by security professionals at Black Hat?
How much the trust people they don't know with details of security exploits.
They generally even trust people who don't go to their conferences, people they have never and never will met, anonymous readers on the internet, with security exploits.
They seem to be one of the most trusting bunch of folks in the world today.
As further proof, later on today they'll be by posting about how anonymous people on the web should be trusted since they're all geniuses with trust funds and plenty of time on their hands, who'd discover every single one of these exploits on their own anyways.
Why boast about finding an exploit if you think that every basement dwelling teenager could do the same thing?
Personal injury lawyers have more ethics than your high profile security conference attendee. (Personal injury lawyers don't throw people under buses in order to create clients.)
Get the right mindset, and then maybe you can create secure code. (For those security professionals who know how to create maintainable code.)
"Get the right mindset, and then maybe you can create secure code. (For those security professionals who know how to create maintainable code.)"
You then have the problem that your spotless, impeccably secure code has to work surrounded by code other people have written. Do you trust that external code? Do you have enough years in your life to rewrite everyone else's code so that you can trust it?
You might have to work out how you can cope with running code from multiple sources and not trusting it. When you've done that you could even give a talk at Black Hat about it. Or you could re-read the article & try to understand what it was about.
So even though you've built a small, tightly controlled secure zone it's completely subverted by something below the OS level.
Thank you Intel, and AMD for playing follow-the-leader with them.
Let's be real f**king real here.
People know how to do this. They've known for decades. But they won't accept the performance hit it will impose despite the techniques being around since the late 60'x/early 70's and processors being about 1000x faster.
The pwnage of everyone's systems (by everyone with the skills to do so) will continue until security becomes an issue that has to be improved.
"People know how to do this. They've known for decades. But they won't accept the performance hit it will impose despite the techniques being around since the late 60'x/early 70's and processors being about 1000x faster."
There's also the simple issue that what man can MAKE, man can BREAK. At SOME point, you have to trust SOMETHING, and that's where a determined adversary can get you.
In fact no one is arguing with you.
The trouble is that right now "trust something" starts quite often with what's being typed into an entry field on the application IOW "trust" bloody near everything.
The level of trust could quite easily be much lower for a much larger range of functions, including functions within the OS itself.
Right now it's a case of an apartment block with a poorly front door and no doors on the apartments.
And how many f**king times have I heard "this exploit is due to (yet another) deliberately caused. buffer overflow error" ?
This is how it has always been. In nearly every security certification the mantra is, "Absolute security is impossible". Therefore, there should always be a plan to ensure when a system is owned, it fails 'gracefully', and if necessary it fails over to a backup/COOP system.
Then there is prioritizing criticality. The scale used for this can get a bit complicated, but broken down into the simplest form, it's about paranoia.
Once again, we have someone who is relatively new to security trying to make a name for themselves... without taking 15 minutes to really think about what they are saying.
Rule is.. if it appears to be the obvious, then it probably is; therefore, someone else has already figured it out.
Have you? Where do you think Rutkowska claimed anything about "absolute security"?
Rutkowska is not "relatively new to security". I'm assuming you don't know that because you don't know much about the IT security field yourself.
The commentardiat is in fine form today, I see. But then the security articles generally bring the little-knowledge types out of the woodwork.
You both guys are known, at least I've read all you security related articles posted on your site and available on Inet as well. Highly appreciated. I use them for references. However, I neither support people who question others' knowledge and background nor "others" trying to claim their land. That is basically not polite and useless.
Concerning the concept is question, the discussion around it shows its questionable matter. What ever is between black and white is grey. Too wide to discuss and useless as well. Everybody knows about these colors and shades. There is only one way (from my personal experience) to prove the land ownership - make clear what was before you said the word and what is after. Show the difference. If possible, make that in math. At least try that. If succeeded, you won, if not then the matter is possibly obvious. Takes time but clarifies a lot. All my due respect. Mikhail Utin, CISSP, PhD.
In networking its always been from the m/c treat the network as pwned, from the network treat the m/c as pwned.
Trust needs to be established, and not taken for granted.
Cmon people code injection is still top of the OWASP top 10 - Its not just the user thats stupid
the problem is maintaining all three of the CIA triad, the system has to be available, or there is no point in it existing, and if it has no integrity, what use is it?
And based on experience, the problem is intractable. Any system that's available can be subverted, any form of integrity and trust can be betrayed, and it WILL happen according to the human condition (because people WILL cheat). Not to mention it's getting easier all the time. IOW, all three legs of the CIA triad are matchsticks.
IOW, is it time to wonder if the Internet is overrated?
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
