kitten, by Clevergrrl

Have you checked out ISSA Connect yet? The next issue is up there with my column, Trusting Trust. What would we do without a little bit of trust? Our lives would certainly be much less convenient, and has the potential to be more secure.

If you are a member, log into ISSA Connect and join the discussion! Interact with great professionals globally as well as the authors that you enjoy reading every month. If you are not a member, sign up today!

Possibly Related Posts:

• August 2010 Roundup
• Herding Cats August: Embrace the ISA Program
• July 2010 Roundup
• Herding Cats July: Back to Basics
• June 2010 Roundup

• Microsoft releases new tool to defend against DLL attack – SC Magazine US
• ShackF00 » The 13th Requirement
  LOVE this.
  (tags: PCIDSS FAIL)

Possibly Related Posts:

• links for 2010-07-20
• links for 2010-07-19
• links for 2010-07-01
• links for 2010-06-30
• links for 2010-06-15

Stay Classy, San Diego!

What was popular in August? I personally closed out the month with a huge milestone, corrective surgery that should hopefully remove my requirement for glasses and contacts. I am in recovery, and can SORTA see this post, so I disclaim any responsibility for the content herein.  Actually, should probably do that for the whole blog.

Here are the five most popular posts from last month:

1. Why QSAs Should Not Be Your Security Partner. That’s right, folks. It’s time to separate your consultants from your assessors. Do you know what motivates QSAs?  Here is an inside scoop on what goes on inside your QSAs head, and why he doesn’t have your best interests in mind.
2. Where’s the Breach? Is this the new way to deal with a breach? Just find someone who has fallen victim in the past and blame him? Maybe.
3. The Council is such a Tease with PCI DSS 2.0. With no payoff, I might add. The Council released a preview of PCI DSS 2.0, but without any real meat to the announcement.  It’s good to see where things are moving, but ultimately, we need to see the exact language to understand the impact.  Read this post to find out why.
4. PCI Security Standards go to Three Year Lifecycle. Still on the top five one month later, this post details some of the pros and cons to the new three year lifecycle that all of the standards will adopt starting with the pending release.
5. 2010 Verizon Business Data Breach Report Released. Amidst the flurry of BlackHat and Defcon last month, Verizon released an updated version of their data breach report. This post outlines some key takeaways.  It’s made buzz in the industry mainly due to the trends (which should not have been reported as is).

Thanks for stopping by, San Diego!

Possibly Related Posts:

• Herding Cats September, Trusting Trust
• Herding Cats August: Embrace the ISA Program
• July 2010 Roundup
• Herding Cats July: Back to Basics
• June 2010 Roundup

It’s been an interesting week in the PCI DSS world. I was a contributor to a Webcast from First Data on scope reduction using Tokenization.  We had the webcasts from the Council about the changes in PCI DSS coming on October 28, and I seem to have gotten a flood of emails reminding me about the community meetings in Orlando and Barcelona.

Y2K, by Nancy Wombat

From a global perspective, PCI DSS is slowly making strides in several locales, to the point where I often adjust my daily schedule to help customers in the pacific rim, middle east, Asia, and Europe. Australian and New Zealand based companies seem to be taking particular interest in PCI DSS, equivalent to the levels we saw in early 2007 prior to the Visa CAP enforcing fines. Some of my favorite discussions around PCI DSS are helping companies that are just starting to explore the complex standard.

Square 1, as it were.

I was on the phone with representatives from a company this week where someone asked me how serious PCI DSS was, and if it would end up being another Y2K¹. I had never thought of it that way, but the parallels between how we solved the Y2K problem and how many companies approach PCI DSS are very interesting.

Those in the industry that lived through the compliance scrambles of 2007-2009 remember that companies often struggled in year two, because they forgot that PCI DSS was a continual process, and not just some one-time project like Y2K was. All the controls that were put into place and validated either disappeared or were neglected. Big examples of this include quarterly scans, daily log reviews, and change control tickets.

For those of you taking on this task today, do yourself a favor and treat it as a journey, not a project.  PCI DSS is a process of continuous improvement and a constant reminder of the war that we face with the bad guys. Celebrate your victory of crossing the first mile marker when initially achieving compliance, but don’t forget there are many more miles to go.

