System iNetwork

October 21, 2008

Does Being Compliant Equate to Being Secure?

I touched base with Gary Palgon, vice president of product management for nuBridges, Inc., to get his in-the-field perspective on what's happening in the security arena as regulations continue to evolve to address ever-changing security threats. I asked him about the latest risks he's seeing, whether any new laws or regulations are coming down the pike, and if being compliant is enough to keep your business secure.

What security risks do you see businesses facing today?

Palgon: As we look back over the last four years or so, security concerns have evolved from just physical security to general security to system and software security. Today, the big push is the implementation for the Payment Card Industry Data Security Standard (PCI DSS). That standard changed security from just something that happens and that only the IT group worries about to something that has escalated to senior management.

The risks reported in the news media were initially about credit card information breaches. In the last 18 months, the news has been about breaches of other personally identifiable information. For businesses, the big risks associated with breaches today are, as data is breached, regardless of the kind of data, companies lose credibility and face lawsuits and fines. Most often, the threat driving companies to comply is the fear from the loss of credibility with their customers.

What's interesting is to note that while credit card information was the driver for compliance mandates, we're now seeing a lot across industries that don't have anything to do with the credit card piece but rather with all the other data: birth dates, driver's license numbers, and other personal information. So the laws that these companies must comply with are not what they feel threatened by, but the bigger problem for them is risks to their brand and their credibility in the event of a breach.

So the interesting part is that the only laws that require audits are SOX and HIPAA, and it has only been in the last nine months or so that true audits from HIPAA have come to fruition. For state breach notification laws (about 40 states have them), nobody comes into your business and says you're not complying. It's really an aftereffect: If you lose data, then the law kicks in and you're liable for having to notify the individuals whose information was breached. The validation that you're compliant doesn't take place until the problem has already occurred. In the insurance industry, it's those companies' responsibility as good corporate citizens to protect their clients' data, but nobody is coming in to say to them, "I'm going to routinely check that you're protecting your data." But PCI and SOX do require routine auditing.

What are the latest industry mandates, state regulations, international laws, and/or pending federal laws that you're seeing businesses needing help with?

Palgon: When we talk about the PCI Data Security Standard, there's actually a broader group of standards to consider, managed by the PCI Security Standards Council. PCI DSS is only one of several standards being overseen by this group. There's the Payment Application Data Security Standard (PA-DSS--the “cash register” itself), the PCI DSS, and the PIN Entry Device (PED) Security Requirements. There are some new laws for unattended payment terminals such as kiosks. There are rules that guide all of these.

As for federal laws, there are some pending ones but nothing that's going to happen in the next few months because of the change in the U.S. presidential administration. So we're in a quiet period for federal laws.

With international laws, there are no news ones lately, but a handful do apply. Like SOX in the U.S., the U.K. has the Companies Bill. The U.K. also has several other laws that are specific to the U.K. on how you handle data. Europe has its own laws; all around the world, there are laws. Companies that operate on a global basis have to pay attention to those laws where they operate. Regardless of where your headquarters is, you're liable for the laws where your company does business.

Does being compliant with a security mandate or regulation equate to actually being secure?

Palgon: The answer to that is easily, no. Where that became apparent was with what happened at Hannaford Bros. Co. The company was actually compliant with PCI DSS but in fact was not secure. One of the themes at last month's PCI Security Standards Council conference was that compliance doesn't equal security. So you have to continually evolve your organization and always look for new things to be secure. As we look to see how data has been breached over the years, we see that the typical bad guys initially went for data at rest in databases, so that's where the standard went to, with the PCI DSS. Then, as companies began to address that vulnerability, we got things like what happened to TJX: attacks on data moving through wireless networks. Bad buys then realized companies were locking those avenues down. There's a gap in the current PCI DSS in that it does not require data in motion within enterprises to be encrypted. Hannaford Bros. was secure on its B2B transfers and in its databases, but as data was being moved within the company, it was not encrypted.

So this is the next new area that needs to be addressed, and regulations will follow. It's an open issue that will have to be investigated to see what the options are. There has to be a start and an end to each data transfer, and the trick is to make sure that at no point is the data exposed in the clear, and when it gets to the endpoint, how do we make sure it's not put in the clear and is thereby insecure? Encrypting data is pretty simple; the difficulty is the security behind the keys and being able to make sure that only specific people have access to the keys, that no single user has control over the keys, and most important, that you rotate and change out the keys periodically.

With your customers, what issues are you seeing that need to be addressed to achieve data security on the IBM i as well as other hardware in the corporate IT environment, and how are you helping your customers tackle these issues?

Palgon: Really, it's kind of interesting, because we have a large IBM i customer base, and while historically we thought of IBM i shops as only i shops, there really are a lot more systems running in those shops than just the i. The more enterprises we touch, even though they have an i, we find that they're also running Windows, Linux, Unix, mainframe, and so forth. You can't look at those environments as silos because each of those environments must be able to transfer data and utilize data. You don't want to have to encrypt, decrypt, and re-encrypt between each environment. Companies are having to look at encryption and key management across the different platforms.

From a managed file transfer standpoint, what you're really trying to do is have control over all your transfers, external or internal, plus visibility of who's transferring what and when and to whom.

What other information or advice do you think our readers should have?

Palgon: In this realm, for data security, you need to take a strategic look and not a patch-and-bandage look. Historically, businesses have run into problems with that patch approach. We saw a lot of that approach three to four years ago, and businesses have realized that the programmer had the keys to the kingdom. Security is evolving, and it does need attention.

--Linda Harty, security & networking/connectivity editor

Posted by lharty at October 21, 2008 10:22 AM