Monday, September 29, 2008

Fun Presentation from Recent ISSA e-Conference

Again, while I am not blogging like mad, here is another presentation on logging. This baby is a big philosophical and mildly inspired by Dan Geer and it looks into connections between logging and broader concept of "accountability," as it is defined in IT and even beyond. I also explore the ideas that "controls don't scale, while monitoring/logging does."

The presentation is also embedded below:

Logs = Accountability
View SlideShare presentation or Upload your own. (tags: logs chuvakin)


Possibly related posts:

Friday, September 26, 2008

Presentation from GOVCERT.NL 2008: Log Forensics

While I am too busy too blog [I will explain why soon!], I wanted to give my readers some fun logging and security stuff to read.

So, I am releasing one of my favorite presentations, the one on log forensics, in its newest expanded form: "Logs for Incident Response and Forensics: Key Issues for GOVCERT.NL 2008"

Here it is also embedded below:


Possibly related:

Monday, September 22, 2008

Is PCI DSS "Too Prescriptive"?

I did this fun panel on PCI compliance at SecureWorld Bay Area the other week. What is interesting is that almost every time there is a discussion about PCI DSS, somebody crawls out of the woodwork and utters the following: "PCI is too prescriptive!", as if it is a bad thing (e.g. I mentioned it before here)

I used to react to this with "Are you stupid?! PCI being prescriptive is the best thing since sliced cake :-) Finally, there is some specific guidance for people to follow and be more secure!" BTW, in many cases end users who have to comply with PCI DSS still think it is "too fuzzy" and "not specific enough" (e.g. see "MUST-DO Logging for PCI"); and they basically ask for  "a compliance TODO list." (also see this and especially this on compliance checklists)

But every time it happens, I can't stop but think - why do people even utter such utter heresy? :-) And you know what?  I think I got it!

When people say "PCI is too prescriptive," they actually mean that it engenders "checklist mentality" and leads to following the letter of the mandate blindly, without thinking about WHY it was put in place (to protect cardholder data, share risk/responsibility, etc). For example, it says "use a firewall" and so they deploy a shiny firewall with a simple "ALLOW ALL<->ALL" rule (an obvious exaggeration - but you get the point!) Or they have a firewall with a default password unchanged... In addition, the proponents of "PCI is too prescriptive" tend to think that fuzzier guidance (and, especially, prescribing the desired end state AND not the tools to be installed) will lead to people actually thinking about the best way to do it.

So the choices are:

  1. Mandate the tools (e.g. "must use a firewall") - and risk "checklist mentality", resulting in BOTH insecurity and "false sense" of security.
  2. Mandate the results (e.g. "must be secure") -  and risk people saying "eh, but I dunno how" - and then not acting at all, again leading to insecurity.

Take your poison now?! Isn't compliance fun? What is the practical solution to this? I personally would take the pill #1 over pill #2 (and that is why I like PCI that much), but with some pause to think, for sure.  I think organizations with less mature security programs will benefit at least a bit from #1, while those with more mature programs might "enjoy" #2 more...

BTW, this post was originally called "Isn't Compliance Fun?!"  I had a few fierce debates with some friends and all of them  piled on me to convince me that "compliance is boring, while security is fun!" The above does illustrate that there are worthy and exciting intellectual challenges in the domain of regulatory compliance. It is not [only] a domain of minimalists (who just "want the auditor to go away") and mediocrity, as some think. What makes security fun - the people aspect, the ever-changing threat landscape, cool technology, high uncertainty, even risk - also apply to compliance ...

So, need a cool marketing slogan BUT hate "making compliance easy"?  Go for "Making Compliance Fun!" :-)

All posts on PCI - some are fun:-)

Thursday, September 18, 2008

Dumb Luck IS a Strategy!

While still at GOVCERT.NL, I've attended a fun little presentation, describing a penetration test (I cannot provide any more details as it was a "No Press" presentation - this post is not about it, but rather was inspired by it!)

In any case, if you do pentests, think about all the RECENT cases where you break in to a major corporation through:

  • a Solaris system with Internet-exposed telnet with a guessable password OR a telnet vulnerability (circa 1994!)
  • an exposed VPN appliance with a manufacturer's administrator password
  • a router with default "enable" password
  • or, something else entirely - but something that rivals the above example in its unparalleled, unbelievable, abysmal, deep idiocy.

Indeed, many of my pentesting friends still report plenty of such cases (one was also featured in the presentation mentioned above). Whenever I hear about it from a pentester, I always ask:

