Jon Udell: Security

ACLs don't scale, accountability does

2002-08-28T09:47:47-05:00

On Monday I got to meet Jamie Lewis face-to-face for the first time, and we had a great talk about a lot of things. We're both looking forward to the upcoming Digital Identity Conference. Chatting about PingID and XNS, Jamie quipped that for longtime industry watchers like us, it becomes necessary to qualify acronyms with date ranges. So for example: XNS₂₀₀₀ versus XNS₁₉₇₅.

On the subject of security, I aired my concern (shared by acquaintances at Baltimore Technologies) that ACLs don't scale. Even if we can layer a permissions matrix on top of web services, the combinatorial explosion of that matrix will create complexity that nobody can understand or manage. The example here is from Zope, but we've all done this -- and it's unthinkable to do it for thousands or millions of rows and columns.

Jamie agreed, and cited a speech by Dan Geer, who's CTO of @stake, in which Geer advanced the notion that ACLs don't scale, but surveillance and accountability do. Here's an excerpt from the full text of the speech Geer made to the Security Industries Middleware Council (SIMC):

If the access control matrix eventually scales out of reach, what then? I submit that where the geometric scaling of access control will kill it in the end, accountability stands ready. This is not to say that I like pervasive, universal accountability, per se, but the only reason a free society works is that you can pretty much do anything though if you screw up badly we will find you and make you pay. Accountability is like that, i.e., it is a log processing problem. When it comes to processing logs, Moore's Law is on your side. Observability is on your side as it puts off the deductive costs to later when you need to invest in making them, and you can probably use grid computing as a log processing tool since the web search engines have got that pretty well worked out. Because disk prices fall faster than CPU prices and because network prices fall faster still, log information storage and availability are just not problems.

I'll buy that. As Jamie points out, this mirrors how things work in the real world. No ID and access-control mechanism can prevent me from committing a crime. But an eyewitness or a surveillance camera can hold me accountable.

Telling stories about web services security

2002-08-27T10:20:03-05:00

I spent yesterday in Boston at a joint W3C/OASIS Forum on Security Standards for Web Services, part of the XML Web Services One conference. (If you're going there this week, note that although the conference page says the event is at the Seaport Hotel across the street from Boston's World Trade Center, it is in fact at the WTC.)

The morning was dedicated to what we awkwardly call "use case scenarios" -- more colorfully, storytelling. The storytellers were from publishing (Lexis/Nexis' Chet Ensign), aerospace (Boeing's Steve Whitlock), finance (Niteo Partners' Kevin Cronin), and government (the U.S. OMB's Kim Johnson). The stories were about electronic publishing, search and retrieval of engineering documents, collaboration with parts suppliers, corporate cash management, and government recordkeeping. The moral of each story, and of all the tales collectively, was a laundry list of requirements for web services security standards. This was a terrific format. It reminds me of Alan Cooper's persona-driven methodology for software specification. I'd be interested to know much of the original design of WS-Security and SAML was guided by stories as specific as these. My guess is not enough, but I'd like to be proven wrong.

One of the requirements that came through loud and clear was "make it buildable and understandable." Chet Ensign, for example, pointed out that while big players like Lexis/Nexis can "program their way out of any mess that gets made" ¹, the weak links in the chain are the smaller fry -- customer-partners who lack development resources, and need turnkey solutions.

¹ Not, he added parenthetically, to imply that a mess is being made. He thinks the standards process is working pretty well so far.

The contrast between Ensign's digital rights requirements, and Cronin's financial requirements, helped to clarify the risk/value continuum along which security solutions are arranged. Electronic publishing doesn't (yet) involve the kinds of high-value transactions that compel Cronin to anticipate and solve every imaginable kind of spoofing or denial of service attack.

Lexis/Nexis, on the other hand, faces massive rights-management challenges. When the Supreme Court ruled in the Tasini decision that freelancers hold electronic rights, the ownership of tens of thousands of documents in the Lexis/Nexis archive suddenly changed.

For Boeing, with a huge investment in LDAP and CORBA, the question is how to avoid what security architect Steve Whitlock calls the Jurassic Park syndrome. Remember the scene in which the characters scramble down from their tree-bound crashed car, only to have it fall on top of them? ("Well, we're back in the car again.") Whitlock, who doesn't want to end up there again, points to the dark side of web services security: we've been there before, and wrapping angle brackets around everything doesn't change the name of the game.

