Fun Reading on Security and Compliance #24

Here is an issue #24 of my “Fun Reading on Security and Compliance,” dated March 31, 2010 (read past ones here). You can judge that my “2blog” folder has been kinda full, since I was too busy working on a few fun consulting projects.
This edition is dedicated to RSA conference – an unending source of awesomeness!
Main section:

1. First, a great read from Dave Shackleford “A Glimpse Into the Security Mindset” which reminds: “Security people have a challenge that is 100% unique to their discipline [within IT – A.C.]: we have adversaries.” While there, also read his “5 Reasons Your Security Program is a Failure.” (quote: “if you don’t have daily SOPs around your monitoring tools and capabilities, you will end up with shelfware, and that just sucks”). But if you really into sucking, check Lenny’s “How to Suck at Information Security”
2. Gartner blog has hilarious “Worst and Best Security Sales Practices” (first). Example: '”saying your product is in market X, since X is currently cool”
3. Josh Corman, Jeff Williams (of OWASP fame) and David Rice (of “Geekonomics” fame) launch “RUGGED software” manifesto: “Software that endures against the environmental forces arrayed against it in cyberspace.” The manifesto is here at its brand new site. 
4. Sad hilarity reigns supreme here in comments at  “Thor vs Clown”  from TaoSecurity. Example: “P(Compromise) = P(C.SMS) x P(C.PIN)”

Logging, log management section and SIEM section:

1. ”Using Logs To Reduce Response Gap”: “Unfortunately, auditing and never really using logs for anything except for records retention can cause organizations to treat them as merely objects to move around and not necessarily utilize for any action.”
2. Prism Microsystems continues its epic mega-saga of “100 Log Management Uses” here at “#27 Printer logs.”   While there, also please read “Sustainable vs. situational values” by Ananth that has this great quote: “I am often asked that if Log Management is so important to the modern IT department, then how come more than 80% of the market that “should” have adopted it has not done so?”
3. Something made the Team Securosis think about correlation – and even argue between themselves: “Network Security Fundamentals: Correlation” (quote: “Most security professionals have tried and failed to get sufficient value from correlation relative to the cost, complexity, and effort involved in deploying the technology.”) and “Counterpoint: Correlation Is Useful, but Threat Assessment Is Fundamental” – then Rocky comments on the whole thing [BTW, I have no idea why they think correlation is about NETWORK security…]
4. BTW, fun correlation discussion is also ongoing at one of the SANS blogs: “IT Audit: Correlating Logs and Event Logs.” It looks like David Hoelzer might bring his DAD correlation project back to life…
5. A fairly intelligent piece on logging (“Best Practices For Windows Log Monitoring”) has this great quote: “Not monitoring your Windows logs is like setting up a security camera and putting an exit sign in front of it.”
6. Lenny has “Establishing a Practical Routine for Reviewing Security Logs:” “A practical routine for reviewing security logs is regularly scheduled, partially automated, alternated among team members, and linked to problem resolution.” Our joint project, "Critical Log Review Checklist for Security Incidents" definitely helps with that.
7. I mean, come on, even McAfee suddenly started talking about logs (something they’ve been ignoring forever). Eric Cole talks about logs in the context of SANS CAG/CSC in “Critical Control 6: Maintenance, Monitoring, and Analysis of Audit Logs.” He says: “Unmanaged Logs Hurt” and reminds that “Sometimes logging records are the only evidence of a successful attack.” Sadly, at the end he hints that you should be using ePO as a SIEM… gasp.
   

Vendor section [now that I am not employed by the vendor I can call vendors names, etc :-)]:

1. Finally, one SIEM vendor realized that  analyzing firewall rules together with vulnerability data should not be left to the dedicated vendors [I always thought that fw rules + vuln scans analysis is waaay too narrow to launch a company on; SIEM should have ‘owned’ that a long time ago] and launched a new product that looks at events, flows, rules and vulnerability scans. Good idea!
2. And one log management vendor realized that “Reviewing logs everyday is a pain, we just made it easier”
3. AlienVault, OSSIM commercial home, has released OSSIM 2.2. This deck has the highlights. As I am using the system now, it looks more impressive than ever. Seriously!

Enjoy!
Possibly related posts:

• All other security reading posts.

Fun Logging Webcasts: 4/1/2010 and 5/12/2010

In the next few days, I will be doing two fun logging webcasts with The Open Group. Here is the info, quoted from their site:

Title: Enterprise Logging and Log Management: Hot Topics
Date & Time: Thursday, April 1, 2010, 11:00am Eastern Time

