Wednesday, March 17, 2010

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:

Tuesday, March 16, 2010

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:

Monday, March 15, 2010

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…

Friday, March 12, 2010

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!

Monday, March 08, 2010

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!

Thursday, March 04, 2010

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++"

Wednesday, March 03, 2010

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, 20082009!

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:

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.

Monday, March 01, 2010

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:

Saturday, February 27, 2010

Short Observation on Open Source SIEM

Check out these two pictures, grabbed from my blog’s Google Analytics:

open_SIEM_2008-2010 open_LogMgt_2008-2010
Open source SIEM Open source log management 

These show that people are desperately looking for “open source SIEM” all the time.  In fact, open source SIEM is of higher interest than open source log management. I am really curious about that, but my guess is that folks who are looking for open source logging tools don’t think of them as “log management” in their heads… Vendors, buy me a beer at RSA for this insight :-)

BTW, the next few posts will be about RSA conference– all other blogging activity is hereby STOPPED :-)

Possibly related posts:

Thursday, February 25, 2010

RSA 2010: Where to Find Anton?

Since everybody is  heading down (…up or sideways – in my case) to RSA, here my schedule. If you want to meet up, it will help you to track me down.

  • Monday: Metricon 4.5. Sadly, missing the Cloud Security Summit. Is there anything more important than cloud? Yes, security metrics! :-)
  • Tuesday: mostly meetings with clients, prospects, friends and everybody else. I plan to attend a few GRC-themed RSA presentations in the afternoon.
  • Wednesday: at SecurityBSides, speaking on PCI DSS and otherwise having fun. Come say hi if you are there! Obviously the way to end this day is at the famous RSA Security Blogger Meet-up.
  • Thursday: attending RSA, more meetings with prospects and friends, and – YES! - our PCI DSS book signing (!!!). Come have your PCI book signed by BOTH Branden and me (a rare event indeed!) at 1PM at the RSA bookstore.
  • Friday: yet another day of meetings and RSA presentations.

BTW, we […for any value of ‘we’] totally need to bunch up and do a vendor hall walk – if for no other reason but to make fun of vendors with incompetent marketing, look for hippos (=misspelled HIPAA) and “compliancy” as well as other fun stuff. Maybe this year I should finally organize the “1st Annual RSA Vendor Hall Walk”, especially given that I do not work for a vendor anymore

Tuesday, February 23, 2010

Nobody Is That Dumb ... Oh, Wait XII

RSA is that time of the year when a lot of otherwise hidden hilarity is suddenly exposed – thru the work of noble PR folks. For example, below is a pre-RSA press email I received the other day – it made a perfect candidate for my “Nobody Is That Dumb ... Oh, Wait” series. The last post in the series was a while ago, so this was a perfect opportunity to revive the series.

“I know your time at RSA is filling up, but I wanted to tell you about “Embarrass Security” [company name sanitized – A.C.], a company that is changing the way companies protect their web properties. “Embarrass Security” is going to be at booth No. XXX [sanitized – A.C.] during RSA and will be:

  • Announcing a new ‘counter-hacking appliance’ for enterprises
  • Demonstrating a ‘live hacking & sting operation’  demonstration in the “Embarrass Security” booth (with the disclaimer that no animals will be harmed in the production of the demo)

With the counter-hacking appliance, “Embarrass Security” will demonstrate the ability to alert companies when hackers are knocking at the door, and can also show how they thwart evil intentions by making sure the hackers don’t actually see what they think they’re seeing. “Embarrass Security” enables enterprises to protect their web properties at a deeper level that even the bad guys can’t touch.”

Nothing to add really.. let’s all go buy the “counter-hacking appliances,” thwart some evil intentions and be done with it :-)  I can’t help but wonder what kinda people work for their product management / marketing team…

Possibly related posts:

Saturday, February 20, 2010

Book Review “Cloud Security and Privacy”

Amazon just posted my review for “Cloud Security and Privacy” by Tim Mather, Subra Kumaraswamy and Shahed Latif.

It is reposted below for posterity – and my esteemed blog readers :-)

