Preserve us from Sharepoint

It's a web server.

In a world blessed with Zope, Plone, wikis, and other content management systems, I'm amazed that anyone would pay money for Sharepoint. They should pay you to adopt it because of the hideous negative value that is vendor lock-in.

It's a web server.

It will cost a fortune to customize to your needs. Just as any other system will. Only you will continue paying for it until you die. Then someone else will pay for it. Unless they decide you are moving to whatever else they want to sell you. Then you will pay for that whatever else until you die, at which point someone else will take over paying for it.

It's a web server.

Ooh, it integrates with our hopelessly vendor-locked-in authentication system? (AD) pam_ldap, folks.

It's a web server.

It's a web server that will be bought by people who look around for Microsoft products to buy, rather than needs to address. Because if you'll buy that, you'll buy dog turds in a can so long as it comes from them.

Repeat Rant: Do not Perform Arithmetic on Ordinal Numbers

I've previously written on the topic here .

Today I attended a meeting of the Agora, a monthly symposium on networks and security at the University of Washington. It was my first meeting and I was impressed. Lots of local infosec celebrities. The last speaker jumped on my last nerve (as my housemate puts it), though.

Andrew Macpherson presented a draft of an unpublished paper on a Threat Calculator he and others developed at the U of New Hampshire as part of an outfit called Justiceworks. The dude has some background; during 9/11 he was at Dartmouth College's Institute for Security Technology Studies and did some work for the Feds during the aftermath. Also in his favor is the correct use of the term "Threat" - at least per Richard Bejtlich, who is smarter than me and probably you. A threat is an entity with the intent and capability to attack.

Where he goes wrong is basically...his whole project. He takes a bunch of factors (24, I believe) to describe threat-actors (ok, he waters down the term "threat" - deduct a couple points), assigns each factor a rating on a scale of 1-5, and adds them up. Highest possible score is 140 points.

Where do I begin.

Numbers used to rank items are called Ordinal Numbers. Apart from Set Theory, you can't do arithmetic on ordinal numbers. Why not? Think about it. There is no precise relationship between numbers on a ranking scale. 1 < 2, but 1 is not half of 2 nor is it one less than 2. One is just in a position to the left on the scale. It might help to think of "First, Second, etc." instead of "One, Two, etc." We are so used to "regular" numbers that it's easy to make this mistake, but basing any decisions on this fundamentally flawed reasoning is a blunder. And the seeming precision - "hey, we quantified this shit! gives resonance to the blunder. You just painted a qualitative assessment with quantitative coloring.

You can't do arithmetic on numbers where the units are different. 5 gallons plus 3 hectares = ???

There's a problem of weight. Is a 5 for technical capability = a 5 for National/Cultural Stability? They have the same weight in the calculator. Funny that all 24 factors are exactly equal in importance.

There's a problem of scale. Even given the appropriateness of addition for this exercise, is a 5 really only 4 places more than a 1? This scale encompasses the PRC and my technologically illiterate neighbor. Sure, something close to 140 is scarier than something close to 24, but what's the scare curve look like? Does the pucker factor zoom skyward as you cross 100? 50?

These combine in unwholesome ways to undermine the whole exercise. The Netherlands scores high in technical aptitude, national stability, infrastructure similarity (they use similar control systems so they know how to attack them), etc. All of which is totally blown away by low scores in ideological antagonism. Yet overall they probably score higher than outfits that WILL commit serious cyber attacks some day.

