Thursday, January 28, 2010

REAL PCI Compliance Percentages?

Reading "UK Security Breach Investigations Report 2010" [PDF] (source) makes for some truly blood-curdling reading.


"Prior to having suffered a cardholder data compromise, 26% of the organisations had believed themselves to be PCI DSS compliant upon submission of completed
Self Assessment Questionnaires. The investigations also revealed that none of the organisations met all requirements of the PCI DSS."

This is how it starts. It is all downhill from there:

"Indeed, in just over one quarter of the cases, none of the twelve requirements were met."


"7Safe has found that all the merchants who have been subject to a breach and have completed an ASV scan
have believed themselves to be secure based solely on the results of this scan"

I literally cannot read any further, since I am starting to get angry! Can somebody come and kick those merchants in the balls, please? Actually, no. Do not kick them! Stand on their balls. :-)  Then have then buy our book!

Tuesday, January 26, 2010

On Log Context

Recently somebody asked me: what do I mean by LOG CONTEXT? And what is “log enrichment correlation?”

This picture explains it clearly:


For each element in the log message shown, you can gather some contextual information. Contextual here simply means that the information is gathered NOT from this particular log entry. For example, a log entry might contain an IP address, but its DNS name needs to be grabbed from the DNS server, which “enriches” the log entry and makes it more useful.

One of the ways SIEM and log management systems performs such enrichment is by gathering and displaying context information. Context information is the additional information required to make the limited details available within the log entry more meaningful. Context information does not come from the logs themselves [not from the entry in question – it might come from other logs], but originates in the surrounding IT environment such as other systems inside or outside the organization.

As I say above, one of the simplest example of context data is name resolution: the DNS names or Windows NetBIOS host names are added to the logs. While the log file may have already provided IP addresses, the added context of a human-readable name makes the log more meaningful. Normally, DNS names are not present in logs, but have to be obtained by queries to a DNS server. The SIEM tool might find context data in a variety sources, including:

  • Windows name services, DNS and NIS servers: to map IP addresses to names
  • Defined asset groups: internal or external status of an IP address
  • Asset management systems: to gather information about systems, their ownership, compliance relevant of each system or group of systems
  • WHOIS servers: WHOIS information for external addresses shows who owns them and where they are located
  • Geo-location: show the physical location of the system
  • Active directory and LDAP servers: to map user names to actual user identities
  • Attack details and vulnerability information: to gather additional details about the log data and/or the log source.

BTW, back in 2008, I did a poll on what context is the most useful for log analysis. That is what came back – it shows that some useful context is simply documentation on what the log mean (might be pulled from the internal knowledge base of a SIEM product):



Thursday, January 21, 2010

“I Want to Buy Correlation” or How NOT to Pick a SIEM?

Somebody showed up at my door the other day and said “I want to buy some correlation!” Don’t get me wrong – I love correlation; I developed correlation rules for a living some time ago. Correlation is totally fun. That’s why I wrote a couple dozen papers  defining and explaining security event correlation (example here, here, here).

Despite all that, I am still shocked when I see people who define their requirements for an expensive security product (such as Security Information and Event Management – SIEM) in that form: I want to buy correlation. BTW, I ridiculed this as one of the “worst practices” here in this fun presentation – see slide 11.

First, correlation engine is … well… an engine. What can you do with an engine? Unless you are an engine mechanic and think that it is fun to just tinker with it, you probably prefer this engine to be embedded in a car. And car is that thing that allows you to get from A to B faster [than walking … unless you drive up RT101 in the morning]. So, you are buying “transportation” and not “correlation.” Or, in our security realm, you are buying [a chance for] automated near-real-time detection of incidents. Or a tool to simplify your security monitoring.

Second, engine needs oil and gas to operate. What is correlation “oil and gas”? Content! This jargon term simply means correlation rules, alert/notification templates, views, workflows and reports that define how correlation will actually solve your particular problem. That is not everything that allows the engine to contribute to solving “the transportation problem,” but it is pretty darn important. Even engine mechanics drive their cars using oil and gas, even after they build that extra turbocharger on the side :-)