Possibly Related Posts:

• Check me out on the Network Security Podcast!
• Where’s the Breach?
• The Council is Such a Tease with PCI DSS 2.0
• Why your QSA should not be your Security Partner
• PCI Council, How About a Map?

1. Meaning, HYPE HYPE HYPE HYPE HYPE HYPE fizzle.

I met up with Martin Mckeay out at BlackHat this year, and we found what we thought was a quiet corner to chat about security.  Go check out the Network Security Podcast here!

Possibly Related Posts:

• PCI DSS versus Y2K
• Where’s the Breach?
• The Council is Such a Tease with PCI DSS 2.0
• Why your QSA should not be your Security Partner
• 2010 Verizon Business Data Breach Report Released

I recently gave a presentation to a graduate advertising class about social media with ideas on how it might be used as a part of an overall marketing and advertising strategy¹. One of the things I covered was the concept of geo-tagging and how it relates to social media. There are tremendous privacy concerns related to geo-tagging, but also interesting market opportunities as well.

Day 70/365.v2, by Perfecto Insecto

We ignored the unintended geo-tagging that occurs when people use location services in their mobile phones, or use cameras that are location aware and focused on check-in applications.  Some examples of these applications are the popular FourSquare and Gowalla². Well, it seems Facebook has now joined the fun, and added Places. Included in the launch was an updated Facebook application for iPhone that included the new logo, which as Jay Dolan points out, is a perspective view on a square where the roads draw a four.  Is it war?

Maybe.

But with Facebook falling under fire from privacy advocates recently, will Places stoke the smoldering fire into something more substantial?

Of course, you really need to try it to understand how it works. I’ve only begun to experiment with it, but not until I checked the updated privacy settings.  It looks like Facebook did this one right and set the defaults to share, but only with your friends. It should probably default to sharing with nobody, but that’s what we have.

There is another area just below this one, however, that requires you to choose if you want to let your friends check you into places (boy this could be fun).

There are two settings for this one, either enable or disable.  How much do you trust your friends?  How tightly do you control your friend list? I just went through a detailed exercise of limiting and purging based on the settings Facebook provides for us, so having certain friends see my location would not be that big of a deal to me. That said, my ability to limit this to certain groups with the extra granular privacy controls seems a bit broken right now.

Before you go into the weekend, be sure to check your privacy settings and make sure you have it set the way you want, and then give it a shot!

Possibly Related Posts:

• Do Small Service Providers Scare You?
• A Facebook Reality Check
• More Advice when using Public WiFi
• Securing your Social Networking Brand
• The Social Security Office, an Identity Thief’s Heaven!

1. I’ll get this posted soon. I’ve just gotten my templates fixed (Thank you Angry Porcupine!) and will be able to move the material shortly.
2. Also included in this list would be BriteKite and Yelp

Everybody knows that PCI DSS 2.0 is coming! The Council released a summary of changes for version 2.0 [PDF] to be released in October 2010. Council folks have granted this brief interview to Security Warrior Blog; it is provided below in its entirety:

 

Q1: As promised, the changes to PCI DSS are minor. Are you worried that since the next edition will come in 2013, both technology and threat landscape will change way too much and DSS will lose its relevance over time?

PCI Council Answer 1: The Standard is maturing and is increasingly being adopted globally, that's part of the reason why there are no new requirements  in DSS 2.0. Nonetheless, we always have in place an errata process that allows us to add elements or requirements to the standards as necessary. It is important to note that in the years that the standards have been in effect, there has never been a specific threats that has required this. [emphasis by A.C.]

[A.C. – I am sure the highlighted bit will rile a lot of noisy security folks with minimum knowledge of the payment industry, but, upon some thinking, I actually tend to agree with it - mostly. The issue is not with “requirements are stale”, but with merchants not doing this stuff. Daily log reviews are MANDATORY for PCI DSS compliance (see Req 10.6). Are they ALL doing it? Ha. And people still fall victim to passwords guessing en masse – like its 1983. Even future “PCI in the cloud” is fairly well addressed by Req 12.8. So please can this “threats are dynamic” snivel…]

 

