Forgive me if this sounds a bit like an article, but I am writing some business development materials and have some sincere and serious questions. I do hope some folks might chime in.
On top of the obvious malware threats, there are lingering questions about the integrity of common operating systems and cloud computing services. Do Windows, OSX, and linux have security holes? Does Windows supply a backdoor for the U.S. or other governments? Should you really trust your linux multiverse repository? Do Google and Apple data mine your private mobile phone data for private information? Does Ubuntu's sharing of my data with Amazon compromise my privacy? Can the U.S. Government seize your cloud data without a warrant? Can McAfee or Kaspersky really be trusted?
Naturally, the question arises of how to establish and maintain an ironclad workstation or laptop for the purpose of handling sensitive information or doing security research. DARPA has approached the problem by awarding a $21.4M contract to Invincea to create a secure version of Android. What should we do if we don't have $21.4M USD? Is it safe to buy a PC from any manufacturer? Is it even safe to buy individual computer components and assemble one's own machine? Or might the MOBO firmware be compromised?
What steps can one take to insure a truly secure computing environment? Is this even possible? Can anyone recommend a through checklist or suggest best practices?
I run my secure computer in an underground concrete tank; the power source is mice on a treadmill, and the internet connection is to another machine 3 feet away. I play Solitaire on it.
There's no guarantee of security anywhere. That said, the TrustedBSD project has gone a long way towards making some of the F/OSS platforms (and one rather larger one) more secure. That would be my choice, if it were *my* choice instead of my employers' ... it's what I used for my own company, when I tried doing such a thing.
/!!\ mysql_ is deprecated --- don't use it! Tell your hosting company you will switch if they don't upgrade!/!!!\ ereg() is deprecated --- don't use it!
dalecosp "God doesn't play dice." --- Einstein "Perl is hardly a paragon of beautiful syntax." --- Weedpacket
I posted this same question on slashdot and got a lot of the "drop it in concrete and throw it in the sea" or "just don't connect it to a network" responses. A lot of folks mentioned a Faraday cage--not exactly the type of discourse I was looking for. There were, however, some noteworthy trends and details in the discussion.
A lot of folks referred me to the classic paper "Reflections on Trusting Trust" by Ken Thompson. While I'm still trying to understand the technical details in order to realize the epiphany therein, the paper states this pretty clearly:
Originally Posted by Ken Thompson
The moral is obvious. You can't trust code that you did not totally create yourself. (Especially code from companies that employ people like me.) No amount of source-level verification or scrutiny will protect you from using untrusted code. In demonstrating the possibility of this kind of attack, I picked on the C compiler. I could have picked on any program-handling program such as an assembler, a loader, or even hardware microcode. As the level of program gets lower, these bugs will be harder and harder to detect. A well installed microcode bug will be almost impossible to detect.
If I understand correctly, the idea is that one must construct one's own compiler -- without using someone else's compiler to do so -- in order to be sure that one's programs don't have back doors in them. This is the kind of succinct detail I think I'm after in asking this question. Let's face it -- I probably won't be creating my own C compiler to compile my OS from scratch. If I can't establish perfect security myself, I want to at least be able to explain why not and to understand where in the armor the chinks lie. This helps me to understand Weedpacket's post:
Originally Posted by Weedpacket
You could fab your own ASICs, but do you really trust the HDL compiler not to insert a back door?
With that XKCD cartoon in mind, I'm curious about where the vulnerabilities lie. Obviously, creating a back door in the hardware itself sounds really difficult compared to creating one in software or tricking a hapless user. If anyone has stats or detail on the relative frequency of attacks in these various categories, I'd love to see it. Surely someone has done a survey of exploits along these lines?
Another guy volunteered this link in response to the oft-cited Thompson paper. Apparently there's something called "Diverse Double-Compiling" that mitigates the compromised-compiler attack.
Another interesting tidbit someone offered was that a couple of guys have built their own computers and written their own software: http://www.homebrewcpu.com/ http://www.bigmessowires.com/category/bmow1/
These computers are really f-ing primitive. The second guy apparently wrote a compiler in assembler That's one way around the compromised compiler attack.
Bruce Schneier of course appeared a couple of times. I have his book "Applied Cryptography" and the dude is pretty awesome. I expect I'll be cruising his site to read about safe personal computing and also his advice on becoming a security expert.
The most considered responses made a very good point: Security costs time and money and you really need to balance the cost of your security investments against the value of the assets being protected. I'm still looking for more ideas about how to secure one's workstation (and also servers). I'm imagining it might be feasible to construct some kind of matrix detailing the universe of possible security measures and their associated costs and how such measures might address the various species of exploit. Such a matrix might help one to plan one's security investments most effectively to address the most common attack vectors.
If I understand correctly, the idea is that one must construct one's own compiler -- without using someone else's compiler to do so -- in order to be sure that one's programs don't have back doors in them.
Not quite: the very sentence that you quoted notes that he "could have picked on any program-handling program", not just the compiler.
However, the point made in the xkcd comic comes into play here: often the weakness lies in humans. If proper procedure monitored by responsible humans had prevented the "install this binary as the official C" step, then this exploited would not have succeeded. If code review (and/or pair programming) had been performed properly, the malicious code could never have been used to compile a bugged binary that might be installed as the official C compiler. Unfortunately, humans fail, so procedure can be subverted and code review could be performed by a partner in crime.
The most considered responses made a very good point: Security costs time and money and you really need to balance the cost of your security investments against the value of the assets being protected.
In fact the alt-text of that xkcd cartoon touches on the last part of this aspect as well.
Yes, Schneier is very good authority. His later book, Secrets and Lies is possibly more apropos to your current interest; he actually starts out by saying that he made a mistake in Applied Cryptography, because in it he gave the clear impression that Cryptography=Security. In Secrets he admits:
The Error of Applied Cryptography is that I didn't talk at all about the context. I talked about cryptography as if it were The Answer™. I was pretty naïve.
Having neglected the effect the real world has on security and the problem of implementing it, he says "the result wasn't pretty". So he wrote a new book, "about those security problems, the limitations of technology, and the solutions".
Also noteworthy was that most folks recommended FreeBSD as the secure OS of choice. Still not sure why. Any thoughts?
And someone offered this link describing encrypted computing in the cloud.
As someone with a bit of knowledge of the BSD community, I'm somewhat surprised that OpenBSD doesn't get that nod, given Theo's reputation of putting security ahead of everything else (including drivers).
If FreeBSD is superior to Windows and the Tuxen, it would be because of:
public review - the Tuxen have this, but it's a lot larger and harder to follow (especially due to the disunification of the Tuxen);
unification of the OS - Windows has this, but it lacks public review;
due to the unification of the OS, upgrading is a tad easier (but not as easy as Windows).
a mindset that is more security-conscious - "nothing is on by default" **
Of course, all those points are arguable.
If you've never read Matt Fuller's rant "BSD For Linux Users", it might be worth the time at this point.
**as evidence for this, I'll submit, anecdotally, that FreeBSD disabled telnet by default last century and the documentation has harped about SSH almost as long, while Tuxen docs are probably still floating around on the WWW describing procedures with telnet or rsh(1). Not by anyone with knowledge, mind you; but it's still out there and some "newbs" will read it and take their advice....
Last edited by dalecosp; 12-31-2012 at 10:25 AM.
/!!\ mysql_ is deprecated --- don't use it! Tell your hosting company you will switch if they don't upgrade!/!!!\ ereg() is deprecated --- don't use it!
dalecosp "God doesn't play dice." --- Einstein "Perl is hardly a paragon of beautiful syntax." --- Weedpacket
Well, I guess it depends on what "upgrade" we're talking about. I do have BSD systems that started as v6 that are now running v9; so I guess I can say it's trumped Windows in that regard. But "security updates" are just now catching up with the "easiness" of Windows Update.
Originally Posted by bradgrafelman
Backup all of your personal data
Erase your primary Windows partition (or quick format your drive)
Install new Windows
Re-install all of your apps
Restore your data
Mine's easier:
1. Throw old computer in the barn.
2. Open box and set up/turn on new computer.
Whether or not I still have old data has something to do with how much I want to have it; that is, have I yet gone to the trouble to take out the old HDD and stick it in my BSD file-server.
/!!\ mysql_ is deprecated --- don't use it! Tell your hosting company you will switch if they don't upgrade!/!!!\ ereg() is deprecated --- don't use it!
dalecosp "God doesn't play dice." --- Einstein "Perl is hardly a paragon of beautiful syntax." --- Weedpacket
dalecosp, thanks for spelling out the probably reaosns for a BSD security advantage. Everything off by default is a BIG one IMHO and is partly why I asked this question. My Ubuntu workstation has a bazillion processes running and all kinds of extra crap. In hardening a server, I find that the first step is turning all kinds of stuff off rather than installing all kinds of crap, which makes sense. Most of the security articles you read targetted at casual users tell you to install this or that antivirus and also a malware cleaner, blah blah blah. It just seems like a really good way to degrade server performance and fill your computer up with crapware while making it less secure. On the other hand, McAffee has saved my ass a couple of times by catching a virus or a trojan in a bad link.
I would also agree that public review is a good security advantage. And I concur with BG's assessment of windows upgrade. I always try to use a new disk. I'll also be reading Fuller's rant.
Reply With Quote
Originally Posted by sneakyimp
That's one way around the compromised compiler attack.
Bookmarks