Intrusion Tolerance - Security's Next Big Thing?

An anonymous reader writes "DARPA's OASIS program consists of more than 20 research projects in intrusion-tolerant systems. The basic idea is to concede that systems will be penetrated by malware and hackers, but to keep operating anyway. Other projects take a wide variety of technical approaches to providing intrusion tolerance. MIT's Automatic Trust Management uses models of trust to choose from a variety of ways to achieve system goals; Duke/MCNC's SITAR (Scalable Intrusion Tolerant Architecture) adapts tricks from fault-tolerant systems and distributes decision-making; BBN-Illinois-Maryland-Boeing's ITUA employs unpredictable adaptation. Shutting down the military while waging war is not an option, but the idea of continuing to operating critical defense systems even after known penetration by hostile hackers or damaging worms will take some getting used to."

BIological Systems

I think it is great that something like this is being looked at. Every biological system on the planet works on the same principal, yes, the system will be attacked, keep functioniong, and attempt to regain controll.

I think an interesting option for powerfull machines would be to 'fall on the sword' if complete failure was immenent.

Repeat after me...

...this new mantra of security.

I must not fear. Fear is the mind-killer. Fear is the little death that brings total obliteration. I will face my fear. I will permit it to pass over me and through me. And when it has gone past, I will turn the inner eye to see its path. Where the fear has gone there will be nothing. Only I will remain.

-- The Bene Gesserit Litany of Fear
Dune by Frank Herbert

Re:Repeat after me...

...this new mantra of security.

This replaces the old mantra right? "I refuse to patch, for patches deny faith, and without faith I am nothing." (Douglas Adams)

Re:BIological Systems - Scares me!

Every biological system on the planet works on the same principal, yes, the system will be attacked, keep functioniong, and attempt to regain controll.

I don't know about you, but my neck hairs bristle at the shift of computer systems into the biological (model) realm. I am well aware that biological systems function well in the face of a variety of offenses.

But they (biological systems) also autonomously evolve, compete strongly, and often get wiped out. And when they do too well, they have the tendency to consume all resources, pollute, and then die out or reinvent themselves.

We (humans) are a biological animal. Let's be careful building something that will compete with us. The potential dangers of this scenario have been played out in Terminator and countless other sci-fi epics. Self-aware entities fight for their survival and the survival of their species/genes.

You might say "but we control the technology", but in fact the next generation of computers will control us. Digital Rights Management (DRM) is in effect our surrendering of our rights to machines. As more of our survival becomes dependent on machines (as has been increasing at an exponential rate recently), this means our rights of survival are out of our hands. Think of DRM as the Declaration of Independence, but in reverse -- well, we had a nice run there for a couple hundred years! But I'd rather be a heavily-taxed under-represented colonist of a foreign empire than a farm animal to machine masters any day.

I don't mean to rant tinfoil hat conspiracy nonsense, and it's important to secure our systems from collapse, but let's not be so quick to push ourselves toward slavery just yet. I think this (self-aware networks) is an area that is as important as nano/biotech to watch out for, and it's far more likely that we become totally enslaved to technology than that we all get turned into gray goo.

Re:BIological Systems - Scares me!

You can't avoid the inevitable.

Our biological forms are too fragile to survive anywhere long term except here on Earth. Even if we found a way to terraform other worlds, we would still need intelligent machines to do it for us and then to get us there.

And as many futurologists have pointed out, if we do pursue such technology, there *will* come a point in the next few decades when our creations' intelligence finally surpasses our own.

So what are you going to do? Crawl back to your cave, maybe even give up using fire because of the risk of where it might lead? We need to meet this challenge head on; prepare for it, make room for it in our plans.

I think what it boils down to is this: will our creations tolerate us, can we co-exist? I think the answer lies here: if we ourselves are moral then so will be our children and we will live in peace. If we are not, though, and we create children without any moral spirit, well yes, then as a biogical species we're doomed.

Re:BIological Systems

The biological model is an interesting parallel, but we should also look at the failings of the biological model -- within your body, you are still a big monoculture, so once whatever foreign matter is in, it won't encounter anything radically new.

Intrusion tolerance, IMO, is just a subset of fault tolerance -- something failed to let the intrusion happen. So how do you tolerate that sort of fault?