Q2: Does Council plan to launch any studies on the effectiveness of "the new PCI DSS" vs today's cyber attacks against payment card data?

PCI Council Answer 1: While we have no plans for an official study, we do receive feedback and public forensic reports, like the recent Verizon Data Breach report that allow us to review forensic data gathered globally. [link added  by A.C.]

 

Q2: Will there be any changes to Prioritized Approach to PCI DSS document in light of PCI DSS changes?

PCI Council Answer 3: Not at this point, but the new DSS does allow, on a merchant by merchant basis, a certain degree of a risk-based approach during their assessments.

[A.C. – this means that “implementation first, policy last” thinking will stay in. Intuitively, I get it – policies on their own don’t stop loss, while removal of PAN storage does – but I expect a lot of whining over this one as well]

 

Q4: Does Council plan any additional implementation guidance along the lines of wireless guidelines to help merchants comply with PCI 2.0?

PCI Council Answer 4: At some point, we will be releasing a similar set of guidelines on Bluetooth deployments, similar to the Wireless Guidelines.

There you have it. And we wouldn’t even have to update our PCI book much :-) Go PCI 2.0!

About me: http://www.chuvakin.org

All we need to top off this post is a little old lady screaming “Where’s the Breach?” God bless 80′s marketing.

A merchant out of Austin, Texas is claiming that a breach in their network came from Heartland Payment Systems (HPS), thus it must be their fault. While I am sure this is not the first merchant to be caught off guard, he’s certainly a creative one. Our culture in America seems to relish deflecting blame from oneself on to others.

Why, it couldn’t be me, it must be that guy over there.

What’s interesting about this particular case is that the quotes in the article are being interpreted in a manner that is inconsistent with these kinds of breaches and the kinds of services that HPS offers. I’ve seen a few blogs proclaiming a second Heartland breach, but I’m not sure what specifically would make someone leap to that conclusion. According to their website, HPS does not offer a managed POS solution today (Integrated POS is another story, but I don’t see this as being the issue here). Typically an independent dealer or Value Added Reseller (VAR) will sell the POS, manage it, and then send the payment processing component to companies like HPS. Unfortunately, that’s where things break down¹.

Restaurants are breached frequently. Restaurateurs rarely hire skilled IT staff to build out the systems that run the kitchen and dining areas (that’s what the VARs are for), but they typically find ways to use the basic on-premise IT components to differentiate themselves from their competition. Maybe they offer a community PC or free Wi-Fi connectivity to patrons so they can work remotely while enjoying the food and service the location provides.  The diagram below depicts a typical restaurant setup:

Typical restaurant setup. Note location of Wi-Fi.

Does anything there seem odd to you? It should. In this case, a Wi-Fi access point is on the SAME NETWORK as the POS devices! The correct placement of a customer-facing Wi-Fi access point is between the firewall and the router².

From the article linked above: “The spokesman is quoted as saying that somebody had hacked into a computer system ‘somewhere between Tinos’ point of sale and their credit card clearinghouse company.’” Kind of looks like that diagram, doesn’t it?

One way credit card breaches are found is something called the Common Point of Purchase (CPP) analysis. This analysis will take known compromised cards and analyze the most common place where they are all used. Once a CPP is identified, notification begins and an investigation ensues.

In the case of the original Heartland breach, multiple CPPs began coming in, all tied to Heartland and the common cards showing up at multiple merchants. This caused the investigation to shift upstream to focus on Heartland, and we know the history behind that now. In this case, it’s a little too early to try and claim another Heartland breach. Maybe bloggers want to this out just to say, “Look! SEE! I got something right for once!”

Based on the information in the article and what I can ascertain from other sources, this looks no different than any other of the thousands of restaurant breaches that occur every year.

Possibly Related Posts:

• PCI DSS versus Y2K
• Check me out on the Network Security Podcast!
• The Council is Such a Tease with PCI DSS 2.0
• Why your QSA should not be your Security Partner
• 2010 Verizon Business Data Breach Report Released

1. Often these companies will install systems with weak remote access passwords (Does Welcome1 sound familiar?), or the users will do things like browse webmail on the back of house systems.
2. Or at least the most common place you might find it. Restaurants with integrated router/firewall devices should use the DMZ functionality that comes with it.

