PCI « SecureThinking

Posts tagged PCI

Tuesday, July 20, 2010

CISOs to the Rescue!

By Jill Knesek, Chief Security Officer, BT Global Services

There aren’t many times I check in on the trade publications and see an article that really hits on the issues faced by the C-level audience in the security sector. Frankly, we’re an unusual bunch, with very specific interests, issues, and concerns. But recently, I saw an article by Ernie Hayden at searchsecurity.com that got to the heart of some of the compliance issues that I know I face and I’m sure you grapple with, too.

Approaching compliance from the standpoint of managing processes, Hayden outlines five key propositions that can help guide decision-making and apply as equally to PCI as to NERC. His top picks are:

Your fundamental obligation to the company is to protect data and prevent loss
You should know the ins and outs of the regulations your organization is held to
View training and awareness as key components of your compliance strategy
Understand the root cause of any issues related to compliance
The organization should be kept under constant pressure to be in compliance

To read Hayden’s entire article – “How to manage compliance as Chief Information Security Officer (CISO)” — click here.

And if you’re a C-level or senior security officer in the Chicago area and would like to continue this conversation over dinner, I’ll be hosting a BT Security Roundtable in Chicago on July 28. To learn more about the dinner, please contact our Chicago-area managed security solutions specialist, Kurt Luporini.

Wednesday, May 19, 2010

Five strategies for CSO success

By Jill Knesek, Chief Security Officer, BT Global Services

Last week I spoke at the Secure360 Conference in St. Paul about the challenges facing CSOs. The last decade has been a game-changer for those of us charged with protecting all the different dimensions of the business. Not only do I and my peers have more assets to protect, but we have more potentially troublesome things to protect our enterprise and our employees from.

It once would take a truck to remove 25 million records from a business – now, it only takes a USB drive or an innocent-looking iPod to remove the same amount of data. And where once all employees worked in centralized locations with their computers protected behind the fortress of firewalls, they often now work remotely, connecting from home, the coffee shop, or the train. Adding to the complexity is the fact that a new generation of hackers/cybercriminals are able to compromise millions of computers a day, rather than just one or two sites per week, as was the case when I started my cybersecurity career tracking down Mafia Boy and Kevin Mitnick.

And did I mention that the highest levels of protection also need to be provided while adhering to complex and extensive government and industry regulatory standards, like PCI, HIPAA, and SOX?

Before you think I have an impossible job, I’d like to share a few strategies with you that have helped me be successful:

Change Your Perspective: Think Outside In — Historically, security began and ended at the firewall where we were able to protect our most critical systems and data that was housed in a centralized data center. Today’s critical systems and data are not bound by perimeters but rather reside on our laptops and mobile devices. Therefore, when we think about securing our networks and systems, we must do so from the outside in – that is, from the laptop or mobile device first and then back into our data centers and server farms. We must start with personal firewalls, encrypted hard drives, A/V .dat file updates and patch management. We must ensure that the data which travels around with our mobile workforce is secured at the endpoint, as this will normally be the most vulnerable and easiest to attack. But that doesn’t mean we can forget about the core. We just have to start with our users and work our way in.

2. Reach out to Business Partners — Engaging with all the different groups within the business — from Legal to HR to Sales — early in the process of thinking about security increases the likelihood of success — not only in terms of eventual implementation of security measures, but also with regards to assurance that you’ve covered all your bases and assets.

3. Change your Communication Style — Too often physical and IT security teams are perceived as what I call, “The Department of No” — and that’s not a fun reputation to have. Nor is it likely to win you allies and advocates on the front lines where you need them most. Working collaboratively means you will be less likely to be circumvented and locked out of key decisions and forced to play catch-up.

4. Manage Risks, Not Threats — With the increase in the vector and velocity of threats, it is no longer practical to work in a threat-based model. We must move to a risk-based model where we first identify the company assets, evaluate the risks associated with those assets and then put in place controls and mitigations to protect them from the ever-increasing threat landscape. If we try to protect against all known threats, we will find ourselves always one-step behind the criminals. By focusing on the risk and implementing the right risk management program, we can ensure that our assets are properly protected regardless of the threat against them. Also, implementation of a risk management program that produces proper measures and metrics will allow you to begin putting security in business terms, which leads to the final strategy recommendation.

