Posts tagged as:

PCI

Information Security Policies Made Easy Version 12

by rsa365@hosted.jivesoftware.com on April 16, 2012

in SBN

Full disclosure:  While I am on the Expert Panel for Information Shield, Inc., publishers of this book, I receive no remuneration other than a review copy, nor do I have any editorial input in the book.

 

Information Security Policies Made Easy Version 12 is now out.  My review of version 11 is here.


Version 11 came out over 2 years ago, and version 12 looks to fill in the numerous policy gaps that have crept in since. 

 

To give you an idea of the breath of version 12, the Master Policy List is 53 pages in length.

 

Version 12 also includes new security policies have been added within each ISO 27002 category. 

 

What I wrote about version 11 holds true for version 12: Information Security Policies Made Easy is a valuable tool that can be utilized to create a comprehensive set of information security policies in a cost- and time-effective manner. For those building corporate or organizational security policies, Information Security Policies Made Easy Version 12 is clearly a definitive reference.

 

Full review to follow.

Pain Comes Immediately – Secure Development Takes Time

by Alex Rothacker on April 16, 2012

in SBN

I recently came upon a blog post by Adrian Lane of Securosis titled ‘Pain comes instantly – fixes come later’, in which he comments on yet another blog post ‘Pain comes instantly’ by Oracle’s CSO, Mary Ann Davidson. Anything ‘Oracle security’ always gets me curious, so I went ahead and worked my way through both articles. Let’s just say one of them is a rather lengthy read.

The core point of Mary Ann Davidson’s post is an objection she has with some rules in the PCI PA DSS Vendor Release Agreement. According to her post, the VRA requires a vendor of an approved product to ‘tell all’ to PCI about any known security vulnerability and associated security breaches ASAP to PCI — including specific details of a security breach, exploit information and technical details of the vulnerability, and whether or not there is any mitigation or patch available. Now, once the PCI council has this information, it can distribute it to all PA-QSAs and the exploit details are thus widely available to a community of people that’s too large to be guaranteed to keep that kind of secret.

She has a valid point here, and Microsoft’s recent MAPP debacle does show that a secret is not a secret once too many parties know about it. Once exploit information is widely available, even to a supposedly vetted group of people, it has a good chance of becoming  public and someone  is very likely going to use it to their advantage. Payment systems are an especially interesting target for hackers and organized crime, since they provide access to easy money.

So far so good. Now to the parts that I find interesting and where I disagree with her.

For starters, Oracle has only three products that are vetted by PA-DSS and that would fall under the aforementioned agreement. All three are part of the E-Business Suites Retail In-Store line of products. Oracle’s flagship database product is expressly NOT a payment application for the purpose of PA-DSS. It only falls under PCI-DSS when part of a third-party custom payment system implementation, but in that case does still not fall under the VRA. Thus, I’m surprised that this is worth creating such a ruckus by Oracle senior management.

My next point is, when reading the PCI VRA section 2(a)(iii) and (iv), it is not quite as cut-and-dry as described in her post, but leaves enough room for interpretation that a PA-DSS vendor could keep the juicy details of a vulnerability under wraps well until a proper patch is made available, at which point (and in most cases) a skilled hacker would be able to devise an exploit from analyzing the patch anyway. I also fail to find language in this section stating that PCI will pass any exploit information on to any and all QSAs or even the smaller community of PA-QSAs, but they could probably be more clear on how that data would be disseminated.

Personally, I have always felt that once a patch to a vulnerability is released, the vendor should give as much guidance as possible to its customer base so that they can make an informed decision on how to mitigate the vulnerability — may it be a workaround, such as disabling some functionality, configuring compensating controls like activity monitoring, and of course properly prioritizing the deployment of patches. I think Microsoft has really stepped up to the plate and their security bulletins clearly show the way. They are full of useful information for security practitioners and system administrators, giving detailed guidance on the impact of a vulnerability, how to apply the fix and how to temporarily mitigate it. Oracle, on the other hand, has always been rather tight-lipped about vulnerability fixes and the information included in their quarterly Critical Patch Update information is of limited use.

Another great point was discussed in Adrian Lane’s post. Oracle is not always the quickest when it comes to turning around fixes reported to them by third parties. TeamSHATTER has reported well over a hundred vulnerabilities to Oracle in the past seven years. While some of them have been fixed expeditiously, others have taken their sweet time. Sometimes well over a year.