Finally, there's the fundamental problem of pulling numbers out of your ass 24 times and then munging each together and gazing lovingly on the results like it means more than a single number pulled out of your ass. Some of those numbers are intensely debatable, such as those relating to the motivation of organized crime to conduct strategic cyber attacks. Maybe they will rise to that level of extortion some day. Maybe not. Who knows? I don't - and they don't either. Write me an assessment arguing for one or the other, and include your reasoning. Don't sink your reasoning in a morass of bogus numbers (and take any prospect for debate with it because you can't argue with something as scientifically sound as a number!).

So why does this matter? The tools we use to help us think affect the decisions we make. The pervasive use of Powerpoint at NASA helped doom the shuttle Columbia. (Search "Columbia Powerpoint" for a host of articles detailing the official findings of the accident report, which faulted NASA for discussing the risks via Powerpoint presentations rather than technical reports.) Bad tools, bad decisions. If common sense will rescue us from dumb conclusions reached by this approach, the exercise is merely meaningless. We should have just gone with common sense at the beginning. But I would be very worried if this process really drives any actual resource allocation. "Gambia got a higher rating than Senegal, so prep some wargames..."

Sguil tricks: mass catagorization of events through database queries

If you don't want to catagorize events one by one (or aggregate by aggregate) via the sguil client, you can manipulate the database directly. This is useful if you have tens or hundreds of thousands of useless alerts. My personal best is 1.6 million.

The first step is to stop sguild. It prefers to think it's the only thing acting on the database at a given time, and will be confused if you alter the db while sguild is running.

Then you run a sql query as in the following example:

update event
set status = (desired code) where
status = (current code - usually 0 for this kind of task)
and (condition = whatever, eg signature = 'ICMP PING NMAP')
limit (some limit on the number of times you want this to run)
;

The status codes are a little tricky - I read the source of the sguil client to dig up the following:

"Cat I: Unauthorized Root Access" 11

"Cat II: Unauthorized User Access" 12

"Cat III: Attempted Unauthorized Access" 13

"Cat IV: Successful Denial of Service Attack" 14

"Cat V: Poor Security Practice or Policy Violation" 15

"Cat VI: Reconnaissance/Probes/Scans" 16

"Cat VII: Virus Infection" 17

So if you want to catagorize a real time event (status currently 0) as Cat VII, the query fragment is

update event set status = 17 where status = 0 and ....

I use a different system. I'm not interested in taxonomy, I'm interested in tasks. That is, do I have to deal with this or not? I am the remediator, if remediation is to be done. So I don't need to capture the type of incident. I KNOW that. I also won't run down every event, but I don't want to lie when I dismiss something without conclusive investigation. So I have two catagories for honest punts. This way they won't get buried in the False Positive sections.

My system is Cat I False Positive - no action required SQL update event set status = 11

Cat 2 False Positive - action required (tune rule, suppress alert, mitigate condition (i.e. reconfigure noisy host))set status = 12

Cat 3 True Positive - no action required (harmless worm attacking patched host)set status = 13

Cat 4 True Positive - action required (possibly should escalate F9)set status = 14

Cat 5 Not sure, not worried (Punt)set status = 15

Cat 6 Not sure, worried (Punt)set status = 16

Do not set status = 2 - that's escalate! This gets inserted into sguil client, slowing things down!

Stoopid MS tricks #2

Applications should get their time from the operating system.

There, that wasn't so hard, was it?

Enter the change to Daylight Savings.

If you use Outlook, and set an appointment for 11:00, Outlook will change that. I can only think this is an implementation of "Do What I Mean" technology, which always fails.

11:00 is 11:00. There are no large or small values of 11:00. If I am to meet my boss at 11:00, that is the time I am to meet him. My appointment book should not adjust this. If my system clock is wrong, my reminder popups will pop up at the wrong time; that is my lookout.

When Congress changed the DST date, it caught a lot of software companies. Well, mostly Microsoft. Linux and the BSDs have a simple (extensive, but simple) Time Zone file. Tell the machine where you are, and it will adjust the local time based on that file. Simple. One slashdotter tried to make the case that Windows was easier to use because all he had to do was apply a patch to the OS, a patch to the application, and a patch to the Exchange server and he was done. He lied, as I'll describe below. But he tried to contrast updating the Time Zone file on his linux server. He had to do it in three places, because he was running two servers with chroot jails. That's a feature where you can isolate a service to it's own file system. If the service is hacked, the attacker is potentially limited to that file system and can't make mischief elsewhere. I'm not sure why you'd complain about having the option to use a security feature that ISN'T EVEN AVAILABLE on Windows.

Back to Windows.

There is no DST patch for Windows 2000 - you have to manually edit the registry. There are Windows fanboys who say it's impossible to maintain a system if you have to manually edit a text based config file. Manually editing a convoluted, monolithic database designed by idiots is fine, though.

If you do apply the patch to OS, application, and server, your appointments between 3/11/2007 and 4/1/2007 will get adjusted and will be in an unpredictable state. If you are using Windows XP and Office XP, and do not apply the patches, you will be in a predictably bad state as the appointments get moved an hour ahead. Why? Did 11:00 suddenly become something different? Did we want to meet at UTC -7 rather than 11:00 ? I ENTERED 11:00 AND THAT'S WHAT I MEANT.

Even if it gets things right, it will resend meeting invitations for some goddam reason.

Deeply disturbing and disturbed.


Let's say it again: applications, if you need to know what time it is, ask the OS.

Update: 2007-04-13
Ok there is some point to recording an appointment in UTC +/- offset for a groupware application used by a global organization. This was still a debacle and when MS tech support can't tell you what the state of your appointments is going to be after applying their provided fixes, then the overall point - they suck - stands.