It goes without saying that I was very excited to pick up the first book on cloud security and privacy. Due to my Cloud Security Alliance (CSA) involvement, I was extremely interested in Tim’s take on the subject. The book is indeed a comprehensive treatise on everything cloud, and everything cloud security. The author team covers the topics based on IaaS/PaaS/SaaS (SPI) for infrastructure, platform, and software as a service model. They address stored data confidentiality, cloud provider operations, identity and access management in the cloud, availability management as well as privacy. My favorite chapter was of course the one on audit and compliance - chapter 8. Another fun chapter was chapter 12 on conclusions and the future of the cloud (which is, BTW, all but assured…).

One of the most important things I picked from the book was a very structured view on separation of security responsibilities between the cloud provider and the customer for all of the SPI scenarios. This alone probably justifies getting your own copy.

As far as technical contents, the book stays fairly high-level even though it touches on the details of SAML and other authentication protocols.

The only downside of the book is its extremely dry writing style. There are only a few examples and case studies. Following “just the facts” model sometimes might lead the reader towards losing interest, no matter how important the subject is – and this subject is pretty darn important. To put this in the context, I do read security books for fun, not only for work.

Enjoy the book!

Possibly related posts:

Workshop on the Analysis of System Logs (WASL) 2010 CFP Out!

Just as last year, Workshop on the Analysis of System Logs is planned. This is the only venue where people who actually THINK about logs can share their findings. Even though it felt a little too academic to my taste at times, 2008 and 2009 events brought some good info (like this gem here, for example). So, a 2010 CFP just came out:

“Workshop on the Analysis of System Logs (WASL) 2010

    http://www.systemloganalysis.com
                        Call for Papers
                ===============================
                      October 3, 2010
                      Vancouver, Canada
                          (at OSDI)
                ===============================
          FULL PAPER SUBMISSION DEADLINE: Sunday, June 13, 2010 
          FINAL PAPERS DUE: Sunday, August 22, 2010
--------------------------------------------------------------------------
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.
Topics include but are not limited to:
   o Reports on publicly available sources of sample log data
   o Log anonymization
   o Log feature detection and extraction
   o Prediction of malfunction or misuse based on log data
   o Statistical techniques to characterize log data
   o Applications of Natural-Language Processing to logs
   o Scalable log compression
   o Log comparison techniques
   o Methods to enhance and standardize log semantics
   o System diagnostic techniques
   o Log visualization
   o Analysis of services (problem ticket) logs
   o Applications of log analysis to system administration
So, if you are thinking about logs, submit something!!!
Possibly related posts:

Wednesday, February 17, 2010

“Security Scoreboard” Out!

