Book Review “Practical Intrusion Analysis: Prevention and Detection for the Twenty-First Century”

“There is no spoon.”

“Practical Intrusion Analysis: Prevention and Detection for the Twenty-First Century”  by Ryan Trost–but-not-really (it is claimed to contain contributions by five other folks, but exact chapters they wrote are unknown) is not a book: it is a collection of papers about security and intrusion detection. The book bears unfortunate, but noticeable signs of being written by multiple people who didn't talk to each other much.

I just finished reading the book and I can say I enjoyed it. It does have interesting ideas peppered in some places. Overall presentation consistency, however, is not lacking – it is absent. Also, the book is not terribly practical if you define practice as “protection of systems and networks from attacks.”  Many chapters are shallow and make the impression of being added to get the book to 450 pages threshold.

So, some chapters are fun and insightful (“Geospatial ID”, “Physical IDS”, the sections on signature tuning), some are funny (example: one chapter talks about SIEM, SIM and SEM, but errs about what “M” in those stands for… seriously!) and some are sad (example: the one that mentions IDMEF), while others are very shallow (“Wireless IDS/IPS”). The chapter on ROI made me fall under my desk; I experience an actual literal ROFL – more on this below.

Here are some of the highlights. Ch3 has a lot of useful Bro NIDS tips; if you have never used Bro in production, give it a try. In Ch4, I liked vulnerability-based signature definition worklfow, which takes into account sig performance tuning. Ch5 was written by an academic, who doesn’t get out much; if works great if you want to really know what the word “befuddled” means (it also mentioned IDMEF for extra punch :-))  Ch6 is fine if you never dealt with network flows; not a bad intro. Ch7 is a very shallow intro to web application firewalls, while ch8 is the same for wireless IDS/IPS.  Ch9 deals with physical security and I loved; such information rarely shows in IT books and it was great to learn it. Ch10  that deals with geospatial intrusion detection is another good one; the approach looks a bit weird (example: all events with the sources address close to a company facility are considered “false positives”…). Ch 11 on visualization mentions all the right books on the subject, but then chooses to makes itself a bad comparison to them.

Now, ch12 (“Return on Investment: Business Justification”) is pure freakshow; I have not laughed that hard for a few months a least. After I had a chance to think about, I realized that maybe it was intended for humorous relief since it is the last chapter. Also, I am proud to be mentioned there (on page 404 – is this numerologically significant? :-)) In any case, the work computes the precise ROI for any IDS system, like that:

Gain  [IDS] from investment = ALE = SBE x ARO = $517,580

SBE comes from 2007 (!) CSI survey data, SBE = $345,005. ARO comes from risk  probability x expected number of incidents  = 0.46 x 3.2 = 1.5.  IDS is assumed to prevent all breaches (!), for computational simplicity, I am sure.  … Anyhow, you get the drift.

Overall, if you want a moderately interesting security read with some good ideas, get it. If you are looking for information on practical intrusion analysis in whatever century, skip it.

Finally, Addison-Wesley provided me with a review copy.

Possibly related posts:

• All book reviews on this blog
• My older book reviews
• My Amazon reviews

Donn Parker’s “Risks of Risk-Based Security” Summarized

Finally, I got my hands on the famous “Risks of Risk-Based Security” by Donn Parker, published in “Comm. of ACM” March 2007/Vol. 50, No. 3 (thanks for obtaining the paper for me, Mike!)

Juicy quotes follow:

“Management deals with risks every day, and risk reduction justification makes it too easy to accept security vulnerabilities in exchange for other benefits.”  [A.C. – it is interesting that Donn doesn’t just say that ‘risk is not a good approach,’ he blames “risk thinking” for a whole lot of today’s security problems!]

“It is relatively easy to justify increased security to stop or control ongoing significant loss incidents such as virus attacks—because they are certainties, rather than intangible security risks.” [A.C. – now communicating to management that these are indeed certainties remains a problem, of course]

“Information security departments have attempted to justify expending security resources to address these rare problems [A.C. – such as whatever ‘advanced’ attacks and not the certainties mentioned above] by managing and reducing security risks. To manage, they must control; to control, they try to measure the benefits of information security “scientifically” based on risk reduction. However, security risk reduction is generally not measurable.” [A.C. – thus reducing the reduction to guessing]

Key quote: “Security risk is different than measurable business risk that consists of voluntarily investing resources to produce a profit or meet a goal. Security risk is not measurable, because the frequencies and impacts of future incidents are mutually dependent variables with unknown  mutual dependency under control of unknown and often irrational enemies with unknown skills, knowledge, resources, authority,  motives, and objectives—operating from unknown locations at unknown future times with the possible intent of attacking known but untreated vulnerabilities and vulnerabilities that are known to the attackers but unknown to the defenders.”