Third, the above two points should tell you that you need to know what problem you are trying to solve with correlation before you go “shop for correlation.” And here is something magical: don’t pick a problem of “improving food quality in a buffet on a ‘Titanic'.” Pick ship survivability instead! (BTW, “Titanic” was compliant!) What I mean here is that if you are not ready to handle real-time notification of incidents, then focus on investigations first with log aggregation, indexing and searching. This paper should jolt your brain in this useful direction.

Now, if your organization is looking for some help defining the requirements for a SIEM or log management product, choosing the right tool etc, figuring out how to operationalize it, I can definitely help.

BTW, this is posted by the scheduler. I am away attending to a family emergency; response to comments will be slow.

Possibly related posts:

Tuesday, January 19, 2010

Some Fun Reading and Listening

As I am preparing to attend to a family emergency and thus go “offline” for a while, here is something fun stuff for my dear readers:
  • “PCI War” rages one in this “CSO Online” podcast “The Great PCI Security Debate of 2010: Part 1[MP3] with such fun people as Joshua Corman, Mike Dahn, Jack Daniel, Ben Rothke, Martin McKeay, etc.  It is a bit chaotic at times, but fun and enlightening. It was also fun to participate in, despite the fact that it was recorded at 7AM. This piece provides some background for the debate.
  • The second part of the PCI debate was just posted here.
  • Those with interest in SIEM must read Rocky’s “The 2010 SIEM Winter Olympics Preview
Enjoy! More fun posts coming when I am back. For now, buy The PCI Book :-)
BTW, see you all at ShmooCon and then at RSA 2010.

Wednesday, January 13, 2010

More on PCI DSS and Logging

Despite my older post on this (“MUST-DO Logging for PCI?”), people continue to harass me to create an “authoritative”  guide on logging for PCI DSS: what events to log? what details to log? what logs to retain? what logs to review? how to review? etc, etc. BTW, the quotation signs above are there since only your QSA holds an authoritative view on the subject; the rest have to settle on “defensible” view, such as the one from my very self :-)

So, OK, I will [eventually] share my entire defensible guide on logging for PCI DSS, even thought it doesn’t sound anywhere near as glam as an authoritative guide would :-).  In this guide, I analyze all the PCI DSS logging requirements (in Requirement 1, 5,10,12 and all others too) and translate them info a logging policy and more-or-less-actionable tasks and operational procedures, while making few assumptions here and there about your organization. What it more important, I cover both PCI logging requirements that you need to achieve PCI DSS compliance, stay compliant with these requirements and what you need to [most likely - see the comment about QSAs above] get validated. It goes without saying that such logging will be actually useful, following the traditional "compliance+" model.

Still, no externally-created guide will ever be fully effective in defining logs and logging for your organization, for your applications, for your in-scope PCI environment. Indeed, the only way to get it right is to hire a consultant and have him customize and “operationalize” the document by replacing the assumptions with actual facts about your organization [oh-nos, I started to sound like a consultant already :-)]
The document will be shared later this year (unless I roll it into my upcoming book on log management..oops!.. that was a secret :-)) If you want it sooner, you can hire me to do this for you organization as some other people just did. Here are some examples of what I built for this F1000 consulting client:

Logging Policy
In light of the above, a PCI-derived logging policy must at least contain the following:
  • Adequate logging, that covers both logged event types and details
  • Central log aggregation
  • Log  retention (1 year)
  • Log protection and security
  • Daily log review
Let’s now focus on log review in depth. PCI DSS states that “Review logs for all system components at least daily. Log reviews must include those servers that perform security functions like intrusion-detection system (IDS) and authentication, authorization, and accounting protocol (AAA) servers (for example, RADIUS).“ It then adds that “Log harvesting, parsing, and alerting tools may be used to meet compliance with Requirement 10.6”
PCI DSS testing and validation procedures for log review mandate that a QSA should “obtain and examine security policies and procedures to verify that they include procedures to review security logs at least daily and that follow-up to exceptions is required.” QSA must also ”through observation and interviews, verify that regular log reviews are performed for all system components.”
Below [in the full document, not here – A.C.] we document PCI Application Log Review Procedures and workflows that cover:
  1. Log review practices, patterns and tasks
  2. Exception investigation and analysis
  3. Validation of these procedures and management reporting.