Something awesome happened in security industry today: Security Scoreboard  launched.  I am amazed - no, deeply amazed! - that nobody has thought about this before. And now Boaz did! Security Scoreboard is a place where information about all the security vendors and products will be aggregated, where products will be rated by users ("this half-baked IPS totally misses Slammer even it slams it in the head!” :-))  and that will help organizations decide which product solves a particular security problem they have. On top of this, the place will not be run by the vendors. And will list competitors explicitly. Think about a Zagat for security products, that is what it is.

In my opinion, Security Scoreboard is one of  the most useful projects in the entire security industry today since it  helps answer that painful question “What security gear to buy to solve a specific  problem?” Deep down, every security professional knows that many purchases “miss the mark” (provided the mark is even there to begin with…) and there is a lot (ah, let’s be honest: A L-O-T!) of confusion about overlapping market segments, poorly defined functionality, compliance marketing noise, etc. In some cases, it is hard to even determine what their freaking box does based on the vendor's own website...

Quote from the site follows:

“Finding the right IT security vendor can be time consuming. Security Scoreboard is a site dedicated to helping security pros looking for a vendor to get oriented quickly.
On Security Scoreboard, you will find all the information security vendors you might be considering buying from. Security Scoreboard lets you quickly identify the players in a given space and provides information and links you need to make the right purchasing decision. Security Scoreboard is a site for security professionals, by security professionals.
Thinking of making an IT security purchase? Don't forget to check our user reviews to make sure that you're not buying a lemon. Are you an IT user? Please submit a review. You can share your experiences and help your colleagues make the right purchasing decision.”
To experience it, check out this sample entry. Also, the site got some interesting press which you can see here.

Finally, I have to add that I am honored to participate in such tremendously useful project!

Monday, February 15, 2010

Fun Reading on Security and Compliance #23

Here is an issue #23 of my “Fun Reading on Security and Compliance,” dated February 16, 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 consulting projects.
This edition of dedicated to all bloggers who only care about the opinions of other bloggers. Please grow up! :-)

  1. First, I’d like to highlight a surprisingly intelligent whitepaper "SIEM: Five Best Practices for Success" from some outfit called Pivot Point Security (which I personally never heard of before).  You have to register to get it, but it is worth it for those who are planning to deploy a SIEM.
  2. "Ranum's Rants: Cloud Forum Roundtable": Marcus Ranum + Cloud + Security. What can possibly go wrong? Boom! Quotes: "Cloud Computing is going to happen. In fact, if you think it hasn't happened, it just means you're out of the loop"  and "loud Computing can be seen as the business units' final revenge on IT (and security) for saying "no" one time too many, taking too long, or costing too much"  as well as other fun insights. Read it!
  3. Finally, read this("Don’t ask me, ask that guy over there") and think really hard: "How many organizations out there consider data breach notification laws to be completely irrelevant to them?  Not because they aren’t applicable, but because the organization’s security state is so abysmal that they wouldn’t know a data breach if it sent them a strippergram with their own money? " or even "You’re ignoring the vast majority of people who are responsible in some way for the security of their networks, but (a) don’t know it, (b) don’t care, and/or (c) don’t have the knowledge or management backing to do anything about it."  SO, next time you whine about PCI DSS, keep that in mind!  BTW, while you are there, read this too on political risk.
  4. FUDSec continues to impress; for examples read these two pieces: "FUD and Other Sales Errors" and "FUD Just Feels Right" ("FUD is something we all use, abuse and understand and it is a Good Thing[™] as long as it motivates action and does not lead to submission.").Oh, and this one too: "Guerilla Security Leadership."  And this one: “he argues that FUD is less about security, and more about shills selling security to suckers” and “Why, without a firewall, you're screwed like a slow ape by a fast gorilla!”
  5. Somehow I forgot to mention Ben's "How NOT To Build a Security Program" is a fun read. While on this subject, read “Top 10 Reasons Your Security Program Sucks and Why You Can’t Do Anything About It”: “The bad guys are more interested in attacking you then you are in defending yourself, at least they work longer hours.”
  6. Cloud: Security Doesn’t Matter (Or, In Cloud, Nobody Can Hear You Scream)” is a good piece from Chris Hoff: “Manage compliance, don’t let it manage you because a Cloud is a terrible thing to waste.” :-)
  7. If you read only one piece from all the APT/Google/China crapfest, that’s this one from Richard: “4. The victim named the perpetrator. This amazes me. We need more of this to happen. By doing so a private company influenced a powerful policy maker to issue a statement of a diplomatic nature.”
  8. Finally, a quick – but often useful - reminder from Securosis: “Getting Your Mindset Straight for 2010.” Quote: “Repeat after me: A widget will not make me secure. Neither will two widgets or a partridge in a pear tree.”
  9. Dave always has a very fun prospective on security, here is an example: “Everyone says an attack is "sophisticated" whenever any 0day is involved. But that should be the baseline. Or rather, it IS the baseline and everyone seems to just be finding out.”
  10. AlertLogic folks has quietly launched SecureCloudReview.com  and it has some fun posts, like “Cloud-Bashing and The Innovator's Dilemma”: “The most relevant points of debate are about current examples of the fits and starts of cloud evolution.  Will cloud solutions succeed in "trickling" up-market or will they become extinct after a short life?” (they will trickle, for sure - example)
  11. Read these two and weep: “Is Quantified Security a Weak Hypothesis?” (which refers to this [PDF])  and “THE MOST MAGICAL QUESTION OF ALL -- WHY ARE SO MANY BRIGHT PEOPLE FOOLING THEMSELVES ABOUT THE SCIENCE IN NFORMATION SECURITY”: "Read that if you think there is a place for science in information security. On the other hand, if you think information security is something else, better off to go read something on creative journalism, public relations, politics, marketing, etc.”