PCI-DSS, as well as PA-DSS, has some guidelines on coding practices and code review, especially addressing issues related to prevention of code injections, buffer overflows, XSS and other common attack vectors. Researchers are frequently finding vulnerabilities for all of these coding issues in Oracle products — including new product lines, not just older products that suffer from code that predates modern secure coding practices.

If there is one change that I think would be worthwhile for PCI to consider, that would be a requirement for all PA-DSS certified products to produce timely fixes to vulnerabilities reported to the vendor. I think a six-month maximum turnaround would be a desirable timeframe.

Sir, Put Down the Loaded Weapon

by Branden Williams on April 13, 2012

in SBN

Sensitive information is sometimes like a loaded weapon someone might randomly stumble upon in a park. For those that have some kind of training with weapons, you can probably think of a dozen things you would and wouldn’t do if you were in this situation. But what if you had never seen this kind of weapon before? Would it become a paperweight on your desk? Maybe a doorstop? Or in an extreme case, earrings? Maybe you see peers treating these weapons the same way and all the sudden it becomes acceptable.

Until one goes off.

Prepare, by Photo Monkey

Then everyone flips their lid and its utter chaos. Questions like, “How did this happen?” and “Why isn’t the government protecting us?” start to pop up in daily discussions. Then when the newness wears off and no other incidents happen, people stop talking about it and go back to doing things the way they did living with the assumption that it was a black swan.

Until it happens again. Then we lather, rinse, and repeat.

Rob Sadowski has a great blog post entitled “Time to Push the Reset Button” that discusses recent events in our industry (go give it a read). There is one really great point that I’ve touched on before which is, “Why do you still feel the need to handle payment card (or other sensitive) data?” I remember one meeting sitting in front of a CIO from a very large company saying, “What business do you have operating a payment processor? You are a retailer! Your core competencies are marketing and supply chain!”

“B-b-b-but… we’ve always done it that way!” This post (same as above) details why that mentality doesn’t work anymore.

Most companies don’t handle risk management very well when it comes to information security because they can’t agree on a way to value data. It’s not entirely their fault, this process isn’t easy at all. Here in the US, some elements of breach recovery is public knowledge through regular SEC filings, but in many places it simply isn’t public. But here’s where risk managers screw up: they equate bits to dollars (somehow), therefore, they will make decisions and set policy using unreliable data.

Instead, risk managers should add a new variable to their formula: C, somewhere in the denominator of their formula (confidence). Large values of C mean we are supremely confident in our estimation of risk, therefore we reduce the unknown element to our formulas. Small values of C mean we really have no idea what we are doing, and it’s time to make it someone else’s problem (outsource). There are too many options available that are both cost-effective, and largely transparent to current business operations (with minor changes in nearly every case) that allow you to handle a plastic facsimile of the loaded weapon instead of the weapon itself.

Possibly Related Posts:


Share

Time to Push the Reset Button?

by Payment Security Focus on April 12, 2012

in SBN

By Rob Sadowski – RSA Director, Marketing, Payment Solutions

Payment security is back in the public eye with the recent disclosure of a cardholder data breach at a leading US payment processor. While initial reaction to this latest incident has been unfortunately predictable, characterized by plenty of uninformed speculation, outrage, and a general lack of understanding of the workings of the payments industry, the story that is ultimately written about this latest incident might be one that is completely unexpected.

If this latest breach has reinforced something that we already know, it’s that cardholder data remains a valuable commodity in the criminal underground and that sophisticated and determined fraudsters continue to target organizations who have it. Large or small, processor or merchant, Level 1 or Level 4, if you handle payment card data, you are a target.

What’s also becoming clear is that defending information assets is more difficult than ever. As former U.S. Director of National Intelligence Mike McConnell recently stated in testimony on cyber security: “there isn’t a corporation in the nation today that can’t be penetrated, not one.” While he is speaking primarily about threats from advanced attackers seeking defense or military secrets, if there is another unfortunate fact that we are all aware of, it is that bad actors are better at sharing information than good actors, and successful techniques will soon become common knowledge and widely used against any valuable target.

Faced with this reality, we have to begin to accept the idea that intrusions are inevitable. It’s not easy. It doesn’t feel right, especially when we have relied for years on a perimeter security model where the focus is on keeping bad guys out of our networks. But once we do, we can start to envision a constructive path that moves payment security forward.  While intrusions may be inevitable, they don’t have to equal data loss and defeat. This industry has proven time and time again through its history that it can effectively manage risk to acceptable levels.