“… risks are related in unknown complex ways so that reducing one risk may increase or decrease other risks. […]  You never know what amount of liability, litigation, or secondary effects may ensue after even a minor incident.” [A.C. – risk ‘butterfly effect,’ anybody? :-)]

“There are too many interrelated unknown and known variables, with unknown values. They all change in unknown ways over time, depending on unknown future circumstances.” [A.C. – admittedly, weather prediction has a lot of unknowns too, but this seems much messier than that…]

“humans are notoriously bad at qualitative risk assessment.”  [A.C. – the above means you can’t count; this adds that you can’t guess either :-)]

So, what does this teach us? More work on this is definitely needed - I am not just whining aka “bringing up the issue.” :-) Also, I now have a dream of a mythical document called “Practical Guide to Risk-less Security”…

Possibly related posts:

• Is Risk Just Too Risky?
• Risk vs Risk
• Thoughts After Chicago “PCI Dinner” Panel

Obligatory “added everywhere” posts :-)

• I am not at Qualys anymore and looking for the next big security idea to work on! Meanwhile, I might be available for fun consulting projects related to PCI, log management or other fun security things.

Speaking at CSI 2009 and Conference Discount Passes

While I will be in Baltimore for SCAP Conference, I will also speak at CSI 2009 … on PCI DSS, exploring a hot subject I wanted to explore for a long time: can you AND should you use PCI DSS as a base for your security program?

My session info:

“Topic: PCI DSS as A General Security Framework: Good, Bad or Maybe Ugly?

Speaker: Dr. Anton Chuvakin (Security Warrior Consulting)

Date/Time: Wednesday (October 28, 2009) 11:00am — 12:00pm

Presentation Abstract
Since PCI DSS covers twelve domains of security guidance, can we use it as a security framework to quickly build a security management program? Is it a good idea or a horrible one? How to do it? This session seeks to answer these and other questions and also generate discussion about broader applicability of PCI DSS.”

Also, I got some CSI discount passes; first come, first served, of course (this means: if you try it and it fails, that means that they are already used up by others)

“The passes cover the full conference, Monday–Wednesday, October 26–28, 2009, for a 40% discount!

To pass along your discount passes, go to CSI 2009 Registration to register for a CSI 2009 Conference Pass and have them enter the below Promotional Code in the box provided:

SPK14

CSI 2009 takes place in D.C.'s newest conference venue and hotel, the Gaylord National Resort in National Harbor, MD, just minutes from downtown D.C.”

Possibly related posts:

• Speaking at NIST Security Automation Conference

Obligatory “added everywhere” posts :-)

• I am not at Qualys anymore and looking for the next big security idea to work on! I might be available for consulting projects, whenever I finish my current consulting projects.

Bad Humor: Funny Security Roles

Beer + long train ride + academic papers on security (!) = this piece of bizarre humor.

Funny, hopefully fictitious, security roles [any matches with reality are mere coincidences]:

• Experienced cloud security veteran
• Innovative SOX auditor
• Fork bomb prevention expert [A.C. – inspired by a security “research” paper from 2009 about a new method to detect and prevent fork() bombs on Unix]
• Massive DoS detection specialist
• Open source Windows security expert
• DOS security architect
• Professional sniffer sniffer [A.C. – inspired by a security “research” paper from 2009 which invents new method to detect sniffers, BUT only those that emit (!) packets]
• Syslog psychic reader
• Legendary NAC security guru [A.C. – inspired by Unicorns, of course]
• Executive security reverse engineer

Care to continue this meme? Get some beer and then read a random paper on security written by somebody from a University who never dealt with a single real security problem in his life…

UPDATE: I am copying what was suggested by my esteemed readers from comments to the main post. Enjoy!

Suggested by toxa:

• Metasploit Certified Security Auditor
• Advanced Wireshark Network Analyst
• PCI DSS Clause 11.3 Guru [A.C. - loved this one!]
• Experienced Layer2 Attacks Specialist
• Famous Oracle App XSS Researcher
• Professional Web Applications Written In PHP Pentester

Suggested by Christophe:

• Experienced Password Policy Compliance Manager [A.C. - this one is awesome!!]
• Armed Layer 1 Attacks Specialist
• Veteran ITIL Conformity Observer
• User's Stupidity Documentation Writer
• Senior Unplugged Cables Auditor [A.C. - senior, no less! :-)]
• 2000 Bug Reappearance Sentry