CloudAudit delivers it’s first batch of cloud compliance specifications. Quoting from the announcement:

“The CloudAudit initial distribution features five elements:

1) The CloudAudit normative specification in .txt format [cloudaudit-specification_draft.txt]
2) The CloudAudit CompliancePacks archive of .xls files which map controls/control objectives to namespaces based upon the Cloud Security Alliance Control Matrix [cloudaudit-compliancepacks.zip]
3) The CloudAudit namespaces archive which represents a complete CloudAudit directory tree representation of all CompliancePacks    with placeholder index.html/manifest.xml created in each directory stub [cloudaudit-namespaces.zip]
4) The CloudAudit Python script pack which automates the creation of the CloudAudit namespaces above  [cloudaudit-namespace_creator.zip]
5) A README.txt file [this content]”

and

“The CompliancePacks map control objectives to specific namespace entities which are contained below and feature NIST SP800-53, PCI DSS, HIPAA, ISO27002 and COBIT compliance frameworks.  Ultimately these directories are where a Cloud Provider will store and secure the assertions and supporting materials related to each compliance framework or assertion.” [<- the bold part is kinda the whole point :-) A.C.]

Grab the mammoth itself here [ZIP].

Enjoy!

About me: http://www.chuvakin.org

They totally are!  Giving us this little tiny preview of upcoming changes without really getting too specific.  It’s like me saying, “Dude, that chick is HOT!” Then when you ask me to describe her I say, “It’s a lady all right!”

Teased, by urbanlatinfemale

OK, back to the real reason you are reading this, the changes to PCI DSS and PA-DSS slated to drop on October 28 are outlined here.

The majority of the document reviews the new lifecycle, how and why changes are made, and the three general types of changes outlined: clarifications, additional guidance (which is just a fancy way to say clarification), and a requirement that is evolving based on new threats or a change in the market. This release represents a positive step by the Council to help key stakeholders understand what is coming, but falters on the execution a bit.

Those that have been working with PCI DSS for any period of time quickly learn that the devil is in the details. While this overview is helpful for us to understand where the Council is moving, most of the actual change will be driven by interpretation. On the surface, a significant amount of the change appears to adjust the wording to reflect the intent of the requirements. This is increasingly important in areas that are seeing increased drive and focus on compliance. As new QSAs are certified, the changes will help make up for interpretation nuances that experience will eventually yield.

One particularly noteworthy change is the note on the scope of an assessment. While we don’t know the ACTUAL change yet, it doesn’t appear that some kind of DLP tool will be required to validate scope. That said, it certainly would play a key component in scope validation in addition to interviews. I don’t believe QSAs could attest and validate scope without tools in conjunction with interviews¹.

Another change that specifically popped out at me was the centralized logging requirement for PA-DSS. It may signify a lack of attention to detail by QSAs assessing companies that deploy products capable of complying with PA-DSS. Many PA-DSS compliant applications can be configured in a non-compliant way, and with downward price pressure on QSAs², sometimes shortcuts happen. I’m not saying that I’ve ever done it, but I’ve walked into a customer that had their entire POS environment ignored because the assessor saw it on the PA-DSS compliant application list³.

I wouldn’t rush to download and read the five page release, but put it in your “to read sometime” pile. Your best bet may be to register for the webcast on August 24th, but unless Russo get’s something more than a prepared statement based on this document, that’s probably not even worth attending (except to see if someone torpedos his notes like the last one).

Possibly Related Posts:

• PCI DSS versus Y2K
• Check me out on the Network Security Podcast!
• Where’s the Breach?
• Why your QSA should not be your Security Partner
• PCI Council, How About a Map?

1. At least not in good conscious.
2. And arguably, the commoditization of the service.
3. Hint, it was storing PANs in an area that it was not supposed to be…

kitten, by Clevergrrl

Have you checked out ISSA Connect yet? The next issue is up there with my column, Embrace the ISA Program. Some industry folks fear the empowerment that the Internal Security Assessor program from the Council brings to the table.  I, for one, see it as an opportunity to more accurately assess PCI compliance. Oh, and the Hoffacino makes a cameo