Capturing log information is critical to IT organizations for many reasons, including for security incident detection and response, and for compliance with numerous regulations and standards. Join one of the foremost experts on log management, Dr. Anton Chuvakin, as we discuss enterprise logging challenges and issues.

Moderator: Jim Hietala, VP Security, The Open Group
Panelist: Dr. Anton Chuvakin, Security Warrior Consulting

To register and attend: https://opengroupevents.webex.com/opengroupevents/onstage/g.php?t=a&d=664303043

Title: Logging Use Cases and Standards Update
Date & Time: Wednesday, May 12, 2010 11:00 am Eastern Time

Following on from our April 1 Log Management Challenges webcast, this second webcast will explore some log management use cases, including around accountability for data access. In addition, an update on progress in standards work from The Open Group (XDAS) and MITRE (CEE) will be presented.

Moderator: Jim Hietala, VP, Security, The Open Group
Panelists:

• Ian Dobson, Director, Security & Jericho Forums, The Open Group
• Dr. Anton Chuvakin, Security Warrior Consulting
• Joel Winteregg, Netguardians
  

To register and attend:
https://opengroupevents.webex.com/mw0306l/mywebex/default.do?siteurl=opengroupevents&rnd=0.20892260101881588

 

Possibly related posts:

• All posts tagged presentation

PCI Myths 2010 Talk - FUN

Last week's presentation on "PCI DSS Myths: Why Are they STILL Alive?" is online. If you'd like to ask me for a slide deck, don't - listen to the recording. It is seriously  fun!

The whole thing is embedded below:



Enjoy!

Thursday 3/25 IANS Webcast + Panel on Log Management: “Awesome++”

If you are at least a bit into SIEM and log management, you MUST join this IANS webcast (“IPC” for Interactive Phone Conference) called “Navigating the Data Stream without Boiling the Ocean: Case Studies in Effective Log Management.”
As IANS faculty,  I will lead a panel of enterprise SIEM/LM users (example) into battle… eh… discussion about deploying and using SIEM and log management tools. A lot …no… A L-O-T of insight will be shared by the people who use the tools on a daily basis and solve security problems using them - a tiny example in the picture.
“Navigating the Data Stream without Boiling the Ocean: Case Studies in Effective Log Management”

March 25, 2010 at 3:00 pm EST  / 12PM PST

“What makes a log management program effective? Log management activities must be prioritized in order to operate your security team effectively. We will review and analyze best practices for implementing  log management programs as well as address SIEMs’ influence on the goal of optimization. This virtual discussion is ideal for risk, compliance, and security managers, as well as anyone looking for new approaches to gain intelligence from their log data.”

Sign up NOW – and ask questions later! And don’t later tell me I didn’t warn you! :-)


UPDATE: awesome coverage of this webcast from Rocky DeStefano can be found here at his VisibleRisk blog.


Possibly related posts:

• All posts about SIEM
• All posts about log management

Log Management / SIEM Users: “Minimalist” vs “Analyst”

Just a random piece of some research project I did at some random point :-) In discussions at RSA 2010 conference, somebody mentioned that SIEM, log management and other monitoring/detection security product users are split into two major categories: one actually uses the product while the other “buys it for compliance” and then eventually uses … as a doorstop, for example.

And I actually had  an old presentation about this that was offered as strategic guidance to my consulting client (a vendor).

Here is that picture and text: two types of SIEM/log managements users that your solution has to make happy:

“Minimalist” SIEM/LM User

•Still evolves from “logs are dirt” to raw collection of log data

•Pure compliance focus – “deliver me from evil… eh… auditors” (or assessors, in case of PCI DSS)

•Collecting logs is the primary “activity”; not even thinking about log review yet

•Checkbox mentality is rampant among that type of user (sometimes, “correlation” is one of the checkboxes, sadly)

•Less mature; needs more hand-holding when deploying the product (might not want any help though…)

“Analyst” SIEM/LM User

•Evolved to “so we have them collected – now what?”; stuck now and not sure how to use “all that data”

•“Compliance+” or even pure security/operational focus; for example, SOC operation

•Using logs – review, analysis, at the very least investigations

•Explore and use logs mentality, focuses on getting the value of the data and solving problems

•More mature; needs more “cool tools”

So, before you plan/design/build your solution, think what is the primary user type… but keep in kind that to be truly successful you might need to entice both.

Enjoy!

Possibly related posts:

• SIEM Bloggables
• The Myth of SIEM as "An Analyst-in-the-box" or How NOT to Pick a SIEM-II?
• Log Management + SIEM = ?

 

Minor Bit of Promotion: PCI Book Rocks!