1. reduce interdependency and single points of failure. If everything relies on the firewall box, and the firewall box goes down, then everything is down, even if everything else wasn't compromised. This is a failing of the biological model -- there are lots of lines of defense, but what happens when something goes straight for the heart? The brain? The spleen? A fault-tolerant system can't have a single point of failure.
2. just say "no" to monoculture. This should be a given in redundancy and fault tolerance, but often isn't. So your firewall is a linux box, and it gets hacked, but that's OK because you have another firewall. Oh wait, it's a linux box too, so it will fail in the same manner. This is not good intrusion tolerance, because your intruder can duplicate his or her (or its) past actions -- more of the same probably won't even slow him/her/it down much.
3. spread stuff around. This usually happens anyway because of load balancing, but couple this with #2 (reducing monoculture) and you'll really slow down an attacker, especially if you can make the separations transparent from the outside.
4. be vigilant! There's no replacement for the human element; hire somebody (or a team of somebodies) to do nothing but spend all day logged in to critical machines and make sure that nothing out of the ordinary happens. This is another failing of many security models -- people think that they can replace people with machines, but machines are easy to fool -- well-trained people are harder to fool, and the combination of the two (since they are fooled in different ways, see #2) is a lot harder to get around.

A good fault-tolerant system will have multiple layers that fail in totally different ways. This will thwart most automated attacks, since they tend to exploit a single, known vulnerability and won't be equipped to respond to another, totally different layer. If the layers are different enough (say a *nix-based firewall behind a Windows-based firewall), most attackers will be so thrown off that they will (at the very least) have to spend a significant amount of time trying to figure out what to do next. This buys you time to realize what's going on and stop it. Couple this with a very low interdependence, and an attacker can spend a lot of time breaking in to something that may be of little or no use to them.

Intrusion tolerance? You betcha -- this acknowledges the fact that there's no such thing as failsafe security, but takes advantage of a wide variety of options, which won't fail similarly, to slow down attacks and give administrators time to see what's going on and stop it.

Isn't this all obvious though? It seems like it when you read it, but the 4 concepts noted above are very often ignored (to varying degrees). Especially #2; this is the hardest because it means hiring a *nix geek and a Windows geek and a Cisco geek and maybe a couple of other ones as well, and no one wants to spend that kind of money. So instead, they get a guy or gal who only knows one system, so everything lives or dies on the failings of that system. Or even worse, they hire a whole team of guys and/or gals that all agree to use the same platform, for simplicity's sake. Bad! Bad! Remember the scale:

More Secure...................Less Secure
_________________________________________
Less Convenient...........More Convenient

Eh. Talking's easy...

--
eep

Re:BIological Systems

It's a good analogy but it doesn't apply to individual machines.

Think of your computer as a cell, and the network as the biological system.

The network can continue running when infected, but not the cell. When the cell is infected, it dies (or worse.)

Ergo, I think intrusion tolerance is a meritless approach.

I think an interesting option for powerfull machines would be to 'fall on the sword' if complete failure was immenent.

This idea I like. Call this intrusion intolerance. Require the system to meet a comprehensive suite of invariant conditions, or cease operating. A much more practical and effective solution.

Ed note : no, it isn't

What to do when penetrated

1) Remove all sources of power
2) Incinterate the hard disk, ram, motherboard and most importantly, the sys admin who was in charge of the box.
3) Bury the ahses in a safe concrete cavern, do not touch for 1000 years.

"intrusion tolerance"

upon hearing this, my first thought was the chatter-box prostitute from Bruce-Willis's "Last Man Standing."

Somebody drag my mind out of the gutter please!

Obvious Question...

The obvious question is how did the hacker get there? These computers shouldn't even be connected to the internet. And if they're not, then there are more important things to worry about, such as why is there an agent from a different military operating on restricted computers.

Analogy

What has to be understood is that a compromised system, if part of a larger group of compro & non-compro systems can have a lot of undesirable consequences. In a Corporation network of say 150 servers a couple broken in boxes serving as open relays, ftp/warez sites or just sniffing around do not necessarily have to bring the whole Company down for a day, pulling the plug on them is always an option.

However if your servers/farms are crunching numbers for a Satellite recon or is running a battlefield communication center then your not quite sure how it would behave. A lot of modelling and discussions will go on about this, but some of these problems (of data consistency) have already been handled previously in Computer Science... so its not that big a deal.
It will I guess be like one of those "decisions" a battlefield commander takes, of how much he trusts the intel he is getting and how he wishes to proceed and are the risks acceptable.
Similarly the network/systems ppl will be making choices whether they can live with this intrusion or not...how best to handle it without stopping the grid.

That's what war is all about!

Shutting down the military while waging war is not an option, but the idea of continuing to operating critical defense systems even after known penetration by hostile hackers or damaging worms will take some getting used to."

What do they think the military goes home when someone gets killed or they find out there might be a spy? That's why our military security is completely segmented. The whole concept of need to know basis, is the understanding that information will fall into the wrong hands, you just want to minimize how much information can fall into the wrong hands when someone or something is compromised. That computers, especially military computers would follow this highly pragmatic principle shouldn't come as much of a surprise.

Fog of War is the operative model