PCI DSS section:
  1. Fun follow up from our “The Great PCI Security Debate of 2010” is here: “LOAD UP ON STEEL, AND SHOOT IT OUT! PCI AND THE MARKET FOR SILVER BULLETS”: “By way of hypotheses in the market for silver bullets, we then find ourselves seeking to reduce the exposure to those external costs; this causes the evolution of some form of best practices which is an agreed set that simply ensures you are not isolated by difference.”
  2. Heartland Breach: State of Payments Security 1 Year Later” is a fun read as well.
  3. If you have a Forrester subscription, read “PCI Unleashed” by John Kindervag. If not, read Branden’s blog about it: “Just try asking a rep from a payment brand if this is why PCI DSS was started, and you might learn a new way to answer a question without actually answering it.” :-)
  4. Time to Revisit Intent of PCI DSS”  has some curious arguments, like: “When you add up all the money being spent on that compliance effort, you can’t help but wonder if it would be simpler and less expensive for all if the payment card issuers were to stop doing business with a minority of merchants that become embroiled in a fraudulent act until they can prove that they have put the appropriate level of security in place.”
  5. PCI Security Policies and You - Part 3” from Walt shares some wisdom on PCI DSS security policies: ”A good security policy template provides you with a structure while preserving flexibility. It also should lead you to additional resources where this can be useful.”
Enjoy!
BTW, I can use a bit more work in March – let me know if you need anything done around the area where I focus: logs, SIEM, etc.
Possibly related posts:

Sunday, February 14, 2010

The Right Place for Information on Common Event Format

… is this place: http://www.arcsight.com/solutions/solutions-cef/ This is where you can request it via email.

image

The reason for this post? A lot of Google search traffic for “common event format” lands here on my blog (see picture) and the link above is the correct place to go to.

Now, if those are generic searches looking for some kind of log or event format, then you want CEE (when we finish it, actually)

Possibly related posts:

Wednesday, February 10, 2010

ShmooCon 2010 – Our PCI DSS Panel

It goes without saying that our PCI DSS panel was – for me – the most fun part of ShmooCon 2010. Yes, spectator sports are OK, but the most fun is had when you are playing and kicking the ball – or balls as the case may be in a heated discussion :-) So, Mike Dahn, Jack Daniel, Joshua Corman – over video Skype! he got “snowed out” – and me got to play.

Everybody who’s been to ShmooCon, can easily figure out that the audience there is extremely smart – I sensed there were no “security laggards” in the room. So what happens if you combine PCI and some smart security people? Rage! In fact, we had people from large merchants, QSAs, issuing bank (!) and other organizations. I am amazed that even some non-PCI folks, who can’t tell a QSA from an SAQ found the discussion enjoyable…

It was very interesting to watch that the debate split into two distinct flows: “security vs prescriptive compliance” AND “fuck PCI, they [the brands] must fix the system.” The latter sentiment was very strong, like the Dark Side of the Force (even though there is absolutely nothing dark about it…). It ranged from “why don’t they fix it [the payment system]? they have billions in profit!” (naive) to “if 4 millions of people put the Band-Aids on, is this cure for cancer?” (philosophical). The impression that PCI DSS approach is “too much work” even if good security results from it – which is …how should we put it… not always the case… was also represented. Given the circumstances, it is evident that the view that PCI DSS is many companies’ first encounter with real security management kinda was not very visible…

Also, I always felt it for the issuing bank guys, since they were often left holding the bag for ignorant merchant (TJX anybody?) and unlucky processors or acquirers (Heartland anybody?). But I didn’t expect the present issuers to be so angry at the brands – and not at the merchants! Well, learn something new every day…

The other discussion that even if “checklist security” is offensive to some people, it is the only way to many organization to actually do something. A lot of “risk management stuff” just goes – whooosh! – over their heads. IMHO, this is still an unsolved problem.