The PCI book site has been updated with recent PCI DSS related videos and writing from Branden and me. For example, another big free chunk of a chapter (Chapter 12 “The Art of Compensating Control” by Branden) is posted. The picture proves that we did manage to write “The PCI Book” and not just “a PCI book” :-)
And, of course, the ever-so-funny PCI videos:

ShmooCon 2010 Conference Panel "An Existential Threat To Security As We Know It?" (direct video link [FLV]")

Security BSides San Francisco Panel "The Great Compliance Debate: No Child Left Behind or The Polio Vaccine" (part 1, part 2)

RSA 2010 Quick Clip "If you’re going for PCI compliance, just shut up and log" (direct video link)

Enjoy – if you missed it live.

While I am at it, let me make a few quick announcements.
Here are my fun upcoming speaking ops:

1. Source in April in Boston, MA (with Branden)
2. PCI DSS Workshop in April in Indianapolis, IN
3. Honeynet Project Annual in April in Mexico
4. HITB Amsterdam in July in Amsterdam (cool!)

Recent writing [guess what? it is about logs! And sometimes PCI DSS]:

1. "PCI DSS logging: A must for compliance" (part 1)
2. "Practical priorities in PCI DSS logging" (part 2)
3. "Shut up and Log!" 

Miscellaneous:

1. You can now “rent a bit of Anton” via Institute for Applied Network Security (IANS). I officially became “IANS faculty” a few weeks ago.
2. If you somehow missed the release of our  "Critical Log Review Checklist for Security Incidents," then go get it!

Enjoy!

RSA 2010 – Day 4-5

The final RSA 2010 post covers the last two days: Day 4-5.
As during the previous days, I had quite a few fun meetings with people that will hopefully translates in to more business for Security Warrior Consulting.


One of the days, Branden and I did our PCI book signing (picture). First, we were shocked to learn that the book actually sold out (!) at RSA bookstore and the publisher had to rush another batch in (which actually almost sold out as well by the end of the show…)

On Friday, I went to a really interesting presentation called “Got DLP. Now What?” Some guy from Forsythe delivered a VERY well-thought-through presentation on what to do after you got that DLP box. Basically, stuff on DLP program, process, even how to think about DLP (“not for malicious attacks”, “not for malicious data theft”), etc.
Just as SIEM, DLP most often fails for political and cultural reasons, not because the technology is somehow inadequate.  His range of common DLP mistakes went all the way down to “we don’t know whether we have anything sensitive, but we think DLP will protect us” (yeah right!)
I also loved that he focused on building incident response procedures first after buying DLP (and, better, even before!). Indeed, response plan is needed first (SIEM is the same – what happens when that correlation rule triggers?). He also reminded that DLP will likely require full-time employees (or staff augmentation by a skilled consultant) to operate it.
He also said that “just run DLP and then chase alerts” approach never work. Thousands of alerts – the IDS syndrome- will kill it. Starting from a detailed DLP policy is the only way (surprise! :-)); AUP or general security policy won’t do.
Another thing I loved is the dilemma of “classify first OR discover first.”  Just as I suspected, in a perfect world , “classify first” works – just not in this one (see Rich explain it here). “Discover scan first then create policy/classification” is more useful.
Similarly, “monitor first then slowly add prevention” is the only way to successful implementation. Overall, this presentation proved to me that RSA conference is not just about business development, chasing VCs and partying :-)

Finally, the juiciest bit: The Vendor Hall.


First, the meta-observation. Security industry is baaaack!  RSA 2010 felt more like super-glam RSA 2007 than like the meager RSA 2008. Economy in crisis? Not in this sector, baby! New vendors, old vendors, large vendors, small vendors – everybody is back in business [in fact, even some folks who shouldn’t be… you, triple-dead-zombies, you :-)]
Second, I noticed a lot of new security vendors with REEEEEEEEEEEEEEEALLY bad marketing, all the way down to this [BTW, somebody mentioned that the vendor in question has pretty useful and novel technology, it’s just their marketing is a bit … ya know… dumb].  BTW, “bad” here is defined as actually ineffective, not “overly deceptive” (e.g. compliance appliance) or “somehow offensive” (e.g. utilizes boobs and, especially, augmented ones).
Yes, there was even an obligatory village idiot with “we sell SOC-in-a-box” message. As well as “<our name>= Security” (while everybody knows that their name merely stands for PCI DSS compliance). And don’t even get me started on APT marketing – Rich said it best here.
Sometimes I felt like all vendors are divided into those who know what they are doing and how to market it; those who know what they are doing, but not how to market it; those who know don’t know what they are doing, but with great skills on how to market it; and, finally, those who don’t know what they are doing and have no idea how to market it (sad).
Third, it was funny when I’d approach a booth of Log Management Vendor X and everybody (including people I don’t personally know) will say “Hi Anton.” Then I approach Log Management Vendor Y and ask them a question, while wearing my name tag, and they  will say “come talk to this press guy over here” (!) and then they will start explaining to me what a columnar database is  :-) This was indeed hilarious! BTW, there was plenty of log management and SIEM vendors [some would say too many] and most if not all of them looked pretty optimistic.
Fourth, I have not picked anything that smelled like a new technology trend. It looked like most security subspaces (well, maybe not NAC…) are experiencing a major reemergence. The only thing that jumped at me (not sure why) was a large number of authentication and “access control” (loosely defined) vendors. Cloud stuff – even if in name only! – is even louder than in 2009 (substance is a bit hard to find, of course). You can try to do a quick divination on “Securosis Guide to RSA” [PDF], but I suspect all trends have been mined from there already :-)
Here is some more fun RSA 2010 (and BSides) notes from other folks (in no particular order)