Perhaps the aproach should be to throw so many false leads at the attacker that they play their hand before they do any real damage.

There is an old philosophy that you don't need to create a perfect lie. You only need to tell so many lies that they truth can no longer be seen.

A system of honeypots, firewalls, and harmless paths into a network would allow a hacker to be studied, traced, and combated (counter-hacked?).

The law is becoming an obstical to such an approach. There is legal speculation that honeypots constitute a form of wiretapping. Bad laws are going to make it very difficult to be a white hat in a few years.

Re:That's what war is all about!

That's why our military security is completely segmented. The whole concept of need to know basis

And, as with the military, if you compromise high enough up the chain you can do a WHOLE lot of damage. Senior military officials don't just have military drivers because of their rank - The drivers also have guns.
There's a reason former US presidents get USSS protection for quite some time (now 10 years, formerly life) after leaving office - What they know remains highly prejudicial to national security after they go.

The problem with computers is that you can force them to reveal everything they know without leaving them catatonic with drugs or physically destroyed - In theory, nobody would ever know.
This biological concept of security needs to use the full biological model of sacrifical guards. The body repels invaders by sacrificing cells to attack the invader. A computer that merrily allows an intruder to work its way back through the network until they can read everything is no use.
Maybe create switches that have fusible links on the network ports that can be destroyed with a command from within the network? Make the links cheap and easy to replace, so that it's not a major imposition to fix if someone does it maliciously or accidentaly. A physically "down" network port is absolute security against a remote attacker, particularly when a computer only has a single NIC.

Re:That's what war is all about!

This biological concept of security needs to use the full biological model of sacrifical guards. The body repels invaders by sacrificing cells to attack the invader. A computer that merrily allows an intruder to work its way back through the network until they can read everything is no use.

I don't think the idea is that the computers will just ignore intrusions. At the very least, they'll notify a human operator that an intrusion has taken place while trying to continue normal functioning. If possible it will probably try to elimiante the intrusion.

However the first priority is to continue it's primary functions. The military can't aford to have it's communication grid or it's airflight control or other items of such a crucial nature shut down in the middle of combat, not unless there's a backup ready to take over. (And do you trust a compromised machine to decide whether or not a backup system is available?)

So the system continues to do it's best to carry out it's tasks while a human operator decides when and if the machine can be shut down and another swaped in to take it's place, and coordinates any possible counter-hacking operations.

If you want to fall back to a cold war/MAD mentality, here's a worst case scenario for you. Say that twenty years from now China launches an unexpected nuclear ICBM assult against the US. At the same time Chinese hackers attempt to infiltrate every known computer in NORAD and any SDI systems. Would you want the computers to automatically destroy themselves, thereby eliminating any chance of a timely defense or counterattack, or assume that the hackers haven't got full access and keep the computers going as long as possible since the other alternative is death?

And if you're going for a MAD strategy, which of those two systems would you want your adversaries to know that you have?

Perhaps systems which undo intrusions?

I think the next step from intrusion-tolerance would be a system that logs intruder activity, determines how the intruder got in, and when the intruder leaves, cleans up whatever rootkits, etc. were left behind after logging everything it can about the event.

Other interesting ideas would be determining "tainted" processes run or otherwise affected (library overwrites, etc) by the intruder, and automatically sandboxing these processes in a nifty little world that looks realistic, but couldn't be used for a DDoS.

Anyone up for writing a drop-in libc replacement that screens any attempts to overwrite libc? You'd also have to override the linker behavior, so that an attacker couldn't just LD_PRELOAD a normal libc for their apps. You'd still be open to statically compiled apps, so this may be a lot of work for only a little gain.

Of course, this would make it hard to upgrade libc ;)

What's so unusual about this?

Seriously. The implementations are new, but the concept goes back to the dawn of interconnected computers, maybe further. Back in the Iron Age, you used different passwords on different systems specifically so that, if one of the systems were penetrated and your password compromised, all the other systems you had access to would not be immediately compromised as well. That was a limited form of intrusion tolerance, forcing the intruder to start over from scratch on every system in the network.

Example of intrusion tolerant system

All micorsoft operating systems are extremely compliant with RFC intrusion tolerance. Indeed they positively welcome intruders open arms and open legs. once in the intruder can pretty much do as they please. If that isn't intrusion tolerant I dont know what is.

interesting, but not really a new concept

All it's doing is moving the security barrier. You're creating a new line, and saying that it's OK for attackers to cross the old line, since that doesn't get them across the new line. But defending the new line is not fundamentally any easier than defending the original line.

Re:interesting, but not really a new concept

Huh? The military has had *thousands of years* of experience in information security! They created/funded/supported research in almost every major communications system/cypto system of the past two millennia.