The first question to ask is why are organizations that have no need to handle unprotected payment card data still doing so? Here I am referring to merchants. We’ve been writing in this blog for the past two years about end-to-end encryption and tokenization. Properly implemented, with encryption where cardholder data enters the merchant environment for authorization, to the replacement of card data with tokens for use post-authorization, cardholder data is either protected or removed from merchant systems altogether with no loss of business functionality. Merchants who implement these capabilities as a service from a provider like their payment processor never have access to the unprotected card data, which drastically  reduces their risk and exposure in the (inevitable) event of an intrusion. If merchants cannot avoid being targets for cybercriminals, they have the means at their disposal to largely avoid the consequences.

Apparently, we’re not the only ones who think so. VISA, in their statement regarding this latest breach stated: “Visa also supports advanced security layers such as encryption, tokenization and dynamic authentication … to further protect sensitive account information and minimize the impact of data compromises.”

Our partner First Data has more than 250,000 merchants using this technology today. While this is a large number, it’s less than 5% of the more than 5 million US merchants that VISA tracks. As an industry, we’ve got a long way to go to reduce our attack surface.

This brings us full circle back to payment processors and card associations. The way the system works today, to authorize transactions, they must have access to unprotected card data in parts of their networks. They will remain the highest value targets for cybercriminals. The security mindset of these critical participants needs to evolve from preventing every intrusion to how to quickly discover intrusions, stop the attackers from gaining a foothold, minimizing the effects, and avoiding a substantial breach.

This next statement may seem like heresy, but as soon as we let go of the notion that we can have perfect security, that we will be able to keep every determined and skilled adversary at bay, we can constructively move forward as an industry. RSA has written extensively about this new security paradigm. You can read more here in this report, “When Advanced Persistent Threats Go Mainstream” and here “Getting Ahead of Advanced Threats”.

Let me make one more suggestion. While conventional wisdom would dictate that this is perhaps the worst time to make this statement, I think the attention makes it precisely the right time to make it: Merchants should seek to entrust the security of their customers’ payment card data to processors and other “repositories of risk” who will always be better prepared to face and defend against the latest attacks and threats. If merchants can’t trust their current provider, they should find one they can. Security has to be a core competency of these providers by virtue of their role in the ecosystem and the way the payments value chain works today. They need to embrace security as a duty and deliver it as part of their core product. But it needn’t be for merchants, whose core business is merchandising goods and services and serving consumers. RSA and a team of industry collaborators predicted such a shift several years ago in a research paper entitled “Secure Payment Services: Card Data Security Transformed” Many of our conclusions seem particularly prescient against the backdrop of recent events.

So what will be the long-term impact of this latest breach? Will we speculate endlessly about who perpetrated it, how it happened, the supposed ineffectiveness of regulations, or revisit any number of familiar rehashed topics, or is this finally the event that causes the payment security industry to reinvent itself based on today’s security reality?

I, for one, would like to see us push the reset button.

Rob Sadowski leads RSA’s go-to-market efforts with partners in the payments industry.

The Security Bug Disclosure Debate

by Tim Whitman on April 11, 2012

in SBN

Mary Ann Davidson’s recent post Pain Comes Instantly has been generating a lot of press. It’s being miscast by some of the media outlets as trashing PCI Data Security Standard, but it’s really about the rules for vendors who want to certify commercial payment software and related products. The debate is worth considering, so I recommend giving it a read. It’s a long post, but I encourage you to read it all the way through before forming opinions, as she makes many arguments and provides some allegories along the way.

In essence she challenges the PCI Council on a particular requirement in the Payment Application Vendor Release Agreement (VRA), part of each vendor’s contractual agreement with the PCI Council to get their applications certified as PCI compliant. The issue is over software vulnerability disclosure.

Click for complete article >>

Introducing Tripwire Log Center 6.5.1

by Cindy Valladares on April 3, 2012

in SBN

Today we’re announcing an update to Tripwire Log Center. This release has some new capabilities to help you do your log management and incident detection functions easier and faster. Here are some of the highlights of this update: Find log events faster. We’re utilizing MITRE’s Common Event Expression to standardize log event messages. You benefit [...]

Visa Removes A Service Provider After Data Breach

by Tim Whitman on April 3, 2012

in SBN

Visa removed Global Payments, an Atlanta company that helps the payment giant process transactions for merchants, from its list of “compliant service providers.”