• Martin McKeay on our compliance panel
• Rocky DeStefano on BSides and RSA
• Securosis team on RSA (those guys also notice amazing spurt of optimism!); read this one about APT as well (quote: “astounded at the outlandish displays of idiocy and outright deception among pundits and the vendor community”)
• More RSA 2010 and SecurityBSides impressions are here, here, here (from RSnake) etc.
• And of course, #rsac Twitter hash tag, if you’d like to be overwhelmed.

So, I am really looking forward to RSA 2011 :-)
Possibly related posts:

• RSA 2010 – Day 1 Metricon
• RSA 2010 - Day 2-3
• RSA 2010 EXCLUSIVE PCI Security Standards Council Interview
• RSA 2010: Where to Find Anton?
• All RSA conference coverage (all years)

RSA 2010 – Day 2-3

Continuing my much delayed coverage of RSA 2010, this is my summary of Days 2-3.

Day 2 was all meetings and getting new business for Security Warrior Consulting, so nothing to write about (yet). By far the most fun part was a long discussion with Rocky DeStefano, that went all the way back to 2003 when we faced each other through the gun ports of the warring battleships… eh... competing SIEM vendors [his side eventually won :-)]

Day 3 started from attending  an 8AM session by Bob Russo. Now, think about it!

RSA conference + Wednesday (day after heavy party Tuesday) + PCI DSS + 8AM (!) = empty room?

I honestly thought I’d be the only one who wouldn’t want to miss Bob Russo (session GRC-201). Ha-ha-ha, poor naive Anton :-) I came at 7:55AM – and there was barely a place to sit in a HUGE room. Bob didn’t say that much new, but he heavily focused on educating the merchants to focus on security, not checklists and “teaching to the test” [=PCI assessment]. See my RSA interview with the PCI Council  for more PCI DSS updates.

After the panel, I spent some time wandering the vendor hall – one of my favorite things to do at RSA; coverage of this will be presented in the next post since I am still sleeping on some of the trends that I think I’ve noticed.

Later in the day, I jumped to SecurityBSides where our compliance panel “The Great Compliance Debate: No Child Left Behind or The Polio Vaccine” was about to be held. This time we also had a QSA , a large service provider CSO and the usual suspects: Josh “PCI is the Devil” Corman and Jack Daniel, our illustrious moderator.  The panel went well and was a much better experience overall than our similar ShmooCon panel (notes, video [FLV]): more structure, more useful discussion and just enough anger to keep it fun :-)  To me the most jarring part was a comment by an esteemed audience member (sadly, she is not seen on the video) that implementing PCI DSS controls is COMPLETELY out of alignment of what she needs to do based on her understanding of risk at a mid-size service provider. Hopefully, she clarifies it on her blog soon :-) So, watch the video: part 1 and then part 2. Also, read some more notes here.

Enjoy! One more RSA 2010 post to come: Days 4-5.

Possibly related posts:

• RSA 2010 – Day 1 Metricon
• RSA 2010 EXCLUSIVE PCI Security Standards Council Interview
• RSA 2010: Where to Find Anton?
• All RSA conference coverage (all years)

RSA 2010 – Day 1 Metricon

Let me start my [much delayed] coverage of RSA 2010 conference with the awesomeness of Metricon 4.5 (technically, a Mini-Metricon 4.5 :-)) where I spent my first RSA day (sacrificing the Cloud Security Alliance meeting that was reported to be packed).

Here is an agenda for the meeting with my comments:

08:45 - 10:05: Morning Session I - Chair: Jeremy Epstein

• Qualitative Tuning as Preparation for Quantitative Methods, Pete Lindstrom