Do you think "somebody bad" had already passed through the hole you just discovered?

Maybe an hour ago, a day ago - or a year ago?!

I cannot see how the answer can be "no."

Even though pentesters usually don't focus on forensics (no time for this), it is not uncommon to notice "your predecessor's" intrusion traces while you break through systems, "plant flags", change screen backgrounds [for the admins to notice that you've been there...], etc.

Let's think what this situation really means? Here are the choices I see:

  1. Nobody discovered the hole - a law of large  numbers (aka "dumb luck") have "shielded" the company from an incident. Yes, Virginia, dumb luck IS a security strategy for some companies... AND it works for them.
  2. It was discovered, but not used/abused by the attacker - maybe he was busy hacking other systems, or saved this for later and never came back due to his ADD. Congratulation, you win! The immense power of dumb luck wrapped you in a protective "security" blanket ... again :-)
  3. It was discovered; the attacker went in, looked around and compromised a few others systems, but found nothing of interest (no low hanging fruits)  - and he was not a bot herder. Again, you win. Next time you are in Vegas, bet on "00."
  4. It was discovered; the attacker went in and deployed a bot on "your" system - given how many botnets are there, this situation is clearly acceptable to many organizations. In this case, dumb luck strategy, apparently, still work: so they use your box to spam and phish somebody else ... big deal!
  5. It was discovered; the attacker went in and stole all your credit card information (it is now for sale) - even in this case, the user of "the dumb luck strategy" still "wins" (in some perverse sense)! Unless and until the stolen information IS tracked back to you OR a friendly neighborhood PCI auditor come and jams a broomstick up your ..., you can still continue to be stupid at your leisure and ignore basic security practices.
  6. It was discovered; the attacker went in and stole your CEO's Inbox, including the email related to his affair (it is now on CNN) - now, in this case, you lose AND it is time to stop being stupid! Welcome to the "0wned world." Time to launch (relaunch?) your security program and get serious.

What does this teach us about RISK? The lesson here is important:

  • For a security professional, an Internet-exposed system with "root/root" is an obvious HUGE risk!
  • For your boss's boss's boss, it is NOT!

This is exactly why I think that the most critical problem in security today is METRICS. Metrics that a) work AND mean something to decision makers and b) can be clearly communicated to said decision makers [BTW, a) and b) are two separate problems.] Metrics that cover not only threats and vulnerabilities we face, but also the effectiveness of security countermeasures we deploy. Metrics you can act on - and ones your boss (and his boss) will act on. Metrics that lead to correct decisions about which risks to accept, which to  mitigate (all while knowing with what efficiency such mitigation occurs) and which to transfer.

Until that time, the dreaded "C-word" (compliance) will trump "the other C-word" (common sense) as a driver for security ... and we will continue to live in the "0wned world."

Possibly related posts:

Wednesday, September 17, 2008

One More Thing About GOVCERT.NL 2008

This is a post that I forgot to post from my drafts folder...

I am [well, I was :-) when I create it] flying back from GOVCERT.NL 2008 and lemme tell you! I have not ever seen a security conference which were THAT well-organized. Really! Everything just worked. Keynotes (first, second) were - gasp! - fun and useful (take that, RSA! :-))

My presentation was "Logging for Incident Response and Forensics: Key Issues" and I promise to post it online (here). BTW, if you attended the presentation, feel free to send the questions direct to me (since I didn't have time to answer them all at the end)

Tuesday, September 16, 2008

Google Docs 0-day?

Or what?

Live Blogging from GOVCERT.NL 2008 - Marchus Sachs Speaking

The next presentation at GOVCERT.NL 2008 is Marchus Sachs's "Security in Supply Chain"; very interesting as well.

If the world weren't already 0wned due to bad software (see my account of the previous presentation), Marchus talks about how "0wning your supplier to 0wn you" will become more popular. Infected disk drives, picture frames, GPS units (!), laptops, USB keys, MP3 players, etc are a sign of it; the public one, that is. Real "pre-0wned" stuff is the stuff you never see ALL THE WHILE it gets incorporated into our critical systems (like the fake Cisco routers - this one somehow sounds very ominous to me...)

BTW, the one I have not heard is one about Apple iPods being shipped infected with Windows-based malware :-) WTH?

I also love his example of a chewing gum AND a USB stick lying on the floor.
Will you pick a stick of gum and stick it in your mouth? Ewwwgh...
How about a USB stick? Hmm...