If you are a member, log into ISSA Connect and join the discussion! Interact with great professionals globally as well as the authors that you enjoy reading every month. If you are not a member, sign up today!

Possibly Related Posts:

• Herding Cats September, Trusting Trust
• August 2010 Roundup
• July 2010 Roundup
• Herding Cats July: Back to Basics
• June 2010 Roundup

This one is link-laden folks.  Enjoy

SeparatedEggs, by YoAmes

It’s just mere weeks before we’ll see the FOURTH iteration of the PCI DSS, and companies inside the US seem to be getting better at it as we go. PCI continues to be a driving force in information security, and as the standard changes, your business environment will undoubtedly change as well.

Many merchants and service providers mistakenly depend on their QSAs to find all security and PCI compliance issues. Considering the downward market pressure on assessment prices, many security professionals are discussing how QSAs are pressured to get a complete and compliant ROC in the cheapest way possible.  QSA companies are motivated by three main things:

1. Scope and price the deal in a manner that will win the business,
2. Make (or beat) the margin, and
3. Stay of the remediation list.

If you enter into a contract expecting your QSA to find everything, or to be some form of liability transfer, you are misleading yourself into a false sense of security¹. QSAs are indirectly trained to create great reports, but in order to gain the efficiency required to compete, much of the ROC is complete before the engagement even starts.  The executive summary and details in each requirement still need to be written, but you can’t do much more for 10-20K.

This is not to say that you should start spending hundreds of thousands of dollars on QSA assessments, but when you consider that many assessments are performed with only one assessor for a short period of time, shouldn’t you ensure that you are not just going through the motions of fooling a hurried QSA?

Let’s assume that your QSA is better than most and is helping you work through security AND compliance issues. Why would you let your QSA design your controls as well as assess against them? Gartner published an opinion in 2007 that the Payment Card Industry has much to learn from the financial auditing industry—in particular the notion that the firm providing validation services should not be the same firm to provide consulting solutions around security and PCI DSS².

Sure, it’s easier to deal with one firm instead of two, but are you really getting what your management is (at least in spirit) asking for?  It should be validation that you are in fact compliant with PCI DSS to lower the chances of a breach and ensure that if one occurs, you won’t be subject to the same fines as an entity that was found to non-compliant.

That is why you need to use a different firm for consulting around security and PCI than you do for assessment or audit work.  It’s the same generally accepted principal that you would use in other audit scenarios, and it will lead to a better overall result:

You will gain confidence³ that you are both more secure and compliant after spending ridiculous sums of money to meet that end state.

It may not be the easiest way to go, but it certainly makes for a generally better outcome.

Possibly Related Posts:

• PCI DSS versus Y2K
• Check me out on the Network Security Podcast!
• Where’s the Breach?
• The Council is Such a Tease with PCI DSS 2.0
• 2010 Verizon Business Data Breach Report Released

1. baZING!
2. See the above linked research report for many more details.  It’s written by Avivah Litan and Joe Pescatore.
3. Both yours and senior management’s

Stay Classy, San Diego!

What was popular in July? We wrapped the month with some fantastic presentations at Blackhat, Defcon, and BSides. I am enamored with the fun stuff browsers can do (and not so fun things to the people that ineptly run them), and approaching application security with a renewed vigor.

Here are the five most popular posts from last month:

1. PCI Security Standards go to Three Year Lifecycle. More than twice as popular as its nearest challenger, this post details some of the pros and cons to the new three year lifecycle that all of the standards will adopt starting with the pending release.
2. Tokenization and Chargebacks. The NRF making is more waves, and Visa released new guidelines. Check out this post to see what is missing from Visa’s new report.
3. PCI Doesn’t Take Vacations. But we do! And while returning from my vacation I saw something shocking in my taxi cab. This taxi service decided to warn consumers about the insecurity of using credit cards with their company instead of actually addressing security.
4. 2010 Verizon Business Data Breach Report Released. Amidst the flurry of BlackHat and Defcon last week, Verizon released an updated version of their data breach report. This post outlines some key takeaways.
5. PCI Council, How About a Map? We’re not just aimlessly wandering in this whole data security with credit cards journey, are we? Well? Wouldn’t it be nice if the rest of us could see the map as well?