A security breach at Global Payments reported on Friday was thought to have compromised up to three million credit card accounts. It is among a group of companies that act as the plumbing in the electronic transaction chain, authorizing millions of transactions a day. That makes the companies prime targets for data thieves looking to steal richly detailed financial information.

Click for complete article >>

PCI DSS Keeps Its Perfect Record Intact

by ashimmy@hotmail.com (Alan Shimel) on April 2, 2012

in SBN

I was reading Brian Krebs follow up article on the Global Payments breach this morning that something less than 1.5 million credit card records may have been stolen in this mess. How much less is still open. Could be 50k, could 1.499m, I guess we will have to wait for more info. (BTW, kudos to Brian for once again showing why he is just so out in front of everyone who writes about security- bloggers, reporters, writers, etc.).

I then read my friend Bill Brenner’s piece that Global “has some ‘splaining to do”. Bill is right, Global Payments is going to have give us a lot more details about how this happened and they should step up and take the blame here. The truth will set them free, but the fines I am sure will be heavy.

In the meantime, the security industry will analyze, over-analyze, read tea leaves and goat innards trying to piece together how this could have happened. With Albert Gonzalez behind bars, our own Lee Harvey Oswald couldn’t have done this one, we should be on the look out for the next Sirhan Sirhan.

One party though who will take no blame on this is the PCI Council. In fact they have managed to keep their perfect record intact through this one. As Brian noted and Bill said as well, Visa has promptly removed them from their list of compliant service providers. They are not PCI compliant. That is why they were breached. Of course if they were compliant, this breach would have never have happened, right?  Wrong. 

No PCI compliant provider has ever been breached. The whole thing is crazy. If you are breached you are not compliant by definition. Your compliant status was only at the moment you were certified, the moment after, if anything happened it is because you were no longer compliant. So what is the use of being on VISA’s compliant service provider list? It just means you haven’t been breached yet or recently.

So Global was not PCI compliant and will now have to be re-certified. The moment after they are certified if anything happens, they will not be PCI compliant again. This is a game where all of the rules are stacked for the Council. They can’t lose.

The losers are consumers and merchants who play this game. Merchants are charged lots of money to become PCI compliant. They are told that everyone has to be compliant, most especially the processors. Consumers are told that VISA, MasterCard and the rest of the industry has instituted the PCI DSS to protect them. That no PCI compliant merchant or provider has ever been breached.

The reality is that the only ones getting any protection are the card brands and their bank cronies who are offloading the liability to merchants and processors instead of themselves and who dip their beak every time one of us pays with plastic. The idea behind the bank and credit card company fees was that they were taking the risk when people promised to pay later while using plastic now.  But much of that risk has now been offloaded to merchants and processors, debit cards take the money out of your account almost instantly. The card brands have little to know risk and still charge both the consumer and the merchants high fees, dipping their beak on both sides of every transaction. That is not being a bird, it is being a pig.

So while their perfect record remains intact, the PCI Council remains the undefeated heavyweight champion of meaninglessness.


Global Payment Systems delisted by Visa

by netsecpodcast@mckeay.net (Martin McKeay) on April 2, 2012

in SBN

Last Friday Brian Krebs broke the story that MasterCard and Visa were warning of a major processor breach.  Later in the day it was announced that the payment processor was Global Payment Inc. and that approximately 50,000 card numbers had been compromised, a number that was later revised to 1.5 million card numbers.  Global Payment took such a pummeling in the stock market that they had to halt trading in the middle of the day on Friday, and appears to not have resumed trading as I’m writing this post.  They have a press conference this morning, but the initial reporting shows that Global Payments isn’t saying anything that’s not already in a press release.  And to add insult to the injury that Global Payments has had their listing as a compliant service provider yanked as of Friday, pending the security review of the compromise and a new assessment, a process that could take months.

The relationship between customer, merchant, banks, card processors and the card brands is complex and not at all clear to the average consumer.  When a customer swipes their credit card or places an order online, the merchant passes that information on to their processor.  The processor is a company, such as Global Payments, that has been designated by the merchant’s bank to process payments on their behalf.  The processor sends the request to the card brands, who check the balance with the bank that issues the credit card and forward an approval or denial based on credit availability and fraud checks.  That approval is forwarded back to the merchant and the customer and the whole process only takes 2-3 seconds on the average day.  At the end of the day the merchant bundles the credit card requests and sends them to their bank, appropriately designated the merchant bank, who forwards the information through the card brands to the banks of the people who charged their cards that day.  The relationship is complex and my explanation doesn’t cover the many variations that can crop up, but it covers the basic idea.  For more information, there is a wiki page.

