Slashdot Mirror
Certifying Software As Secure?
"It turns out that the much-touted Microsoft Windows NT 3.5 and 4.0 TCSEC C2 rating basically states that the operating system assures separation of users and data and audits user and security-related events -- capacities that are essentially standard expectations of any modern 'enterprise' operating system. That rating is essentially two (2) levels out of seven (7) from the rating for utter lack of security (D1). See the U.S. Government's Commercial Product Evaluations page and its associated Trusted Technology Assessment Program (TTAP)'s FAQ entry on TCSEC evaluation rating interpretation for more information. For now, be aware that the evaluation ratings go non-intuitively, from lowest to highest: D1, C1, C2, B1, B2, B3, A1. Microsoft's rating also only applies to very specific configurations of the Windows NT Operating System and none of its frills -- like ASP, for instance.
Still, even from the standpoint of researching evaluation and certification options, it looks like only International Government Evaluation (i.e. the 'Common Criteria' evaluation process) and perhaps the ICSA certification are available to any vendor who wants to be pro-active and benefit from standards in the process. (Please let me know if you know better!) And I've talked with a number of hacker types who sneer at the idea that any of these certifications are worth the money and effort to put into them.
At the same time, pointy-haired types eat this certification stuff up. In point of fact, government contracts can be much more possible and much easier to obtain if you get certified this way, and as Microsoft's spin-doctoring of their C2 TCSEC rating points out, it just makes the company that has the rating look more responsible, all around, or can, if your readers and customers don't know what the rating actually means.
Sure, it's possible to contract with any security auditing firm to get something or someone to say that your product's at least minimally secure, but it's still unfortunate, but true, that if you want any kind of widely-recognized, standard certification, you'd better actually seek out some kind of formal evaluation and rating.
Do people agree, disagree, and either way, can they prove it?"
You can find all of the rainbow books here and here. They're worth a look.
--
So far, I've proven that addition on my Turing machine is secure, provided the intruder doesn't have physical access to the tape.
I'm still working on multiplication...
Sun's Trusted Solaris (I'll let somebody else get a few Informative points by posting a link; I don't have it handy) lets you do some useful things in this respect. I don't recall their rating offhand; somewhere in the midrange.
You can do some really cool things besides impress your boss with the rating, too. Like make indidivdual directories and files simply not be there when certain users do an ls(1). I don't mean "permission denied" kind of things, I mean the kernel itself just skips over that file; doesn't even report its existence.
It's great for situations when information at different classification levels (Top Secret, Secret, Confidential, Stuff That Used To Be Secret Before You Put It On The Damn IIS Server And Some Eleven-Year-Old Kid Got It, etc) all need to live on the same machine.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
To truly certify software as secure is a very huge task. It assumes you understand and have validated every single state the machine can be in, which is practically infinite. Even the state of the power button matters.
I really hate the false sense of (ahem) security that certification gives. They're trying to assure the software is secure, which to is almost an impossible task for any non-trivial system. Anybody who says a system is secure is lying to themselves and others.
With things this complex, security can only be approximated.
Of course, you can certify a design as secure with much less effort but it's the implementation that matters the most.
Network Security Library
Common Vulnerabilities and Exposures
SecurityFocus
You can find everything you want to know (and more) at these sites.
``We are the people our parents warned us about.''
1. THERE IS NO SUCH THING AS SECURE SOFTWARE.
:)
Like Yogi Berra said, "In theory, there's no difference between theory and practice. In practice, there is." No matter how stringent the testing, no matter how exacting the software development (up to and including provably-correct software), software cannot be secured. In theory, following a provably-correct software design (such as is possible in some Ada subsets) allows you to design software which is provably correct... but that's theoretical, not practical.
Sometimes, the buggiest thing in a system is a feature which is working exactly as it's designed to do. Provably-correct software is predicated on there being a correct assessment of what the software needs to do and needs to not do, and so far, nobody's come up with a way to do provably-correct brainstorming.
Auditing cannot, repeat, cannot make a piece of software secure. All it does is find errors, not all errors, and maybe even not all the major errors.
2. TRUSTED SYSTEMS ARE JUST THAT.
Trust. It's another way of saying "I have faith in you." Faith is the antithesis of proof. For years my Linux box was a haX0r's dream--I didn't bother to turn off services, my root password was fairly easy to guess, etc. That doesn't sound like a trusted box, does it?
Wrongo. It was very trusted, because it wasn't connected to any network and it was in my bedroom. I trusted it a lot--I had faith that it wasn't going to be compromised.
Whenever you see someone advertising a "trusted system", ask yourself: who trusts it? Why do they trust it? Should I trust it? "Trusted systems" are sometimes a lot of snake-oil; people who don't know beans about security buy "Trusted Solaris" because it says "Trusted", even though their incompetency as a UNIX sysadmin makes the box vulnerable.
(Note: I have a lot of respect for Trusted Solaris, even more than I do for OpenBSD. I'm just making the point that the word "Trusted" doesn't mean much.)
3. THE MOST IMPORTANT ELEMENTS IN SECURITY ARE THE USERS AND THE SYSADMIN, IN THAT ORDER.
Most people will reverse this around, claiming that the sysadmin is more important security-wise. There's merit to that (after all, root == God), but I reverse it. There's only one sysadmin, and an attacker more or less has to take his chances that the sysadmin is incompetent enough to fall for (a crack, a social engineering attack, a DDoS, etc.). But if there are hundreds of users, it's certain that at least one of them is going to be a complete fargin' idiot, which means attacks which involve users are more effective than those which go straight for root.
This is an important point. No matter how secure the box, no matter how trusted it is, the weakest link are the users. When companies get on a security kick, they tend to spend lots of money on software and very little on educating their users. This has always struck me as backwards.
4. USERS DON'T WANT SECURE SYSTEMS.
Have you ever tried to use Trusted Solaris, or OpenBSD in a particularly bondage-and-discipline configuration? Sure, they're locked up tight against intrusion, but this comes at a steep price in usability. People want computers to be easy to use more than they want them to be secure. If you make computers too secure, your own legitimate users will circumvent security. I regularly see passwords on Post-It notes stuck to monitors--not just in Corporate America, but in government offices which routinely handle extremely sensitive data.
5. FOR ALL THIS, SECURITY AUDITS ARE A GOOD IDEA.
Security audits do two things: first, they tend to ensure that software works the way it ought, and second, they tend to ensure that software doesn't work the way it oughtn't. The potential problem that's spotted and corrected due to a security audit may never have resulted in an exploit, but it may well have resulted in a Blue Screen of Death at some point down the line.
Security audits don't just make systems more secure; done properly, they make systems more reliable, which in turn makes them more usable.
I personally think that there is at least some value in getting your software audited. OpenBSD is clearly a good test case for the value of internal audits in producing secure code. OTOH, internal audits are never going to be as convincing to some people of the quality of security as external audits are because of the temptation to cheat.
I think that the government standards for secure computing bases are very valuable in giving you good ideas of what to do. It's clearly the result of careful thought by some very intelligent people. I think that they're missing out on an intermediate security level between their C and B levels that includes horizontal mandatory access controls (basically capabilities) without security levels.
That being said, I think that all flavors of Unix are always going to be inherently insecure as long as they maintain their "root is god" attitude. As it is there's no room for error. One security hole is enough to give an attacker complete control over your box, and OpenBSD levels of paranoia and auditing are necessary in order to achieve security against anything but a casual attacker. Unix isn't going to be reasonably secure until it implements some kind of mandatory controls, either capabilities or a full class B access control with security levels.
There's no point in questioning authority if you aren't going to listen to the answers.
> There is starting to be support for capabilities in Linux
Linux's so-called "capabilities" are a joke. They are nothing of the sort, they are just more acl bits tacked onto operations. You want real capabilities, try something like EROS. A true capability manifests as a visibility thing -- you can't call a forbidden operation if you can't even get a handle on it. A true capabilities system is a "thought police" model. You can't perform a forbidden operation because you just can't have that thought. You can't delete a file you can't touch. You can't open a device you can't see. Etc.
Capabilities can be rock-solid security, but they do have some problems, like revocation. The neat thing about EROS is that stack smash attacks can't gain any extra privileges, because they can't manufacture any extra capabilities -- you'd have to smash the kernel stack to do that.
I've finally had it: until slashdot gets article moderation, I am not coming back.