The procedures will be provided for using automated log management tools as well as manually when tools are not available or not compatible with log formats produced by the application.”

Possibly related posts:

Monday, January 11, 2010

How to Stay Compliant? or Ongoing Tasks in PCI DSS

This post and, of course, the paper included below, are inspired by some work I’ve been doing on so-called “ongoing compliance,”  in particular as it applies to PCI DSS. The table in the paper below is the result of my going through the text of the Data Security Standard and extracting all the requirements which are NOT “one point in time”, but periodic in nature. I did it just to prove to some buffoon that PCI actually mandates security things to be done periodically and NOT just before the assessment were to start or SAQ was due. No deep thinking here, but a useful reminder about the fact that …
  • Validation is “point-in-time”
  • Compliance is “over time.”
BTW, a good QSA can check for signs that an organization is actually “equipped” for ongoing compliance and not simply “cooking evidence” to impress him…
“What do I really need to do to STAY compliant?” paper was originally published here. BTW, check out this fun PCI DSS poll that accompanies the paper (results, vote).
Lately, a lot of security industry discussions have been focused on PCI DSS- Payment Card Industry Data Security Standard. The conversation ranges from practical advice on “how to get compliant” all the way to branding PCI as a devilish invention (Google for “PCI is the devil”) Fiery debates aside, PCI DSS guidance helped countless organizations to see the light of security where there was none before. It goes without saying that it didn’t magically make them “become secure” – no external document can.
One of the frequent criticisms of PCI DSS focuses on the misguided view that “PCI is all about passing an ‘audit’.” Many people would be surprised to find out that PCI DSS lists specific tasks that you have to be doing all the time – NOT just before the assessment. This paper focuses on the exact steps organizations must take to actually stay compliant and not just pass validation via scanning, on-site assessment by QSA or self-assessment questionnaire ( SAQ)
Indeed, very few experts will actually tell you how to STAY compliant and not just how to GET compliant. Recent cases of massive card data breaches at companies that were at one point validated as PCI DSS compliant show that staying compliant is much harder than getting compliant. Security benefits of PCI DSS are not realized just because an assessor in a fancy suit tells you that are “validated as compliant.” Such benefits are there if you are “doing PCI” and “doing security” every day (yes, PCI does included daily tasks for you to do!) By the way, if you are trying to use PCI DSS to launch your security program, this resource would be a useful guide.
Despite the above focus on “getting compliant,” some security vendors preach the theme of “ongoing compliance.” In fact, they’ve been doing literally for years. Of course, the “ongoing compliance” theme is awesome. Sadly, a majority of the same vendor customers don’t do it like this (to their own loss – this why it is sad). They still have assessment-time rush, “pleasing the QSA” approach and “checklist-oh-we-are-DONE” mentality. We can conclude that before one wants to “sell” continuous compliance concept, one need to educate the audience first.
To top it off, achieving 100% PCI compliance for validation gets much more resources at corporations, compared to maintain 100% PCI compliance.
In light of the above discussion, a lot of people are surprised that PCI DSS document itself  contains a list of tasks to perform to maintain compliance between assessment. The table below shows these periodic tasks:

