May 18 2010

Taking Credit Card Security Seriously

Category: pci dssDISC @ 1:33 pm

NEW YORK - MAY 20:  In this photo illustration...
Image by Getty Images via Daylife

PCI DSS v1.2: A Practical Guide to Implementation

By David F. Carr @ Forbes

The easiest way for small businesses to address the information security requirements imposed by credit card companies is the wrong way. I’m talking about lying and praying.

In 2004 the major credit card companies got together to define a common Payment Card Industry Data Security Standard (PCI DSS, often referred to as just PCI). They are gradually ratcheting up the pressure on merchants of all sizes to comply. Large companies, and some smaller ones that process a large volume of transactions (particularly if they’re doing it on the Web), are required to have an independent review of their processes and systems by a security professional credentialed as a qualified security assessor (QSA). Most small businesses can instead complete a self-assessment questionnaire, where they essentially grade themselves. That’s where the lying comes in. It’s not so hard to check off all the right answers (“Sure, I review my e-commerce server logs on a daily basis.”) without actually making them true.

If you’re lying, you had better also be praying. If caught, you could be fined for non-compliance, to the tune of tens or hundreds of thousands of dollars–enough to put many a small organization out of business. Expect even harsher treatment if someone hacks your systems and downloads card data you claimed you weren’t even storing.

Most of the requirements are basic security, like making sure there is a firewall between your Internet connection and any system that stores credit card numbers. Factory default passwords on your network equipment must be changed, so that no one can log on as user “admin,” password “admin.” And so on. More specifically, you’re responsible for protecting card holder data, and there’s some data you’re never supposed to store–like the full contents of a card’s magnetic strip.

Many small businesses are still under the impression that the rules don’t apply to them because they’re too small, or because they don’t conduct e-commerce. Actually, the rules apply to any business–and even any nonprofit–that takes credit card payments. You can look for ways to lighten the compliance burden, but you can’t get yourself off the hook entirely. Even if no one has yet compelled you to complete a questionnaire or conduct an automated scan of your networks, you’re still supposed to be locking down your systems.

Some businesses complain this all sounds too complicated and expensive. But they are missing the point, says Anton Chuvakin, author of PCI Compliance: Understand and Implement Effective PCI Data Security Standard Compliance. The PCI rules really represent the minimum security standards businesses must meet to be fair to their customers, who, after all, are trusting the merchant every time they hand over a credit card number. In the wake of a card security breach, a larger business might suffer from the fines, damages and adverse publicity resulting from a card security breach. By contrast, “a small business is more likely to be GONE,” Chuvakin said. “Businesses that endanger their customers really do deserve to die.”

If your organization is not equipped to handle credit card data securely, maybe you should not be handling it at all. Look for ways to shift as much of the burden as possible onto a service provider that specializes in secure payment processing. Services such as PayPal and Authorize.net let you forward customers to their websites for payment processing; credit card numbers never pass through your hands at all

Small businesses such as restaurants that use an older generation of countertop credit card terminals may be breaking the rules inadvertently because the device stores magnetic stripe data or otherwise violates the PCI requirements. So consider upgrading to a payment device that is certified PCI compliant. Basic terminals capable of encrypting Personal Identification Number (PIN) codes and protecting other sensitive information are available for as little as $100 and might even be offered free by merchant account services trying to win your business. The PCI Security Standards Council publishes a list of approved devices. Just remember that using a compliant device is only one element of making your business compliant.

Even if you’re not storing anything explicitly prohibited, you may be storing more credit card data than you need to. Small merchants typically store a day’s worth of credit card numbers on a card swipe terminal, then process all the transactions in a batch at the end of the day. Bigger retailers may record the card numbers in a centralized database so they can track all a customer’s purchases, and so they can retrieve the number if they need to issue a refund. But do you need to retain those numbers at all?

Possible Solutions
Perhaps not. Martin McKeay, a QSA and author of the Network Security Blog, recommends looking at new strategies for using end-to-end encryption and “tokenization.”

For example, payment processor First Data ( FDC – news – people ) and security software firm RSA Security have developed a product called TransArmor that allows merchants to get authorization for a credit card number and then immediately dispose of the card number, replacing it with a token. The token is another number that acts as a stand-in for the credit card number itself. First Data keeps track of which tokens correspond with which credit card numbers. So if you’re executing previously authorized transactions at the end of the day, you send First Data a batch of tokens, and it relays the card numbers on to the bank. But if the tokens are stolen, by themselves they are worthless to anyone else.

“With this, the only time you need the true credit card number is when you do the authorization,” says Craig Tieken, First Data vice president of merchant product management. “The merchant, in our opinion, no longer needs the card number.” TransArmor is still in beta testing, scheduled for release in the summer of 2010.

PCI DSS v1.2: A Practical Guide to Implementation

Tags: Business, Credit card, First Data, Payment Card Industry Data Security Standard, PayPal, Personal identification number, Qualified Security Assessor, Tokenization


May 11 2010

OCR draft guidelines for security risk analysis

Category: hipaa,Security Risk AssessmentDISC @ 12:42 am

US Department of Health & Human Services
Image by veeliam via Flickr

