 |
|
|
|
|
Generally, compliance regulations are quite clear on what kinds of data companies need to protect. ...Things get tricky when you need to figure out where the compliance-related data is.
|
|
|
|
|
|
|
|
|
|
In all the fuss surrounding the need for enterprises to prevent data leaks and data theft, how can an organization be sure the data it's working so hard to protect is truly all of the data that needs to be protected? Data integrity is a crucial part of Payment Card Industry Data Security Standard (PCI DSS) compliance (not to mention a company's ability to function), so ensuring that data is whole and accurate must be a priority within security and compliance teams.
Knowing which data to protect, however, can be tricky.
Generally, compliance regulations are quite clear on what kinds of data companies need to protect (cardholder data, personally identifiable information (PII), personal health information (PHI) etc.). That's the easy part. Things get tricky when you need to figure out where the compliance-related data is within your organization to appropriately track and protect it.
So before you even start to worry about PCI, it's necessary to understand how and where the important data flows within the company. Despite what DLP vendors might say, this is not strictly a technology problem, but a process and personnel issue as well. You'll need to interview people in every business unit, because you will find they are using data in ways that you couldn't possibly imagine and have perceived business needs you may not have considered. These interviews will undoubtedly spur more interviews, and eventually you'll have a pretty good idea where the data that you have to protect is and whether you are, in fact, protecting the right data after all.
With regard to PCI DSS, while in some sense the overall program is all about data integrity, a deeper dive will discover that none of the 12 PCI requirements strictly fall under the rubric of data integrity. That being said, while all 12 are important, when looking specifically at data integrity issues, there are some specific requirements that can help lead to having data integrity.
Most notably, look to the requirements around protecting cardholder data (which consists of Requirement 3, protecting stored cardholder data, and Requirement 4, encrypting transmission of cardholder data across open, public networks) and the implementation of strong access control measures (which consists of Requirement 7, restricting access on a need to know basis, Requirement 8, that users must have unique user IDs, and Requirement 9, restricting physical access to cardholder data). Requirement 8 leads directly to Requirement 10, which mandates regular monitoring of access to all cardholder data and network resources. Finally, there's Requirement 6, which mandates the development and maintenance of secure systems and applications. So, all in all, more than half of the requirements directly and obviously address data integrity issues.
As for best (or at least common) practices, what can be done to maintain the integrity of enterprise data? For starters, encrypt the data both at rest and when transmitting it across the network. Though this isn't a requirement of PCI DSS, I highly recommend that data be transmitted over SSL, even within an organization's own private networks. It doesn't add much (if any) complexity and can really help maintain integrity by ensuring that data can't be pilfered or tampered with.
Next (or even better yet, in parallel), set up logging and auditing of applications and networks so the organization can know who is accessing its data, when it is altered, and, perhaps more importantly, where that data is going. This should include some sort of ability to perform network analysis. Though not part of the PCI DSS standard, logging and auditing will become necessary if all data is encrypted; these also offer the bonus of quickly identifying when sensitive data traverses new or different paths on the network, which could potentially be a breach in progress. From what little we've heard about the recent Heartland Payment Systems Inc. breach, this sort of logging and auditing technology would have likely identified the issue much sooner, sparing the company some serious fallout.
Similarly, by building and maintaining secure systems and applications, you can have a much higher comfort level that the data you have in those systems is the data you think you have, and that only those who have appropriate access and authorization have been able to alter it.
As an added bonus, by following these types of processes (encryption, logging, auditing, secure applications, etc.) you gain not only compliance with PCI DSS, but also with other regulations such as Sarbanes-Oxley (SOX).
For other suggestions, there are many more detailed PCI DSS descriptions available online. Examples include general information on PCI DSS, creating a prioritized approach to PCI DSS, guidelines for PCI DSS compliance for wireless networks and understanding the intent of the PCI DSS requirements. These will give you a great baseline from which to start dealing with data integrity, as well as some ideas on where to go from there.
About the author:
As CSO-in-Residence, David Mortman is responsible for Echelon One's research and analysis program. Formerly the Chief Information Security Officer for Siebel Systems, Inc., David and his team were responsible for Siebel's worldwide IT security infrastructure, both internal and external. He also worked closely with Siebel's product groups and the company's physical security team and led up Siebel's product security and privacy efforts. A CISSP, Mr. Mortman sits on a variety of advisory boards including Qualys and Applied Identity and Reflective, amongst others. He holds a BS in Chemistry from the University of Chicago.