Speaking at NIST Security Automation Conference

Just a quick FYI – I will be speaking about log standards at 5th Annual IT Security Automation Conference by NIST. 

The info about the conference:

”Conference Date:

October 27th and 28th, 2009

Location:

Baltimore Convention Center, Baltimore, MD

Registration:

Conference Registration Form

Agenda:

DRAFT Conference Agenda”

I guess if I end up being employed by that time, I will make this my first speaking op at a new employer :-)

Finally, if you are in Baltimore, let’s meet up.

Possibly related posts:

• Log Standards Make A HUGE Step
• RSA 2009 Impressions, Part IV or The Rest of RSA 2009
• CEE White Paper Out (Finally!!!!!!!!!!)
• My older log standards slide deck.
• All posts on CEE log standard.

Obligatory “added everywhere” posts :-)

• I am not at Qualys anymore and looking for the next big security idea to work on! I might be available for consulting projects.

Fun Reading on Security and Compliance #19

Instead of my usual "blogging frenzy" machine gun blast of short posts, I will just combine them into my new blog series "Fun Reading on Security AND Compliance." Here is an issue #19, dated Sep 23, 2009 (read past ones here).

This edition of dedicated to all the folks who write blogs, but never read blogs. Shame on you :-)

1. Very, very bold statement: “Why On-Premise Log Management is Destined for Extinction” from my friends at AlertLogic: “why, for all but the largest organizations, hosting your own log management solution in your data center simply won’t be a practical solution”
2. “Health IT Data Breaches: No Harm, No Foul” is eye-opening: “If the entity decides the harm to an individual is not significant, no notification is required.”
3. “Professionalism in the Security Community, Part Deux (Clever Talkers)” , a must read for all in the community. It reminds me a bit of my “Myth of an Expert Generalist” and “On Media Whoring” (especially the latter…)
4. Mike wonders about log management and SIEM, but he knows the answer; he gave it himself (“SIEM still struggles (and it’s our own fault)”), others say the same (“The SIEM Market: Why Isn’t it Doing Better?”).
5. Rich posts some hot cloud stuff: “Cloud Data Security: Use” and “Cloud Data Security: Share”
6. The truth about complete 0wnage starts to seep out in the mainstream (“Heartland on Defense at Senate Hearing: Senator 'Astonished" That Breach Lasted So Long”): “Sen. Susan Collins, R.-Maine, asked Heartland CEO Robert Carr to explain how this delay happened. Carr responded that a breach is usually detected when the processing payer is notified of fraudulent use of cards, and that didn't occur until the end of 2008.” This means: “there is no spoon” … and here is no security industry :-(
7. “I’m Not Secure and You Can’t Make Me” from FUDSec. FUDSec exudes pure awesomeness. Enough said.
8. “Logs of Our Fathers” from Marcus Ranum is a must read for all loggies; quoted log entry: “Mouse climbed into the blower behind regulator rack, set blower to vibrating: result no more mouse and a !!! of a racket."
9. I found one more set of posts that I forgot to repost here, but they are very, very useful to read (but then again – most of Richard’s stuff is): “Black Hat Budgeting”  (“for $1 million per year an adversary could fund a Western-salaried black hat team that could penetrate and persist in roughly any target it chose to attack”) and “White Hat Budgeting” (“for $1 million per year a defender could not fund a Western-salaried white hat team that could plan, resist, detect, and respond to any $1 million black hat team”)  Read both and mediate on them for a while!
10. David Rice from “Geekonomics” (my review) fame, writes in his “An Absence of Leadership: Four reasons why leadership trumps compliance”: “Compliance, benchmarks, and checklists [A.C. - yes, they can!] can always help cybersecurity improve, but never enough to compensate for a lack of leadership. Far too often, in my opinion, organizations are relying on tightly scripted audits, consensus benchmarks, and information sharing to unite people around cybersecurity.”
11. Finally, new fun site devoted to social engineering, one of my fave subjects: “Nothing even close to the level of documentation required to treat social engineering like a science”

PCI DSS section:

1. “Why You Should Love A PCI Hater!” by Branden: “the majority of the individuals (normally falling into the first three categories above) hating on PCI are doing so out of a fundamental misunderstanding of the standard” and “If you think that the payment brands force merchants to store cardholder data, you might be a PCI haytah.”

Enjoy!

Possibly related posts:

• All other security reading posts.

Obligatory “added everywhere” posts :-)

• I am not at Qualys anymore and looking for the next big security idea to work on! I might be available for consulting projects, whenever I finish my current consulting projects.

Nobody Is That Dumb ... Oh, Wait XIII

For a while, I was looking for the next entry to my award-winning (eh..maybe) series “Nobody Is That Dumb ... Oh, Wait.” However, I didn’t expect this:

“in August a customer of the Rocky Mountain Bank asked a bank employee to send certain loan statements to a representative of the customer. The employee, however, inadvertently sent the e-mail to the wrong Gmail address. “

it gets better:

“Additionally, the employee had attached a sensitive file to the e-mail that should not have been sent at all.”

better still:

“The attachment contained confidential information on 1,325 individual and business customers that included their names, addresses, tax identification or Social Security numbers and loan information.”

even better:

“the employee “tried to recall the e-mail without success.”” [A.C. – now, success at that would have been totally world-changing….]

and reaches a crescendo here:

“the employee sent a second e-mail to the recipient instructing the person to delete the e-mail and attachment “in its entirety” without opening or reviewing it. The employee also asked the recipient to contact the employee to “discuss his or her actions.””

Ha-ha-ha-ha-haaaaar. This is stupidity at its absolute, highest best!

[source: Wired]

UPDATE: if you think the above was stupid... sit down. Breath deeply. It was just reported, that after the papers were filed the court SIDED WITH THE BANK and asked Google to deactivate an account of a person who received that mistaken communication from the bank... No, I don 't believe it either :-(

UPDATE: good news! Somebody sued Google over that.

BaySec on Wednesday, 9/23 (=Tomorrow)

Stealing the entire text  from Ryan’s email:

“The next Baysec meeting is Sept 23 at Kate O'Briens. Come out and
meet fellow security people from all over the Bay Area. As always, this
is not a sponsored meeting, there is no agenda or speakers, and no RSVP is needed.

See you Wednesday, Sept 23, 7-11 pm. The group will be towards the back.

Kate O'Briens
579 Howard St. @ 2nd, San Francisco

BTW, this time I will actually make it there! Seriously!

Is Risk Just Too Risky?

BlackHat made me think about risk a lot; I also had a bunch of fun conversations about that very subject. I had a chance to play both sides: for example to argue that “risk is a scam and risk management is voodoo” as well as to argue that “striving towards scientific risk computation is the most important pursuit in security today.” After all, that is what conferences are for..

So. Let’s start our discussion of risk from … compliance. The “enlightened security dogma” goes like this:

1. Audit mentality + compliance + checklist –> bad for security
2. Risk mentality + protection + risk-based policy –> good for security.

This comparison looks easy – pick #2 and you automatically join the club of deep security thinkers. Recently I was reading a document written by a noted security consultant and the document started (started!) like this: “1. quantify all enterprise risks.”  Apart from a loud ROFL and possibly even a ROFLMAO, such sentiment does not elicit any other response since few if any organizations can just go and “quantify all risks.”

Now, let’s try this comparison for size:

1. Audit mentality + compliance + checklist –> bad for security
2. Risk stupidity + protection of random assets with random safeguards + opinion-based policy –> ???? for security.

Not so easy now, huh? In other words, comparing the “evil checklist” to the “good risk-based approach” requires taking into account the current “state of the risk art” at an average (if there is such a thing…) organization. At least, I think that it IS required to keep this debate practical and not philosophical.

Thus, let’s see what can we do with risk:

1. Ignore risk: just ignore it, hide under the desk, read a PCI book :-)
2. Banish risk: read Donn Parker to learn everything about this approach.
3. Manage risk: this (as they say) requires you to first measure it since, presumably, “you can’t manage what you can’t measure.” So …
4. … Measure risk: this is where all hell breaks loose since there is no accepted approach for measuring risk in information security (for as long as you stick to the accepted definition of “measure”; and, no, “ALE” isn’t it :-)). Thus, some folks propose that you can just …
5. …Guess risk: this is where an expert defines what is risky based on his opinion. Approaches such as FAIR seek to replace guessing at risk with guessing at its constituents; they cannot be simply discounted as GIGO since they improve the quality of the guessing – while remaining such.
6. Reduce risk: this (as they say) does not require you to measure it. It also makes my head spin :-) since whenever I think about it I see a thermometer that moves up and down, but has no numbers or units. I still classify this as a special case of “guessing risk”: such as “Oh, I guess that lowers it!” or “No, that’d be too risky!”