Also, somebody very smart in a red blouse :-) said the following: even if we “do everything perfect with PCI DSS”, we will only solve the problem of cardholder data…not any other data (like SSN or key IP) and not any other security issue. Indeed, if PCI DSS magically “just works” and payment card security “becomes 100% secure” , a lot of security work will remain. This is something useful to keep in mind.

I don’t remember signing any NDAs, so I will share some of the reviewer comments that I got from the ShmooCon feedback system (BTW, if you were at the show, please leave the feedback!!)

“Best panel discussion of the con. You could tell there wasn't agreement amongst the panel but the disagreements weren't made personal. Mike and Josh did a great job in explaining their positions and Jack did a super job moderating.”

as well as:

“This dissolved in a religious argument 30 seconds into the talk.”

(in reality, it was maybe 20 minutes into the talk :-))

Overall, the panel was “awesome+” We even took one question from the Internet, something I have not seen at other sessions. Looks like that live video feed was not broadcast in vain… So, watch the video when [correction: it appears that the correct word is “if” here…] it comes out – VERY fun!

BTW, I had an Eureka moment when I spoke to Josh after the panel – deep thought warning! – if we think that the only way to get some merchants to secure their system is to force PCI DSS on them, then how can we expect for them to do a good job with it and not just “check the box”? “Forced standards” and “doing a good job” are hardly compatible.

Finally, thanks to my publisher for providing a copy of the PCI book for the event. I had a chance to wave it at the audience a couple of times :-), but in all the excitement I completely forgot that I wanted to give it out via a contest (FAIL!). In any case, a well-deserving person got the book.

Possibly related posts:

Tuesday, February 09, 2010

ShmooCon 2010 – Show Notes

First things first: ShmooCon was one of the most awesome conferences I attended in quite some time.

If you’d like to see what REALLY was going on as Washington, DC was plunging into a “snow-pocalypse”, go check out #ShmooCon Twitter coverage. Then read other show accounts, such as this one from PaulDotCom.

My note follow below:

First, Bruce’s “intro” was kinda interesting.  For example, he made a couple of TSA jokes (the video was hilarious) and noted that “if you think this is funny, then you’d see that network security is actually worse.” What was interesting to me that he also noted that many organizations prefer to “buy new boxes” rather then do something useful, like log “accepts” and “allows” and analyze them.

Then I went to “Social Zombies II: Your Friends Need More Brains.” This was one of those “shit is bad” presentations. Maybe it’s just me, but somehow the idea that some people disclose too much info (Blippy anyone? Anyone sane? Heloooo…)  fails to scare me.  No shock value really. It can be summarized as "info is out there. done."  Then again, I have to admit that their “KanyeWestify” tool was pretty cool and I downloaded the Maltego tool already, so it was pretty useful (Twitter+Facebook+text mining tools = hilarity! :-)). More coverage of it is here and the deck is here.

Now, “GSM: SRSLY?” talk was massive fun. For one, I had no idea that a [relatively simple] piece of hardware can both capture all local cell phone connections (by easily masquarading as AT&T or T-Mobile)  AND force them into A5/0 mode that means “no encryption – and you don’t know about it.” So, as I said, I didn't know much about the area, but this talk was very enlightening, useful and overall awesome.

Ah, “Build your own Predator UAV @ 99.95% Discount” talk was fun as well. Think what you can do with an autonomic, mostly quiet robot plane that can fly around (10-12 mile range) and do some wireless hacking and video (via video goggles, of course). No missiles though. What can possibly be more awesome than that? Check  out the partial video of it here and many of the UAV building tips are here.

The next presentation was my only disappointment, the  “Cyborg Information Security: Defense Against the Dark Arts” talk. Think of this as Dan Kaminsky, but with no issue described in detail and no Dan Kaminsky :-) Yes, some implantable medical devices are a) wireless and b) unencrypted. This is sad. So what?  But "This shit is bad! FAIL! Epic fail" summarizes the talk well. Not useful, not really amazing - and, honestly, not really shocking either. And as my opinion of the talk was going down – they misspelled HIPAA. At which point I realized: these guys built the talk based on some googling and no real research at all. FAIL! Epic fail! :-)  In some post-show conversation, I actually tried to defend the talk as “raising awareness”, but was beat up by other folks, most of whom labeled is as content-free and aimed only as some posturing.