5. Learn to Speak ‘Business’ — One of the most important things I’ve learned is how to speak the language of my senior executives. While they may be impressed by my command of technical lingo, what they really want to know is how the money that is funding my security budget is being used — and also how precisely it is protecting the company and the bottom line. Being able to talk about what I do in terms of EBITDA and P&L has helped me have security needs woven into the fabric of decision-making.

I know that these five things have made my life as a CSO far easier. What strategies have helped you do your job more effectively?

Wednesday, May 5, 2010

The States Take Action: Washington Becomes the 5th State to Give Data Privacy Some Legislative Teeth

By Sushila Nair, Product Manager, Managed Security Solutions Group, BT Global Services

In 2005, California’s Assembly Bill 1950 (AB 1950) became active, requiring a business that owns personal information about a California resident to “implement and maintain reasonable security procedures and practices to protect personal information from unauthorized access, destruction, use, modification or disclosure.” Since then, this law has been used as a basis for private and class action lawsuits and, it would seem, a model for other states’ legislation.

Similar legislation has been passed in other states, including Massachusetts, Minnesota, Nevada and, most recently, Washington state. HB 1149, which takes effect on July 1, 2010, provides issuing banks a legal mechanism to collect the costs to reissue payment cards after a payment card security breach. While there is no explicit requirement for organizations to take reasonable care to avoid a breach, companies that fail to do so may be liable to pay for re-issuance costs after a breach.

Of all these laws, the Massachusetts law is regarded as being the most comprehensive and, not surprisingly, implementation has been delayed many times; currently, the deadline for compliance to Mass. 201 CMR 17 has been extended to May 1. The law clearly calls for the need to discover and protect sensitive data in a manner that is absent from other laws that are being passed; but it no doubt will become a template for similar legislation elsewhere.

A federal law mandating security controls is missing, but it’s worth noting that in the case of a large scale security breach, the FTC has taken action by claiming that organizations have engaged in “unfair practices” in violation of Section 5(a) of the Federal Trade Commission Act, 15 U.S.C § 45(a). The FTC said it was unfair for the company, TJX, to collect private credit card information from consumers and fail to use adequate security procedures to protect it. TJX must obtain audits by independent third-party security professionals every other year for 20 years as a result of the FTC’s action. The definition of “adequate security” is, however, not clearly defined by the FTC, but it is fair to assume that PCI DSS forms a framework which can be used to measure an organization against.

With different states mandating various forms of security controls on storing sensitive information, organizations will obviously be required to comply with multiple sets of “reasonable security” requirements for each state where they have customers, a factor that will be confusing and expensive. The focus will center on one set of security controls and, love it or hate it, PCI DSS undoubtedly is being focused on as providing this framework.

What becomes an interesting part of this debate is whether or not this is the right direction for the United States to be taking for credit card security. Elsewhere in the world, the focus has been on increasing the security of credit cards by introducing smart cards and requiring secondary authentication for online banking. Half the world’s credit card transactions occur in the U.S., and while smart cards do not reduce card fraud, it’s a step in the right direction to introduce security into payment systems that were never really designed with security in mind.

As we struggle to get companies to introduce more effective controls around the storage and transmission of personal data, the question becomes — should we also be focusing on strengthening the processes that use that data to prevent it from being used without additional authentication. It is likely that banking regulators will revise their guidelines and start to issue stricter guidance, which in turn will prompt banks to offer better authentication mechanisms to protect consumers. But that needs to follow through to online merchants and the login behind credit card transactions — because let’s face it, the entire process seems to be quite broken.

Thursday, April 1, 2010

Does the Punishment Fit the Crime? The Sentencing of Albert Gonzalez

By Toby Weir-Jones, Vice President of Product Development, Managed Security Solutions Group, BT Global Services

Albert Gonzalez was sentenced on Thursday, March 25, to two concurrent 20-year sentences for the TJX and Dave & Busters attacks, and another 20 years (also concurrent) on Friday, March 26, for the Heartland case. The Federal Government’s recommendation to the two District Court judges was 25/20/25 years, respectively, so the judges clearly adhered closely to those suggestions.

The scale of Gonzalez’s crimes was certainly unprecedented, and given both the magnitude, the size of damages, and the willful intent exhibited by Gonzalez and his associates, Federal sentencing guidelines would have tolerated a recommendation of incarceration for life. Without the plea bargain, they likely would have pursued that kind of sentence.