This was one of the most fun presentations, focusing on expert opinion vs. fact/metric in security. Pete showed an interesting approach for assessing the opinions in order to come up with something that looks more like fact.

• Metrics for insights on the state of application security, Ashish Larivee

This was an interesting presentation of Veracode research of binary analysis (paper, some highlights). A few thing actually blew me away first, but, upon further consideration, started to look perfectly logical. For example,  software industry is worse at developing secure software than financial service industry. It can be explained that FS folks develop only mission-critical software though. Still, this seems to prove that in some areas “if you want it done well, do it yourself and do NOT trust the professionals to do it” :-) In fact, commercial software overall fared worse [vulnerability-wise] than internally developed AND outsourced software. It also had longest remediation cycle, while open source had the shortest (for methodology details see their full report)

10:20 - 11:40: Morning Session II - Chair: Joe Magee

• Translating the Narrative into Metrics: The Verizon Incident Sharing Framework,Alex Hutton and Wade Baker

Verizon VerIS was released via this presentation (release, exec summary, document [PDF]). VerIS “translates the incident narrative (the attacker did this, then that, then the other thing) into a data set” and thus allows the creation of such awesomeness as DBIR.

• Ontologies for Modeling Enterprise Level Security Metrics, Anoop Singhal

This presentation was a bit of a cruel joke. It carried unfortunate signs of being done by somebody who never ventured in the real world of security (for example, single number “asset value”, “risk = damageValue”, “security measures that reduce the frequency of attacks”, etc, etc, etc). And, what was even more embarrassing, it came after the stellar presentation by the Verizon team; I think I have seen the grimaces on their faces :-) And every time the NIST speaker mentioned “this was done on tax payer dime” or uttered the word “ontology”, I wanted to just reach for a ShmooBall. To make his material even more insulting, he was also a bad presenter. Yuck!

13:10 - 14:40: Afternoon Session I - Chair: Caroline Wong

• Improving CVSS-based vulnerability prioritization with business context information, Christian Fruhwirth

This was a curious little preso that basically can be summarized in one phrase “using CVSS as it was intended by the original team – with Env scores – is valuable.” Even though there was one “cringe moment” when the speaker expected a normal distribution of vulnerability CVSS scores (pray tell me, why medium severity are more likely than low severity?)

• Security Metrics Field Research, Ramon Krikken

This presentation by a Burton …eh... Gartner… analyst Ramon Krikken was hugely insightful. They did some metrics research among their clients and came up with some surprising conclusion that shows metrics programs largely in the Stone Age (in fact, what was before the Stone Age? Ah, yes, Sharpened Stick Age! The maybe the metrics are in that age…). Here are some of the themes, but get the presentation materials when they are posted – very worthwhile. As expected, “compliance metrics are easy; security metrics are hard”, “assessments and audits matter”, “need to map to ” and “ONLY prevention of ‘business being stopped’ matters at many companies.” The research showed no focus on improvements, no peer benchmarking, etc. Regarding tools, MS Excel was by far the #1, couple of times RSA/Archer and SIEM.

 15:10 - 16:30: Afternoon Session II - Chair: Ray Kaplan

• Metrics for Cloud Security, Lynn Terwoerds, Caroline Wong, Betsy Nichols

This panel announced that CSA is starting a cloud security metrics effort, which was in a VERY early stage. No material has been created yet.

• Identifying critical information security areas with a Threat Agent Risk Assessment, Matthew Rosenquist

I read the TARA paper back when it came out, but this presentation (and the discussion) was still VERY interesting. The main idea is that vulnerability or asset focused approach makes no sense since there are way too many vulnerabilities (presenter example was “data center is vulnerable to a meteor strike”) and thus the way to go is to focus on threat agents that are motivated to cause damage and that can realistically to do so. The logic thus becomes: threat agent –> vulnerability –> control –> what remains is the risk that needs to be dealt with somehow. But read the paper instead of this, Intel folks explain it much better :-)

 

So, as I said, Metricon was the most thought-provoking part of RSA for me! And I am not even mentioning the level of hallway discussions there…

RSA 2010 EXCLUSIVE PCI Security Standards Council Interview

At RSA 2010, I was given a unique opportunity to interview Bob Russo (GM at PCI SSC) and Troy Leach (CTO at PCI SSC). I have prepared a deck of very tough questions and then had an hour-long discussion with Bob and Troy around those questions. What follows is the interview reconstruction from my notes with minimum edits and clarifications by the Council folks.