PCI DSS Requirements Version 1.2.1
3.6.4 Periodic cryptographic key changes
§          As deemed necessary and recommended by the associated application (for example, re-keying); preferably automatically
§          At least annually
6.6 For public-facing web applications, address new threats and vulnerabilities on an ongoing basis and ensure these applications are protected against known attacks by either of the following methods:
§       Reviewing public-facing web applications via manual or automated application vulnerability security assessment tools or methods, at least annually and after any changes
§       Installing a web-application firewall in front of public-facing web applications
9.5 Store media back-ups in a secure location, preferably an off-site facility, such as an alternate or backup site, or a commercial storage facility. Review the location’s security at least annually.
9.9.1 Properly maintain inventory logs of all media and conduct media inventories at least annually.
12.1.2 Includes an annual process that identifies threats, and vulnerabilities, and results in a formal risk assessment
12.1.3 Includes a [security policy] review at least once a year and updates when the environment changes
12.6.1 Educate employees upon hire at least annually
12.6.2 Require employees to acknowledge at least annually that they have read and understood the company’s security policy and procedures.
On-site QSA assessment (Visa L1, Amex L1, MC L1-2, etc) or self-assessment (Visa L2-L4, Amex L2-3, MC L3-4, etc)
1.1.6 Requirement to review firewall and router rule sets at least every six months
1/6 months
11.1 Test for the presence of wireless access points by using a wireless analyzer at least quarterly or deploying a wireless IDS/IPS to identify all wireless devices in use
11.2 Run internal and external network vulnerability scans at least quarterly and after any significant change in the network (such as new system component installations, changes in network topology, firewall rule modifications, product upgrades).
11.5 Deploy file integrity monitoring software to alert personnel to unauthorized modification of critical system files, configuration files or content files; and configure the software to perform critical file comparisons at least weekly.
10.6 Review logs for all system components at least daily. Log reviews must include those servers that perform security functions like intrusion detection system (IDS) and authentication, authorization, and accounting protocol (AAA) servers (for example, RADIUS).
12.2 Develop daily operational security procedures that are consistent with requirements in this specification (for example, user account maintenance procedures, and log review procedures).

A lot of other processes require to “maintain”, “ensure”, etc - as well as procedures mentioned in item 12.2
As needed
(Source: PCI Data Security Standard, v. 1.2.1)
What do we learn from the above on how to stay compliant? Based on the above, we can come up with the following lists of periodic tasks, which are directly mentioned in the DSS (many more, of course, are implied…):
Every year
o Review security of web application
o Review security policy
o Perform security awareness training
o etc
Every six months
o Review firewall and router configurations
Every quarter
o Perform external and internal vulnerability scanning
Every week
o Run integrity checking on critical files
Every day
o Review logs from the systems in scope for PCI
o Perform other daily operational procedures defined in security policy

To conclude, while getting compliant gets more attention, staying compliant is where a lot of mistakes and faults (leading to data breaches) are made. As you are working on PCI DSS compliance related initiatives, make sure that staying compliant” is taken just as seriously as getting to that first validation…
Finally, there are still 2 days left to get THE “PCI Compliance” book at 30% off launch discount.
Possibly related posts:

Thursday, January 07, 2010

Annual Blog Round-Up – 2009

If monthly, why not annual blog round-up? These are my top popular "Security Warrior" blog posts for 2009. This list covers the posts most popular in 2009, not necessarily only those written in 2009.  Enjoy!
  1. The quest for open source SIEM continues! In fact, the TWO top posts on my blog in 2009 resulted from search queries for “open source SIEM.” They are: “Why No Open Source SIEM, EVER?” and “On Open Source in SIEM and Log Management.” BTW, all SIEM posts are tagged here.
  2. Next, we got scientific (eh..statistical :-)) proof that Heartland Payment Systems mega-breach was The Security Event of 2009. My coverage of the Heartland saga is next on the top list: “On Heartland”, “On Heartland II”, “On Heartland III”, “On Heartland IV”, “On Heartland V”, “On Heartland VI.”  BTW, what is the overall security lesson of the “HPS-gate”? Sorry, but it is “it’s OK to have a massive card data breach!”
  3. I suspect a lot of security folks do a lot of career soul searching nowadays. That is why “A Myth of An Expert Generalist” is so HOT. I suspect you already read it, but if not – go do it!
  4. It is interesting that Windows log collection is still very much an issue with many folks. That is why “Windows Log Collection Poll Analysis” is in the top for the year.
  5. Thoughts and Notes from PCI DSS Hearing in US House of Representatives”  needs no introduction or explanation why it is on the top list for 2009 :-)
  6. Top Log FAIL!” summarizes the most egregious, reckless, painful, negligent, sad, idiotic examples of “Log FAIL.” Log management at its worst!
  7. I am not really “a rant-master”, but some of the more philosophical posts (“Smart vs Stupid: But Not Why You Think So!”) end up being very popular – this one definitely struck a cord with many people.
  8. “Compliant” + 0wned = ?” … this posts seeks to answer this “eternal” question.
  9. A champion of multiple months – AND last year!-  “MUST-DO Logging for PCI?  is also on the list the second time; the world does need more specific PCI DSS guidance. PCI DSS guidance is not “too prescriptive,” it is more often not prescriptive enough!  BTW, you can hire me to help you with your logging, log architecture, log management/SIEM product selection or related product development.
  10. Five Reasons to Dislike PCI DSS – And Why They Are WRONG!” is a fun little piece which fights the war in defense of PCI DSS.
