Recently in Security Category

Joel Rosenblatt describes methodology used at Columbia for tracking abuse complaints as automatically as possible.

Developuction: when a service or host intended for development gets pressed into production. Usually this is done in a reaction to some external event, and nearly always results in fail somewhere down the road. If sysadmins are lucky, it just means the service collapses under a load it wasn't designed to handle. If they're not lucky, it means that somebody took a shortcut that compromised security somewhere, and the box gets well and thoroughly pwned. This is nearly always the fault of the sysadmin and not the developer who wrote the code, or the manager who caused the service to be pressed into production.

Developuction is a fact of life for many system administrators, and points to one or more serious issues in their shops. For instance, they could lack professionalism. This is generally ignorance, which is sometimes willful. They could be not granted any authority over technical decisions, in which case management needs to understand why it is that professionals are hired. But ultimately, it's a sign that short-term answers are favoured over sustainable long-term stability. Sometimes shops get lucky with developuction, and later they run into trouble when this luck is confused with competence.

We've all done developuction at some point or another. Sometimes it really is the best way to solve a problem. The key is understanding when it's acceptable, and being able to properly analyze the risks involved. It helps if you've not treated the development machines as a place where processes don't matter because "it's just a dev box."

Actual conversation I just had with a new Windows XP box:

XP: O HAI U R NOT UPDATIN

me: yeah, I'd like to go upd-

XP: OH HAI U R NOT UPDATIN AND U HAZ NO AV

me: yeah, I was about to -

XP: O HAI, WOULD YOU LIKE ME TO UPDATE?

me: ok, so go upd-

XP: O HAI WOULD YOU LAIK A TOUR?

Dealing with Windows is just like dealing with an ADHD child who also has HIV and you have the cure except you can't inject it into the kid because it's whirling around in a circle showing you the new dance it just made up.

And then when you've just about caught it, some dude in a black hat walks in and shoots your ADHD HIV+ kid in the head and the kid turns into a zombie and tears your throat out just before turning all your other kids into zombies too.

Life with Windows: like life with zombies, only infinitely more exciting.

Interested in risk metrics in IT security? Matthew Rosenquist on the sad story.

Having looked into this (in a cursory manner) for Job Stuff, I can relate to the multiple bodies with different, competing metrics.

Article: "Why security and usability don't go hand in hand."

Wrong. In fact, so wrong I'll say it several more times. Wrong wrong wrong wrong wrong wrong. The most succinct way to say why is this:

If it isn't usable, it's not secure. If it's not secure, it isn't usable.

Not only do they go hand in hand, they absolutely must go hand in hand. These are not two axes that must be constantly balanced against one another. That view is outmoded and grounded in the idea that we make something secure by making it less usable, and you make it more usable by making it less secure. Why must that be?

Consider this: if something is "secure" but not "usable," what will those who need to use it do? Figure out a way to make it usable, which will almost certainly obviate whatever security measures were put into place. If something is "usable" but not "secure," well, that speaks for itself. Expect to see articles on pogowasright and security mags lambasting your laxness.

I'd say I can't believe this is even a question, but obviously it is, ergo I must believe. But I don't have to be happy about it.

I'd like your opinion on whether we need to be doing anything in particular in relation to the Conficker worm. Is it anything you guys are concerning yourself with?

-- my former manager in an email

I am honestly surprised at the coverage that the Conficker worm (aka Downadup or a few other names) is receiving.

It is a serious problem, and worthy of attention. So is any other worm. Its original form exploited a brutal vulnerability in Windows, one of those "here, kind sir attacker, I place all my resources at your disposal, please treat me gently" sorts of problems, and it exploited the problem fairly well, generating millions of infections.

But that vulnerability was fixed in October 2008. On our campus it could have been bad; in January I found nearly 200 machines lacking the MS08-67 patch. With some aggressive scanning and network disconnects, we had that number down to a handful of isolated machines by the time MS09-01 came out. We saw 0 Conficker infections, despite security policies and management attitudes that a pessimist would say haven't changed much after we got absolutely hammered by Code Red and Slammer. Two years ago, Storm was a genuine problem on campus, and every day we get dozens of notifications of one security issue or another.

This is not to say that our experiences with Conficker mirror those of the entire outside world. China's apparent infection numbers are a full order of magnitude greater than any North American or European country. Brazil and Russia have been vulnerable as well. But the North American press is approaching this as an apocalypse, when the figures just aren't there to back this up: total US, Canadian, and Mexican infections are less than half of Russia's.

Worldwide problem? Yes.

Serious issue? Yes. It's a worm, but one whose spread is mitigated by proper patching.

Problem for my co-workers? Not really. Keep pushing and improving your security policies, and you'll be all right.

References, in increasing order of technical complexity:

Wikipedia writeup

Verizon Business Security

SRI International writeup

An essential part of computer forensics is talking to the user. I talk about this in the presentation I gave to the campus technology conference last December and will probably be re-addressing that this year. A key thing to remember is that talking to the user is the beginning of your forensic process, not the end. Too many people are willing to take what our users say at face value - "no, I don't run P2P software," ok, so it must be something else. Sometimes it turns out that the something else was Skype or some television viewing software. Both of those are (or can be) p2p as well, but since they're not BitTorrent, people forget about them. This is not to say that we need to approach our users in a hostile manner, as some do - that is counterproductive. Rather, we need to take our time and doublecheck: "ok, so you don't use p2p, but this behaviour just started - what have you installed lately?" Sometimes that approach yields the answer you need. Other times, it's more digging. This post was brought about because we've been seeing a lot of alerts on possible Kraken activity on our network courtesy of our Snort sensor, but in the one response I've received, it was to say "oh, I reinstalled the workstation, so no problem." I'd even asked specifically if the admin could check to see if there was a problem, since I don't know how well this rule is working for us. Another admin did actually dig down, and the user's response was essentially nope, no p2p, but I just started using this software called UUSee to watch soccer games. Turns out there was a game on the same time we were receiving the alerts. I never claimed to be the sharpest crayon in the box, but I can connect two dots if they're put down for me.

This is as much for my own edification and future self as anything else. Three system / health monitoring tools of which I'm aware are:
Nagios and the unfortunately-named but always excellent companion nagiosexchange.

Lighter-weight tools are monit and mon. A friend of mine tried the latter and proclaimed it Good, although the names for both of those are pretty crap, especially mon. At least give it a cute tagline or something. Software authors should always google the names they're considering; think of somebody who sort of remembers the name but maybe not quite, but wants to find it again. If the mighty GOOG returns 10,000 hits, maybe your name isn't so good after all.

Standalone Sysadmin has links to a bunch of neat tricks you can play with SSH keys.

Andrew Hay started a good discussion of how to get started with an incident handling / incident response program over at the Security Catalyst forums.

There's lots of good information in there. As poster Dave Hull notes, academia is good for practising your IR stuff. There are both lots of intrusions, and lots of weird things that look like intrusions, but aren't.

Like some of the posters there, I've taken the SANS 504 course, although I'm not sure that I would characterize it as an in-depth introduction to incident handling. It is as much about how to avoid doing the handling in the first place as anything else, although there is definitely some good stuff in there on IR/IH.

I haven't checked out the NIST publications yet, although that's not the first place I've seen reference to them.