In light of this, let’s do a simple test of “risk-based security.” So, dear risk aficionados, please give me the answer to a simple security question:

What is the risk-driven, correct frequency of changing my email password?

<crickets…. silence… more silence>

Yes, we all can quote that “PCI DSS says 90 days” or “whatever regulation says 30 days”, but what does risk say? What actuarial information we need - if we are to define risk through probability of loss? What info about my email usage? Value of information stored there? Frequency of attacks on other similar email accounts? Chances of attack success? My approach to protecting the password? My personal password reuse “policy?” Anything else? On a related note, maybe this is simpler: what is my risk [of having the account compromised] if I change the password every 30 days, 90 days, 300 days?

So, any idea how to go about it?

This little experiment might well show us that “risk-based security” is an awesome thing – but not one achievable in this world today…

Possibly related pots:

• Risk vs Risk
• Thoughts After Chicago “PCI Dinner” Panel

Obligatory “added everywhere” posts :-)

• I am not at Qualys anymore and looking for the next big security idea to work on! I might be available for consulting projects.

Fun Reading on Security and Compliance #18

Instead of my usual "blogging frenzy" machine gun blast of short posts, I will just combine them into my new blog series "Fun Reading on Security AND Compliance." Here is an issue #18, dated Sep 14, 2009 (read past ones here).