The question, however, is not whether Gonzalez was sentenced appropriately, but whether the investigation and subsequent trial and outcome will serve as a useful deterrent. These crimes were unusual in the cyber-crime arena because they were often committed in person, close to the target stores, so they don’t really go to the heart of the major threat of cyber-crime. This is the ability to perform criminal acts from thousands of miles away, in a different country or jurisdiction. And all signs continue to point to increasing connectivity between corporate networks, private MPLS or other WAN systems, and the internet.

Folks will continue to deploy wireless access points in default or minimally-secure configurations, and open the front door to the corporate network as a result. But we can’t simply blame bad wireless implementations for the losses suffered by Gonzalez’s victims, because there are plenty of other ingress points.

This case should serve as a wakeup call to anyone who operates a network in the public space – not that bad guys might get caught and jailed, but that there are lots more bad guys trying to get into your network next. There is no excuse for not implementing sound security architecture and practices from the outset. And the scale of losses suffered by TJX, Heartland, and the rest serves to illustrate the consequences of neglecting a sound defense. These are not nice-to-have additions — they should be fundamental to the project, budgeted up-front and anticipated for ongoing testing and enhancement.

Given the choice, I think Heartland would have still preferred not to lose $170M or suffered such damage to their brand, rather than see the perpetrator go to jail.

Friday, February 12, 2010

Are you driving yourself insane with compliance?

By Pete Russo, Senior Marketing Manager, BT Global Services

Is compliance enough for your organization to be secure? BT’s Jason Stradley recently wrote in CSO magazine how companies confuse a completed compliance checklist with ironclad security. Interestingly, Stradley says, “… compliance is a poor excuse for security”:

Approaching this from the direction of building specific solutions or groups of solutions to answer each compliance requirement will ultimately lead to an overall security posture that is lacking basic elements and is inherently insecure. Such an approach may create a security function that is more reactionary than it was prior to having the regulatory compliance variable factored into the mix. This leads us to the undeniable realization that while a byproduct of security is compliance, the reverse couldn’t be further from the truth. Given that realization, hopefully we can all be somewhat in agreement that compliance is a poor excuse for security!

If you need evidence, look at the Heartland Payment Systems breach. This major breach has taught us that compliance alone is not enough to stop an attack. While Heartland was compliant with the PCI DSS requirements, the company still experienced the biggest breach ever involving payment card data.

Clearly, compliance is not enough. As more organizations accept this fact, we must look at how we can accomplish a comprehensive security program that is a strategic function of an organization. Here’s what Stradley recommended:

Develop a long term plan or “road map” for information security within your organization and include provisions for the known compliance requirements
Work closely with your senior business executives as you create this “road map,” so that they can understand where you are going, how it will affect their part of the operation, and it will give those business leaders an opportunity to provide you with better information to build it right the first time
Share the vision of your “road map” with your entire security organization and empower them as evangelists of that vision
To the extent that your are able, plan for potential future compliance requirements in your road map
Think of these potential new requirements as you build the various security capabilities within your organization. Try to build in the ability to adapt to new or more stringent compliance requirements without major upheavals to current processes, procedures and controls in place

By following these recommended steps, your security team will become less reactionary and more proactive. This will enable your security programs to become more valuable to your enterprise and a true strategic partner to the business.

Leave us a comment and let us know your thoughts.

Monday, November 30, 2009

Security Trends and Cyber Monday: What John Pescatore’s Comments Mean To You

Toby Weir-Jones, Vice President of Product Development, Managed Security Solutions Group, BT Global Services

Most internet users give little thought to security issues beyond asking their teenaged neighbor if it’s safe to send pictures of Fluffy to their kids at college. Despite untold billions spent on awareness campaigns for the home user and at work, seemingly endless patches to Internet Explorer and Firefox, and any number of other reparative measures, we still have the same basic problems today that we had 10 years ago: users make mistakes that appear to have no real consequences, but in fact can be massively troublesome, and even potentially expensive.

John Pescatore, VP and Research Fellow for Gartner Research, was recently interviewed by Tom Field at BankInfoSecurity.com, in which he gave his opinion on the pressing security issues of the day. Among his various suggestions, the most intriguing is the notion that internet activities should be insured and, more importantly, that users should have some kind of incentive structure in order to become insurable.

Cyber Monday is just the beginning of the online seasonal frenzy that will run its course over the next few weeks. Your family, your colleagues and your staff are all likely to buy something online. Some of them will start by looking for coupon codes, or responding to apparent promotions received by email. And a smaller subset will end up going to the wrong sites, picking up some kind of nasty malware, and generally having a rotten time when their machine gets taken over, or they enter the credit card information into the wrong place. Who is really responsible for the costs of cleanup and recovery under those conditions?

