Tuesday, October 26, 2010

“So, What Should I Want?” or How NOT to Pick a SIEM-III?

So, what should I want?” – the allure of asking that question is truly irresistible when dealing with somebody who – presumably – knows more than you do about a particular subject. Lately, I experienced its force first hand when dealing with various contractors on swimming pool, flooring, A/C, remodeling – all new to me due to purchase of our first house. These insane words just roll off your tongue after a contractor explains 57 floor board options or 4 types of swimming pool heaters.

In light of this, I am not shocked when a SIEM prospect asks that question of a vendor sales guy or – slightly better – a field engineer. Have you ever caught yourself asking  questions like:

  • What log data I should collect first?
  • What are the best reports I should run?
  • Which correlation rules I should enable?
  • What data I should search for?
  • What is the best access control policy for my SIEM implementation?

That stuff happens out there every day! Despite all the evangelizing about “business requirements”, “use cases”, “focus on problems solved” and other words and phrases of wisdom, a lot of SIEM is purchased as described above.

Dear vendor, tell me what should I want?!

And you know what? If your organization is truly committed to the cause of furthering world’s idiocy, that may work! Asking the vendor is BETTER than just choosing at random (as I discovered with some of my house-related chores). Yes, on average, you’d get suggestions towards more expensive stuff (surprise!!), but vendor research + vendor opinion (IMHO) are better than no research + random choice.

And of course! The above point about that working (occasionally, somewhat…) does NOT remove the simple fact that:

THE RIGHT WAY TO PROCURE A SIEM IS STILL …

… THINKING ABOUT YOUR REQUIREMENTS AND THEN YOUR USE CASES. And then choosing a product.

Still, evil allure of “please tell me what I want?” is very hard to resist when looking for SIEM and log management tools.

BTW, On Choosing SIEM  has the “less wrong” way described in more details.

Possibly related posts:

Enhanced by Zemanta

Wednesday, October 20, 2010

Security Scoreboard Updated

FYI, Security Scoreboard aka “Yelp for Security Products” comes up with an update which makes it even more useful!

The following is reposted from their news blast:

Real-time Vendor News and Reviews - Vendor pages now feature real time news and analysis pulled from select credible sources. Security Scoreboard filters and sorts these results to bring you the most relevant links for each company.

User Link Submission - Users can now submit their own links to relevant online sources for inclusion in vendor listings.

Listing Competitors - Security Scoreboard now lists select competitors on vendor pages. This helps CISOs and CIOs quickly find the main players in a specific market segment such as, for example, firewall management tools or phone-based 2-factor authentication solutions.  <- HOT feature! [A.C.]

Comment Section - Visitors can now leave comments on any listing without filling out a review.

Sadly, there are still a few mistakes. For example, check out their SIEM listings: which ONE company has absolutely nothing to do with SIEM there?

I always recommend starting your security product research there, if you don’t know where to start.

Monday, October 18, 2010

Verizon PCI Report is Out

Taking notes as I am reading Verizon’s awesome “Verizon 2010 Payment Card Industry Compliance Report” [PDF]

“Organizations struggled most with requirements 10 (track and monitor access), 11 (regularly test systems and processes), and 3 (protect stored cardholder data). ” - not surprising, given DAILY log review in 10.6.image

“Overall, organizations that suffered a data breach were 50% less likely to be compliant than a normal population of PCI clients.” – one of THE KEY  findings and a good measure of PCI DSS efficiency. “PCI works” side of an argument gets a powerful weapon!

“All of the top 10 threat actions leading to the compromise of payment card data are well within scope of the PCI DSS.” – not at all surprising to me, but might surprise some of the “attacks are soooooo dynamic” people :-)

“An organization may be able to pass validation in order to “achieve compliance” but then—once the QSA leaves—become lax about maintaining the degree of security the standard is designed to provide over time. As such, the goal of any organization should be to maintain its state of security in adherence with the minimum baseline compliance requirements set by the standard.” – a very useful reminder to more than a few folks who forget that “QSA do not manufacture compliance”

“22% were validated compliant with the PCI DSS at the time of their IROC.” – indeed a point worthy of discussion. 22% found compliant from the 1st shot is pretty darn good, IMHO.

“these organizations had at least some expectation going into the validation process that they would be found compliant and yet over three quarters of them were not” – indeed, compliance is MUCH easier if exists only in your mind :-)