See you in December 2010 when I will post the next annual blog round-up (see my previous annual “Top Posts” - 2007, 2008)
Possibly related posts / past monthly popular blog round-ups:
Obligatory “added everywhere” posts :-)
  • I might be available for fun consulting projects related to loggging, log management, SIEM, PCI DSS, security writing, events, etc. Please see the services list at my consulting site.

Tuesday, January 05, 2010

Monthly Blog Round-Up – December 2009

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. It sure seems like most SIEM vendors and log management vendors have again camped at my blog :-) How else can I explain that “Log Management + SIEM = ?” takes #1 spot in December?  This topic is getting really, really hot – it is also the subject of my recent consulting projects.
  2. Completely unsurprisingly, my “Security Predictions 2010” post takes a much deserved #2 spot. Why #2? ‘Cause my 2020 information security predictions went up on 1/1/2010 only and didn’t make it into December top roster :-)
  3. Top Log FAIL!” is still hot! The post summarizes the most egregious, reckless, painful, negligent, sad, idiotic examples of “Log FAIL.”
  4. Again this month, “Smart vs Stupid: But Not Why You Think So!” stays on the most popular post list. You need to go read it to know why it is so awesome :-)
  5. On SIEM Complexity” is next – it is a piece about Security Information and Event Management (SIEM) and why it is / is perceived as “very complex.”
  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.

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 visitors to my blog:

  1. Bruce Schneier blog
  2. Dancho Danchev blog
  3. Alexey Babenko (in Russian)
  4. Gunnar Peterson
  5. Richard’s TaoSecurity blog

Thanks for all the link-love! And now back to carving powder at Heavenly :-)

See you in January; also see my annual “Top Posts” - 2007, 2008 and the coming 2009!

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.

Friday, January 01, 2010

Security Predictions 2020 (!)

How impossible is it to predict anything in the field of information security? 10 years? Into the future?  Still the purpose of this endeavor is not necessarily to “have everything right”, but to have fun in the process and to get people to think beyond the immediate tactical horizon in information security.

Let's start from the overriding trend that will define the rest of the discussion:

cyber_vs_realThat trend is that the walls between the computer world (aka the Internet, cyber-anything, online, virtual, cloud, etc) and the “real” world (aka meatspace, Earth, “outside”, “reality”, offline, etc) will break down beyond a certain interesting point, both on the perceptual level and in reality. With – duh! – huge implications to our profession and practice of information security.

What do I mean by this?

Whether perception is reality on not, studies I’ve seen (examples, more, more, more) point that most people behave differently in an online world and in the so-called “real” world. People can also point at many factual differences between online world (that happens inside the human created medium – networked devices) and the outside. I believe that this difference explains at least some of the current information security problems – on some deep level people just don’t see computer intrusions and other issues as “real enough” for them.  Even the simple fact that we have “crime” and “cybercrime,” points that this difference.

So here is the punch line: I think that in the next 10 years these two worlds will be much closer to each other, in both perception and “real” reality. HUGE implications to information security will result.

