Archive for October, 2009

Securitas Vigilantiae Instantis Praemium

Posted in General Security, NSM, Why watch the wire? on 28 October, 2009 by Alec Waters

The inner title page of MI5’s authorised history shows one of the Service’s past logos, bearing the motto: “Securitas Vigilantiae
Instantis Praemium”, intended to mean “Security is the reward of unceasing vigilance”. This seems to me to be as good a motto now as it was seventy years ago.

An enterprise has numerous tools at its disposal to control what happens on its infrastructure. Some examples are technical controls (such as port filtering, or blocking access to certain types of website) and non-technical controls (such as Acceptable Use Policies, violation of which could lead to disciplinary action).

Controls like these describe what you hope should be happening on your network, which isn’t necessarily what is happening. Controls may have been:

  • Intended, but not actually implemented at all
  • Improperly implemented
  • Removed
  • Changed
  • Circumvented (intentionally or otherwise)
  • Or they may not be as effective as you’d have hoped (anti-virus is a good example).

Implementing a control and then leaving it to its own devices doesn’t seem like a viable tactic. Rather than believing it to be effective, we need to make sure it is effective through strategies like the collection of information and the (unceasing) vigilance to detail required to extract the greatest meaning from it.

By doing this, you can verify the effectiveness of your controls. When things go wrong, you can use what you’ve collected to help you understand what happened and how you can modify your controls to help prevent it from happening again.

Without vigilance, we have our head in the sand, hoping for the best. If our vigilance is not unceasing, Murphy’s Law dictates that something Bad will happen the moment we take our eye off the ball.

“Securitas Vigilantiae Instantis Praemium” hardly ranks as catchy, but it certainly hits the nail on the head. Well, one of the nails, anyway.

Alec Waters is responsible for all things security at Dataline Software, and can be emailed at alec.waters(at)

Information Escapology

Posted in General Security, Information Leaks on 16 October, 2009 by Alec Waters

Any sensible IT system isn’t going to store passwords in clear text, nor will it transfer them over a network in any fashion that makes eavesdropping feasible. Yet some days I get a nice list of user passwords emailed to me, a list created without the need for keyloggers, social engineering or psychic powers. The list is created by my own users, aided and abetted by the system that’s designed to protect their passwords, not leak them. Let’s see how the password goes on its journey from the user’s brain to my inbox.

It’s Monday morning, and Joe.User hasn’t had his coffee. He sits at his keyboard and tries to get the day started:

CTRL-ALT-DELETE… joe.user… jo3i5l33t… <return> … damn, failed login… try again… joe.user… <tab> jo3i5l33t… <return> …ah, I’m in!

The failed login was due to Joe missing <tab> the first time around – the focus didn’t move from the username field to the password field, so he tried to login as a user called “joe.userjo3i5l33t” with no password.

That’s not so bad, is it? Well, depending on how hard you’re listening to your network and your level of vigilance to detail, Joe’s password is well on its way to publication:

  • Depending on the audit policy in use, Joe’s login failure as “joe.userjo3i5l33t” will leave an impression in the event log of the local machine, and also the domain controller that processed the request. The log impression will contain the composite of Joe’s username and password because that was what he typed into the username field.
  • In my specific case, the domain controller’s logs are harvested at five-minute intervals into a security event correlator wotsit (a Cisco CS-MARS, in this case). Joe’s password takes another step closer to me.
  • Every day, the MARS emails a report of failed logins to me, primarily so I can spot (albeit retrospectively) things like brute-force login attempts. Most of the time the report lists innocent login failures, but today I have a bonus – Joe’s username+password combo.

So now I serendipitously know Joe’s password, thanks to the written record that now exists in several places (Joe’s machine, the domain controller, the MARS and my inbox).

There are other flavours of this leak:

  • Sometimes a user will omit their username altogether and enter their password in the username field. The login will fail, leaving the password in a log entry. It’s quite simple to determine the username that owns the password – the chances are, the next valid login to the same workstation will be from the user in question.
  • If there is a KVM switch in use, sometimes the user uses their credentials for system A when the KVM is actually showing them system B. System B’s administrators now have a valid login to system A.

So, only our diligent security admins are seeing this, right? They’re the ones who read these reports, and they’re the guys we trust, right?

  • Server administrators will be able to see the contents of their own eventlogs.
  • If emails are stored centrally for a period of time in line with corporate policy, the email administrators can potentially find this information.
  • The screen-scraping/email-copying malware on my PC might be sending this stuff to who-knows-where.

The point is that the scope of Joe’s password leak is potentially quite large (and may even extend outside the bounds of our own enterprise). The consequences of the leak will of course depend on who sees the information and what they do with it.

A diligent, trustworthy admin will force Joe to change his password at the earliest opportunity, rendering the leak moot. An evil admin will just use Joe’s password, given that Joe is the CEO and all. Perhaps I’d like to read his emails, or open that document called salaries.xls? Hmm, I wonder if Joe habitually re-uses passwords in other places? Does he have a GMail account? Or eBay? Amazon? I’ll be back in a tick, I’ve got some shopping to do…

Alec Waters is responsible for all things security at Dataline Software, and can be emailed at alec.waters(at)

net-entropy Sguil agent and wiki

Posted in net-entropy, NSM, Sguil on 6 October, 2009 by Alec Waters

The story so far:

I’ve written a basic Sguil agent that will upload net-entropy’s RISING ALARM messages into Sguil. You can download the agent here, and the config file here.

On a Sguil sensor that has net-entropy installed, copy the agent to wherever your other agents live (/usr/local/bin on my system), and the config file to where your other config files live (/etc/nsm/sensor1/ on my system). Then fire it up:

   -c /etc/nsm/sensor1/net-entropy_agent.conf

With a bit of luck, you’ll see the agent register in the Sguil client:

net-entropy sguilAnd we’ll start to see net-entropy messages appear, too:

net-entropy sguil eventsThe bottom right pane of the Sguil client will behave as it does for the PADS agent, and will show you the event detail:

net-entropy sguil detailSguil will correlate these events in the usual fashion, and allow you to right-click and say “Transcript” or “Wireshark”. It all seems to work pretty well!

Finally, the net-entropy project has a new wiki – it’s here. This is the place to go for the latest source code, which now includes a Paninski entropy estimator in addition to the original Shannon estimator. Have fun!

Alec Waters is responsible for all things security at Dataline Software, and can be emailed at alec.waters(at)