Anton Introduction:  I think PCI DSS is the most valuable thing to hit security industry since its inception – both as a driving force for security improvements and as a source for security guidance. However, there are skeptics among merchants (too much security) and some security professionals (too little security). Some of my questions below focus on dispelling the misconceptions such skeptics might hold.
Anton Question 1: What, in your opinion, is the main value of PCI DSS – to the community at large? Merchants? Banks? Brands?
Bob and Troy @ PCI Council answer:
You have answered this question yourself above: it is security. Motivation for payment security improvements is the value of PCI. For some companies it is also a springboard for additional security improvements needed for their businesses. This benefits everybody!
PCI value can also be rephrased as demonstrating trust across organizational boundaries and. As we know, payment security has many sides and PCI compliance is one way of demonstrating trust across organizational boundaries.

Anton Question 2: Way too many companies seem to focus on compliance and not on security. What is the best way to prevent “teaching to the test” for PCI DSS compliance?
Bob and Troy @ PCI Council answer:
Too many companies focus on studying for the test. We believe the PCI Standards provide a solid foundation for a security strategy to look after payment and other types of data, but security does not start and end with compliance with standards.
Education is very important and that is why the PCI Council will focus even more on educating the merchants and changing their mindset from one of compliance to security. Their old way of doing business – retaining card data, for example- was viable one day, but not today.One of the steps we see is increased outsourcing of payment processing to trusted providers.

Anton Question 3: Some people say that “the brands must just change the system” since Level4 merchants [=typically smaller merchants] can never be educated and this never can be secured. What do you say to this?
Bob and Troy @ PCI Council answer:
It’ll happen eventually, but it is obviously not so easy. We’re talking 5 to 10 years here. The payment system is diverse and incredibly complex. Any drastic changes will probably be more costly and disrupt merchants’ business even more than PCI DSS ever could, so they have to happen gradually. The PCI Council’s mandate is to get as much done to improve payment security as possible - within the existing system. Security has to become part of every business that deals with card data.

Anton Question 4: There are many debates about PCI DSS in security industry, among merchants, etc. How can the impact of PCI DSS payment security be measured? Who might have the data to do it?
Bob and Troy @ PCI Council answer:
Security breach statistics demonstrating a root cause that can be mapped to PCI DSS requirements is one such possible way to prove the value of PCI. For example, if the company did not take any measures to protect against SQL injection and got breached through that, they need to pay more attention to Requirement 6.6.
On the other hand, trying to analyze what the non-breached companies are doing right with PCI is harder since you don’t hear about the myriad of success stories of companies that are defending against breaches through following DSS or have minimized card data compromise in breach situations through strong logging and monitoring, mandated by PCI.
PCI DSS prescribes logging and monitoring, which help detect data loss. Unfortunately some recent incidents had breach evidence present in logs, but since logs were not reviewed until breach became public (contrary to PCI DSS requirements) this was not utilized for detecting the breach.
More education efforts are needed to explain to merchants that PCI is not only about breach prevention, but also about detection of intrusions and security monitoring. Thus, judging its value only on breach prevention is shortsighted.
Enhanced information sharing will drive more improvements here.

Anton Question 5: What is your opinion of mandating the discovery of stored card data and especially track and other prohibited data? This technology was not high on the list in PWC report.
Bob and Troy @ PCI Council answer:
Many QSAs already use data discovery tools today. Since PCI scope covers systems where card data is present, payment card data discovery should be part of scope validation. “Forgotten” credit card data dumps were indeed present in some recent breaches stories.
Methods of such discovery can vary- using an automated tool is one of the options, but such tools are still not mature.

Anton Question 6: Do you think that there should be tiered security requirements for small and large organizations (that go beyond today’s SAQ validation levels)? For example, daily log review seems onerous to many merchants.
Bob and Troy @ PCI Council answer:
You cannot dumb security down below a certain level. More education efforts will be needed to explain to merchants how to satisfy requirements and become compliant [and stay compliant].
However, the Council is planning to build more tools in order to help merchants understand what exactly they need to do to become compliant. A wizard interface or some other method to simplify the SAQ process can be used here to highlight which controls the merchant needs to implement.

Anton Question 7: The “None were compliant when breached” rings true to me. Why do you think so many people object to this?
Bob and Troy @ PCI Council answer:
People simply need to know the facts and find out what happened in those breach stories. For example, some breached companies had massive stores of prohibited data, such as authorization data. Or they were not adequately protected at the application or database level against things like SQL injections. There is a difference between “breached due to negligence” and “breached due to bad luck.” Being diligent but still ultimately failing to protect the information is possible (so safe harbor does exist for such companies); it just isn’t what happened in those incidents.

You just need to get the facts. If a company gained compliant status by misrepresenting the facts to a QSA, PCI standards are not at fault when the breach happened.

