| |
 |
Wednesday, May 15, 2002 |
|
Security, immunology, and health
Steven Hofmeyr just gave a fascinating talk on immunological approaches to security. The basic idea is that you generate detectors, which are just bitstrings, starting from random patterns. Throw away the ones that match patterns in the self set. You're left with selectors for non-self. Give them finite lifetimes, and constantly regenerate them, so things stay dynamic. A key point about these detectors: they evolve within, and are specific to, local environments.
The real-world experiment: try to protect a LAN. Characterize patterns of communication: source, target, and service (SMTP). Each datapath is a string. Detectors are strings equivalent in length to these datapath triples (e.g. 20.20.3.1, 20.20.3.2, smtp). The test monitored 50 computers on a LAN. Each computer had a set of 100 detectors. False positives were less than 2 per day. Events detected: port scanning, address-space probing, stealth probing, failed intrusions, successful intrusions.
Real immunological systems suggest more sophisticated strategies:
- The B-cell adaptive response. Cells in your lymph adapt to recognize pathogens, in your lymph, according to Darwinian selection. We can imagine using a genetic algorithm to evolve our detectors.
- Migration of detectors. In immunological systems, cloning and distributing detectors is a rapid-response mechanism to a fast-spreading threat -- like a worm.
What about Schneier's issue of diversity vs monoculture? Two points. First, there's more diversity than you might think. Systems vary by patch level and configuration profile. Their vulnerability varies accordingly. That said, there is also a need to manufacture more diversity in software. There's research on having compilers do this. Mass-customizing software, with varying patterns of no-ops, might be one defense against buffer overflow. Maybe software needs to evolve introns -- that is, the mysterious inactive stretches of DNA
All this was a hopeful counterpart to Bruce Schneier's brutally cold assessment. Biological systems are incredibly robust. It's hard to make them fail; they tend toward health. That's clearly not true of computers, software, and networks. There will always be risk, and the need to manage it, but that needn't be the whole bleak story. Learning how to make systems inherently healthy is a great new challenge with, let's hope, a bright future.
9:54:32 PM 
|
|
|
Security, insurance, and hard realities
Here are some notes from Bruce Schneier's talk. Hard, cold realities. Microsoft and its peers don't care about security, he argues, because it's not rational for them to do so. As businesses, they shouldn't, because they're not liable for their practices. Schneier is running out of options, he says, and what he's left with is a two-pronged strategy. One, require businesses to use insurance to manage risk, just like businesses use it to manage all other risks. Two, beef up prosecution of computer crime.
I'm sure he is right. If we change the economic incentives governing security practices, like we've done in the case of environmental protection, then there will be change. Otherwise not.
Suddenly a company choosing an operating system gets handed two insurance policies -- here's what it costs if you use Linux, here's the policy for Microsoft. The math gets much more interesting now. Security will improve because the CEO will now care.
This has disturbing implications for small software companies. Is there another way? He doesn't see one.
8:23:52 PM
|
|
|
Out with the old, in with the new
Here was Rick Rashid's summation of the past and future of operating systems:
| out with the old |
in with the new |
|
| run programs |
event execution |
| file focused |
database focused |
| implicit data definition |
self-describing data |
| explicit resource management |
automatic resource management |
| program centric |
task focused |
| system behaves same for all |
system models user behavior and responds |
| deterministic |
probabilistic |
Sounds great. But I couldn't help wondering about whether we've really mastered phase one. I bought a new PC the other week. It came with Windows XP, which I'd never used. I decided to try it, so of course a few days later I was on the phone with an HP tech support guy dealing with my PhotoSmart printer. He dragged a bunch of skeletons out of the closet, including 386enh.ini if anybody remembers that. In the end he showed me how to use msiconfig to selectively disable and reorder boot-time services, and we "solved" the problem.
After a while we realized that we'd both been playing these games for 20 years. I wish we could say of today's systems that resource management is explicit and deterministic, but it doesn't really feel that way. If we haven't mastered explicit and deterministic, are we really ready for event-driven and probabilistic?
Cory is talking right now about the triumph of non-optimized systems. "Machines that are optimized for one purpose end up doing just that one thing," Cory says. This fails to account for unintended consequences. "When you are reliable, and when you optimize, you close the door on innovation," he says.
This is an issue of scale, of course. We want emergent behaviors to arise from loosely-coupled systems. At global scale, they can. But at local scale, reliability is an innovation that's still waiting to happen. It would be nice if the small pieces that are loosely joined worked well.
2:51:26 PM
|
|
|
PKI: no silver bullet, but not worthless either
John Robb's comment -- certification isn't worth doody -- overstates the case. Despite exploitable flaws in the PKI/SSL infrastructure, I would rather transact business with a company that has identified itself to some third party than with a company that hasn't.
I'd also much prefer to transact business with individuals who take the trouble to identify themselves to some third party. The assurance offered by my Thawte freemail cert, while minimal, is far more than what's available in typical email discourse.
Just because PKI has been oversold doesn't mean it should be underestimated. Groove shows us just how seamless the exchange of trust can be for users. Although it presumes a PGP-like model, it was built to be -- and in version 2.0 has become -- a system than works with enterprise and cross-enterprise PKI-based trust. The issues addressed by PKI aren't going away, and the technologies woven into PKI will play out in our lives one way or another.
2:35:08 AM
|
|
© Copyright 2002 Jon Udell.
|
|
