Notes from CSI2009 Annual Conference

If you’ve ever been to a ghost town before,  you didn’t need to go to CSI this year. It seemed to have only a few people even at HOT topics. Initially I thought that it was because I spent only the last day of the show there, but others told me that it was not the case. I saw a ghost of risk management there, BTW…

Other people’s impressions:

• Rafal Los on CSIAnnual (some observations about lack of passion, which I didn’t notice since I spoke on PCI DSS and PCI=passion :-))
• TechRumble on CSI (some fun cloud stuff that I missed at the show is mentioned there; quote: “Today even a 1-person startup can compete with Google and IBM in terms of infrastructure”)

Also, if you’d like to see my “PCI DSS as a framework for security” presentation (with voice and all!), go here. It is essentially the same presentation that I gave at CSI, minus some magic tricks I played on the live audience :-)

BTW, if you suffer from mild voyeurism, you can see a picture of me giving this presentation here (yes, I had explosions and demons in my PCI presentation :-)).

Possibly related posts:

• All conference stuff
• Notes from NIST SCAP 5th Security Automation Conference (a day before CSI2009)

Top Log FAIL!

The Wal-Mart story inspired me to summarize the most egregious, reckless, painful, negligent, sad, idiotic examples of “Log FAIL.”  Here they are:

1. Logging disabled: if you got a system which had operational logging enabled by default and then you turned it off before deploying in production – congratulations! You truly earn your title of a Log Idiot! :-)
2. Logging not enabled: this is more sad than anything else … and the person who will suffer the most from this is likely the one who has caused it. After all, you’d need those logs at some point yourself. There is nothing sadder than see a person having to explain to management, police, FBI, press, QSA, SEC, whoever: “Well, logging … was … never … enabled!”  (check out this motivational horror story)
3. No log centralization: Windows admins, read this one – logs on the machine that crashed, was 0wned or even stolen will do you absolutely no good. It used to be that only Unix administratory can do this (via the magic of /etc/syslog.conf line “*.*    @loghost.example.com”), but you, on the Windows side, could not. Please notice that the world is different now!  (check out this deck on benefits and tips related to log centralization)
4. Log retention period too short: the picture on the right should make this item (as well as the one above) painfully clear: doing “the right thing” and building the centralized logging infrastructure and then limiting the retention to 30 days is still “log FAIL.” Many, many scenarios today require logs from the past – for the juiciest examples check all the recent “compromised in 2006 – discovered in 2008” stories (see some here in this deck)
5. No logging of “Granted”, “Accepted”, “Allowed”, etc: I don’t even know where to start on this one – maybe thus: logging a firewall “connection blocked” events simply means that the firewall was doing its job, logging “connection allowed” shows that somebody is now in your network… The same  idea applies to logging “login failed” and missing “login successful” – please make really sure to always log both (read this tip for more examples, instructions and ideas)
6. Bad logs: if you are in operations, this is truly not your fault. But if you are in development – it probably is. Creating such logging classics as “failed successfully”  and “login failed” [with no actual user name recorded] are fine examples of this “log FAIL.” Be aware that our work on CEE will fix it eventually, but more hilarity will have to transpire before it happens (see this deck for  some ideas on how not to engineer logging and how to do it – and for some examples of hilarity, of course)
7. No log review or nobody is looking at logs: I am saving this “log FAIL” for last;  logs are created to be reviewed, monitored, searched, investigated, etc and NOT – I assure you! – to simply use up disk space (check my famous “Top 11 Reasons to Look at Logs” as well the classic “Top Logging Mistakes” for more info on this one)

BTW, check out Branden’s musings about the same subject  here.

Possible related posts:

• Another One from "Ignore Logs at Your Peril"
• Are YOU Ignoring Logs?
• Again, On Criticality of Logs
• Top 11 Reasons to Analyze Your Logs
• Everything tagged “logging” (a lot!)

Read Ranum’s Anatomy of Security Disasters

If you will read one article on security today (and, in fact, this whole week), read this: “Ranum's Rants - The Anatomy of Security Disasters” (here also in PDF and here in slide form)

The piece is fun to read (especially if you are fond of saying “EPIC F.A.I.L.” :-)) and is full of lines which promise to be useful and insight for the next…let’s say… 30 years :-)

Just quotes:

“So, what’s going on? We’ve finally managed to get security on the road-map for many major organizations, thanks to initiatives like PCI and some of the government IT audit standards. But is that true? Was it PCI that got security its current place at the table, or was it Heartland Data, ChoicePoint, TJX, and the Social Security Administration? This is a serious, and important, question because the answer tells us a lot about whether or not the effort is ultimately going to be successful.” [A.C. – it was PCI DSS, actually, and not the breaches. The later can be “it-won’t-happen-to-us”’ed away easily]

“I’m very skeptical of the notion that "Risk Management" has any value beyond the butt-covering obviousness of having made an attempt.” and later “If you accept the argument I am making so far, perhaps I can convince you that "risk management" is a fiction that plays into the disaster-cycle.” and even “Ultimately, risk management is a numbers game; you multiply a wild-ass guess by a fudge factor. Worse, the potential cost of failure is estimated in as a factor, too. So you're trying to balance an unjustified estimate of cost of failure against a wild-ass guess multiplied by a fudge factor.”

“The difference between Alan’s viewpoint (other than that security practitioners are ‘whiners’) and mine is that he appears to believe that anything worth doing, can be done safely. Or, at least, with controlled risk.”

“Computer security hasn’t been tagged with an epic failure, yet. So far, computer security has "merely" been blamed for things like billions of dollars of losses. In its simplest form, the problem with computer security is that (like most risky propositions) it's easy to simply not worry about it as long as "nothing has gone wrong, yet."”

“I describe that as having happened in the past tense because it's important to emphasize that the computer security disaster has already happened - we simply have not yet reached the end of the sequence of events that started being put into motion in the mid 1990s.” [think about this one!]

“The reality gap comes into play when the executive decided to shop the idea around: he asked for this thing to be done securely, and got a resounding "no" from the security group, but a "yes" (it can be done, but not securely) from the web group. All he hears is the "yes" and when the whole thing blows up a year later, his memory will be that he asked if it could be done safely, but someone lied to him.”

“A few years ago, when a friend and I were discussing this problem at a conference, he said, "Yeah, but what should we do about it?" The only answer I can honestly give is: "The wrong decisions got made 15 years ago and now it's too late to go back and un-make them." “

“Remember: every fatal skydiving accident is that diver’s first fatal accident.”

“Do not allow management or clients to believe that they can do dumb things in safety, and do not hide behind bogus probability guesses.”

… but you MUST read the whole thing!!

UPDATE: fun comments to it can be read here.

SIEM Is Not What Is SIEMs Nowadays...

"Aliso Viejo-based High Tower Software, a venture-backed developer of security, compliance, and log management software, has shut down."

Wonna go into SIEM market, anybody?

UPDATE: to put it into context, read this

UPDATE2: read "SIEM: The Quickening Begins" too. Long (forever?) live Connor MacLeod :-)