Eric Fitzgerald: "I get asked the question pretty regularly how to determine from the security log whether a user logged on using a smart card or not.
The short answer is, you can't be absolutely certain. The longer answer is, well, you can be pretty certain for the time being, especially if you're not running any non-Microsoft Kerberos code."Now, I realize that for some this question will sound like "Is plumbing an art?" or even "Is accounting an art?" However, I think now is not a bad time to ponder this one, again. You might recognize this post as being of the type "written_while_flying" :-) only more so since it is actually of a type "written_while_flying_from_Europe." :-)
It started from a CrateMaster 2000 joke about a CVSS. And then this comment came in: "CVSS is the same way. It tries to reduce something to a single number (or set of numbers) that is inherently complex. It gives the appearance of scientific legitimacy to something that is as arbitrary as a game or movie review. ("I give this vuln two thumbs up!!!")."
And then this: "The fundamental problem with cyber-security metrics is that the things we can
easily quantify are rarely interesting, and the things that are interesting are hard to quantify..."
On the other hand, many folks in our profession are sitting on huge piles of checklists and counting the days when security becomes a formal if unexciting discipline, reduced to a set of simple, and, well, not so simple, rules that everybody would need to follow (and some actually would). A science of sorts. Or a least a management discipline.
As I put it in my landmark :-) post on "Will Security Ever Be Done?" (also some discussion here) I find this complete transition rather unlikely. However, I think vuln scoring is picking a wrong battle for the "security is an art" types. Say whatever you want, but a well-define vuln scoring seems perfectly doable, even if not trivial. And CVSS is a quality effort to get there, with some results to show.
Now, on the other hand, something like incident response will never become formal and will not be reduced to just following a checklist (even though incident response checklists are immensely useful!), just as - analogy alert! - police investigative work will never be reduced to following a formalized procedure ...
How about making the next step along this road: are those parts of infosec which are akin to art immeasurable by definition (kinda like poetry)? This question should be left unanswered for now (esp. given that I am finishing this post at Mini MetriCon 2007)
A long, long, long time ago (eh, like, in 1997 :-)) Marcus Ranum said in his post "artificial ignorance: how-to guide": "... you build a file of common strings that aren't interesting, and, as new uninteresting things happen, you add them to the file." And then you watch for other log records, which are then presumably interesting. This introduced the concept of "negative" filtering i.e. looking NOT for what you know to be "good."
This technique is indeed extremely effective for finding "interesting" (i.e. unusual + actionable; see more, for example, here [PDF]) events in logs. I even wrote a few prototype tools myself - including filters such as "new log record type for this port", "new for this network segment", "new for this sensor", "new for this IP range", etc or even two-dimensional ones such as "new for this port and destination IP address" which worked really well. All approaches had adjustable timeout after which the tool would consider an event to be new (e.g. "new for this week", "new for this month", etc). However, few vendors chose to incorporate such analysis approach in their products (bizarre, isn't it?).
And now, 10 years later (!) somebody finally did. In his post on 'Finding Events that have "Never Been Seen" Before' Ron Gula (with Marcus Ranum standing over his shoulder, no doubt :-) ) talks about implementing this in his product. What took you so long? :-)
They say "Regardless if your event logs are from UNIX systems, router access control violations, wireless access DHCP logs, intrusion detection systems or so on, after a certain period of time, the same events tend to repeat themselves. This is because most of our networks run controlled and automated processes. With this in mind, finding out when something "new" occurs could indicate a security or administration problem. " Right on! There is more fun stuff in the follow-up post 'More on "Never Before Seen" Log Events'.
Now, VOIP security has been talked about for a few years; it started even before organizations started to deploy VOIP in greater numbers. Many folks like to say that “VOIP security is a disaster,” but usually they don’t explain how or why.
Given that I am closely involved in a log management business, I sometimes have those moments that I see logs everywhere. But guess what? Logs are everywhere! From a server under your desk to satellites to ship systems to personal electronics to telecom equipment to building control systems - logs are indeed omnipresent.
And, at present, such logs are never looked at. How often do you - or, even worse, a typical computer user - look at your Windows (Linux?) workstation logs? I am guessing: when something goes wrong. It is pretty much the same for most of the above logs. And that is how it always was - from the olde times of "The Cuckoo Egg" (and probably even from the times of the ENIAC) to today.
But - and here is the point! - it is changing now. My natural flow of log management shows us that people start looking at common firewalls and servers before they look at operational logs from, say, an elevator in their building, such log sources are out there. However, the time when people will start looking at most of the above logs - and not only after a problem rears its ugly head - is coming ...
Yes, I am being somewhat philosophical here at 21,456 ft, flying back from DoD Cybercrime 2007...
Despite this cheesy title, I am talking about something serious here. Many security solutions are being sold as "compliance solutions" nowadays (and there is nothing wrong with that). However, sometimes I can't help but chuckle (or, less often, roll on the floor laughing :-)) when I see a vendor make an especially tenuous connection between their offering and whatever compliance mandate or regulation (e.g. "our firewall is really a ... khmmm ... yes! a compliance solution, because it ... eeeeh ... helps you, you know, be compliant and stuff" :-))
However, there is one technology that has "compliance" written all over it: log management. Why am I saying this? Is it because LogLogic pays me? No, this post is actually inspired by this paper here. Two quotes illustrate my point:
1. "By reviewing the logs, data center managers can record specific kinds of activities to show auditors that controls are in place." Yes, one can try to look at the configurations to see the controls, but only logs show how those controls manifest in real life.
2. "The other function of log data in compliance is to report on exceptions -- explicit log events that represent issues requiring investigation [...]" Indeed, logs provide an objective (subject to known caveats ...) trail of activity and should be used pretty much in all investigations.
The paper further mentions the role of logs in SAS 70 audits; while some people make jokes about it as a means to "prove security", it seems to be the choice of some companies that seem to streamline their audit processes.