On of the most interesting aspects of this is that Visa has removed Global Payments from the list of compliant processors, a step that I don’t think has been taken for any breach since that of CardSystems in 2005.  CardSystems was the first major breach of the credit card flow to catch the public attention and it was very clear that de-listing was done to buoy consumer confidence.  But since then very few service providers of any stripe have had their listing pulled, which indicates there may be more going on behind the scenes than is being reported publicly.  Global Payments’ relative silence and the updates to the number of records compromised add to this impression.  Of course, no one expects any company to come clean immediately when faced with a compromise, but the degree to which this incident is causing lips to be sealed is interesting by itself.  Will Global Payments have to go through a similar process as CardSystems, basically selling themselves to prevent total collapse?

We’ve gotten to the point where we almost expect daily or weekly notifications from merchants stating they’ve been compromised.  But where merchants are not in the business of securely taking in credit card numbers, that’s exactly what processors and banks are supposed to be focusing on.  A merchant makes their money by selling products to consumers whereas a payment processor is selling the security of the transaction and any breach of that trust is a major issue.  The processors are also aggregation points for multiple merchants and many processors have millions of card transactions flowing through their systems on a daily basis.  As such, they know, beyond a shadow of a doubt, that they are being targeted by attackers and that their security is paramount to continuing to be in business.

I strongly suspect that what’s been disclosed so far is simply the tip of the iceberg.  If Global Payments was compromised for a month and a half, as currently stated, then a much higher number of card numbers than 1.5 million were most likely processed during that time.  Which means the compromise was either contained in some way with or without the awareness of Global Payments, or there is another shoe waiting to drop.  My money is on the latter.

 

Update:  I forgot to add that there was a brief outage of the Visa network on Saturday morning when they updated systems inside VisaNet.  Yeah, that can’t be at all related to the Global Payments breach, could it.

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]

Today's business environment has become more regulated - with different mandates and requirements spanning multiple industries and regions. Some regulations require multiple audits per year and depending on your industry, you may have to comply with multiple regulations. Even if you don't have to comply with the bevy of standards or requirements such as PCI-DSS, SOX, NERC CIP, HIPAA, and so on, you most likely still have (or you SHOULD have) internal reviews and checks of security policies.

While regulations and ensuing IT audits go beyond firewalls and firewall policies, these devices are often a good place to start when it comes to becoming "audit-ready" and gaining continuous visibility of what's going on in your network.  

In this blog series, we'll examine what you need in order to successfully go through an audit of your firewall estate and most importantly how to ensure continuous compliance (this is where automation plays a big role). This blog will focus on step 1. This relates closely to what my colleague Josh Karp has blogged about in his series When PCI Compliance meets real world security, specifically the first step he has examined.

 

Step 1: Gathering Pertinent Information Before You Undergo an Audit

An audit has little chance of success if you do not have proper visibility of your network, including software, hardware, policies and risks. This sounds like an obvious statement, but many organizations do not have the necessary visibility of their IT environment.

Some examples of "quick wins" in the pre-audit phase would be to collect the following information:

  • Make sure you have copies of all the relevant security policies.
  • Ensure you can access the firewall logs - this is important so you can analyze the logs against the firewall rule base to understand what is actually being used.
  • Obtain a diagram of the current network and firewall topologies.
  • Gather and review documentation from previous audits, including firewall rules, objects and policy revisions. This can help you from repeating the same mistakes and hopefully key in on issues from the past that may not have been properly addressed.
  • Identify all Internet Service Providers (ISP) and Virtual Private Networks (VPN).
  • Obtain all relevant firewall vendor information including OS version, latest patches and default configuration.
  • Understand all the key servers and key information repositories in the network and their relative values to the company.

Even though this is just the preparation for the audit, you're not quite done. Once you have gathered this information, you must have a plan to aggregate and store this information in a way that will make analysis and reporting easier - and no spreadsheets don't really count. Spreadsheet compliance is a surefire way to make the audit process painful. Document, store and consolidate this important information in a way that enables collaboration with your IT counterparts. Remember, you're most likely going to have multiple audits per year.

Then and only then can you start reviewing policies and procedures and begin to track their effectiveness...