The Splendiferous Story of Archive Team and the Rapidly Disappearing Digital Heritage” rant was purely that – a rant. But it was 5PM, people were tired and needed a drink – and a rant :-) So it was a perfect fit for the occasion. Apart from reminding everybody about backup (and if there is one thing that everybody always needs a reminder of – that’s backup! I am backing up my laptop as I am typing this :-)), Jason basically talked that some web content just dies – think GeoCities. More details are here.

Even though I am not a web hacker, “Exposed | More: Attacking the Extended Web” aka “owning the APIs” talk was actually very interesting – and useful. I wish he’d speak more about methods to discover undocumented APIs though.

Next – OMFG! – was our “PCI" panel” – but let me first finish with other’s talks and I will write a whole post on that tomorrow.

Also, I went to “Pulling the Plug: Security Risks in the Next Generation of Offline Web Applications” by the zScaler guy and learned about csSQLi  and other interesting offline apps stuff. HTML5 will make security fun again – eh.. that is if it is not fun enough for you know :-) That talk – IMHO – was how “a new security issue”-type talk needs to be presented: with details and ideas for solutions. There is enough of fun and epic FAIL in our realm, but the talk was not just whining about it, but actually taking it apart and showing areas of concern.

Finally, as with any great conference, “hallway conversations” are golden. This time I broke the record and probably deserve the Guinness record book inclusion: on the last day of the show I was involved in – srsly! – a 9 hour (!!!) such conversation. It will probably result in a dozen blog posts, a few papers, a few consulting projects  and some other interesting implications…

The usage of word “fun” count: 8

Thursday, February 04, 2010

Logging, Log Management and Log Review Maturity

This picture depicts log management and SIEM maturity curve and is taken from a soon-to-be-released [eh..make that when-my-consulting-client-decides-to-release-it] Guide to SIEM and Log Management. It says it all – and if your organizations tries to enter in the middle…well... FAIL happens:

LogFLow_ignorance

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Enjoy!

Wednesday, February 03, 2010

Monthly Blog Round-Up – January 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. As predicted, my security predictions ( “Security Predictions 2010” and “Security Predictions 2020 (!)” - yes, 2020!) took the #1 spot this month. They are fun – but I will also check how well they panned out early next year. Then we will know who is laughing :-)
  2. How to Stay Compliant? or Ongoing Tasks in PCI DSS,”  a repost of my paper published at EthicalHacker.net was next. Indeed, “getting compliant” is only half the fun (actually, getting validated is only 1/3 of it :-))
  3. SIEM is on a lot of people’s minds. That is why ““I Want to Buy Correlation” or How NOT to Pick a SIEM?” is on the hot list. BTW, I am planning more of “how not to buy a SIEM?” posts…
  4. Top Log FAIL!” is still hot! The post summarizes the most egregious, reckless, painful, negligent, sad, idiotic examples of “Log FAIL.”
  5. MUST-DO Logging for PCI?” took the next spot. BTW, there is a newer post on the subject of PCI DSS logging requirements: “More on PCI DSS and Logging.” This, BTW, has been the main goal of some of my recent consulting projects. Should I maybe talk about “PCI logging in the cloud” next? :-)
  6. Open source SIEM theme continues to drive a lot of traffic – 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. BTW, the funny (and new!) part is that I see more queries for “open source log management” as well.
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. Dancho Danchev
  2. Walt Conway
  3. Alexey Babenko (in Russian)
  4. Richard Bejtlich
  5. Gunnar Peterson
Thank you for all the link-love!
See you in February; also see my annual “Top Posts” - 2007, 20082009!
Possibly related posts / past monthly popular blog round-ups:
Obligatory “added everywhere” posts :-)
  • I might be available for fun consulting projects related to logging, log management, SIEM, PCI DSS etc. Please see the services list at my consulting site.

Tuesday, February 02, 2010

Live Test of FUD Value: Pro/Con?