The Health & Human Services Department published draft guidance to help healthcare providers and payers figure out what is expected of them in doing a risk analysis of their protected patient health information.

The security rule of the Health Insurance Portability and Accountability Act (HIPAA) requires that providers, payment plans and their business associates perform a risk assessment, but does not prescribe a method for doing so, according to draft guidance from HHS’ Office of Civil Rights (OCR). The HITECH Act directed that OCR oversee health information privacy.

Risk analysis is a technique used to identify and assess threats and vulnerabilities that may hamper the success of achieving bsuiness goals. In risk analysis determines if the security controls are appropriate compare to the risk presented by the impact of threats and vulnerabilities.

The guidance is not intended to provide a one-size-fits-all blueprint for compliance with the risk analysis requirement. Rather, it clarifies the expectations of the Department for organizations working to meet these requirements. An organization should determine the most appropriate way to achieve compliance, taking into account the characteristics of the organization and its environment.

Some of the content contained in this guidance is based on recommendations of the National Institute of Standards and Technology (NIST), OCR said

OCR guidance document explains several elements a risk analysis must incorporate, regardless of the method employed. So basically the auditor will be looking for all the elements required by the guidelines during an audit.

OCR dratf guigelines details

Information Security Risk Analysis, Tom Peltier

Tags: Business, Civil and political rights, Health care, health insurance, Health Insurance Portability and Accountability Act, National Institute of Standards and Technology, Optical character recognition, Security


May 04 2010

IT risk assessment frameworks: real-world experience

Category: Risk AssessmentDISC @ 5:17 pm

By Bob Violino, CSO

Assessing and managing risk is a high priority for many organizations, and given the turbulent state of information security vulnerabilities and the need to be compliant with so many regulations, it’s a huge challenge.

Several formal IT risk-assessment frameworks have emerged over the years to help guide security and risk executives through the process. These include:

Operationally Critical Threat, Asset and Vulnerability Evaluation (OCTAVE)

Factor Analysis of Information Risk (FAIR)

the National Institute of Standards and Technology’s (NIST) Risk Management Framework (RMF)

Threat Agent Risk Assessment (TARA), a recent creation

OCTAVE
OCTAVE (Operationally Critical Threat, Asset and Vulnerability Evaluation), developed at the CERT Coordination Center at Carnegie Mellon University, is a suite of tools, techniques and methods for risk-based infosec strategic assessment and planning.

OCTAVE defines assets as including people, hardware, software, information and systems. There are three models, including the original, which CERT says forms the basis for the OCTAVE body of knowledge and is aimed at organizations with 300 or more employees; OCTAVE-S, similar to the original but aimed at companies with limited security and risk-management resources; and OCTAVE-Allegro, a streamlined approach to information security assessment and assurance.

The framework is founded on the OCTAVE criteria—a standardized approach to a risk-driven and practice-based information security evaluation. These criteria establish the fundamental principles and attributes of risk management.

Also see How SCAP Brought Sanity to Vulnerability Management

The OCTAVE methods have several key characteristics. One is that they’re self-directed: Small teams of personnel across business units and IT work together to address the security needs of the organization. Another is that they’re designed to be flexible. Each method can be customized to address an organization’s particular risk environment, security needs and level of skill. A third is that OCTAVE aims to move organizations toward an operational risk-based view of security and addresses technology in a business context.

Among the strengths of OCTAVE is that it’s thorough and well documented, says Brooke Paul, managing director at Capital Informatics and former CSO at American Financial Group. “The people who put it together are very knowledgeable,” says Paul, who has evaluated the framework for clients. “It’s been around a while and is very well-defined and freely available.”

Because the methodology is self-directed and easily modified, it can be used as the foundation risk-assessment component or process for other risk methodologies, says Ron Woerner, security systems analyst at HDR, an architectural and engineering firm. Woerner says he’s used a hybrid of OCTAVE, FAIR and other methodologies.

“The original OCTAVE method uses a small analysis team encompassing members of IT and the business. This promotes collaboration on any found risks and provides business leaders [with] visibility into those risks,” Woerner says. “To be successful, the risk assessment-and-management process must have collaboration.”

In addition, OCTAVE “looks at all aspects of information security risk from physical, technical and people viewpoints,” Woerner says. “If you take the time to learn the process, it can help you and your organization to better understand its assets, threats, vulnerabilities and risks. You can then make better decisions on how to handle those risks.”

Experts say one of the drawbacks of OCTAVE is its complexity. “When it shipped, we spent hours trying to understand what it was that this package was going to do for us,” says Adam Rice, global CSO and vice president of managed security services at Tata Communications, a provider of communications services.

“There was a lot of time taken up just trying to understand what the approach was, because it wasn’t very clear to me,” Rice says. “Anything that takes a lot of time detracts from its use.”

Paul adds that a downside to OCTAVE is that it doesn’t allow organizations to mathematically model risk. “It’s a qualitative methodology, like most others available today,” he says.

Next at page 2:FAIR, Page 3:NIST RMF and Page 4: TARA methodology
1 2 3 4 »

Information Security Risk Analysis, Tom Peltier

Tags: FAIR, NIST RMF, OCTAVE, Risk Assessment, TARA