They know no system is totally secure - especially when your adversary has spies, troops, and bombs. You expect enemy signals intelligence, broken codes, code-books captured in combat, spies in your data centers, secure comm channels destroyed.

There is no one line/security barrier: the only rational approach is a defense in depth, with montoring of problems, and the ability to route around compromized and destroyed systems.

Prior Art?

" concede that systems will be penetrated by malware and hackers, but to keep operating anyway"

Hasn't this always been the strategy of Windows? Now if they could just finish implementing that second part...

Same as in many materials uses

Much engineering effort goes into the benefits of balancing somethings hardness against its resilience. The broad idea for security lately has been to make systems as hard as possible, but leaving them brittle. Even Diamond and Alumina Ceramics shatter relatively easily. Building systems with something more akin to the resilience of steel makes sense... ... as long as you have some damned way of translating materials science into network security.

perhaps I need coffee :)

Jeepers ...

... sounds like somebody is reinventing Multics... again.

Why does it have to be like this?

Why do we have to accept break ins? OpenBSD hasn't had a vulnerability disclosed in months now. Does that mean there are no vulnerabilities? No. Is an OpenBSD box pretty much unusable out of the box? Pretty much yes. But the thing is if you keep things simple, they should be easy to audit. Bugs should be easy to detect and fix.

You get into trouble when you start piling on feature after feature after feature. Is all of that really needed?

Denial of Service is, unfortunately, harder to deal with. But when you have your own network, it's much easier to deal with. Dependancy on the Internet still creates a problem (the majority of US government data communication is done via the Internet). It comes down to a cost benefit analysis - is it worth building a totally seperate network? For the military, I'd say yes.

Just My .02 USD

In general, I don't like the idea of making a concession that malware will have to be operating in a given computing environment (as stated above), and to think otherwise would simply be incorrect. OK, Windows environments may be an obvious exception ;-)

I would prefer to consider that (at least from my own philosophical viewpoint), that you can construct systems with defined patterns of behavior, even when "malware" is introduced.

From one of the links referenced above :

Successive levels in the hierarchy are linked by refinement mappings that can be shown to preserve properties of interest. This project will apply this technology to intrusion tolerance properties.