Thanks for stopping by, San Diego!

Possibly Related Posts:

• August 2010 Roundup
• Herding Cats August: Embrace the ISA Program
• Herding Cats July: Back to Basics
• June 2010 Roundup
• Herding Cats June: In or Out?

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.

1. “Top5 SANS Log Reports Update DRAFT” finally beat the previous champion of a few months “Simple Log Review Checklist Released!” In a few days, I will post the results of a community effort to refine the new SANS Top 8 (!) Log Reports…stand by.
2. Career posts somehow always get top scores automatically and “Skills for Work vs Skills for Getting Hired” is no exception. Just as its predecessor, “Myth of an Expert Generalist”, it got on my monthly Top 5 posts immediately, was featured on Reddit.com, etc, etc.
3. “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. 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.
4. Next up are my notes from University PCI DSS workshop where I delivered a keynote: “My Best PCI DSS Presentation EVER!” (the infamous “compliance kitten” quotes comes from here)
5. The report from HITB 2010 Amsterdam conference which I opened with a keynote “Security Chasm” is also on the monthly top list – “HITB 2010 Amsterdam Awesomeness.”

Also, below I am thanking my top 5 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. Raffael Marty
3. Dancho Danchev
4. Walt Conway 
5. Cédric Blancher

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

P.S. Watch for a fun post tomorrow, releasing a new SIEM whitepaper that I wrote for a client.

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

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

About me: http://www.chuvakin.org

by Chipmonkey

Verizon Business released their 2010 Data Breach report hours ago, and with the combination of Secret Service data for the 2010 report, there is a ton of interesting things in here.  Here are a few of the highlights that I took from the report:

• Financial & Hospitality Beware: These two categories represent 56% of the groups involved in breaches¹.  Those of us in the industry know the ridiculously poor state of security in the hospitality sector.  Now with the economy on its way to recovery, these businesses will once again see an uptick and criminals will see an opportunity to capture valuable data.
• Medium-Sized Businesses are in the Crosshairs: The grouping of victims had between 1,001 and 10,000 employees. In my experience, companies in this range that are growing rapidly tend to push security to the back burner which can hurt them.
• Collusion is Key: Right away readers will notice that the percentage breakdown for the top causes of breaches add up to more than 100%.  Bryan Sartin, director of incident response for VzB, confirms that the reason for this is that often multiple issues caused the breach. An interesting statistic might be to list the percentage of breaches that occurred with just one type, two types, and three or more types of intrusion. This shows the complexity of successful attacks is still rising and keeping ahead of the pack is as important as ever.
• Social Engineering is BACK: People hacking is one of the most effective techniques for gaining information, and an interesting note to help illustrate the significant amount of data loss associated with organized crime.  Sartin said that it is easier for crooks to buy off an insider than it is to try to knock over perimeter defense.  It certainly makes it harder to prosecute the real crook when the insider becomes the fall guy. How do you identify a potential fall guy? 26% were simply employees or end users.
• TRUE PCI Compliance Makes a Difference: 79% of the breaches discussed here did not comply with the PCI standard, but 21% did? How do we reconcile this discrepency with the payment brands’ and PCI Council’s assertion that no PCI Compliant company has been breached? This 21% represents breaches coming from companies that validated PCI compliance (either internally or through a QSA) at some point, not that they were compliant with PCI at the time of the breach.
• Basic Security FAILs cause Breaches: In the PCI analysis at the end of the report, I was shocked to see that Requirements 2 (change vendor supplied defaults) and 5 (deploy anti-virus) represented a decline in compliance. Those two are arguably the foundation for why PCI DSS was started.
• Malware is a Key Compromise Vector: 94% of the records compromised could be attributed to malware, and 96% to hacking. Why is that significant?  See the above bullet. Most breaches can be traced to a hacker breaking through some part of the defenses and installing malware to collect data (a significant portion of which coming from web-based infections). Addressing this is pretty basic stuff, however increasingly complex in large environments.
• Data is King: 92% of the records compromised were pulled from database servers.  Again this goes back to my mantra, “Delete all data you don’t absolutely need (and take a hard look at what you ABSOLUTELY need), and defend what you do need to the death.” Just because 2009′s record count was less than half of 2008′s doesn’t mean that we’re in the clear. In fact, it could mean that the market for stolen data is a bit soft right now, and the bad guys are waiting for the economy to recover.
• Look for Activity: In the “On Logs, Needles, and Haystacks” sidebar, Verizon asserts that instead of looking for the needle in the haystack—the successful breach—maybe we should look for the haystack! I LOVE this analogy, as the mere trend of common vulnerability exploitation like SQL Injection indicates 1) a threat, and 2) a potential compromise.  Don’t give up on this stuff, folks. Functional log capture, management, and analysis is a requirement when vigilantly defending your assets.