Whitlock (who, apropos of nothing, colorfully describes an airplane as "five million parts flying in close formation") also gave a sobering assessment of what better identity management could mean to an organization like Boeing. The yearly help-desk bill for resetting lost passwords adds up to over one million dollars!

The afternoon was a whirlwind review of specs: WS-Security, SAML, XKMS, XML Encryption, XML Signature, and several rights-management proposals. Although I've read many of these, the overview was really helpful. Rights management aside, it became clear -- as Netgrity's Prateek Mishra noted in the Q and A -- that the rest of the specs are pretty cleanly partitioned and complementary to one another. But, he asked, what's the story with Rights Language and XACML, which two different OASIS committees are pursuing? "Will the one with the more lawyers win?" Entegrity's² Hal Lockhart, who presented the two specs, noted (as did Jamie Lewis) that DRM isn't just a political train wreck, it's also a poorly-defined space that nobody really knows how to partition.

² Note to would-be startups: tenegrity is apparently still available, being used at the moment only as a misspelling of tensegrity.

Kudos to the W3C and to OASIS for this well-conceived and well-executed forum. It definitely helped me see the big picture developing. As somebody said during the wrap-up, web services security -- without which, everybody agrees, web services will be dead on arrival -- isn't a binary, all-or-none deal. In most respects, it seems likely we'll soon have enough of a framework to get started. The elephant in the room, as Scott Bradner (of Harvard and the IETF) did not hesitate to say, is key distribution and management -- not a new problem of course, but a huge obstacle. Bradner sees no way around it. VeriSign's Phillip Hallam-Baker begs to differ. He thinks XKMS is the breakthrough we desperately need. But that's a story for another day.

"Sir, were there reasonable alternatives at the time?"

2002-08-14T13:59:54-05:00

Having recently found his voice, Ray Ozzie is also finding that he has a lot to say -- both on his his blog and elsewhere. In an article today on news.com (the decorated version is better), he concludes:

Someday, some shareholder is going to lose quite a bit of money because an electronic message was "sniffed," or "spoofed." Someone's health or financial records are going to get into the wrong hands. A design will be compromised; someone will get hurt.

And at that point, network television cameras are going to be focused on a lawyer who's asking a company executive, or a government official, "Sir, were there reasonable alternatives at the time?"