This harkens back to enforcement mechanisms (Biba Integrity Model, No Read Up, No Write down policies, Models for descriptions of multi-level secure behavior, etc...). (Aside: Amoroso's book is an excellent reference)

What this alone tells me (I didn't read all the blurbs, articles, and briefings), is that we are discussing mappings (mathematical functions), and properties (which can be mathematically tested for by use of a logic or algebraic system).

At a glance, I am thinking of some of the issues in formal methods, proven-secure-O/S kernels, and other high-reliability software engineering methods for [secure] systems.

I like the idea that mathematical theorem provers can be applied to any system so defined.

Some basic issues do arise for practical application :

- Theorem - proving aspects mean very precise use of functional requirements and mathematical specification for system behaviors. (Also, special talent and additional manpower is necessary. Also, mis-applications of the tools used, or introduced human error in the test process can subvert the efforts)

- This should be applied (I believe) to systems-of-systems and their behaviors. The systems that your system interacts with would have to had similiarly rigorous analysis and design.

- There is (I believe) a trend in military computing towards commercial, and less custom, software development. Long-term, where will the actual development of such systems be funded (beyond the initial R&D stage).

- The use of analysis of pre and post conditions in the executing environment (to ensure that violations of the underlying security policy are not permitted) is not a new concept. While I am not saying that this is an intrinsically ecessary mechanism for these methods, most current system lack such an approach, and there may be fundamental computer security issues present by the nature of the software development environment. If these methods are used, it is still highly desirable to design systems with security in mind regarding their handling of all data, traffic, and O/S vulnerability issues.

I only took a brief look at the material, but these are some thoughts. I also think that the effort itself is very worthwhile, and potentially of value. Also, looking at Dr. Lulu's credentials, there is no naivite in his software background; the basic tenents can't just be shrugged off.

Sam Nitzberg
[e-mail]
http://www.iamsam.com

The way it should be

Recently I upgraded and migrated to a newer, much faster server. When I moved over all my software, everything worked OK, so I switched DNS about 2 weeks ago.

However, I got sporadic complaints about images not sizing properly, even though I initially found nothing wrong.

However, what had happened is that a critical piece of software (ImageMagick) wasn't loaded on the new server - but since all the functions that resized images had numerous fallbacks (such as using expired, cached copies, and failover to full size display which even then didn't always cause a problem since they were frequently resized with HTML tags)

In any event, this (I think) demonstrates the idea - there were several layers of failure that had to happen before images didn't show - and everything kept more-or-less rolling for 2 weeks.

Similar idea to another group

This is similar to research being done at MIT [mit.edu] in the Computer Architecture Group [mit.edu] by Martin Rinard [mit.edu] and his graduate student Brian Demsky. They are building and researching ways to automatically detect and repair data structure errors so that if a programs data structures get corrupted their tool will repair the heap so the program can keep running.

There was related work done like this back in the day at AT&T but Rinard and Demsky have introduced automatic repair which, as you might imagine like this security idea, is scary to some people. Imagine a program that would have crashed due to some bug or malicious data mangling, now kept running by a tool... But the tool chooses the repair actions based on heuristics and specifications by the developer... takes some getting used to!

All of this stuff falls under fault tolerance... its pretty crazy to look at what the AT&T/Lucent Phone Switches do when they fail... they try a million different things to keep operating no matter what happens...

The next big thing?

More likely, the next big jive word my boss is going to get obsessed with. I mean, sure, it's a great idea, and eventually I see it coming into heavy use, but for right now, I just see the corporate types throwing it around in their techno-babble pissing matches

Suit 1: We've got 10,000 uberhumungo servers running Microsoft 2003 Humungo Server Edition, with b2b backend, integrated transaction safe, load-balanced Humungo Edition IIS.
Suit 2: Well, we have all of that, plus Intrusion Tolerance.
Suit 1: Oh, baby. Can I merge with you?

tolerance and love

Oh... I thought we were going to start being Politically Correct and stop saying bad things about script kiddies.. I'm relieved to see the world hasn't quite reached that level or purgatory just yet.

penetrated in advance

My best guess is that the military (and the pseudo government international defense-corporate twins) know they are penetrated in advance, ie, they got spies inside, and no way to keep them off their nets, even if secured from the "internet". They need some way to keep functional even though they know they are compromised. When you have top level nuke secrets waltzing out of supposedly secure places like los alamos, well, no amount of software is going to save you. When you have top FBI cybercops being spies, military IT people being spies, research univerities where english is a minor second language to whatever the majority of the researchers grew up speaking, and etc, well, that's an insecure system(s) from the gitgo. You can have an airgap, steel doors, retina scans, you name it, if the PEOPLE involved are not all on the same team, means will be found to sneak off with the IT gems, either on a one time basis or ongoing. That's the part I don't think they are emphasizing. That and a lot of the top level politico bosses being blackmailed/bribed off, again, adding huge levels of insecurity.

The old saying is "who watches the watchers?", but now it can be added to "who can you trust when no one is trustworthy?"

Sounds like an old thing

Just like paint programs don't allow you to delete files when you open a .jpg, so should any network software have the same power.

You should be able to access data and use it, but the data should not be able to access your computer.

The problem is that many closed source software programs have backdoors and basic coding flaws. If you understand what a program does(open source), then you can know it won't cheat you.

Nothing New...

This is nothing new, Windows has had tolerance towards intrusions for years...

New HCC RAM design for this kind of application

One project is working on a new standard for memory in DIMM form - the HCC DIMM - Hacker Checking and Correcting memory.

Reference model

A fault tolerant system in which, if penetrated, continues to operate until control can be regained. . .
OMG! We've been assimilated. Everybody listen AD2ô8 yç 48

[Carrier lost]

Qmail?

The easiest way (and perhaps the only way) of achieving intrusion-tolerance is by segmentation. Split a program into several parts which trust each other as little as possible (and run with minimal priviledges); even if one part is compromised, the attacker won't gain enough priviledges to do very much.

Oh wait, I've just described qmail.

Excellent

A network, that when penetrated, just lies back and thinks of England...

Kind of like the missus, really...

BREAKING NEWS

NEW YORK (Reuters) - Intrusion Tolerance Chastity Beltz Inc.
(NYSE:NOTIN - News) met analysts' expectations for earnings but did not beat them, and the stock fell 2.5 percent in after-hours trading after it was learned that their new line of chastity beltz, named "O-No-U-Di'int", was found to be easily exploited. The exploit allowed "end users" to sneak in the "back door", all the while, causing minor damage.

Engineers said a patch would be released shorty that would "plug up" the backdoor exploit. The engineers also informed "analysts" that they would also shore up the "chaffing bug" as well...

While we're at it...

Maybe it's time to revive discussion of error-oblivious programming methods. (Google for it.)

what?!?

So the idea is, have a vulnerability, get attacked, keep on trucking with the same vulnerability, continue to get pounded through the same vulnerability relentlessly by every script kiddie's scan, vendor never patches because we've all accepted that we can just live with the vulnerabilities, keep on suckin'?

From the MIT article, it sounds like some intelligence will shut some non-critical services down so that the core still runs, but isn't that what Intrusion Prevention is supposed to do? When you're talking military use, I expect the important areas to be surrounded by honeypots as part of the Intrusion Detection and Prevention.

Sort of explains...

an ealier slashdot story [slashdot.org], as in "um, no sir. It's not insecure, it's "intrusion tolerant".

waging war?

Shutting down the military while waging war is not an option, but the idea of continuing to operating critical defense systems even after known penetration by hostile hackers or damaging worms will take some getting used to.
How about not waging war? Or better, how about shutting down the military period?

parallel watcher network

one idea would be to have a parallel network watching all network activity and processes but with no actual way to communicate with the watcher network itself other than a physically secure terminal... this of course would lead to other watcher network layerss all the way on up to one point. I know it's not very logical and I can think of a ton of holes in this idea but who knows, a better idea could come from this. sig, with fries... please

Sad to get old

It is sad to get old[er], but this has got to be the absolute dumbest thing I've _ever_ seen. No, really.

A intrusion detection type system should, well, PULL THE PLUG on the offended box. PERIOD. Oh, no, let's keep it working as much as we can until I get my lazy ass around to fixing it? Mean while it's still dumping how many of millions of spam out to the Internet? Or ping bombing the hell out of who? Or just stealing my data enough to not panic my bandwidth button, but getting it none-the-less. Oh, but I can print. Yeah...

Insane computing 101

You want tolerance? Ok. I'll be tolerant and not fire your ass for letting our system get compromised ... for HOW MANY hours? Tolerant that I don't break your knee-caps with the baseball bat I'm holding. It'll cost HOW MUCH to clean this mess up? Tolerant that there will *always* be somebody smarter than you out there and perhaps you just met him or her. Now learn from your mistakes and GET BACK TO WORK. *THAT* would be tolerance.

But I have NONE for letting a compromised system from remaining, well, compromised.

Re:Sad to get old

respectfully disagree. yes, tolerant to the fact that there is always someone better than you i agree with. but these kinds of systems are not the ones that can take care of themselves while you finish your vacation in Hawaii so you can deal with it while you get back. These are the systems that can keep going while you are racing from dinner with your family back to the office to solve the problem.

In 90% of the cases, pulling the plug is the best thing to do. but take EBay for example, 1.2 billion in revenue relying entirely on their systems. That means they earned $2,289.38 every minute. So in that perspective, could you really tell someone to just simply shut off the site while you drive back to the office to fix it?

Charlie is listening...

Remember that from the Vietnam War? Intrusion tolerant computer systems... the more things change, the more the seem the same.

About damn time.

I personally have gotten sick of arguing with people asking them what they are going to do WHEN they get attacked. i lost count of how many admins i have delt with that thought just because they have a firewall and a BSD distribution, noone is going to get in.

bout time the question was change from "how are you going to keep them out" to "what are you going to do when they get in"

The beginning of the end..

Yeah, and what happens when you try to turn them off? They will think it's a possible attack and refuse to be shutdown.

Movies like the Matrix and T-3 come to mind. I think this is a bad idea.

There are dangers here

I guess everyone would agree that there is some merit to the concept of defense in depth. That said, recognise that the typical user (i.e. those most likely to be hacked) will generally not do anything about an intrusion as long as they can continue to work. I think a result of better intrusion tolerance would be a significant increase in the number of long term compromised systems.

Doubting thomases, exit (-1)

If you have a multi-level and/or granular security architecture, penetration or a hack at one security level doesn't mean automatic access to other levels or privileges. So they hack the webserver process. If the webserver is running as a non-root process in a chrooted jail -- perhaps even on a 'virtual machine', does that automatically mean we should shut down the whole system?

It's the same with well designed programs -- there was a slashdot article recently on QNX -- that is designed to be fault tolerant -- and it works. Only when you design huge monolithic code monsters where a fault anywhere in the monster means kill the whole beast do you have such frail computer systems.

Imagine human skin hacked by a scrape on some sharp object. If the first decision was to instantly kill the whole host, there wouldn't be too many humans -- can you say *stoopid* design?

Sure, there are some things that can't be healed, but the majority of us have had scrapes and bruises growing up and are still quite healthy -- and even where the car body may have permanent damage, then engine/CPU (the person's brain) is often quite capable.