So, will RBN (or its tomorrow's equivalent) go into a business of partnering with a fake MP3 player manufacturer AND produce players "pre-0wned" with custom malware? Just an idea ... "RBN-branded MP3 player" to make money two ways.

How do you solve this? More lawsuits?

Live Blogging from GOVCERT.NL 2008 - David Rice Speaking

So, David Rice of "Geekonomics" fame is speaking; the content is pretty much the same as the book, but he sure can speak! :-) [see my review of the book here]

The message is the same: cybercrime is due to bad software; market motivates people to create bad software ("don't worry - be crappy" idea); market will fail to create secure software, etc.

Result? The 0wned world.

So, how to you make insecure software MORE expensive to create than secure software? Laws? Insurance? What else will help? Only time will tell...

Monday, September 15, 2008

Fun Reading on Logs and Log Management - 2

I am amazed (no, AMAZED!) about how many people now write about logs; it is definitely not "the original logging evangelist" anymore :-) Here is a bunch of good log-related reading, useful for those struggling with logs (aka "everybody" :-))

  1. Our brilliant field engineer Dimitri McKay talks about the eternal topic of converting Windows event logs to syslog. Yes, Eric, we ALL know it is ugly, but that is the only way that actually works well across all systems ...
  2. More on Windows and syslog: "Syslog ... 20 Years Later." BTW, this is really not about syslog, but about Vista/2k8 finally getting an ability to natively centralize the event logs via event subscriptions ("It's only about twenty years behind schedule, if you're counting.")
  3. Two fun pieces on correlation: 1 and 2. What often kills "a log correlation project"? "Whoever had worked on it had not had much time available to learn the way to properly configure the software" (from this) and "correlation only really works when backed up by real data about what is the biggest problem in your environment, and how that problem manifests itself in the event logs." (from this) None of this is new, but a useful reminder nonetheless
  4. Fun LogLogic podcast is here. The topic of this high-level discussion (CEO) is related to operational use for logs. I did one with them too; on logs and virtualization (will be up soon)
  5. A couple of good posts on logging from Nemertes Research: "Sharpening Stones and Walking on Coals", "Search or Destroy"
  6. Reminder about a few useful Windows Vista and 2k8 events: 4802 (screensaver engaged) and 4803 (screensaver dismissed)
  7. One person is wondering about the usefulness of logging after "experiencing" Linux auditd logging (kernel audit): "Logs are like a warm blanket; verbose logging means you can know what's happening on your systems if you keep up with the logs. At the same time, logs become a burden very very easily, and they are easy to ignore." This post is a must read for us logging afficionados; producing too much log data is a sure way to make people hate you...
  8. This also follows the same theme: people doubting the god-like power of logs :-) "So for an administrator to not care about logs was a shock." But would I argue that "log management is NOT a pain?" Now, would I? :-)
  9. A classic about logging for application developers: "Building Secure Applications: Consistent Logging." I am noticing a lot more discussions about logging in a developer community, e.g. see this and this (the latter, BTW, contains a lot of info on "why log" for developers). Overall, "getting logging right" is important (and will get more important in the future) and people need something NOW and cannot wait for the standards. BTW, I am planning a mini-crusade on how to train application developers to include useful logging in their applications...
  10. Finally, the "Is SIEM dead?" theme is continued in this fun post "Life after SIEM. Situational Awareness is next." Indeed, context is key for logs. BTW, if somebody mentions that I have "vendor bias", I will kick your ass! :-)


Possibly related posts:

Presenting at GOVCERT.NL 2008

As you well know, I am speaking at GOVCERT.NL Symposium 2008 tomorrow. My talk is "Logging for Incident Response and Forensics: Key Issues," an attempt to squeeze A LOT of knowledge into 45 minutes :-)

Wednesday, September 10, 2008

Second ROI War

Another day, another security ROI blogwar.

Overall, I love it when educated peoples' debate just falls waaaay down to the level of "I won't care what YOU call it as long as you don't care what I call it...." Yuck! :-)

All security ROI coverage is tagged here: The previous, "First ROI War", is summarized here.

If This Isn't 'Semantic Hacking', I Don't Know What Is...

"Shares of UAL Corp. went from $12.16 to $0.01 [A.C. - the number is actually not true; they dropped to about $3, but still] when a 2002 Chicago Tribune article with the headline “United Files For Bankruptcy” appeared today. With today’s date." (more coverage)