This edition of dedicated to all those who would do things for fun that others are paid to do.

1. At some point intruder will reveal vs defender cannot know all. “Response for Daily Dave”: “At some point the intruder is likely to take some action that reveals his presence”  vs “At some point, the intruder is in so deep that he cannot be removed, ever (source)”
2. Old, but excellent piece from Chris Hoff (Asset Focused, Not Auditor Focused) is worth a read (or reread)
3. “John Viega Talks About Beautiful Security” is a worthwhile read as well. I loved the book – and contributed to it as well.
4. Fun “security maxims” from ANL. Read’em. Quote: “Infinity Maxim: There are an unlimited number of security vulnerabilities for a given security device, system, or program, most of which will never be discovered (by the good guys or bad guys)” and “Thanks for Nothin’ Maxim: A vulnerability assessment that finds no vulnerabilities or only a few is worthless and wrong”
5. Dave’s “10 Things Your Auditor Isn’t Telling You” is pure gold; I am so ashamed of not blogging it earlier. Also read his “BS Filtering for CISOs: Vendors and Third Parties”
6. Good insight from “the Big G”: “3 Reasons The Security Market Is (Still) A Big Unconverged Mess.”  Whenever I hear about “consolidation,” I cringe… Gartner said it best: “don’t be fooled into a convergence story where one doesn’t exist.”
7. Is “ignore the risk” the same as “accept the risk”? Read here in “Treating risks.”
8. …. read “Nobody Hates Software More Than Software Developers” and many a mystery of the Universe will be open book to ya :-) Seriously!
9. “The Auditor’s Prerogative”: “In my 13 years of experience as an auditor, I have found that the people I audit do not tell the truth.”
10. “The Tangled Mess” from Dan Blum: “That IT is a mess probably isn’t news to you. […] What will happen when we try to move IT functions to the cloud?”
11. “Security Religions and Risk Windows” explores a good old question: protect everything a bit or protect something a lot. Right answer: both. Popular answer: neither :-)
12. “Legal Implications of Cloud Computing — Part One”
13. Very useful reminder: “On assuming that you are owned.” I used to like that theme a lot in the past – and it is still hot, since you are, obviously, more 0wned than a few years ago :-)
14. “Nao and Zen:  Security Koans for Everybody” is totally worth a re-read… Quote: ‘“There are no material findings,” said the master to the QSA, “since there is no material world.  All is impermanent in this world of the mind.”….’

PCI DSS section:

1. ‘'PCI and Fraud Analysis: To Have and Have Not” by PCI KB is very, very interesting: “Instead of PCI controls helping reduce fraud, for some companies, they are making fraud detection more difficult.”  Moreover, read his “Why PCI Has Not Reduced Fraud” as well. As well as “On The Other Hand, PCI Sometimes Actually Can Reduce Fraud”
2. “QSA Vendor Selection – Points of Consideration” – one of the known hard problems :-)
3. Recasting "Dowsing Your Way Through Enterprise Risk" is a fun read.
4. “PCI DSS Hosting – my new religion” – a very useful read: ““How are you guys going with PCI compliance”? - The response was “We looked into it and decided it wasn’t worthwhile””  :-(
5. How Market Forces Can Fix PCI is a very worthwhile read as well.
6. ““What’s an Acquirer?” And Other Noteworthy SME Questions” with the fave quote: “Small business owners may be too ignorant to ever be PCI compliant.”
7. A very, very fun PCI battle is here. Bob Russo himself had to come down to the trenches to tackle the opponent.
8. “PCI DSS and Incident Handling: What is required before, during and after an incident” (something I wanted to write for a long time, but he beat me to it :-)) - good read.
9. “Picking PCI's Locks” is a good piece from Pete": “PCI "works" if the risk-adjusted amount of damages is reduced by more than the cost of the audit.”
10. “Standards aren’t security: PCI compliance and Heartland’s data breach”  is a very good counter to all the idiotic whining about “PCI is not enough”, “NERCV is not enough”, “FISMA is not enough,” etc. No external standard is enough – please remember it now and forever!
11. Finally, random collection of fun PCI reads: “Why We Need PCI-DSS to Survive”, “Does PCI DSS Expose Risk Or Create It?”, “PCI Debate Ignores Planned Improvement Cycle”, “PCI Service Provider Contracting”, “TJX Settlement: More Proof That Security Investment Is Really Hard To Justify”, “4 Ways to Get the Most from Your PCI QSAs”  , “PCI DSS vs ISO 27001”