Next time you think fault tolerant or intrusion tolerant systems are foolish and impossible, think "Stephen Hawking", or "Einstein" (not able to complete High School). I had a *stoopid* manager who thought that making system-audit so efficient, it could be left on by default in all but the most demanding of compute environments was a waste of time -- that it was *impossible* to build real-time intrusion detection systems.

Of course people thought it was impossible to circumnavigate the globe (you'd fall off the edge), impossible to fly, impossible to go faster than the speed of sound, etc.

Every time someone talks about how "impossible", you have to realize they are consciously or unconsciously thinking inside a box. To do the impossible requires something that *isn't* engineering. It isn't manageable. It can't be driven by a schedule. You have to *think outside the box*. You have to be creative. By definition, engineering, isn't creative. Engineering is taking known principles, applying them in some set of known circumstances, and coming out with another "widget", that looks similar to a previous widget.

Most large companies breed conformity and uniformity. While this type of engineering is great for reproducing Honda's on an assembly line, it greatly hinders thinking 'out of the box' (the box of conformity and uniformity that the company asserts is "necessary" for their business). Then they wonder why what was once a 'wonder company' is now a 'dinosaur company'.

Creative people are often *not* group players -- if they had a group mentality, then how can they be expected to come up with any idea that is radically different from the rest of the group?

Creative people tend more toward not having exceptional social graces (think of the novel ideas of unix, or Multics). These were not done by suit-and-tie, management "yes"-men. Even Linux was started by 1 person -- who has not always been known to be the social charmer, even tempered type -- and I certainly don't get the impression that everything is done by group consensus.

But already in linux, there is a fair amount of doing things the 'linux' way, certain people to please, various people who get say-so or veto powers (or are believed to have such) beyond Linus.

People familiar with Microsoft can remember when even the simplest application crash would bring down the entire system. Unix people would generally laugh at this. But now we see those who think a single penetration should cause the whole system to be brought down. Maybe it will require a next-generation OS (dunno enough about QNX to know if it might qualify), but there are other OS's that have better security records than linux (BSD, OS/X (I've heard)).