Right now we pay for clean-up, but very indirectly, because the losses are generally borne by the banks that issue the credit cards. Sometimes, after a failed PCI audit, the merchants might be penalized, or suffer a chargeback if they didn’t validate a transaction correctly. Those costs – plus administrative overhead and markup – do eventually come back to the consumer in the form of fees, higher prices, or reduced availability of purchasing options. But since we don’t see them on the “Checkout” page, it’s as if they don’t really exist.

And this is the root of the issue. As users we perceive that everything we do online is free unless we consciously choose to accept to pay for it ourselves. But we also feel entitled to push all remaining costs (for development, or delivery, or risk management) back to the supplier, manufacturer, or their proxies. The status quo is so powerful that any one provider who tries to change it will see their customer base evaporate overnight, shifting to a competitor who could withstand the expense an extra day.

The system, for all its efficiencies, has introduced costs which wiggle their way into all the little nooks and crannies brought about by automation and complexity. “But if I buy it online, it has to be cheaper!” you cry. But what constitutes “it”? Yes, you’ve removed retail space and all those expenses, and your order fulfillment is doubtless more efficient, but you’ve also introduced multiple new opportunities for risk, fraud, and expense, none of which you, as a consumer, are currently willing to pay for.

There is evidence, however, that the balance is beginning to shift. Some credit card issuers are already charging a premium if you make a purchase in a country foreign to your billing address – this is nominally a hedge against the increased risk of fraud, and it has the added benefit of being a massive profit center to off-set other costs incurred in the domestic market.

Pescatore’s notion that the users need to demonstrate some form of insurability requires at least two steps: the user goes through the motions and then the underwriter bestows its blessing. This will fail as long as a single-step option, i.e., the status quo, is available. Think of Pescatore’s suggestion as PCI for retail consumers, but with much sharper teeth. There will be huge outcries against such a scheme, but as consumers we must accept that our choice to use e-commerce vendors introduces additional costs into the system. We can pinpoint where those costs originate quite accurately, based on the nature of the abuse, and it is those locations which should bear the costs (if they are legitimately responsible) or be able to pass them along the supply chain (if they are not). While I am rarely a defender of banks, the current regulations limiting consumer liability to $50, simply because a credit card in their name was involved, are far too simplistic.

One way to make such a model more palatable is to pool the risk. Lots of cards track purchases and accrue credits to a cash-back credit account, so we know the mechanics are easy enough. Instead of charging consumers outright (thereby increasing transaction costs each time they make a purchase), collect fees on certain higher-risk transactions, pool the premiums, and then disburse those funds on a quarterly or annual basis to cover loss from any transaction using that issuer’s cards. Don’t allow the banks simply to treat this as a fresh revenue stream; require any fees collected to be used first to offset incentive and IT conversion costs, second, to cover losses for otherwise-compliant merchants, and only third, to go to the bank’s bottom line.

In the meantime, modify the merchant fee structure to offer immediate penalties and incentives for compliance with next-gen PCI. Create a new PCI demarcation for IT shops that can help smaller merchants modify their web sites to use more robust processor engines. Help the smaller merchants by making it more attractive for them to run their credit card processing through larger, more established e-commerce providers, and create a market for those providers to buy books of business (via a combined cap cost and annuity) from the small and fringe processors.

Finally, make the increased cost of all this visible to the consumer. Pescatore wants a dashboard to tell a CEO if his network is safe, but a consumer needs to know that his purchase price is paying for more than just the item and the “free” super-saver shipping. Smart merchants and credit card issuers can leverage their compliance with such programs as a stronger value proposition to attract consumers, and more active participants in the risk-pooling model will help distribute accountability while amortizing recovery costs.

Thursday, September 24, 2009

What We’re Reading Around the Web

Pete Russo, Senior Marketing Manager, BT Global Services

A few weeks ago one of our resident compliance gurus, Sushila Nair of BT’s Managed Security Solutions Group blogged about what Massachusetts State Law 201 CMR 117 would mean for the rest of us. This week, it looks like we’re a step closer to finding out. Scot Petersen, Executive Editor of SearchCompliance.com reports that it looks like, “Massachusetts officials may have finally gotten their data protection regulation right,” based on reaction to public hearings held recently.

Do you think that by accommodating business need – but potentially weakening the legislation – that Massachusetts is heading in the right direction? I’m curious to hear your reactions – and we’ll definitely be checking back in with Sushila to see what she thinks when she returns from this week’s PCI SSC Community Meeting.