Enjoy! Now that I’ve FINALLY cleaned up all the 2blog links, I can finally get to that juicy “editorial calendar” I have created for my blog :-) BTW, I didn’t even know that I was in “10 Popular Security Blogs”  at blogs.com.

Possibly related posts:

• All other security reading posts.

Obligatory “added everywhere” posts :-)

• I am not at Qualys anymore and looking for the next big security idea to work on! I might be available for consulting projects.

Top PCI DSS Security Marketing Annoyances

I figured I’d offer some free consulting (via this blog post :-)) to all those folks that try to market some security thingy using PCI DSS.

As it happens, I just read one too many PCI-focused whitepapers and my annoyance at some vendor’s ignorance boiled over the top. This post is the result:

1. Don’t misspell PCI DSS. It is not “PCI DDS”, and even not “PCIDSS.” BTW, if you want to impress PCI literati, make sure that “PCI DSS” has a space, while “PA-DSS” has a dash.
2. Most definitely, do not pretend that you address ALL PCI DSS requirements for the only reason of wanting to look good.
3. You cannot “automate PCI.” Don’t market it and don’t sell it … or people will call you on it. Admittedly, you can automate a lot of it, but not all (think “policy and process”).
4. Please don’t say “PCI compliancy!” This is just another synonym of “I am a buffoon.” BTW, if you offer “free PCI compliancy”, then you are both a buffoon and an idiot :-)
5. Don’t call QSA (Qualified Security Assessor) “an auditor.” That “A” does NOT stand for “auditor” and PCI on-site assessment is not the same as, say, SOX audit.
6. Further, if you want to market to QSAs or ASVs, spent a few minutes learning what they actually do, which is which, etc. Helpful hint: QSA is not the same as a pentester :-( As per Requirement 11.3, QSA must ”obtain and examine the results from the most recent penetration test to verify that penetration testing is
   performed,” not go and ”just do it.”
7. “Ongoing compliance” theme is awesome. Sadly, a majority of your customers don’t do it like this (to their own loss – this why it is sad). They still have assessment-time rush, pleasing the assessor approach and checklist-oh-we-are-DONE! mentality. If you want to sell continuous compliance, you need to educate them first!
8. Don’t pretend that “PCI is about data encryption.” It is not! If you have to have some simple one-liner, use “PCI is about not having card data sitting around” instead.
9. Please don’t write whitepapers that are structured like this: “section 1: this is PCI”, “section 2: this is our shit”, “section 3": our shit is great” (and, no, it has only very, very tenuous relation to PCI DSS…). Specifically, don’t say “these are PCI-compliant features of our security product.”
10. If you mention cloud computing in your PCI marketing materials, think – very hard! - whether the rest of the content has ANY relationship whatsoever to it…
11. Finally, if you are building the dreaded matrix of how your product magically makes everything PCI compliant, try differentiating between features that directly satisfy requirements vs those that enable somebody to eventually reach compliance vs those that simplify compliance validation. Your users and their QSAs will thank you for it!
    
12. UPDATED (thanks Walt!) There is no such thing as "PCI certified" either. PCI validated is what you are likely trying to say. TO add to this, there are no "PCI validated" products, only companies or organizations.
13. UPDATED (thanks Walt!) Please also forget about "selling into PCI DSS market." This is simply your insanity talking :-) PCI might be a driver, might be some other motivation for buying stuff, might be the regulation du jour, etc. But it .. is ... not ... the ... market.

Overall, unless your goal is humorous relief of people working on PCI projects, please pay attention…

Enjoy!

Possibly related posts:

• All PCI DSS coverage.

Obligatory “added everywhere” posts :-)

• I am not at Qualys anymore and looking for the next big security idea to work on! I might be available for consulting projects…