Linux, laughably, doesn't even have CAPP certification. Sure, there are alot more Microsoft vulnerabilities every

Trust Level

This is all well and good but what about if there is a bug in the actual trust part of the kernel or simple user error gives people more access than they should have? You can't protect against human stupidity

Rus

In The Trenches....

Sounds like a Front Line Honey Trench!

While you swim in the sweet honey thinking your in Heaven; the Soilder Bee is watching YOU! Doing his dance to the other Soilders who are TRACING YOU!

If I RTFA; it'd prolly sa's som'ing 'ike at.

GUess I go read it now.

OT: Please use appropriate terminology.

I know it's off-topic, and I really don't like to have to wax RMS, but it's "cracker", not "hacker". "Hacker" isn't a synonym for "computer criminal"...

I know I'll get modded down for this, but I really think that SlashDotters should not be making posts about those evil "hackers"... I am a hacker. I don't break into systems.

(/rms)

GPL'ed intrustion resistance

Shameless plug: Askemos [softeyes.net] is a GPL'ed incorruptible and intrustion resistant operating system (or application server for that matter).

DOH! UNIX is "Intrustion Tolerant"

One of the cornerstones of any multiuser OS is that some users are expected to malicious.

The OS has to have sufficient isolation that this luser only damages her own files and processes.

IIRC, FreeBSD even has a Write-Once "SECURE" flag that locks even root out from some functions.

byzantine fault tolerance

Byzantine fault tolerance [mit.edu] (BFT) is a "traditional" distributed systems technique that enables intrusion resilience. BFT replicates a service such that the service continues to work correctly as long as less than one third of the replicas are comprimised. Combined with proactive recovery (periodically shutting down replicas and restarting them from a read-only disk), this can enable the system to survive an arbitrary number of compromises over its lifetime.

It's called Survivability

And the CERT/CC [cert.org] has the following to say:

Survivability is the ability of a network computing system to provide essential services in the presence of attacks and failures, and recover full services in a timely manner.

Papers, etc, are also available [cert.org].

Enough theory - try practice

Intrusion Tolerance is already being practiced, although another term for it is defense in depth.

Another poster has described how defense in depth and fault tolerance apply to firewalls, network infrastructure, etc. I'd like to mention host-based measures to slow an attacker down and limit the damage they can do.

One of the oldest host-based D-i-D measures is chroot jails. A 'chroot' in Unix means that an application is run with access to only a limited subset of the filesystem, one which does not contain interesting, useful, or leveragable files. This makes it harder for an attacker to leverage, say, user-level access via a buggy network daemon into root-level access, access to the system passwd/shadow file, or access to system binaries.

chroot isn't perfect; the process still shares access to the OS kernel and the network, and can leverage those.