Anton Question 8: What is the best way to balance PCI DSS lifecycle with both merchants complaints about “moving target” and with rapidly changing threats?
Bob and Troy @ PCI Council answer:
So far, the current two year lifecycle has provided a good balance between structured development and staying abreast of rapidly changing threats. Feel free - and have your readers - to suggest changes to that lifecycle, if you think it needs to be changed! We are considering how it might evolve.

Anton Question 9: What do you think of using PCI DSS controls for non-payment-card data?
Bob and Troy @ PCI Council answer:
It is a good thing, if you keep in mind that PCI DSS controls are the foundation or the minimum baseline for an effective security strategy. Organizations will likely need to build more security on top of the PCI foundation to protect other sensitive data. Layering technology solutions and combining with the necessary people and processes continues to be the most effective means in protecting cardholder data.
PCI has certainly raised awareness for all data protection, not just payment card data.
Anton Summary
Overall, the main themes I picked in the conversation were:

• “PCI compliance” is a means to an end. And the end is “security!”
• Education is one of the ways to change the thinking of merchants and to improve security.

Thanks to Bob and Troy for the insightful discussion!

Simple Log Review Checklist Released!

Today, many people are looking for very simple solutions to big and complex problems – and the area of logging and log management is no exception. Following that theme, we have created a "Critical Log Review Checklist for Security Incidents" which is released to the world today.

In addition to HTML, PDF or DOC versions are available as well (alternative hosting location is here). Feel free to modify the checklist for your own purposes or for internal distribution in your organization - but please keep the attribution to the authors.

The log cheat sheet presents a checklist for reviewing critical system, network and security logs when responding to a security incident. It can also be used for routine periodic log review. It was authored by Dr. Anton Chuvakin and Lenny Zeltser (BTW, Lenny has other useful security cheat sheets on malware analysis, security architecture, DDoS, etc  here)

Here is the embedded version from DocStoc:

Critical Log Review Checklist for Security Incidents -

Enjoy!

Security Warrior Blog EXCLUSIVE: 10 Question Interview with Bob Russo and Troy Leach of PCI Council

... will be posted next week.

If you think it would be awesome...prepare for "awesome++"

Monthly Blog Round-Up – February 2010

As we all know, blogs are a bit "stateless" and a lot of useful security reading material gets lost since many people, sadly, only pay attention to what they see today. These monthly round-ups is my attempt to remind people of useful content from the past month! If you are “too busy to read the blogs,” at least read these.

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

1. Our  PCI DSS panel at ShmooCon (“ShmooCon 2010 – Our PCI DSS Panel”) was very interesting and justifiably took the #1 spot this month. That controversial video has been released [[FLV]. Other ShmooCon notes are in the post called “ShmooCon 2010 – Show Notes”
2. Progressing from logging to log management to log monitoring discussion in “Logging, Log Management and Log Review Maturity” took the next spot. It presents a maturity scale for organization selecting log management or SIEM.
3. Open source SIEM theme continues to drive a lot of traffic (namely “Short Observation on Open Source SIEM”) – it looks like folks are still desperately googling for it. “Why No Open Source SIEM, EVER?” post takes the spot in Top5 this month again. The older inspiration for this post is “On Open Source in SIEM and Log Management.”  While you are reading up on SIEM , check out the post called “SIEM Bloggables” with key SIEM use cases.
4. The announcement about the release of Security Scoreboard was next – ““Security Scoreboard” Out!”. Think of Security Scoreboard as of Zagat or, better,Yelp for security products.
5. A completely humorous post about Advanced Persistent Threat (APT) called “Top Nine Reasons How PCI Is Like APT” (humor! humor! humor! – don’t respond to it seriously!) took the final spot in February Top5.

This month I am continuing a new tradition: I am going to thank my top 5 referrers this month (those that are actual humans, that is). So, thanks a lot to the following people whose blogs sent the most visitors to my blog:

1. Walt Conway
2. Dancho Danchev
3. Chris Hoff
4. Alexey Babenko (in Russian)
5. Richard Bejtlich
6. Paul Melson.

Thank you for all the link-love!

See you in March; also see my annual “Top Posts” - 2007, 2008,  2009!

P.S. Why am I not blogging about RSA while I am at RSA 2010? Well, I am – these posts will come next week after I recover :-)

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