Misc Fun Security Listens and Reads

Here is some hopefully fun content + random bits of self-promotion that I forgot to blog before. More blogging to come; I just finished responding to tech reviewer comments for the last chapter of the PCI book, so I will have more time.

• Anton Chuvakin on PCI DSS compliance, security and nonprofits (direct MP3 link to a podcast)
• A random fun interview with me here; please don’t bug me about my definition of “Enterprise 2.0” though :-)
• This is old (“PaulDotCom Security Weekly - Special Edition - PCI Round Table” aka “PCI Inquisition”), but sooo fun and absolutely worth a listen (sorry that it was stuck in my “2blog” queu for so long) – direct MP3 link.

Sadly, I still have snorkeling on my mind and not security and compliance :-)

Obligatory “added everywhere” posts :-)

• I am not at Qualys anymore and looking for the next big security idea to work on!

Workshop on the Analysis of System Logs (WASL) 2009

 

Just reposting the announcement for a fun workshop on logs.

Workshop on the Analysis of System Logs (WASL) 2009
http://www.systemloganalysis.com

Date: October 14, 2009
Location:  Big Sky, MT (at SOSP conference)

“System logs contain a wide variety of information about system status and health,
including events from various applications, daemons and drivers, as well as sampled
information such as resource utilization statistics. As such, these logs represent a
rich source of information for the analysis and diagnosis of system problems and
prediction of future system events. However, their lack of organization and the general lack of semantic consistency between information from various software and hardware  vendors means that most of this information content is wasted. Indeed, today's  most popular log analysis technique is to use regular expressions to either detect  events of interest or to filter the log so that a human operator can examine it manually.  Clearly, this captures only a fraction of the information available in these logs and does not scale to the large systems common in business and supercomputing environments. 

This workshop will focus on novel techniques for extracting operationally useful
information from existing logs and methods to improve the information content of future  logs.” (quoted from WASL site) 

Workshop Program

Session 1: Log Analysis Tools
       - "Extracting Message Types from BlueGene/L's Logs", A. Makanju, A. Zincir-Heywood, and E. Milios
       - "Incremental Learning of System Log Formats", K. Zhu, K. Fisher, and D. Walker
       - "Visual and Algorithmic Tooling for System Trace Analysis: A Case Study", W. De Pauw and S. Heisig

Session 2: Analyzing System Logs
       - "Mining Dependency in Distributed Systems through Unstructured Logs Analysis", J. Lou, Q. Fu, Y. Wang, and J. Li
       - "A Bayesian Network Approach to Modeling IT Service Availability using System Logs", R. Zhang, E. Cope, L. Huesler, and F. Cheng
       - "Endpoint Identification Using System Logs", S. Melvin

Session 3: Group Discussion on Current State of the Art
       - Tips and tricks in current use.
       - Gaps and challenges in current techniques.
       - Vision and steps for the future.

Session 4: Panel on Future Research Agenda
       - What are the most difficult problems with logging, in the real world?
       - How to make academia-industry interactions more productive?  [A.C. – will probably be very fun!]
       - How to extract meaningful information from logs?
       - How to improve system management?

More info and sign-up here.

On DLP, PCI and QSAs

Raise your hand if you know what “S” in the “QSA” stands for (hint here)?

<dramatic pause> <drum roll> <another, shorter pause>

It actually stands for “security.” “QSA” stands for a Qualified Security Assessor (and woe be on all who are ever to utter a phrase “PCI auditor”) and such definition brings up a picture of a dude who is out there assessing security.

So, what happens if said dude thinks that the security intent of a particular PCI DSS requirement in a particular merchant environment calls for deploying a DLP (Data Leak/Loss Prevention/Protection) solution, whether for protection or for data discovery only?

This thoughtful discussion actually started here (“The QSA Conundrum”, please read the comments too) when it was reported that a QSA suggested that the merchant run a data discovery tool to find files containing card data outside of the defined in-scope environment.

As it is common with PCI nowadays, such situation caused non-trivial outrage from both sides of the debate (!). Specifically:

• “Darn those evil QSAs who ‘invent’ requirements” - whether out of desire to sell stuff or out of being ‘overzealous’ or out of fear of ‘QSA police’ .. eh… QSA QA
• “Darn those evil QSAs who practice ‘checklist security’” – whether due to not knowing better or out of being ‘easy-graders’ or out of fear of being replaced.

So, is this "inventing requirements through implication” (=bad, results in unneeded stuff being bought) vs “following the intent, not the letter” (=good, results in useful security improvements and compliance)?