“Most organizations appear overconfident when assessing the state of their security practices.” – Cap’n Obvious calling..calling..calling :-)

“Regular testing (R11) and monitoring (R10) may be the most crucial but underrated and least appreciated aspects of security.” – if a merchant has to work at it throughout the year, as opposed to simply buy – or check! – the box, compliance rates lag.

image 

image

“we have shown that the majority of organizations do not meet their goal of 100% compliance upon initial assessment” – BTW, do we realize that these guys were likely not compliant for most of the time since their last compliant FRoC?

“Organizations tend to struggle in all of these areas, most notably with generating (10.1 and 10.2), protecting (10.5), reviewing (10.6), and, to a lesser extent, archiving (10.7) logs” – well, it is not only the hard stuff that is hard. The easy stuff is hard too…mmmm.

“breach victims are less compliant than a normal population of organizations [..]  these results do suggest that an organization wishing to avoid breaches is better off pursuing PCI DSS than shunning it altogether” – this is [a part of] proof that PCI DSS works to improve security. Nice!

“it cannot be said that the PCI DSS fails to address the most prevalent threats to cardholder data. None of the top threat actions listed above falls outside the scope of its 12 requirements. For most of them, in fact, multiple layers of relevant controls exist across the standard.” – as obvious as it was to me, I suspect some people will be surprised. Threats today’s don’t seem as “dynamic” as some people think…

“the requirements exhibiting the worst assessment scores (10, 11) are also those most broadly applicable to the threat actions shown in Table 4. It should not be terribly surprising, then, that organizations suffering known data breaches were not highly  compliant with the PCI DSS” – oops! Fail to do the right things –> suffer a breach – with or without PCI DSS.

achieving and maintaining PCI Compliance should not be considered an annual project but a daily process – please keep this in mind, darn it. What is so special about this line that we have to repeat it every freaking day … and still have some people act as if it is news to them!!!?

.. next I started quoting from report conclusions and realized I’d be quoting most of their content. So, just read it!

Finally, a good way to think about PCI DSS below (from page 11 of the report):

image

Overall, a SUPERB piece of work (did I mention that I think it is awesome? :-)) and a must-read for any PCI DSS proponent OR skeptic!

Enhanced by Zemanta

Thursday, October 14, 2010

LogChat Podcast 2: Anton Chuvakin and Andrew Hay Talk Logs

LogChat Podcast is back - and now on iTunes as well! Everybody knows that all this world needs is a podcast devoted to logs, logging and log management (as well as SIEM, incident response and other closely related subjects).

And now you have it AGAIN with edition #2 - through the sheer combined genius of Andrew Hay and myself, Anton Chuvakin.

Administrative items first:
  1. It turns out, we don't need a new name! We are now entirely happy with "LogChat." The prize we offered will hereby be awarded to that one person who liked the original name :-) Marisa, please email me to claim your very own signed copy of the "PCI Compliance" book.
  2. So far, we are still not ready with transcribing.  I did try Amazon Mechanical Turk, but it didn't turn to be as inexpensive as people claimed. If you have ideas for a good/inexpensive transcribing service, we are all ears.
  3. We plan for this to happen every four weeks - recorded on Wednesday, posted on Thursday. However, due to our work schedules, irregularities may occur :-)
  4. Please suggest topics to cover as well - even though we are not likely to run out of ideas for a few years. Our topic today is log collection challenges and solutions: log sizing, EPS estimation, agents/agentless, high volume collection, Windows to syslog, etc
  5. Any other feedback is HUGELY useful. Is it too long? Too loud? Too rant-y? Too technical? Not enough jokes? Too few mentions of the "cloud"? Feedback please!
And now, in all its glory - the podcast: link to #2 MP3 is here [MP3], RSS feed is here - it is also on iTunes now. Enjoy THE LogChat!


Possibly related posts:


Sunday, October 10, 2010

Reposted: On Scope Shrinkage in PCI DSS

Note: this was written as a guest post for Branden Williams blog (my co-author for the “PCI Compliance” book) – it is reposted here for posterity.

People who came to PCI DSS assessments and related services (such as compliance gap analysis and even implementation of PCI controls) from doing pure information security often view PCI scope reduction as “a cheap trick” aimed at making PCI DSS compliance undeservedly easier. They only think of scope reduction as of limiting the area where PCI DSS security controls apply - with negligence, supposedly, reigning supreme outside of that sacred area.

