Slashdot Mirror
Security-Meantime Between Rootshell?
darthtuttle asks: "Hardware has a concept of meantime between failure, so how about applying a similar concept for software. Here's how it works. Cracks can be described by the level of access gained, some examples are: remote root, remote user (root if run by user root), remote group, local root, local user, local group, and so forth. Applications or services have their own measurements and descriptions as well. Most all types of cracks can be listed in an order and a higher level crack is equal to each of the lesser level cracks. For example: a remote root is also a remote user and remote group crack. Now measure the mean time between incidences! Do people find ways to break in to your system every day? Every week? Every month? Every year?"
"Rating a complex system would mean combining the ratings in some meaningful way. for example if you are measuring a RedHat install you might need to consider the name server, sendmail, and all other services running on the system on top of the kernel. Given a method to do this you could rate an entire infrastructure. I'm sure the insurance companies would love this. It would give them a way to measure the chance of you spilling the beans on your customers data.
I'm curious, do you think this would be useful if it could be done reasonably? What kind of mean times do you'd think you'd see for the various products out there?"
The security world has a concept of 'security assurance' - this is the confidence that you can have that a given set of security features (e.g. granular privileges, ACLs, audit logging, label-based security, etc.) actually work. This is taken from the old Orange Book used to rate computer system security, which has its problems but remains a useful model.
p ?theisbn=0201192462&vm=
Bruce Schneier has been talking a lot about the need for monitoring and response to intrusions, based on the reasonable premise that you can't prevent 100% of all intrusions for all time (even OpenBSD has had remote root holes some years ago, and most holes are actually due to specific applications). If you accept this, it seems sensible to define goals for monitoring and response times.
Defining such assurance levels is not easy - on one project, I wrote requirements for security assurance that defined quantified goals for such things as 'minimum time to detect break-in' and 'minimum time to respond to and stop break-in'.
If you are interested in quantifying requirements for security (and other 'soft' requirements such as performance, availability, reliability, usability and flexibility), have a look at Tom Gilb's work - his site is at http://www.result-planning.com/ and most useful book isn at http://www1.fatbrain.com/asp/bookinfo/bookinfo.as
- At last week's IEEE Symposium on Security and Privacy Bill Arbaugh presented a very interesting paper on trend analysis of exploitation, as represented by CERT incident reports. Summary: most attacks exploit known security vulnerabilites that a site admin did not patch.
- Jim Reavis at Securityportal.com did this great study examining the "days of recess" for each of Red Hat, Solaris, and Windows NT. "Days of recess" is the total number of days that an exploit was known but no patch available, summed over all vulnerabilities for that platform.
- At WireX, we are working on a related concept that we call "Relative Invulnerability". Here, the idea is to consider the number of vulnerabilities for a "base" system (e.g. unpatched Red Hat 7.0) that appear over a period of months, and then consider how many of those unpatched vulnerabilities are successfully mediated by some protective technology such as SELinux or Immunix. The fraction of vulnerabilities stopped is the "relative invulnerability" of the defensive technology. This is written up in a paper that is currently being reviewed.
Crispin----
Crispin Cowan, Ph.D.
Chief Scientist, WireX Communications, Inc.
Immunix: Security Hardened Linux Distribution
Now available for purchase
Just a friendly word or two, then: beware of complacency.
.|` Clouds cross the black moonlight,
I've been on a site where I specced out the firewall rules with the native sysadmin; between us, none of *our* boxes ever got cracked in the last 18 months. However, that didn't stop some schmuck sticking a RH6.x box with rpc.statd on a public IP# - give it a week, *boom*.
3hrs' turnaround including a forensics copy, custom build of RH and restoring data, I was quite proud of me. And it's never been cracked again, either. And then I finally found a writeup of a similar incident, and read `check for kernel modules', took another look at the forensics copy, and felt very small...
Maybe another statistic to add to `expected time to (between) cracks' would be `expected turnaround time' as well - part of your security strategy has to be having a spare box to replace anything with.
~Tim
--
~Tim
--
Rushing on down to the circle of the turn
*sigh* i agree about the root exploits part but youre simply trolling for the BSDs which is silly IMHO.
any normal (read not yours) company will have at least dual or quad CPU hardware running in a cluster for their webservers..in most cases this may be outsourced or hosted at exodus or other NOCs. OpenBSD can support only 1 CPU at this time so that blows it out the water. FreeBSD is in a niche (not may admins can use it -- companies hire from the mass market so the skillset is definitely limiting fbsds existance) and doesnt scale properly as far as CPUs go (yes i know about the fbsd 5 improvements -- it aint here yet and still has the giant kernel lock).
Linux is gaining more and more since the availability of admins is there and its easy to set up (even if crackability exists) and is familiar enough with apache. it also scales well now with the 2.4 kernel and supports a lot of rackmount hardware at datacenters.
Solaris is usually what you find with netscape iplanet or apache at most companies..it scales well but costs an arm and a leg.
NT/IIS is another alternative for those cheapo firms who cant afford to hire admins to run UNIX.
Would you work for a company that boasts about its 'mean time to bankruptcy', or hire someone
who's improving their 'mean time between felonious drunken assaults'?
Hardware failure is inevitable and (generally) unpredictable. Gross statistical measures are one of the few meaningful ways to plan and budget for failures. Security is not the same way -- breaches can be avoided through vigilance and good management. Talking about 'mean time to exploit' is a cop-out -- it's surrendering responsibility to the whim of fate.
cheers,
mike
Hardware can be meaningfully rated with a MTBF value because the errors are random, physical (often mechanical) defects. It is a measure of how likely a given operation is to fail.
With software, usually the same operation always fails. Software errors are design errors, not random failure.
While measuring the frequency of breakins is perhaps a useful metric, it shouldn't be confused with something like a MTBF for hardware. Also, the frequency of breakins due to script kiddies that scan and more-or-less target systems at random and just want a shell, or to deface your webpage, versus a deliberate and directed attack against you to steal/corrupt data are completely unrelated. The latter may have access to more sophisticated tools, better knowledge of your network and software, etc. Trying to apply numbers gained from random attacks to indicated your defendability against directed attacks is severely misguided.
Also, attempting an MTBF rating doesn't take into account visibility. If I drop most incoming connections through my cable modem and run a port scan detector, most people scanning my whole ISP will not even notice I am there. This doesn't work for a public website that many people know exists, even if it does drop their traffic to port 31337. Hardware MTBF is usually given in "operating hours" or some other well specified metric. I don't see how to do that for software. A better metric might be the ratio of intrusions/attempts, but since I would wager the majority if intrusion attempts, and even many successful ones are never discovered, that isn't a really good metric, either.
Why gives a damn about root compromises? Surely no applications on your sytem ever run as root? Since when does my FTP server need to be able to create files in /dev?
:) ] is trying to fix this, and is already being used in production systems. Butuntil its in the kernel nothing is being written for it and there's still vast quantities of broken applications.
No wait, I forgot - most Unixes (apart from TrustedBSD, Solaris, Trix, etc) are still using a completely non secure non granular permission system - ie, in terms of security, a broken one.
Ever service a machine provides should run under an account with the same name with permissions to do what the program does and no more.
Capabilities can provide some of this function, but they still can't fix some aspects of this fundamentally broken system. Ie, I have some word processor documents stored on a server. Some users need to read and write the files, another group needs to read the files, and all other users should have no access at all. There are ways around this, but its hacky and makes the system much harder to administer, compared to a four line ACL.
The Linux ACL and Extended attributes program [google
And while we're on the topic: please don't ever assume UID 0 belongs to an account called root (apps, not documentation). Drone about STO all you want, but obscurity as a layer on top of real security simply does slow crackers down. Haven't you ever used a honeypot?
Your proposed standard levels of exploit are very unix centric. While such a set of "levels" might be appropriate (or even best) for comparing current unix-like operating systems, I think you'd want to try to make it more general. Things like: unauthorized permanent storaged read, unauthorized memory write, unauthorized code execution, unauthorized network write, etc.
If you applied such a system to our current linux, you might think it kind of silly since there would be a fair bit of redundancy (anyone who got root could do anything). However, I hope that in a couple years there will be several security systems that plug into linux that will make your current concept of root, user, and group privledges inadequate.
System security covers just that; systems. Not software. Do your users know what to do if somebody claiming to be 'Bob from IT' calls up asking for a password? Could a nice looking person in a suit, with a laptop, stroll into your office, sit at an unused cubicle, claiming to be a consultant, and plug into a live network drop? Do developers or other non-IT people have the ability to put up live systems, say, for development work, testing, or just because they happen to know where they can find a network drop with external access is? Do you have a disaster recovery plan? A hacker or an earthquake will destroy your data all the same. In a similar vein, what sort of locks are on your electrical closet? Can some idiot with a Linux boot floppy with a whack of filesystem drivers get to any machine with data on it? Go read up on the "Orange Book" computer security rating system. Honestly, software is the least of your worries.
Vintage computer games and RPG books available. Email me if you're interested.
any normal (read not yours) company will have at least dual or quad CPU hardware running in a cluster for their webservers
Jippity! If "any normal company" has clusters of dual and quad CPU machines to run their websites, I hate to see the hardware that runs their databases! And on the same token, I guess I haven't experienced these websites from "any normal company".
I agree that it's a bit of a shame that oBSD isn't an SMP monster, but that fact alone really isn't much of a problem these days, especially with 1.0+ GHz processors being the norm. Of the websites I help maintain, one handles an average of 1.2 million requests per day (average of about 14 requests per second, and about 8 GB/day). Granted over 95% of that is static content, but it's all hosted through a Pentium 233 running a heavily-patched version of Red Hat 5.2 and the load average rarely goes above 0.15. Another website handles the registration and accounts of a regional academic competition program and gets an average of 5 CGI hits per second. Using MySQL and Apache+ModPerl on a PII-266 atop Red Hat, the whole works chugs along fine with a load average around 0.10.
oBSD on just one modern CPU may have its limitations, but it could easily saturate a pair of 45mbit DS3/T3 links with dynamic (PHP/perl/etc) content without much cpu load at all.
I'd imagine rating hardware would be easier, as the main failure points are physical components breaking due to heat, etc.. Software has a lot more variables, including the hardware it's run on, experience of the administration setting it up, and such...
www.Beyond7.com Insane modern art water sculpture.
Software, of the other hand, is a digital entity, so its function doesn't change with time. If it was broken on the 10,000th time around, it was broken all along. Whether anyone noticed it was broken is completely another issue.
--- In the battle between the axis of evil and the one of stupidity, choosing intelligence is disloyal.
Our company changed over to OpenBSD from Red Hat because we were fed up of all the root exploits, all the patches all the time, and the incoherent way in which linux as a whole tends to be organised - ie, linux is the kernel, not the OS. OpenBSD is the entire OS, and is much more sane, IMHO.
The problem with linux is the general chaos. Great for hackers, and definately much better for the desktop user, but oBSD and *BSD's generally are much better in production environments.
Put simply, oBSD is the single most secure OS in existance, and fBSD the highest performing. Take your pick, its no contest as far as BSD v linux is concerned for my company.
--Anticipation of a New Lover's Arrival, The