My gut tells me to be on the side of the QSA who helps reduce risk by suggesting scanning for card data, but my brain tells me to wait and analyze it. So, let’s try to analyze it a bit.

Back in the day, I said  (“A Few More Words on DLP and Compliance”) that DLP vendors underleverage PCI DSS and compliance in general in their marketing due to lack of direct mention of DLP in the mandates: “DLP is newer than  most regulations (PCI DSS, HIPAA, FISMA, etc) and the documentation for these mandates just doesn't mention DLP (or CMF) by name.” That means that there is no specific checklist item to check on that. Obviously, DLP can be useful for data security, but people who treat PCI DSS as gospel (or even – the horror! – as ‘enough security’) will probably not buy it. On the other hand, those who use PCI to help their security and not just something to “shoot and forget” are more likely to get it and utilize it effectively.

For example, check out this PCI Knowledge Base entry: “We are a service provider in the travel industry. […] PCI had a big impact on how we spent our security dollars in 2005 and 2006, and still has an impact today. We would not have DB encryption or Data Loss Prevention (DLP) and other security tools if it weren't for PCI.” This also seems to indicate that “90 percent of [DLP] deployments are for compliance purposes (PCI, HIPAA) rather than for the protection of Intellectual Property.”  As a result, I see DLP vendors starting to lean more on compliance to sell their wares. For example, nexTier networks (where I am on the advisory board), just launched Compliance Enforcer, which is a compliance-focused DLP box. Finally, DLP boxes make good compensating controls in some cases (but more on this in the future).

However, the argument of the other side has merit too: QSA’s magical powers wane at the border of the in-scope environment. It is ultimately merchant’s responsibility to define where it begins and ends, based on what PCI DSS document says. This means that a merchant cannot force their QSA to ignore that big database server which stores all the card data, BUT the QSA cannot force the merchant to include that desktop which is properly segmented from the cardholder environment. Even if due to a bizarre twist of fate this desktop contains 200,000 PANs in CSV format…

So, what is the conclusion:

1. Listen to your QSA even if he suggests something that you don’t think is “mentioned in DSS” and evaluate how/whether this helps you secure the data – think about it as “free services from somebody who otherwise charges $300/hr”
2. Next, argue with your QSA if he states that some solution is “mandatory” and – you are in luck! – his company happens to sell it too.
3. Ultimately, the decision is YOURS, not your QSAs! This, BTW, applies to both “right” and “wrong” security decisions. You get to live with their consequences!

There is no way to give a more precise answer: PCI is neither “a pill against stupid” nor “a silver bullet” for all things security.

Possibly related posts:

• Fun Views on DLP
• In Passing on DLP
• So, CAN We Have DLP?
• A Few More Words on DLP and Compliance
• DLP Works – If You Know What “Works” Mean!

Obligatory “added everywhere” posts :-)

• I am not at Qualys anymore and looking for the next big security idea to work on!

“PCI Compliance” Book on Amazon!

This is the big day in any author’s life: the release of the Amazon entry for the upcoming book.

Ours (Branden’s and mine) just came out:

PCI Compliance: Understand and Implement Effective PCI Data Security Standard Compliance by Dr. Anton Chuvakin (Author), Branden R. Williams (Author)

Time for a wild celebration! The cover art might change, the typos will get corrected, but all the champagne will be finished by then :-)

I am not trying to hint at anything :-), but here is the "buy the book" link:

And, of course, time to thank fine folks at Syngress/Elsevier for making it a reality!!

BTW, we are working on a super-cool website to go with it, but it is a complete secret yet :-)

Monthly Blog Round-Up – August 2009

As we all know, 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. 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. Obviously, “A Myth of An Expert Generalist” post wins with a HUGE margin. Nothing to say here – go read it.
2. My change of employment (well, a change from employment to unemployment, that is :-)), covered in “Not at Qualys Anymore” wins the #2 spot this month.
3. Why in the unholy name of cosmic chaos is this post here? :) “BlackHat 2009 Inspired – On Media Whoring” seems to have attracted a lot of readers, despite looking mostly like a rant. BTW, it was not – but it will only be clear in the future…
4. I am no longer surprised that “Why No Open Source SIEM, EVER?” “rules the seas”, taking the spot in TOp5 this month again. The older inspiration for this post is “On Open Source in SIEM and Log Management.”
5. Since Heartland saga is alive again (Zombie ALERT!!! :-)), the post “On Heartland VI” is in this month’s top. Read the rest of the saga coverage in that post.

See you in September. Also see my annual “Top Posts” (2007, 2008)

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

• 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 am not at Qualys anymore and looking for the next big security idea!