However, PCI DSS scope shrink is not just a cop out aimed at not protecting the data. It is not just “PCI project cost reduction” measure. Some half-witted analysts propagate this view by saying things like “by reducing the scope, these enterprises can dramatically lower the cost and anxiety of PCI DSS compliance and significantly increase the chance of audit success” [eh… for starters, PCI on-site assessment is not an audit, stop calling it that!] Well, you will get that – but it is not the point of scope reduction at all.

In reality, efforts to reduce the area of PCI DSS applicability – scope reduction – are one of the most effective ways to reduce the risk of cardholder data theft.

Like we say in our PCI book (Chapter 5, “Protecting Cardholder Data”):
“Before we even start our discussion of data protection methods, we need to remind you that “the only good data is dead data.” Humor aside, dropping, deleting, not storing and otherwise not touching the data is the best single trick to make your PCI DSS compliance easier as well as to make the transaction less risky, reduce your liability, chance of fines and breach notification losses.”
If you’d like, think of scope reduction as one of the manifestation of the “least privilege” principle – or least data needed to do business principle. You stop the spread of card data and thus become a more compact, harder to hit target.

Along the same line, tokenization, data vaults, virtual terminals, hashing, network segmentation, transient PAN storage all reduce scope and reduce risk – at the same time. These are the things that make PCI compliance easier WHILE reducing the risk of damaging compromise. So, reduce scope by changing business process – it will bring more security benefits than THAT FIREWALL you deploy.

And remember that fable about somebody asking a QSA firm that was planning to accept payment cards as payment for PI assessments (oh irony!) – how would they do it?: “What?! Of course we’d outsource it! We won’t touch that toxic [card data] shit”

Friday, October 01, 2010

Monthly Blog Round-Up – September 2010

Blogs are "stateless" and people often pay attention only to what they see today. Thus a lot of useful security reading material gets lost.  These monthly round-ups is my way of reminding people about interesting blog content. 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 this month.

  1. Top position this month is held by my quick analysis of ArcSight acquisition by HP: “End of an Era: ArcSight Goes to HP.” Winners, losers, trends – the usual fun stuff
  2. Our LogChat podcast inaugural issue is next on the list – the second issue is coming next week. Stand by!
  3. On Free Log Management Tools” is a repost from my consulting site. The list of free log management tools is a companion resource to our “Log Review Checklist.” Updated version has just been posted.
  4. Making fun of stupidity in security industry was always one of my favorite pastimes. “Nobody Is That Dumb … Oh Waitseries just got its 13th issue, courtesy of “Information Security” magazine. It is about about how to win a SIEM contest without building a SIEM product – and then get good press on it.
  5. Career posts are always super-popular somehow: “Gartner-heads vs Packet-heads” post is no exception. The previous post in my security career series (“Skills for Work vs Skills for Getting Hired”) still shows up in Top10 as well as their predecessor “Myth of an Expert Generalist.”
  6. Updated With Community Feedback SANS Top 7 Essential Log Reports DRAFT2”, “SANS Top 5 Essential Log Reports Update!” and their predecessor  “Top5 SANS Log Reports Update DRAFT” also show up close to the top. Now that I have a bit more time, I will finally finish the write-up and submit it to SANS for distribution.
  7. How Do I Get The Best SIEM?”, a companion to “On Choosing SIEM“, went to the top like lighting a few months ago and stayed there this month as well. If you are thinking of getting a SIEM or a log management tool, check them out and also look at related resources at the end of these posts.  “The Myth of SIEM as “An Analyst-in-the-box” or How NOT to Pick a SIEM-II?” and ““I Want to Buy Correlation” or How NOT to Pick a SIEM?” also stay at the top – it seems like smaller organizations are looking at deploying SIEM and log management and there is a lot of interest in simple guidance on this.  And you can always hire me to help with the selection, of course!

Yeah, so my Top5 has 7 entries this month. And your point is? :-)

Also, below I am thanking my top 3 referrers this month (those who are people, not organizations). So, thanks a lot to the following people whose blogs sent the most visitors to my blog:

  1. Michał Wiczyński
  2. Dancho Danchev
  3. Raffael Marty

See you in October; also see my annual “Top Posts” - 2007, 20082009!

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

Enhanced by Zemanta

Dr Anton Chuvakin