LIDS [lids.org] is a Linux-specific solution. LIDS allows capabilities on a system to be locked down beyond the capability of even root to modify. For example, you can set /usr/bin/* to be read-only, and not even root can override that without first disabling LIDS. The ability to bind to network ports can be controlled; e.g. only /usr/sbin/sendmail can bind to port 25 (and /usr/sbin/sendmail can be made read-only). The ability to load modules into the kernel and access devices to do similar things (e.g. /dev/kmem) can be blocked. In other words, the ability of an attacker who gains root access on the host to rootkit it is severely degraded. There are still openings, though, e.g. root can access user's files.

Security-Enhanced Linux [nsa.gov] is the next step. Rather than emasculating root as LIDS does, it "has no concept of a 'root' super-user, and does not share the well-known shortcomings of the traditional Linux security mechanisms...." Privileges can be carefully handed out to protect the system from the users and the users from each other.

Even Windows can benefit from some careful configuration. Consider how NIMDA used the Windows TFTP.EXE binary to bootstrap its access up - why is TFTP.EXE executable by anyone on the system? Set ACLs on system binaries. Make sure the IIS web root isn't on the OS drive to block directory traversal attacks. Remove things that aren't needed.

I can't remember the attribution, but someone summed Intrusion Tolerance up by saying, "If you can't prevent it, you sure as hell better be able to detect it." Keeping the bad guys off the server may be impossible, but every little roadblock you put in to slow them down will give you a better chance of detecting them and stopping them before they capture the flag and end the game.

What about TCP/IP?

Military is looking for options like this a long time ago. That's why they funded the research of packet switched networks (like TCP/IP) when all the known networks first established a path an then routed all the communitacions throw this path (circuit switching networks, like telephone networks). The whole idea behind military funding TCP/IP is to be able to shut-down compromised nodes without taking down the entire network. Id est keeping the system running even when the system is partially compromised. Aureliano.

Most of those things is just a lot of words...

...and very little thought. Really people who develop such projects should realize that the things they want and things they can get are two very different things, and no matter how much they want the former, they will get nothing but a false sense of security unless they will realize that they can only get the latter, and should pursue that instead.

Once something is broken into, it can not be trusted. This is the definition -- it won't be "broken into" if it was possible to trust it after the intrusion, it will be "operating as intended". Therefore if someone admits that a system may have vulnerable parts, he can either make sure that their vulnerabilities are eliminated (what is both impossible at the scale of existing setups, and beyond the scope of this kind of work), or make it impossible to access the vulnerable parts of the system (what is the reason for all kinds of firewalls, and this direction of work already reached its limitations without producing anything close to a desired effect), or to reduce the amount of damage that can be caused by a successful attack on a vulnerable part of the system (what is the only direction left that is still worth pursuing).

Obviously, the first thing that comes to mind is to separate parts and provide interfaces that do not propagate trust unnecessarily between those parts. Subsystems running under minimally necessary privileges, privileges separation within parts of subsystems, etc. are already used in various secure setups, however there is a lot left to be done, mostly in standardization and implementation of those ideas. Too bad, none of that activity looks attractive enough for bigwigs, and the theory and amount of work involved is hard to explain to people that can only understand network security through bad metaphors.

Another issue is DoS tolerance. This is a very complex problem because DoS by their nature can not be counteracted without a risk of becoming the source of another DoS -- for almost every imaginable DoS there can be a worse DoS that relies on the response mechanism that is supposed to react on the first DoS. Simulate a DoS against some host, and see that host "responding", creating a real DoS. This means that DoS can be only counteracted by proactive measures, such as SYN floods being prevented by the use of cryptographic SYN cookies. Also elimination of a large number of vulnerabilities in comsumers' computers goes a long way toward decreasing the effectiveness of DDoS, a kind of attack that has no possible response of the victim that is not exactly the same as the goal of the attacker -- making the victim unaccessible to the legitimate users.

Detection of the attacks is of much less importance than what it usually assigned to it. In fact, any attack detection that does not go through a human system administrator has a potential of being a part of an attack -- in most of cases the automated response to an attack can produce a more dangerous attack by itself than the attack being detected (similar to DoS response issue), this is a situation when not knowing about the attack is much better than knowing. Even with humans involved, a system that will cry wolf every ten seconds will become at most a nuisance.

Same in a large part applies to intrusion detection -- even a _successful_ attack may still be less dangerous than the heavy-handed automated response to it. The real value of intrusion detection is in allowing the sysadmin (or sometimes an automated system) to revert the compromised subsystem to pre-attack state, keep the whole system consistent after this change, and replace the vulnerable part with an alternative that supposedly does not have exactly the same vulnerability, allowing the time for analysis and elimination of vulnerability. AFAIK, absolutely nothing is done in the direction of automating this task, and none of the "security" companies provide this kind of service. This is a very valid area to apply new research, development and businesses' efforts, however it doesn't look like anyone interested in

Re:Article is FLAWED! No Mac OS (9.x, 8.x) hack ev

maybe its because noone bothered trying =-)

this coming from someone that has been begging his boss for a mac laptop for 2 months. mini-me sold it, i want one.