Where's the evidence? Here are all the things that I bundle in that “ultimate convergence”

  • Everything geo-related: GPS in phones, location- aware services, and even integrated Internet in cars. When you start to “google for coffee,” you straddle both worlds.
  • Augmented reality, conspicuous high-speed video uploads (in 2020) and video analytics capture the real world and ”map” it onto the online world. And as computing devices first become wearable (needed for AR), and then implantable (best for AR), the convergence between both worlds will become even more intense.
  • Everything computing embedded in objects: embedded computers in an ever-increasing percentage of the things we use in the real world; these will go a long way from the first Internet-connected refrigerator. Yes, clothes and shoes, not just sunglasses, are not far behind – and with bluetooth or whatever future incarnation, such wearable “PAN” becomes within reach. BTW, trains and planes run on computers too… And I am not even touching SCADA.
  • Everything robotics: robots, from Roomba to military hardware, is one more way for a computer realm to “act out” in reality. If you are confused about this argument, think about the following: a crashed computer will destroy only a computer and information inside. A crashed computer in a vacuum cleaning robot can potentially destroy … your carpet.  A crashed computer in a robotic high-speed cannon… you get the picture.
  • On a perceptual level, some studies have noted that younger generations (and here) do not draw the line between their Facebook friends and their real-world friends.  This is an example of the same trend, but occurring in the mighty realm of perception. If you are born and then grow up with (and on) the computer, you views of “computer world” will be different from those who still see computers as something “not really real.”
  • On top of this, advances in bio-sciences will obviously rely on computers and algorithms. I predict this would be another way for the computer realm to impact the “meatspace” and not only through the implantable computers.
  • Finally, the Ultimate Proof that such convergence has in fact taken place will be - you guessed it right! – cyber-terrorism. Smart folks today object to the concept of cyber-terrorism by [correctly!] stating that “real world” terrorism is more impactful. Today – it sure seems like it. In 10 years, when “real world”  is so much closer to the “computer world” – I am just not going to bet on it…

All of the above will make information security and computer security (as well as a dying art of network security) PAINFULLY more relevant for people’s lives. If an attacker from a remote location can crash the computer and steal your data, this is bad. If that same attacker can impact what you perceive to be your “real world,” the game changes. And change it will - probably even before 2020. What will stand between such attacker and others? That’d be you and me, my dear reader :-)

The above convergence will also be combined with these “side trends”, all with big impact to security:

  • In 2020, a lot of tasks can only be done with computers - or not at all. Now we can still buy a book in a bookstore, you can pay with a credit card when computers are down. Forget that – in 2020! Such irreplaceability of computers and Internet will make security sharply more relevant. Your business will not simply switch to an old, inefficient mode, when Internet is not an available. It will STOP.
  • To quote Alvin Toffler, there will also be a lot more information and thus a lot more computers to process it. These are added to the above mentioned embedded computing devices.  The result is not just an increased target set, but also more businesses being completely reliant on computers for their operation.
  • I also predict a much larger use of non-deterministic algorithms, such as those based on statistical methods. This will imbue the phrase “computer did it” (and we don't know why and how) with a whole new meaning…
  • Complete local and network scope convergence due to cloud computing and ubiquitous connectivity. They will be no such thing as a device asking “can I connect to the Internet?” As a result, Internet becomes a fabric of distributed applications, not client/server push/pull model we still largely have today.  Security implications? You bet! BTW, this will also kill the whole “but why did they connect that to the Internet in the first place?!” thinking.
  • As a result of the last point, the whole control over data will have to be done in a completely new way - or not at all. And if you think web hacking is fun today, just wait until 2020 :-) 

So, I don’t know what features your log management system will have in 2020 or what the label “firewall” will mean in 2020, but I know is that it'll matter much, much more than now. Despite all the harping about information being “critical for business”, we only protect information today.  Sorry for a bit of grandstanding here, but we will literally protect the world in 2020…


BTW, other fun views of the year 2020 technology are here (created in 1994), here (created in 2005), here and in many other places.

Dr Anton Chuvakin