In other news from around the web, Robert Westervelt reports that we may be a little closer to understanding Conficker, thanks to researchers at SRI International who reverse engineered its P2P protocol. He cautions though, that while this research helps understand how Conficker spreads, vulnerability levels remain high.

How does your company defend against bots? Learn more about BT MSSG’s suggested best practices to defend against Conficker and other worms here: Conficker: What’s Next?

Monday, September 14, 2009

What We Can Learn From Albert Gonzalez: PCI DSS

by Sushila Nair

When Albert Gonzalez was indicted by the Justice Department in August for the largest and most brazen theft of credit card numbers it was estimated that he was responsible for breaches that resulted in the theft of more than of 130 million credit and debit card numbers from late 2006 to early 2008. The best known card heists in history from TJX to Hannaford all seem to lead back to Gonzalez.

According to the new indictment, Mr. Gonzalez and his conspirators reviewed lists of Fortune 500 companies to decide which corporations would be suitable targets . According to the charge sheet Gonzalez, along with two others who ‘resided in or near Russia’, injected ‘structured query language’ (SQL), a computer programming language designed to retrieve and manage data, into the computers of companies, such as Heartland, one of the world’s biggest credit and debit card payment processing companies.

Despite all the damage caused by Albert Gonzalez and his co-conspirators, there is one small silver lining: their actions have had one of the biggest impacts on the Payment Card Industry Data Security Standard (PCI DSS) and have made the standard more robust. PCI DSS was updated based on the forensics of past breaches and version 1.2 introduced the requirement for stronger wireless security, removing WEP as an option for encrypting wireless networks and requiring a wireless IDS. In particular, given that many of the attacks perpetrated by Gonzalez relied on SQL injection the introduction of web application firewalls should help prevent this kind of attacks. Gonzalez’s actions and the PCI’s response to them also plainly indicate to businesses that, in an economy where budgets are tight but the risk of breaches are high, it makes sense to place controls at the points of greatest risk.

Gonzalez and is conspirators aimed to retrieve card data out of the databases where they were stored because they got the most bang for the buck by going straight to the source . Databases are always going to be the prime avenue of attack and it makes sense to strengthen controls surrounding them. Since applications will never be bullet proof so monitoring is absolutely crucial. In the case of targeted attacks then anomaly detection becomes crucial. For example, the TJX attack occurred slowly and ostensibly silently over and18 month period. The depth and breadth of the breach would, however, have been significantly less if they had been monitoring access to the data and if they had rationalized the data that they were storing.

It would seem that with the endless tales of breaches that without requirements such as those imposed by PCI DSS many organizations would rather ride with the risk and pay fines rather than makes the investments in even rudimentary security. Before PCI DSS most retail organizations had flat networks, credit card data was unencrypted and stored in multiple places. Many retail organizations did not even have basic security detection devices like IDS/IPS. I personally have been involved in several discussions at large scale retail organizations where their IT staff were still arguing about the price of A/V software, let alone delving into more sophisticated discussions about network security. The good news, though, is that several U.S. states, including Massachusetts and Nevada, are codifying PCI DSS-like standards and are bolstering annoying fines with legal consequences.

So, while the costs of enhancing network security with IDS/IPS units and monitoring are arguably still larger than the penalties imposed by the credit card companies, the consequences of being liable under U.S. state disclosure laws are forcing companies to smarten up. For example, the full cost of the TJX breach is approaching $1 billion in the US, because of consumer protections through disclosure laws. However, if a similar breach occurred in Europe or Asia where there are currently no disclosure laws, then the company would only be liable for the costs of penalties from the credit card companies.

Gonzalez and his associates did not use rocket science to carry out these attacks – SQL injection attacks have been around since shortly after the introduction of SQL databases. Rather, their great fortune was that most companies had neither a strong understanding of the weak spots on their network nor a good grasp on how to implement rudimentary controls around sensitive data. While PCI DSS does not provide a panacea to security breaches, it certainly raised the bar and provided some more tangible steps for companies to make improvements. There is no doubt in my mind that in the years to come, tokenization and end–to-end encryption will become the standard for confidential information. We need to move the security control to where the asset really is. There is however a battle brewing on standards for accomplishing just this and the technology is expensive. Whilst we are waiting for better technical innovation around security information at the data level we need to strengthen our network access control and monitor, monitor and MONITOR.