Are You Confident You Are Meeting Compliance Requirements?
Why do we have so many different compliance regulations that affect our companies and our need to protect data? The fact is that there are people out there trying to access that sensitive information and devastating data breaches happen on a regular basis. While breaches are very difficult for companies that suffer the loss of customers, brand damage, and stiff financial penalties, it is the consumers and individuals who are most impacted by the loss of personal information, credit card numbers, or bank account numbers. Because these breaches happen and have such a catastrophic effect on individual people, state and federal and private regulations have been necessary to help motivate companies to try to protect that sensitive information and keep it out of the hands of those who would use it to commit the financial crime and fraud.
Since most companies fall under a number of compliance regulations, here is recap of the most predominant points:
PCI Data Security Standard (PCI DSS) applies to merchants, public or private, who take credit cards for payment. While PCI DSS applies to payment cards, credit cards, and debit cards (anything to do with electronic payments) there are some core components of section 3.5 and 3.6 that require encryption and proper key management:
- You must encrypt credit card numbers
- You must use an industry standard encryption (AES)
- You must provide proper management of encryption keys
- You must have dual control, split knowledge, separation of duties
PCI section 10 requires logging:
- Tracking user access to core resources
- Collecting security events in an un-modifiable log
- Consolidate the logs across all of our servers
- Monitor them for potential breaches
HIPAA/HITECH Act covers the medical segment and any partner entity under thefederal law has to comply with data protection for protected health information (PHI) of patients and must meet requirements about protecting patient information and PHI. The most recent meaningful use guidance was very clear that organizations who fall under HIPAA/HITECH must protect patient health information and we must use proper key management as a part of any encryption strategy. They were quite blunt when they said ‘don't store encryption keys on the device with protected data’... there is no gray area there!
GLBA/FFIEC applies to the financial industry (bank, credit union, trading organization, credit reporting agency). Gramm Leach Bliley Act sets standards for protecting information and consumer information. The FFIEC is responsible for publishing guidance, actually performing audits, and enforcing the standards set by GLBA around encryption and key management best practices.
Sarbanes-Oxley (SOX) applies to public traded companies (section 404 - information technology and data protection for stakeholders). SOX provides detail around data protection, guidance around cryptographic key management, and security requirements for data management. They issue very strong guidance for encrypting sensitive data of personally identifiable information (PII) that is being managed by a publicly traded company. SOX closely mirrors the National Institute of Standards and Technology (NIST) which publishes best practices guidance for encryption key management, key management lifecycles, and logging.
In the United States we have a number of state privacy laws, some of them mandate encryption, others strongly recommended it. These laws apply to both public and private organizations of all sizes and provide guidance for breach notification and penalties around data loss. There is a wide recognition that protecting data using industry-standard encryption and proper key management is a basic common safe harbor from having to do breach notification. Additionally there is a proposed federal privacy law that will eventually replace the individual state laws.
What elements do all of these regulations have in common?
- All are expecting organizations to secure personally identifiable information (anything that can be actually used to individually and specifically identify somebody) with encryption or tokenization and actively monitor their systems
- Laptops, mobile devices, removable storage, tape archives, or backup archival files must be encrypted
- Requirements that vendors, business associates, and service providers must meet the same regulations of the industry they are serving
- Multiple regulations may apply to one company (ie: a doctors office that takes credit card payments would fall under PCI DSS and HIPAA/HITECH)
One of the biggest points of audit and compliance failure is around the encryption key management strategy. While compliance regulations do not mandate FIPS 140-2 validation on a key management solution, auditors will red flag encryption or key management that's not industry-standard. They're looking for certifications like NIST validation of AES libraries or other encryption components and FIPS 140-2 validation of key management solutions. Once you encrypt your data with AES, encryption keys are the secret that you must protect. The nature of an encryption key is that it is unique to you. It cannot be easily detected or reverse engineered from the data itself. Look to NIST for recommendations about how to manage the creation and lifecycle of an encryption key (when it should be rotated or changed).
What do auditors look for in certifications and standards?
- Standards-based encryption (AES)
- FIPS 140-2 validated key management
- Security best practices of dual control, separation of duties, and split knowledge
- Policy based security
In terms of developing a data protection strategy, apply the best and strongest data protections provably based on industry standards and security best practices to all sensitive data and remember:
- Regulations are getting more stringent and specific… not less!
- Fines and penalties are getting steeper… not cheaper!
- Define personally identifiable information (PII) broadly…not narrowly!
Also crucial when you begin to consider a data protection strategy and your data is moving across multiple operating systems, databases, and platforms is to look for a common approach to encryption and key management, it will be very helpful in reducing costs and maintenance over the long-term.
I’ve included a link to our recently recorded webinar, which focuses on the IBM i system, but is applicable across most platforms. There is a great deal of detail and information on how we can help you address compliance regulations and the four core components of a data protection strategy (on the IBM i, or Windows, or Oracle, or a number of other platforms) for which Townsend Security provides solutions:
- Data at rest – AES Encryption
- Whole file encryption with PGP
- Encryption Key Management
- Secure System Logging