What are some key, actionable takeaways that we can run with for our security planning in 2010 and 2011?

1. De-value your data.  Seriously, you can’t get around this.  Destroy everything you cannot reasonably obtain from a third party, and outsource everything you can to a third party to offload risk.
2. Protect the data you do have. Do you still use only a username and password to authenticate people with access to critical systems and data? For shame. Get another factor in there.
3. Get control of your networks. If you are not doing egress filtering, you will be a victim to a data breach. Don’t just go through the motions though (like many people treat compliance). Smart egress filtering will go a long way to protecting your information assets.
4. Get back to basics. I offered up my man card after writing a column that opened with a reference to Ina Garten’s show on the Food Network, but it’s fundamental to protecting your information assets.  If you don’t have solid patch management, anti-virus, and build standards, then why would you worry about the “Advanced Persistent Threat?” Excel in your performance of fundamental security before you tackle something more advanced.
5. Trust but verify your people’s actions. Collusion is almost a requirement for a successful breach to occur.  Don’t let a disgruntled employee with a little too much access on their hands be your downfall.
6. Train your employees to trust, but verify. Social engineering is ever present, and widely successful. Don’t let Julie in reception be a victim.

Go download this today and read through it for more insights on what is going on in real world breaches!

Possibly Related Posts:

• Check me out on the Network Security Podcast!
• Where’s the Breach?
• Why your QSA should not be your Security Partner
• A Thought to Take You to the Weekend
• PCI Council, How About a Map?

1. Add in retail and you are up to 71%

Mum's Thought, by JasonDGreat

It’s been a crazy week, and I’ve been busy gearing up for BlackHat on top of all the fun stuff my day job entails.  To close out the week, I wanted to throw something at you that I thought about while discussing how to better approach compliance initiatives. It’s a simple one liner that really describes why companies should invest in security instead of compliance:

A good information security program makes compliance with any standard a tweak, not an overhaul.

Compliance should not be the notion that drives security in your organization. Security, among other things, should support and drive compliance.

Compare that to your approach.  Does that fit with how you execute your security strategy?  If not, why?

Possibly Related Posts:

• Check me out on the Network Security Podcast!
• Why your QSA should not be your Security Partner
• 2010 Verizon Business Data Breach Report Released
• PCI Council, How About a Map?
• Herding Cats July: Back to Basics

• Skimmers Siphoning Card Data at the Pump — Krebs on Security

Possibly Related Posts:

• links for 2010-07-19
• links for 2010-07-01
• links for 2010-06-30
• links for 2010-06-15
• links for 2010-06-11

• Novel New USB Attack | Optimal Security: The Lumension Blog

Possibly Related Posts:

• links for 2010-07-20
• links for 2010-07-01
• links for 2010-06-30
• links for 2010-06-15
• links for 2010-06-11

When I started writing this post, I was trying to think of a metaphor for a map and a journey of some sort, but everything came out dripping with Cliché Cheese¹ or would have made sense only to a limited audience (Shout out to the P1, between the devil and the deep blue sea, and kick the tires and light the fires… as it were). The point I was trying to make, however, was in light of PCI, we seem to be navigating a changing world with a semi-static map.  Like that GPS I bought seven years ago that freaks out every time I drive on a road that was completed four years ago.

Grand Central terminal, Jul 2008 - 05, by Ed Yourdon