Think about it...

Worms? RBN? Bots? Rootkits? DLP? NAC? For kids.

Friday, September 05, 2008

Logging Poll #9 Analysis: Log Security

This is the analysis of my last poll; the responses are here and also below.


First, the most obvious conclusion: people still don't care much about log security; I am saying that since this was BY FAR the least popular of my polls. Only 24 people responded, so everything below is pretty unscientific :-)  A good way to explain it: look at the recent media? Do these people care about their key business data and their customer data security? Nope. So, how on Earth do you make them care about securing their log data?

Second,  it is entirely unsurprising that 83% of respondents want "Authenticated access to log server." In fact, I'd opine that 100% of people want authenticated access to any of their servers :-) But, this was my "red herring" to set the baselines for the rest of the questions... 

However, this is where the buck stops: other security measures are notably less popular.

Third, "Logging all access to logs" is my favorite and I am happy to see it reported as popular. But do you really do it?  Do you log access to log server OR access to actual logs? Think about it... I think a lot of people who do the latter still answered "yes" to this one.

Fourth,  "Reliable / acknowledged network transfer of log data" and "Encryption of log data in transit " are two true "no-brainer" security features; they took the next spot at 45% and 50% of those who answered. They are simple, they are easy, they make  sense - and, obviously, they don't make logs entirely secure so you need to do more. Why only 50%? Where is THE OTHER 50%?!

Fifth, "all things crypto" are below 40%. "Cryptographic hashing of stored logs", "Cryptographic signing of stored log data" and "Encryption of stored log data" all hover at around 30%. I attribute them to general disregard of log security AND reliance on "system security" (separate server, etc) over "data security" measures for log protection.

Finally, I am embarrassed to say that I missed  the obvious security measure "Separate server for logging, not accessible from the Internet;" one of my readers added this using "Other security measures" choice. Indeed, this is a good point - and a good idea to do it. Another option mention there was "Destroy old logs." Amen to that too!

Possibly related posts:

Thursday, September 04, 2008

Monthly Blog Round-Up - August 2008

I saw this idea of a monthly blog round-up and I liked it. In general, blogs are a bit "stateless" and a lot of good content gets lost since many people, sadly, only pay attention to what they see today. This is an attempt to remind people of useful content!

So, here is my next monthly "Security Warrior" blog round-up of top 5 popular posts and topics.

  1. In a bizarre twist of fate (maybe driven by my latest poll), the "Top 11 Reasons to Secure and Protect Your Logs" came up as #1 most popular post in August.  The analysis of said log security poll is coming up tomorrow. BTW, see my other logging pollspoll #8 that covered context data for log analysis is analyzed here and a controversial Windows Log Collection Poll (which is a poll #7)  and poll #6 about logs that people actually review and poll #5 about logging challenges.
  2. Next up is my post "Log Management - Day 1," which talks about the very first thing you do when embarking on a journey to log management.
  3. Still burning hot is a post with my irreverent comments on a Terry Childs saga. Namely, "On Doomsaying (Terry Childs case)", "So ... Am I? Maybe I Am!" and "Admins , Good Guys or "I am NOT an Idiot!""
  4. Somewhat predictably, PCI compliance is all the rage again with 1.2 coming out soon. So, MUST-DO Logging for PCI? post was again propelled to a place in my monthly Top5 list. It discusses the fact that there is no "easy list" of what you MUST do to comply.
  5. Finally, my post "11 Signs That Your SIEM Is A Dog or "Raffy, You Killed SIM!"". It is both humorous and sadly true (and backed up by other sources)

See you in September,  when .... ah, come on! I will tell you later :-)

Possibly related posts / past monthly popular blog round-ups:


Technorati Tags: ,,,

Wednesday, September 03, 2008

What CAN You Do?

This is NOT a funny post. At all.

Alan is not the only one who got 0wned. I am hearing VERY disturbing rumors from some other people (sorry, can't share them here) - and they are good, paranoid people :-) People who don't have a password of "password." :-)

Now, think.

What can you, personally, do today if you know - or, at least, suspect - that somebody is after you?

Change all passwords? Create paper copies of financial records? Backup everything offline? What else?


Maybe it will become a new blog meme... In any case, I AM thinking about it. Today!

And I suggest you do that too.

UPDATE: a very good follow-up post to this with a lot of practical suggestion. Go there!

Dr Anton Chuvakin