• Monthly Blog Round-Up – January 2010
• Monthly Blog Round-Up – December 2009
• Monthly Blog Round-Up – November 2009
• Monthly Blog Round-Up – October 2009
• Monthly Blog Round-Up – September 2009
• Monthly Blog Round-Up – August 2009
• Monthly Blog Round-Up – July 2009
• Monthly Blog Round-Up – June 2009
• Monthly Blog Round-Up – May 2009
• Monthly Blog Round-Up – April 2009
• Monthly Blog Round-Up – March 2009
• Monthly Blog Round-Up – February 2009
• Monthly Blog Round-Up - January 2009
• Monthly Blog Round-Up - December 2008
• Monthly Blog Round-Up - November 2008
• Monthly Blog Round-Up - October 2008
• Monthly Blog Round-Up - September 2008
• Monthly Blog Round-Up - August 2008
• Monthly Blog Round-Up - July 2008
• Monthly Blog Round-Up - June 2008
• Monthly Blog Round-Up - May 2008
• Monthly Blog Round-Up - April 2008
• Monthly Blog Round-Up - March 2008
• Monthly Blog Round-Up - February 2008
• Monthly Blog Round-Up - January 2008
• Monthly Blog Round-Up - December 2007
• Monthly Blog Round-Up - November 2007
• Monthly Blog Round-Up - October 2007
• Monthly Blog Round-Up - September 2007
• Monthly Blog Round-Up - August 2007

Obligatory “added everywhere” posts :-)

• I might be available for consulting projects related to logging, log management, SIEM, PCI DSS etc. Please see the services list at my consulting site.

The Myth of SIEM as “An Analyst-in-the-box” or How NOT to Pick a SIEM-II?

In response to one of my previous SIEM posts (“I Want to Buy Correlation” or How NOT to Pick a SIEM?”), one of my readers grabbed onto my analogy (“correlation engine as engine, SIEM with content as car”) and said:

“They want a Security Analyst in a Box, because once you deliver the engine in a car, they realize they don't want to drive either”

This is, sadly, very true, despite the deep and obvious ridiculousness of such sentiment.

So, WTF? Did anybody sell you a tiny teeny security analyst stuck up in one of those 1U SIEM appliances you can buy at Walmart nowadays – or at least from your friendly neighborhood VAR? Where did this come from and what we can do about it?

Well, one thing we can do is simply say: if a Security Information and Event Management vendor came to you and said “this little box will manage your security” and you believed it, you need to have your head examined. But just saying this wouldn’t be funny enough for this blog! Noooooo…

So, instead, I came up with 7 reasons why SIEM is NOT “an analyst in the box”:

1. SIEM requires the buttons to be pressed, and analyst presses those buttons. See? There is a difference.
2. Imagine the best SIEM out there with the best correlation engine, the best rules, the best interface, etc [it is also the most expensive…] Now imagine the dumbest person ever to be tasked with event analysis. Well, they are about equally intelligent [*].
3. Despite what you might think, log analysis (and, definitely, security monitoring in general) is a pretty subjective “art.” Boxes don’t do art well, humans do.
4. Modern SIEM products have some “value out of the box”: report, stock rules, knowledge bases, etc. And, indeed, a vendor system engineer can even schedule the reports and set the rules for you – before leaving. However, do you have anybody who actually understands the information coming out of the product? Well, that’s the analyst, and he ain’t in the box. You have to hire him or her! (or have a consultant help you :-))
5. In addition to art, log management often involves politics: can we get those logs? Can we get the context needed for analysis (e.g who owns that system … eh…in addition to RBN that 0wns it, that is :-)). Just like art, boxes don’t do politics well, humans do.
6. Think of a good SIEM as a robot defender [assuming that you turned on automated response, oh the Adventurous One]. Do you see the military switching from human soldiers completely to robots? Exactly! SIEM + analyst = security defense. SIEM alone = gun rusting in the trench.
7. Analysts needs to be fed, SIEM can survive on just the diet of logs.

Thus, if you expect a security information and event management system to “be an analyst in the box”, stop expecting it. If you don’t want or can’t run a SIEM, don’t buy it (look here to see whether you are ready) or don’t download it. In other words, SIEM requires ongoing commitment to keep delivering value: no commitment – no value, it is that SIEMple.

BTW, I am thinking of writing a whole mammoth paper on picking the right SIEM. My dear vendor friends reading this blog, wonna sponsor it?

[*] I have seen some data mining algorithm mimic – and actually rival! – the performance of a junior security analyst. Sadly, they were build for a home-grown SIEM, now defunct… Oh, the lore of civilizations long gone :-)

Possible related posts:

• “I Want to Buy Correlation” or How NOT to Pick a SIEM?”
• “Logging, Log Management and Log Review Maturity” (helps to know whether you are ready for that SIEM)
• “Log Management + SIEM = ?“
• “SIEM Bloggables” (has SIEM use cases)
• “On SIEM Complexity“
• All blog posts on SIEM