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?"
Mean Time Between Important Slashdot Articles.
Currently, 3 years.
I agree with both sides of the *BSD argument. I use OpenBSD and Linux every day. I play with FreeBSD sometimes. I use Linux for my desktop (need SMP, multimedia, and VMware) and OpenBSD for my home firewall.
I love the nice tight feel of the BSD's. I like the FreeBSD install much better than the over complicated or install-to-much Linux installs.
Even though I really like the BSD's, Linux has got a lot of momentum behind it at this point. Some of the coolest (for me anyway) opensource projects are all too often Linux-only.
True, a default Linux install can be less secure than say an OpenBSD install. Part of the problem is in the install and default configurations in Linux. I fully believe Linux can be as secure as OpenBSD if set up correctly. And there's some really neat security projects going on (SElinux, LOMAC, etc) and will really tighten up security for Linux (and offer more options and control than OpenBSD can at this time).
Linux also seems to have more choices for encrypted filesystems. I like the lookback single file/device vs. the CFS encrypting each file that the BSD's use. ppdd was/is cool too, waiting for a version that works with a recent kernel because it's awesome to encrypt your root filesystem.
It would not be difficult to measure the period of cracks in default installations of $OS with no added software, exposed directly to the internet at a low-profile location. Such numbers would be useless. Almost nobody actually has true default installs of anything, and virtually every system has configuration changes, software added or removed, various local administration practices enforced, etc. It also tells yout nothing about the effect of firewalls and intrusion detection, or the impact of merely *being* a higher-profile target or a site which provides certain services to the world.
In short, there are conservatively a million different inputs to this function, among the least important of which is what the system looked like after the initial OS installation. Until such magical time as OS vendors find a way to make every possible user happy with the set of software and configurations installed out of the box, customizations will remain the rule, and at least in the Unix world, so many customizations are possible, exercising so much different code from so many different sources, that no reasonable analysis of this type is possible.
In short, neat idea, but not possible to implement in any meaningful way.
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
Speaking as a part-time sysadmin in a Solaris environment, I can only hope that referring to Solaris as one of "the most secure OSes" was a grotesque joke. I would not categorically say that it is worse than Linux or Windows, but it is definitely no better- new exploits for Solaris come out all the time- currently I know of one rootshell exploit which is just hanging over our heads because it's in a subsystem which can't be turned off, and which Sun has so far failed to patch. I can't speak to the other OSes you mention, but "how many expolits do you hear of for such-and-such" is totally irrelevant to the actual security of the system, and the fact that you include Solaris in the list makes me rather skeptical of the rest of it.
"Never let your sense of morals prevent you from doing what is right" -Salvor Hardin
I can make the example of the company where I work (no, I won't mention the name).
They buy mostly dual-proc machines since, given processor obsolescence, they will last longer: it's the same reason why I bought a dual-proc at my home, and after three years it's not yet ready to be dumped.
Back to the matter at hand. Those computers (most running NT) sit idle 95% of the time, because the limitations are not CPU power, but ADMINISTRATIVE (what belongs to whom), ADMINISTRATION-related, what kind of setup is needed, whether it's to be high-availability), assorted problems with the OS (load a host more than X and NT - or Win2k - will go BANG), and general reliability problems (if you listened to Microsoft's specification, you'd have one site hosted on each server, no more.
Still, the double CPU thing somewhat limits obsolescence, and so it persists.
That is why for web work I use zope. I can assign acl on a per function basic in my python code. It would slow it down if I did it on everything however if judiciously used you can make solutions near impossible to crack.
I would love to have zope type acl capabilities in linux and am happy that a group is working on it to replace this user/group/world thing.
Check out the kind of security problems zope has had. Almost every one is actually an admin error that got "fixed" so others could not make that mistake. Ie making things essentially suid root. I think if linux had full ACLs with very find grain control and large list sizes the security problems in linux would drop like a rock.
Computer modeling for biotech drug manufacturing is HARD!
- 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
"Put simply, oBSD is the single most secure OS in existance, and fBSD the highest performing."
I agree that OpenBSD is probably the most secure OS out of the box, maybe even the most secure OS period. But the idea that FreeBSD is the highest performing OS is just plain silly. Pick any commercial enterprise level Unix variant at random and it will outperform any open source OS including FreeBSD. When FreeBSD can scale efficiently to 64+ processors like Solaris and AIX then maybe it will be in the same ballpark as these operating systems. Until then its small potatoes.
Of course you could have been trying to say that that it was the highest performing *BSD variant, in which case I'd say you were right.
Lee Reynolds
Muslim community leaders warn of backlash from tomorrow morning's terrorist attack.
*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.
--
The setup of the machine (as in the combination of software) is effectively irrelevant. Reported exploits most commonly happen in individual pieces of software. It _is_ possible to rate software based on the frequency of exploits reported in one piece of software. Even the most complex exploits hit enumerable combinations of software, not thousands of variations[1].
Widespread exploits depend on out-of-the-box insecurity.Similarly, security ratings of locks depend on their out-of-the-box characteristics, not when you've 'customized' them with a hacksaw.
However, the uncertainty of security ratings is almost certainly dependant on the install base of the software. So that, eg the certainty (not the value) of the security level of Windows variants is much higher than anyone else, while that of eg MVS should be fairly low as there are far fewer folk with access to mainframes.
-Baz
[1] This situation is different where there is a widely deployed insecure protocol, such that almost every implementation can be compromised by exploiting the same flaw in the protocol. However even this boils down for the most part to knowing the OS patch level.
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
I think the concept is neat, but I don't think it involves a complex calculus to ascertain a system's security rating. You don't need to add, multiply, or average the package ratings on a machine....
Just read off the lowest one. The security on a machine is only as good as the least secure package.
Of course, you run into the problem of who will be the authority issuing these ratings. No software developer would be honest or forthright about their number (or the measurements would be entirely uncomparable), so a trusted external body would be responsible for the ratings... and they'd be liable for all manner of litigation from trademark infringement to libel to spoiling a market for a product by telling the truth about it.
So I predict it'll never happen. It's hard enough to get vague information about security breaches. Nobody'd dare quantify the risks.
I don't need large brains to have a good time.
First, as the poster above said, that is a hardware error, and exactly the kind of thing that affects MTBF numbers for various hardware devices.
:)
Second, cosmic rays do not actually cause memory errors. What can cause errors are alpha particles, usually given off by decay of trace radioactive elements in the ceramic casing of ICs. This is a problem for any IC, and they have to be designed to withstand it. I don't know if that is actually a significant source of errors in modern memory or not, though.
Of course, the #1 cause of memory errors is defective memory, but that is another issue entirely
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.
Humans have a mean time between failures of something like 900 years. That means for every 900/man years lived on Earth, someone dies (somebody correct me if I'm wrong on that number). Humans however have a Mean Time to Failure of about 72 years. That's the average time a human lives before failing.
Toddlers are the stormtroopers of the Lord of Entropy.
Bruce's argument is that the possibility of an exploit puts all known security holes into the script kiddie category in this cryptogram newsletter
-- no sig
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?"
no, because all you can do is measure the past of a piece of software and that doesn't tell about the current version or a modified version. the function for calculating the score for a piece of software would be unfair because it probably couldn't take into consider oldness and popularity of a piece of software and if it is open or closed.
it would be better to rate admins by their history.
Vintage computer games and RPG books available. Email me if you're interested.
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.
Well, if you are right or wrong, the fact is that the 'trusted' features everyone is raving about are available for OpenBSD right now (even if not part of the main system) go read deadly.org to hear about the patches... Not to mention the 'TrustedBSD' project that aims to impliment ACLs on FreeBSD, which will no doubt spread to oBSD and NetBSD with security improvements in the oBSD code...
---=-=-=-=-=-=---
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
---=-=-=-=-=-=---
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
Mac OS is used by at least a few million folks, most of whom don't know what they're doing, and many of which have nice equipment and lots of bandwidth (artists, DTP folks, etc). Can you think of a better group to hax0r and use their resources?
The reason Mac OS (classic) doesn't get Hax0red has to deal with the OS's architecture. A circa 1982 design with no command-line interface, no unix or dos roots, and no real non-gui way to control the beast. The closest I've seen was a background-only daemon that listens on a certain TCP port for AppleScript commands which it will then execute. Not too useful.
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.
Secondly, I don't think there's any way of coming up with an objective standard, a base line by which such a meantime could be judged. No two servers are alike, and even within broadly comparable applications it's more complex than just measuring traffic to the server, average load, etc. Some servers are more visible, or more desirable (from a cracker's perspective) -- either from a kudos point of view, or in terms of the potential use that can be obtained from a cracked server. It's pretty meaningless to say "my server's been up for months without being cracked" if it's some no-name machine that nobody knows or cares about.
Security's also not just to do with the software -- the computing power of the machine also needs to be taken into account. You're not going to be able to crack a password list as quickly on a 486 as on the latest pentium machine, for example.
So: no, it can't be done, reasonably. And asking what kinds of mean times we'd expect to see is, frankly, trolling for a platform flamewar..
The reason why you can do this with a safe is because there are so many known quantities. You know what the safe is made of, and how it is built, and the properties of both, with no hidden surprises. The vulnerabilities of both stay constant over time as well; you don't ever hear about a previously undiscovered buffer overflow in carbon steel :) And finally, the methods of attacking safes and vaults do not change quite so quickly as hacking methods evolve, so you can know authoritatively what would be done by an attacker, and account for all of it.
For your security, this post has been encrypted with ROT-13, twice.
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.
I just looked it up in "Fundamentals of Software Engineering" by Carlo Ghezzi, Mehdi Jazayeri, and Dino Mandroli.
it is "Mean Time to Failure" (MTTF) and its defined as "the average time interval between two failures".
sorry no good links but MTTF is what your looking for.
"Shut up brain or ill stab you with a Q-tip" Homer Simpson
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
oops i meant bind not sendmail =P
The difference is, of course, that hardware fails, statistically, in a more or less random fashion. Exploitable software fails once, and then near *constantly* from that one mistake.
During my first 5 minutes of looking at BlackICE output, I got hit from about 4 different directions as people scanned through the net...
Cryptogram March 2001 has an article about it, for example.
--
fifth sigma, inc.
Let me clarify something here. I'm not looking for mean time between rootshells for a individual system, but for a type of system. For example, what's the mean time between exploits in BIND 8 in general, not your specific BIND 8 installation. The more general question really is, why don't we measure how often a product has flaws discovered. If I need to choose between RedHat and OpenBSD and security is my biggest concern I'm going to look at 4 years without a remote root exploit and chose OpenBSD, but what if I'm deciding against Solaris and HP-UX? What's the difference?
The reason I find this meaningful because it help measure work load. Am I going to take the machine down once a week to apply a patch, or once a year? The shorter the time between new exploits the more work I have to do to maintain it.
--
Darthtuttle
Thought Architect
Darthtuttle
Thought Architect
The problems with metrics on software has always revolved around the abstract nature of software itself. Almost any sort of metric can be misrepresented one way or another.
Long ago, companies measured programmer productivity by using the KLOCKs, 1,000-line blocks of code. The more KLOCKs you could kick out in a given time period on a task, the greater the perception was that you were working harder. We all now know how easy it is to manipulate that perception. 500 lines to add two integers, sprinkling 1000's of lines of useless looping code documented to look like it's crucial to the system.
Proper measurement of failure is further compounded by the complex nature of most products written in OOP. Underlayered components, physical devices, and operating system issues could be mistaken as problems with the software application, when in fact the application itself requires no modification to fix the problem. Metrics also rely on fixed points of time as references which make matters worse as some problems are beyond the scope of the project (i.e. product works fine, but customer later upgrades video drivers that cause app to break).
Carnegie Mellon University has pioneered the software maturity analysis area with its Capability Maturity Model for software shops (think ISO9000). If I was a large customer (say Boeing), I would probably make my purchase decision more along the lines of the CMM rating of the software team that created the product rather than some silly arbitrary metric that most suits probably wouldn't comprehend anyway.