(Also today, on his blog, Ray cites Charles Mann's extraordinary Atlantic Monthly piece on Bruce Schneier, which I mentioned here a couple of weeks ago, and which is now -- happily -- online. It's crucial for more people, and especially non-geeks, to understand Schneier's philosophical transformation and current thinking.)

For me, the most salient fact about Ray's career is that he has chosen to tilt at not just one windmill, but two: collaboration and security. We tend to preach both but practice neither. Partly that's because we care less about these things than we say we do and believe we should. Do you communicate with coworkers as often and as well as you'd like? (If not, why not?) Do you switch from your cordless phone to a landline when ordering a pizza with a debit card? (If not, why not?)

Partly, though, it's a matter of architecture. The path of least resistance rarely coincides with the path of highest value, but given the right architecture, it can. As Ray has discovered, blogging represents an architectural solution to some longstanding problems that have plagued public online discussion. Groove, likewise, aims for an architectural solution to secure collaboration. Since "security" and "collaboration" are contradictory and almost mutually exclusive from IT's perspective, that's quite a challenge. But it's inescapable.

Cyberspace is not really borderless. More accurately, it's resolving into sets of discrete, sometimes overlapping, sometimes concentric spaces. In these spaces, people and documents gather for moments, days, or years. Requirements for confidentiality run the gamut. Public and semi-public spaces need to advertise their existence, in order to promote awareness globally or within various groups. Private spaces need to be, well, private. Everywhere, strong identity (or at least strong pseudonymity) should be a given.

Weblogs don't yet offer an architectural solution to secure semi-public collaboration. Wrapping SSL and passwords around your blog can work, but the administrative hassles involved push this option far off the path of least resistance. Groove-style "always-on" and "complacency-immune" security sounds appealing, but it's not a solution yet either. It works by invitation only, and that cuts across the grain of blogging which thrives on linking and serendipitous discovery:

A collection of weblogs isn't just a pool of documents. It's also a knowledge network, where at each node human intelligence performs the routing function. The network's architecture is publish/subscribe. Its protocol is RSS (Rich Site Summary), a simple, powerful, and popular application of XML. Bloggers tune into other bloggers' RSS channels; they select and react to items flowing through those channels; they post items that also flow out on their own RSS channels. It's a kind of Krebs cycle where the input is individual thought and the output is group awareness. [Google and weblogs: best hope for KM]

So what's the architectural solution that will make the cells of this awareness network semi-permeable in the appropriate ways? Perhaps translucency is part of the answer. I'm not smart enough to see the endgame here. But I'm sure glad to see that Ray's on the case!

Addendum: The phrase "Patterns of cooperation without vulnerability" seems to capture the essence of the challenge.

Patterns of cooperation without vulnerability

2002-08-09T10:50:47-05:00

Collaxa's Edwin Khodabakchian (whom I have interviewed -- small world -- for an InfoWorld story on web services orchestration) is writing a blog that's a nice example (along with Ray Ozzie's) of how a tech exec can use this medium to project a persona, clarify a mission, and float ideas that may provoke useful reactions.

The path that led to my discovery of Edwin's blog (which needs an RSS feed, by the way) is typical of the serendipity and triangulation that pervade the blogosphere. I subscribe to Loosely Coupled, which today cites a great article by Adam Bosworth arguing for coarsely-granular web services that do not correspond to programming-language objects. I'd seen that article in June when it first appeared, but clicked through to Loosely Coupled anyway in case this was a sequel I hadn't seen yet, and that's how I found Edwin's blog.

Edwin today notes similarities between the E language and Collaxa's ScenarioBeans. That reminded me (in a James Burke kind of way) of a conversation with Paul Prescod about E's capability-based security:

E has no pointer arithmetic. E has no mutable statics. E has an API carefully thought out to prevent capability leaks. This would make it a capability secure language for single-processor applications. But E goes a step further. It takes the concept of a secure, unforgeable object reference and extends it to distributed objects:

- The communication links are encrypted. Third parties cannot get inside the connection.

- The objects are unfindable without a proper reference received (directly or indirectly) from the creator of the object. You must have the key to unlock the door.

- The objects are authenticated. No object can pretend to be the object you are trying to contact.

...

Java introduced the concept of a sandbox for its applets. The sandbox is a space in which no access to dangerous powers is available. To give greater flexibility they introduced the security manager and the ID badge architecture--if the user concludes the applet came from a "trusted source", the applet can get your ID badge and roam wantonly through your system.

A java application that runs in a sandbox is called an applet. An E emaker that embodies a full program is called a caplet. Caplets are not trapped in sandboxes. Instead, you may think of caplets as being trapped in safety deposit vaults. The caplet is started inside the vault, surrounded by hundreds of safety deposit boxes--but not one of the boxes is accessible unless and until you give the caplet a key to that particular box.

...

In the end, one may say that normal object programming is about patterns of computation and abstraction, whereas programming in E is about patterns of cooperation without vulnerability.

What an evocative phrase! "Patterns of cooperation without vulnerability." Selective disclosure is an aspect of it: we want to be able to identify ourselves in limited ways for specific purposes. Blogs are another aspect of it: we cooperate in this medium at a respectful distance, by mutual consent.

Homeland Insecurity

2002-08-02T17:58:44-05:00

The September issue of the Atlantic Monthly has a remarkable special report called Homeland Insecurity (not yet excerpted online). It features none other than Bruce Schneier. I am delighted to see Schneier's philosophical transformation -- from crypto-infatuated fortress builder to pragmatic watchguard -- detailed in a mainstream magazine. People who would never have read Secrets and Lies will read this excellent article, and I hope will ponder Schneier's message:

- Security technologies are brittle

- When they fail, they fail catastrophically

- Human judgment needs to govern the security process

The article concludes with a description of Counterpane's command center:

Highly trained and well paid, these people brought to the task a quality not yet found in any technology: human judgement, which is at the heart of most good security. Human beings do make mistakes, of course. But they can recover from failure in ways that machines and software cannot. The well-trained mind is ductile. It can understand surprises and overcome them. It fails well.

Mixing long stretches of inactivity with short bursts of frenzy, the work rhythm of the Counterpane guards would have been familiar to police officers and firefighters everywhere. As I watched the guards, they were slurping soft drinks, listening to techno-death metal, and waiting for something to go wrong. They were in a protected space, looking out at a dangerous world. Sentries around Neolithic campfires did the same thing. Nothing better has been discovered since. Thinking otherwise, in Schneier's view, is a really terrible idea.

OASIS and WS-Security

2002-07-23T10:43:41-05:00

Under the OASIS umbrella, more folks are linking arms to support WS-Security:

The OASIS standards consortium has organized a new technical committee to advance the WS-Security specification. WS-Security provides a foundation for secure Web services, laying the groundwork for higher-level facilities such as federation, policy, and trust. Through the open OASIS process, providers and users will come together to extend the functionality of WS-Security, which was originally published by IBM, Microsoft, and Verisign. [OASIS]

I plan to attend a forum ("co-sponsored by OASIS and W3C") in Boston on Aug 26 to hear more about this. The picture is still quite fuzzy, frankly, but it does appear we're in a market-making let's-all-work-together phase.

PS: Maybe that shouldn't be surprising. According to today's NY Times, we are wired to cooperate, and doing so lights up the pleasure centers of the brain.

Web services security and XML pixie dust

2002-07-02T11:14:48-05:00

It's an article of faith right now in the web services realm that security is the major roadblock. We're all sitting around drumming our fingers on the table, the story line goes, just waiting for consensus to emerge from that cloud of dust the standards-makers are kicking up.

When I look at the proposed standards, though, I see a bunch of familiar stuff. Name/password authentication, Kerberos, access control lists, PKI certificates, signing, encryption. All this has been part of the web forever, though admittedly PKI and Kerberos haven't really gotten over the activation threshold.

I don't think its a bad idea to wrap XML around this stuff. But I'm not convinced that will solve the hard problem. What's hard is that security technologies are just a royal pain in the ass to deal with. I was sure, for example, that client certificates would be widespread by 1997 as a mode of authentication to websites, and as a single sign-on solution. Today I'm one of a handful of people who have ever bothered to acquire a client cert.

Are we just trying to XMLize Kerberos and PKI and ACLs because we hope the magic pixie dust of XML will make the pain go away?

Triangulating on k-logging for homeland security

2002-06-18T12:57:27-05:00

Hey, this was top news in my own magazine. Cool!

Knowledge management offers hope for homeland security. Technology to facilitate people-based networks [InfoWorld: Top News]

Triangulation. Gotta love it.

Blogging and homeland security: connecting the dots

2002-06-12T08:19:47-05:00

Sunday's New York Times featured a disturbing story on the IT culture clash between Google and the FBI:

Data is compartmentalized so that case information compiled in Phoenix might not be accessible to agents in Minneapolis, and retrieval of the full text of case reports is not possible. Devised for the quick retrieval of the names of known suspects, the network can be searched for terms like "aviation" or "schools, " but not "aviation schools" -- in other words, precisely the kinds of phrases that may have made it easier for law enforcement agents to connect the dots and discern the patterns of activity leading up to Sept. 11 attacks.

Mr. Schmidt of Google said that government had characteristically been slower than industry to adopt new information technology and to link its multitudinous information networks. This leads to a condition that the industry calls "stovepiped" information, which means that data is warehoused in separate, unconnected silos. That is partly by design, Mr. Schmidt said, as a precaution against wandering hackers. "They don't want a network interloper to come in and do a lot of damage to other computers." [New York Times]

I'm sure it's true, though no-one can come out and say so, that the FBI are among Google's most intense users. I hope a private network of weblogs will be the next step. Valdis Krebs has a new paper that suggests how social network mapping can be used to thwart terrorists. He writes:

To gather the data for mapping these networks, individually and as a group, requires much cooperation between departments, agencies and countries. This requires vertical, horizontal, and diagonal links between all of the investigators on the case -- in other words, our network needs to be as good or better than enemy's! [Valdis Krebs]

Maybe I've just got blogs on the brain. But like all stovepiped IT organizations, the FBI's will not be rebuilt anytime soon. The way forward is a human awareness network layered on top of those stovepipes and connecting them.

Such an overlay network needn't, of course, intersect with public blogspace. But purely internal use of existing low-tech weblog software could reproduce the same effect: a knowledge network with human routers. Would it be perfectly secure? Of course not. But in the end, what's the greater risk? That the enemy might discover we had connected the dots and have to change its plans? Or that we have no hope of connecting the dots at all?

Managing credentials with Counterpane's Password Safe

2002-05-18T15:50:56-05:00

Seeing Bruce Schneier at ETCON reminded me that I've been meaning to mention Password Safe, a really simple and useful tool available for free from Schneier's company, Counterpane Labs. It's a GUI app you use to securely maintain a database of passwords.

The version I'm using, 1.7, runs on Windows. Version 2, an open source project, is apparently still also for Windows only, though I guess this could change.

I've been holding my breath for a long time waiting for single sign-on. After a while I started turning blue, and writing down passwords, which felt incredibly stupid but was unavoidable. Password Safe makes that necessary evil feel a lot less stupid.

The database is Blowfish-encrypted. Each entry has a title (e.g., "Amazon"), a name, a password, and a comments field which I find quite important for recording the context of a given credential (e.g. "3rd sample user for test system version 5"). Copying a username or password to the clipboard, for subsequent pasting into an authentication dialog, is easy. There are some thoughtful details: you can have the app clear the clipboard when it's minimized, and it won't ever display any passwords on the screen unless you override a default.

The whole kit -- executable, data file, and helpfile -- amounts to under 400K, and since there are no registry dependencies it can easily be moved back and forth between your desktop and laptop.

Nothing earthshaking about this. Just a simple and practical tool, from the most pragmatic security pro in the business.

Security, insurance, and hard realities

2002-05-15T20:23:52-05:00

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.

PKI: no silver bullet, but not worthless either

2002-05-15T02:35:08-05:00

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.

PKI and SSL: house of cards?

2002-05-14T20:15:12-05:00

Richard Forno, chief security officer for ShadowLogic, takes a dim view of the PKI industry. "Digital trust is a slick marketing tool put out by the PKI industry. DoD wants smartcards with certs by 2004. What's the value of that? I don't know. They don't know."

After contributing to an article on these issues, he thought more about the implications of the MS/VeriSign cert compromise:

On March 22, 2001, Microsoft issued a Security Bulletin (MS01-017) alerting the Internet community that two digital certificates were issued in Microsoft's name by VeriSign (the largest Digital Certificate company) to an individual -- an impostor -- not associated with Microsoft. Instantaneously, VeriSign (a self-proclaimed "Internet Trust Company") and the entire concept of Public Key Infrastructure (PKI) and digital certificates -- an industry and service based on implicit trust -- became the focus of an incident seriously undermining its level of trustworthiness. This incident also challenges the overall value of digital certificates.

Forno agrees with Schneier: If you don't address processes and people, you have no security. For example, a notary only verifies the signature on a document, not its contents. So the real-world trust invested by them is unreliable. Garbage in, garbage out. You don't need to be a cyberterrorist to take advantage of this. You can be a Nigerian scam artist.

Why, he asks, don't certs work like credit cards? Why don't they expire (in a timely fashion)? Passports and drivers licenses expire in a few years. Root certs expire in 2025, 2028, 2037. (True. I just checked my MS root certificate: expires 2020.)

Why, he asks, would you trust a 5-year-old dot-com with your identity, rather than a brick-and-mortar financial institution like CitiBank? Most people, he says, would rather trust the latter. The Digital Identity weblog made this same point recently.

Forno recommends: Ellison and Schneier's Ten Risks of PKI.

Well, it's all true. PKI and SSL do not add up to an e-commerce silver bullet. There isn't one. Every day, credit card numbers shielded by high-grade security land in web-exposed flat files that Google can find. As Bruce Schneier likes to say, it's the liability limit on Visa cards and not SSL that props up e-commerce.

Will this chicken-and-egg situation ever resolve? I guess I'll keep on signing my emails anyway.

SOAP security and external underwear

2002-04-09T23:01:32-05:00

I'm sure Paul Kulchenko will soon fix the SOAP::Lite vulnerability that was just noticed. This episode got me to wondering, though, about the original rationale for the SOAPaction HTTP header, and what can or should be done to make filtering SOAP traffic workable. Several years ago, one of the original SOAP FAQs, from DevelopMentor, said:

Since SOAP packets declare their "intent" by publishing interface and method names in the HTTP header, it is possible for firewalls to perform filtering based on this information (the SOAP spec states that implementations must verify that this information must match the corresponding headers and tags in the SOAP payload, otherwise the call should be rejected).

Here's what the SOAP spec itself has to say on the matter:

The presence and content of the SOAPAction header field can be used by servers such as firewalls to appropriately filter SOAP request messages in HTTP.

Things didn't turn out quite that way, though. No consensus as to the security role of the SOAPaction header is evident among firewall experts [ 1, 2, 3 ], nor among XML protocol experts [ 1, 2, ].

Did the notion advanced in DevelopMentor's FAQ -- that SOAP packets would declare intent by publishing interface and method names in the HTTP header -- make sense? At the time it seemed reasonable to me. But now, I wonder if a SOAPaction policy isn't rather like the scene in Bananas where the newly-installed dictator declares that "everybody must wear their underwear on the outside, so we can check." The interfaces that a company chooses to expose to the world are, in the end, a policy that will or won't be enforced, regardless of the SOAP toolkits in use or the translations performed in a request pipeline. Enforcement will always require more than checking for underwear on the outside.

Sure, opening and inspecting packets will slow things down. And then XML accelerators will be invented to speed things back up again.

Solving this kind of problem is much, much harder than anybody wants to admit. It means you have to inventory your software assets, manage change, and be able to clearly describe the interfaces between your network and the global network. The same was always true for CGI, though; it's no different for SOAP.

Standardizing one HTTP header may not really help much. What will is to enumerate all the RPCs that you support, and as we move to a more document-oriented style of SOAP messaging, to provide the schemas that describe those documents. There's no free lunch. But here's an encouraging thought. The uniformity of XML, and the declarative style of XML processing, may help us to define policies and create tools to enforce them.

myNetWatchman: neighborhood watch for the Internet

2002-04-08T15:22:15-05:00

Thinking about trust and social capital, in online communities, reminds me of the work of Lawrence Baldwin, the creator of myNetWatchman.com. As I mentioned in a column on broadband security, Lawrence takes issue with the attitude of personal firewalls toward the steady stream of malicious probes that they repel. That attitude can be summed up as: "Don't worry, this is just the background noise of the Internet, and we're shielding you from it."

Not so, argues Lawrence. In his vision statement he writes:

Every time your firewall or intrusion detection system logs an event, don't assume the source is the actual hacker. Think of it as a cry for help from a likely victim whose system has been compromised and is just being controlled by a hacker. It's easy to ignore attacks because they don't present an immediate threat — after all, we have a firewall. However, every compromised system is a real and immediate threat to the underlying Internet infrastructure since these systems could be used to attack others and/or to launch distributed denial-of-service attacks (DDoS), potentially incapacitating large portions of the Internet.

In light of these threats, I strongly believe that ALL attack events should be relentlessly pursued.

Lawrence's software reads your firewall event logs, and relays events to his central service, which collates them and automatically notifies the ISPs or organizations that are (usually unwittingly) responsible.

Here is one of Lawrence's success stories.

myNetWatchman is a brilliant use of a network of distributed agents, and perhaps an excellent business model in search of funding, if Lawrence is inclined to go that way. But fundamentally it hearkens back to something we all know in real life: we're safer when we watch out for one another. Good neighbors report trouble when they see it. If you saw somebody breaking into a neighbor's house, you'd report it. Well, we're all neighbors here in cyberspace. Lawrence's software makes it easy to report trouble.

2002-02-02T14:26:07-05:00

Hackers Hit Global Leaders' Summit. An invisible cyber assault has cut off access for the second day running to the Web site of the World Economic Forum, organizers of the gathering confirmed. [The New York Times: Technology]

See Cyber Attacks During the War on Terrorism: A Predictive Analysis, by Michael Vatis, director of the Institute for Security Technology Studies, for an interesting set of correlations between political conflict and cyber attacks.

2002-01-22T19:22:14-05:00

Column | Broadband Security. The Internet is an ideal collaborative environment for bad guys. Fortunately, it can work the same way for good guys too.

2002-01-18T19:42:52-05:00

Column | Dartmouth's Security Think Tank. We expect government to protect critical infrastructure, and it has promised to do so. I'm glad to see that, on the issue of cyber-terrorism, the government has started to put some of our money where its mouth is.

2002-01-18T17:44:01-05:00

Talk | Managed code and security. Because there's no safe memory or robust exception handling in C-based services, they are distressingly likely to surrender a root shell. It seems reasonable to suppose that this general class of problem could be ameliorated by the advent of managed-code-based services."