Can you achieve “security goodness” (and common good) by FUD and [possibly] stretching the truth? Let’s debate this one!
The story started here with this letter from an unknown-but-now-infamous PoS (=point of sale aka cash register – for the non-PCI crowd) vendor about using Windows 2000 after Microsoft EOL’s it and no more security updates come. The letter makes an argument that any OS no longer supported by the vendor will be automatically out of compliance. StorefrontBacktalk, that covers retail tech (and payment security), has a good story on this here. They say:

“For your overflowing folder marked “Ludicrous PCI Scare Tactics That Too Many People Believe” comes a renewed effort from some security vendors to say that out-of-date operating systems this year will cause instant PCI non-compliance. ”
So, the statement about “no security patches –> no PCI compliance” clearly does not hold water. It is what is known as “a lie.” Compensating controls can definitely be used in this case and PCI Council even has a FAQ entry about this very subject (quote: “Systems that use operating systems that are no longer supported with new security patches by the vendor, OEM, or developer are not necessarily out of compliance.”)
However!
While embedded and highly “cut down” Windows 2000 can be “made secure” (with whatever definition: secure enough to run while directly connected to the Internet) even in the absence of patches (especially if some whitelisting software is deployed), I personally will trust neither a typical merchant nor a typical PoS vendor to actually do it. If I were a QSA in this case, I’d accept heavy OS changes plus no user access plus host firewalling plus application whitelisting as adequate compensating controls. However, I doubt that this is the case for most of those “W2K holdouts.”  So, IMHO, that outdated stuff “must die” since it puts everyone at risk (think: botnets). If their W2K install dies together with the merchant – then so be it.
Overall, many security folks treat merchants resisting PCI DSS as either stupid or malicious and irresponsible (or both). The merchants, on the other hand, are simply trying to survive and run their businesses. However, at what cost to society? Every one of those W2K boxes CAN BE (and, in many cases, probably IS) used to attack other sites (think: SCADA) and spread malware. Still, is lying the right tactic to get them to upgrade?
For me, this is a hard call to make.
What do you think? “Go FUD!” or “Truth and W2K Rulez!”?
Possibly related posts:

Top Nine Reasons How PCI Is Like APT

UPDATE: this is HUMOR! HUMOR!! HUMOR!!!

It all started from this tweet: “if you read on #PCI and #APT on the same day, you get some pretty darn interesting high.” Some more …mmm…thinking about the subject resulted in this blog post.

vs

BTW, everybody knows what PCI DSS is, what about APT? APT is “Advanced Persistent Threat”, an acronym with a murky past (some say going back to 1876…) that is used to label “some advanced bad shit that just doesn’t go away” – yes, it is that vague. Some fun discussion about it can be found here, here and here and of course here.
So, how is PCI like APT?
  1. “P” in “APT” stands for “persistent”, “P”in PCI stands for … well … PCI is pretty darn persistent.
  2. Both are absolutely a threat, whether of non-compliance or of severe 0wnage…
  3. “Nobody would ever find that we lied on our SAQ” is said sometimes in PCI, and “no APT will want to hack us” is often said about APT.
  4. People under PCI sometimes do not want to update their anti-malware defenses, because they say “it is too hard.” People under APT often also do not update their anti-malware because… hey… what’s the point?
  5. “A” in APT stands for “advanced,” PCI is pretty advanced stuff for some people who have to be compliant with it (think: your neighborhood gas station)
  6. With PCI, you don’t always know what you need to do; with APT you almost never know what to do.
  7. Also, you are never “done” with PCI, you need to maintain compliance and security; you’re absolutely never “done” with APT.
  8. PCI compliance requires logging and monitoring; dealing with APT absolutely requires extensive logging and monitoring.
  9. People refuse to deal with PCI because they do not believe that anything bad will happen to them, similarly people refuse to deal with APT since they don’t know that APT has already happened to them.
Enjoy!

UPDATE: an awesome follow-up "Why PCI and APTs are NOTHING alike" from Cassandra Security.

Possibly related posts:

  • All posts labeled humor.

Dr Anton Chuvakin