As I wrote about last week, the Council has now extended the lifecycle to every three years, which overall I think is a good thing. But what is missing is solid guidance from the Council (not speculators) on where this thing is going between those updates.  Using a somewhat recent example, application vulnerabilities were on the rise long before the infamous Requirement 6.6 was introduced into the standard. Having some basic thoughts on Web-Application Firewalls and code reviews before the requirement was introduced would have at least started the discussion.  It’s not like all the sudden electronic commerce was a big thing after PCI 1.0 was released.

What the Council needs is a best practice area that constitutes recommendations from industry groups and the SIGs that has been vetted by the Council. This list of best practices would be technologies or processes that companies should become familiar with because they stand a good chance of being incorporated into the standard. Right now, it’s impossible to know definitively what the Council is “thinking.” Sure, we have the PR-driven evangelism², but what we don’t have is a concrete picture on where they think the future of PCI DSS is going.

Because, frankly, it doesn’t matter what guys like me think.

Providing this forethought allows merchants and service providers to at least get a LITTLE bit of direction from the Council which helps:

• Frame the budgeting process
• Prioritize IT projects
• Strategies on a three or five year roadmap

Imagine if the Council had a place that listed three to five technologies as beneficial to protecting cardholder data and key items it was considering for future versions of PCI DSS. As an industry, I believe we would actually see a few early adopters in the form of companies with savvy CISOs that get more input into their process and can better frame their requests to the rest of the executive team³.

Possibly Related Posts:

• Where’s the Breach?
• The Council is Such a Tease with PCI DSS 2.0
• Why your QSA should not be your Security Partner
• 2010 Verizon Business Data Breach Report Released
• A Thought to Take You to the Weekend

1. It’s somewhere between month-old shredded Cheddar cheese that you would toss on some chips and zap for “nachos,” and that orange substance you get on nachos at a high school football game.
2. According to Russo, this is going to change, but we’ve not seen much up to this point that falls outside of this category in my book.
3. I know this is a little pie in the sky, but there are some savvy folks out there that would be willing to stick their neck out if they knew the rug wouldn’t be pulled out from under them.

The NRF released a brief yesterday discussing the clarification Visa made to the operating regulations related the storage of full card data after the transaction. As suspected, some acquirers and processors were interpreting the rule to mean that Visa required merchants to store the full card number for things like chargeback processing¹.

Tokens at Major Magic's, by Benimoto

Of course, with a phone call, acquirers quickly seemed to learn what the real intent of the rule was. I can only describe this second hand, but here’s what I know for sure.

Over the last 6+ years, I have worked with many merchants to help them rid their systems of PANs. In exactly zero instances, I have had an acquirer or processor require a merchant to store this data post settlement for chargeback purposes. Sometimes it takes a little dot-connecting (like at one particular LARGE processor that shall remain nameless), but ultimately a few hours of work on behalf of my clients got written statements from their processors allowing truncated numbers for chargebacks.

Not just for Visa, by the way… but for EVERY payment brand.

In addition, Visa released their own brief on tokenization best practices.  I’m disappointed that Visa remained rather ambiguous on their statements about tokens, and left the definition as broad as they did.

As I’ve argued before, a token should NOT have a mathematical relationship to the original value (which is essentially the definition in PCI DSS today… Requirement 3.4, index tokens, albeit still linked to a cryptographic value, but traditionally not cryptographically related). Their definition just says it should not be computationally feasible, though also referring to doing this via a “known strong cryptographic algorithm.”

Leaves some room for interpretation!

Had I written the brief, I would say that a token cannot have a mathematical relationship to the original value, and instead, should be a reference value. Instead, I’d call things like hashes and other cryptographic-based “token” technology simply cipher text—because that’s exactly what it is. Regardless of your market position, I think that we can all (though in some cases anonymously) agree that the best option for a token is one that is not mathematically related—computational feasibility be damned.

Possibly Related Posts:

• The Council is Such a Tease with PCI DSS 2.0
• Why your QSA should not be your Security Partner
• PCI Council, How About a Map?
• Level 2 Merchants, Are Your Folks Trained?
• PCI Security Standards go to Three Year Lifecycle

1. The clarification was made on the Issuer side of the transaction.