Townsend Security Data Privacy Blog

There are are a few major components of PCI-DSS that need to be addressed when implementing an external key manager into your data encryption equation.  Separation of duties for starters, simply states that those who have access to the sensitive data, such as card holder details or credit card numbers cannot also have access to the encryption keys that protect them.  Conversely, the same can be said for the individuals that are responsible for managing data encryption keys -- they should not have access to the sensitive data for which the keys they are creating are used to protect.  Quite simply, separation of duties is the concept of dividing critical data protection processes between different individuals. This helps reduce the opportunity and likelihood of fraud when processing sensitive data.

I often talk with companies who've until recently considered encryption key management as an afterthought to their security infrastructure.  Often times they would store encryption keys on USB sticks or locally, alongside the encrypted data.  This approach allows individuals within the organization access to both the keys and data, directly conflicting separation of duties.  Utilizing an external encryption key manager to house your encryption keys, as well as implementing a policy where your security team are the only ones managing those keys and your DBA's and users are the only individuals accessing the data, will help move you in the direction of PCI compliance.

But of course there are other pieces to PCI that one should be aware of when it comes to proper encryption key management.  While separation of duties is good practice, there is an additional level of security that can be implemented on the encryption key management side called dual control.  Dual control is a process that requires the involvement of two or more individuals to complete a specified task, such as creating a key, changing its attributes, revoking status, or destroying an encryption from use forever.  Think of dual control as the act of requiring two individuals with two different keys to unlock the launch codes for a nuclear missile.  You certainly wouldn’t want all that responsibility resting on the shoulders of just one person with no oversight in place.  The same can be said for the management of your encryption keys.

To implement dual control on Alliance Key Manager (AKM), our encryption key management HSM, you'd first active it in the AKM configuration file of the hardware appliance.  Then the two Security Admins responsible for key management would install our Java based admin console into their work environments and configure them to communicate with the key manager over a secure TLS connection.  Once this is established, the first Security Admin would authenticate to the key server and set an 'Authorized Administrator' time period.  This allows the the first Admin to specify a window of time (in minutes) where the other Admin can log onto the key manager and perform their duties.  Taking this approach to key creation and management adds that additional layer of security to your encryption key environment.

In Part II of 'Meeting PCI-DSS Requirements for Key Management'  I will discuss the importance of capturing your audit logs and transporting them to a collection server off the key manager device as well as dig into the concept of split knowledge and how AKM meets that requirement. Until then, download our white paper on encryption key management requirements for PCI.

Data breaches are becoming an impending reality for any company maintaining sensitive data on their systems—which is the majority of them. Due to the increase in breaches, you may be asking yourself at this point, “Which compliance regulations apply to my organization?”

Currently, the network of compliance regulations is somewhat fragmented across multiple regulating organizations. Some of them are government based and some are private industry based. The common regulations that all organizations are likely to run into are:

Payment Card Industry Data Security Standards (PCI DSS)

• If you take or process credit card information, you absolutely fall under PCI DSS standards. This means that you must encrypt credit card information, when it is at rest or in motion. You also must implement encryption key management that uses proper dual controls and separation of duties. PCI DSS also requires periodic encryption key rotation.
• PCI section 10 requires the collection of logs, storage of logs, and monitoring of system logs in order to monitor for potential breaches. Over time, as companies have done forensics on data breaches, in many cases the investigators found that a breach could have been easily detectable early on before the data was lost, had logs been properly monitored using system logging.

HIPPAA/HITECH

• If your company operates in the medical sector—which is any organization defined as a covered entity within the HIPAA act—you fall under HIPAA/HITECH data security regulations.
• The HITECH act of 2009 strengthened HIPAA regulations tremendously by referring to the National Institute of Standards and Technology (NIST) for both encryption standards, best practices of encryption key management, and the collection of system logs.
• Although there is no mandate in HHS and HIPAA/HITECH that you must encrypt patient information, there is a “back door” mandate that in the event of a data breach, all covered entities must report the breach to HHS. The only safe harbor from breach notification and potential fines is properly encrypted data.

GLBA and FFIEC

• The Gramm-Leach-Bliley Act and Federal Financial Institutions Examination Council regulate data security in the financial sector. Under these regulations the financial industry is defined broadly and certainly includes banks, but also covers credit reporting agencies and other financial institutions. FFIEC is tasked with conducting audits and making sure banks line up with regulations, which have a strong focus on protecting consumer information. One statement they make in their documentation is that effective and proper key management based on industry standards is crucial.

SOX (Sarbanes-Oxley)

• Any publicly traded company in the United States falls under SOX regulations. There has been quite an increase in the focus on data privacy by SOX auditors--particularly encryption key management and system logging. From the beginning SOX auditors have held departments to high standards in terms of best practices and proper control of data. This increased focus on data protection has developed within the last 12 months or so. Several of our customers have told us they’ve been penalized for their insufficient encryption key management strategy by SOX auditors

Federal and State Laws

• Currently 45 out of 50 states have data privacy regulations. Many organizations are unaware of their own state’s data privacy laws, or assume those laws do not apply to them, when in fact they almost always do.
• Apart from the data security standards listed above, there is currently a proposed federal privacy law working through congress. It is safe to assume that a new federal data privacy law will be enacted soon.

Ultimately, regulations are becoming more stringent, not less. Fines and penalties are getting steeper, not cheaper. And certifications are becoming more important, not less important. Even more critical is the fact that these regulators demand that you use industry standard, NIST and FIPS 140-2 certified key management and encryption. Without these credentials, your company may not be compliant.

For more information on AES, download our white paper "AES Encryption and Related Concepts" and learn about how proper encryption and key management work together to secure your data.

Did you know that any organization that handles sensitive information (PHI, PII, etc) is can be audited in the event of a data breach? You may be asking yourself, what does a security auditor look for? I recently sat down with Patrick Townsend, President & CEO of Townsend Security, to discuss how organizations can set themselves up for success when they get audited.

Patrick Townsend:

“First of all, in my experience, companies will have different experiences with different auditors. Some auditors will be more knowledgeable about certifications and encryption best practices than others. However, there are three critical components of data security that all auditors will look for:

1. NIST-Certificated Encryption and FIPS 140-2 Certified Key Management
One problem that we see companies face is that they are using encryption, but have implemented non-standard technology, which almost never withstands proper scrutiny. At Townsend Security, we stand behind our standards based products because they have gone through rigorous testing by NIST chartered testing labs.  Our AES encryption is NIST certified and our encryption key manager is FIPS 140-2 certified — which means they have been independently tested and certified to meet best practices.

2. Security Best Practices
Use best practices of dual control, separation of duties, and split knowledge. These three practices are parts of NIST encryption key management best practices and are critical to your security posture. As a company, you must insist on employing these practices in order to meet the highest standards of data security.

3. Policy Based Security
Invest in policy-based security. This type of security will be developed to deploy data protection with all data security regulations in mind—both federal and state. Every company falls under state and proposed federal privacy laws, and therefore, companies handling sensitive data will do better to use certified data security solutions built by companies who can tailor their products to meet an organization’s individual needs.

Here at Townsend Security we are always moving forward with you, our customers, to help meet a variety of compliance regulations with the most standard, up-to-date, and industry-certified security solutions. We want to help our customers always pass their security audits with flying colors!

Download a free 30-day evaluation of NIST-certified Alliance AES Encryption to start meeting compliance regulations (PCI DSS, HIPAA, etc.).  Additionally, learn how to easily store encryption keys separately from your encrypted data with a secure encryption key management HSM by visiting our Encryption Key Management Simplified Resources page.

It is important for businesses of all sizes running on SQL servers to encrypt any sensitive data that they store or move. Although business size can determine specific compliance requirements that need to be met, all companies handling sensitive data are vulnerable to the major risk of failing a security audit if their data isn’t properly secured on their SQL servers.

Here are the 5 steps you can take to ensure you pass your next audit:

1. Test applications to address vulnerabilities

Continually test and re-test your applications including payment applications and firewalls  to look for vulnerabilities and address them from the start.

2. Protect information transmission

Protect data in motion by offering secure authentication features, logging application activity, using secure payment applications, and protecting wireless transmissions.

3. Protect your data

Ensure stored cardholder or PII/PHI data is protected with encryption; this information should never be stored on a server that is connected to the internet.

4. Encrypt sensitive traffic over public networks

Any transfer of data over public networks should be encrypted, whether this is cardholder information or PII/PHI data. Encrypting sensitive information guarantees that if it is intercepted that it is unusable without the encryption key.

5. Separate the encryption key from encrypted data

Separating the encryption keys from the data ensures the safety of the data in the event of an outside breach. It also allows internal separation of duties, thereby preventing unauthorized access to the the SQL Server data. This is a best practice for encryption management when dealing with sensitive information.

Taking theses steps in order to pass a security audit will proactively prevent data breaches. Even if data becomes compromised, properly encrypted data will guarantee that the data can not be used or accessed.  With a comprehensive data security plan, your company can easily meet state and national compliance regulations. Using proper encryption and key management on SQL Server will make encrypting your data quick and painless, and will help ensure you pass your next audit.

Download our White Paper “Encryption Key Management with Microsoft SQL Server 2008/2012” to read more about encryption key management, meeting compliance regulations with a certified HSM, and how to utilize about TDE and EKM on your SQL server.

Many people we talk to are gambling with $7.2 million whether they realize it or not.  This week we are at HIMSS12 in Las Vegas meeting members of the IT medical community – an appropriate venue for such high-stakes gambling.  How are these people gambling with so much money?  The average cost of a data breach is $214 per record, or $7.2 million for an organization.  This figure is determined not only by direct costs of a data breach, such as notification and legal defense costs that impact the bottom line for companies, but also indirect costs like lost customer business due to abnormal churn.

Is there a way to make sure you aren’t putting your organization in such risk?  The HITECH Act, the compliance regulation that the medical community is concerned with, says that the only way to avoid a breach notification is through the use of industry standard encryption such as AES, and appropriate encryption key management technologies.  Other compliance regulations (such as PCI DSS) go as far as REQUIRING protecting Personally Identifiable Information (PII) with encryption and key management – not just to receive a breach notification exemption.

Becoming compliant with these regulations doesn’t have to be hard (though it can be).  Townsend Security has made it easy (saving your organization time and money) with NIST-certified AES encryption for all the major enterprise platforms, as well as a FIPS 140-2 certified encryption key management hardware security module (HSM).  For those organizations who are already encrypting but need key management, our encryption key manager can easily work with your existing database (SQL, Oracle, DB2, etc.) to help meet compliance requirements that call for separation of duties and dual control.

If you aren’t familiar with NIST and FIPS 140-2 certifications, the National Institute of Standards and Technology (NIST) provides them to encryption and key management solutions after they undergo a rigorous testing process.  The testing is carried out by independent testing labs who then report the results directly to NIST for validation.  Only the most dedicated security vendors are able to pass the tests and achieve NIST and FIPS 140-2 certifications.  Not only are these certifications essential for meeting compliance regulations, but they provide you an ease of mind that a third-party has verified the integrity of the product.

So are you gambling with $7.2 million?  If you aren’t protecting your PII with encryption and key management you might be.  Take the first step for help and call our gambling hotline (800-357-1019) or send us an email.  We’d be glad to help you step away from the table.

Learn more about proper encryption and key management best practices for HIPAA and HITECH Act in our white paper titled "Achieve Safe-Harbor Status from HITECH Act Breach Notification".

Are you an ISV?  Visit our ISV Partner Program page for more information on becoming a partner or download our white paper titled Healthcare ISVs: Critical Issues in Meeting HITECH Data Protection Regulations.

In the first part of our series on system logging on the IBM i (AS/400) we discussed why system logging is so important and where security information lives on the IBM i.  We will now continue my conversation with Patrick Townsend, Founder & CTO, and talk about log collection and meeting compliance regulations with system logging.

So now that you have identified the sources of this important system information, how do we format it for log collection and SIEM Servers?

This is probably the biggest challenge for IBM i users - getting log information from the IBM i into a usable format.  IBM i logs are not recognizable by a typical log collection sever or a SIEM console that monitor log data.  With Alliance LogAgent, we have tackled this problem by reading all of these sources of event information and translating from the IBM i format to a standard log format.  IBM does provide a few utilities for printing log information, and I have seen people try to use those to get data into a text type format, but they are unsuccessful because the printed log information is not in a standard format.  Another reason why this method doesn’t work is that it is typically not in real-time, so you’re not picking up information in a timely fashion - meaning you are missing threats that are happening in your machine.

Formatting data is a major challenge and we decided that the right way to do this was to bite the bullet and read the internal format of the logs, while they are completely unrecognizable to any standard log collection server, and format them to industry standard formats - based on existing RFC’s in terms of SYSLOG formats or Common Event Format.  Alliance LogAgent puts them in the right format and transmits them.  The technology in our logging solution is really focused on making all that log information usable, doing it in real-time, and then getting it to where it needs to go – allowing it to be monitored by your SIEM in real time.

System logging is also important for meeting compliance regulations too, right? 

Absolutely, if you take a look at PCI data security standards from the beginning, section 10 is focused on collecting logs and analyzing them in a timely fashion.  If you drill down into the recommendations for HIPAA/HITECH Act, or if you’re looking at FFIEC in the financial sector, or even privacy notification laws, they are all very consistent about requiring proper monitoring of system logs.  And this is understandable, looking at how threats evolve and what the typical threat looks like.

Sometimes bad software gets installed on a system and sits there for months at a time, undetected because nobody is monitoring the logs. That software can be phoning home through an IP connection and checking in through remote servers.  Your logs should be showing that activity.  That is why you’ll find across the board, in almost every compliance regulation, a need or requirement to collect logs in a central location, on a log collection server, or in a SIEM.  Someone needs to be paying attention to those logs and “someone” could be automated software, including products from SIEM vendors.  It is really important from a compliance point of view that you are collecting logs, doing it in a fast, real-time fashion, and have something monitoring those logs looking for threats.

View our Webcast “Understanding Log Management on the IBM i” for more information on logging and how it can help you meet compliance requirements with real-time security event logging across your Enterprise.

At Townsend, we have a lot of conversations with customers and prospects about data privacy, compliance requirements and best practices for IT security in general.  We have written numerous articles on these topics and posted them on our blog.  As the end of 2011 quickly approaches, we thought it would be worthwhile to list out our most read articles of the year.

Listed below are the top five read articles from the past year:

• AES Encryption Flaw - Calm Down
  
• PCI DSS 2.0 and Encryption Key Management
  
• Encryption and Key Management in a .NET World
  
• IBM i FIELDPROC Surprises
  
• RSA Encryption Key Size Requirements Change in 2011

We aren’t surprised that the articles on these topics; encryption, key management and PCI compliance are some of the most read on the blog.  We spend the majority of our days talking to people about these topics and helping them solve challenges around data privacy and compliance.  In fact, many of the conversations we have lead to new products and product enhancements.    

In 2012, we encourage you to talk to us about what you need and what you are doing at your company to protect sensitive data.  Subscribe to our blog, like us on Facebook, follow us on Twitter or join us on LinkedIn.

We hope you find the articles listed useful and that it inspires you to think of topics you would like us to write on for 2012. Thank you for your readership in 2011!

We are already preparing and looking forward to sharing more about data privacy in 2012.  

Happy Holidays!!

Last week we held a well-attended webinar titled “Secure Managed File Transfers” Meeting Compliance Regulations.” The webinar covered meeting the data in motion requirements of PCI DSS, HIPAA/HITECH, and other regulatory compliance requirements with Alliance FTP Manager, our secure managed file transfer solution for the IBM i.  During the presentation we received several great questions that we’d like to share with you on our blog.  As always, if you have any additional questions, send them our way.

Is there a reason why I shouldn't use PGP on windows? I can just transfer my file from IBM i to windows and then PGP encrypt it there. Does this make sense?

Yes, I fully understand why customers would want to take that approach, however if you are under PCI DSS regulations you would be out of compliance. The transfer of sensitive data across a network and then landing unencrypted will take you out of compliance, even if you encrypt it later. There is no question about that. That is a situation we have been remedying for customers for a number of years. The security best practice standard is to encrypt at the source and decrypt at the destination. So you need to avoid the transfer of unprotected data through internal servers or across any network. You really want to make sure that the encryption is in place and that the data lands encrypted.

Can managed file transfer be used on just one side or do both sides of the transfer have to have the same software?

Good question, first off, I'd like to point out that managed file transfer is a term of art. There is no formal definition, no RFC, no NIST standard. So for this answer, you're going to get my opinion on this. In our managed file transfer solution there are absolutely no requirement that a recipient of an encrypted file or a secure transfer needs to have our software. Our solution is based on open standards and no customer ever needs to deploy software in order to process a transfer. Open standards give you many software choices and give your trading partners a lot of choices on what they want to use.

Regarding Open PGP implementation, which RFC or RFC's do you follow? 

Well there are a couple. There is an original RFC2448  and there is a later RFC4884. Our commercial PGP product from Symantec is compliant with all of those standards - so the original and newer PGP RFC's are fully supported in our commercial product. Therefore we stay well lined up with those particular standards. Of course, there are some capabilities in the commercial product that are not defined as a part of the open standard - they are an extension if you will. There are a number of capabilities in the commercial version that really help larger enterprises stay lined up with compliance requirements and meet best practices. Those are built on top of full compliance with open standards.

View a recording of our webinar Secure Managed File Transfers: Meeting Compliance Regulations for more information on meeting data in motion requirements of PCI DSS, HIPAA/HITECH, and other compliance requirements on your IBM i.

The recent 2011 PCI Compliance Report released by Verizon concludes that many companies are losing ground on PCI DSS compliance and 44% of all breaches take over a year to be discovered. These findings are disturbing. eWeek.com wrote an excellent summary of the report.

Here is one snippet from the article:

"About 42 percent of organizations had trouble encrypting data in the database or implementing a proper key management strategy to keep the information safe."

We know that data protection is the hardest part of PCI DSS compliance. Many studies show that organizations struggle with encryption and key management. But are they really losing ground after they get their data in place?

I talk to a lot of customer about PCI DSS compliance, and I have a different take on this.

The recent audit and training changes that affect Level 2 Merchants may be showing up in this statistic. Prior to 2011, Level 2 Merchants completed an annual Self Assessment Questionnaire (SAQ). Starting in 2011 Level 2 Merchants must either undergo an on-site audit by a QSA auditor, or send a member of their IT team for ISA training by the PCI council. A lot of companies are opting for the second option and are getting their internal staff through the ISA training process.

I think that a lot of these newly trained IT professionals are coming back home and understanding encryption and key management requirements a lot better. It was easy to put the check marks in the box when doing the SAQ questionnaire. Now there is a lot more thought about what good encryption and key management means. I think that is driving a lot of the change, especially in the area of key management.

Did these companies lose ground? No, they weren’t in compliance before, and they are just coming into compliance now.

Customers tell me that meeting the PCI DSS requirements for key management is their biggest area of remediation. They’ve been storing encryption keys in a file, or somewhere on the hard drive, or on a USB storage device, or on another server where they are not properly protected. None of these techniques can meet PCI DSS requirements for Dual Control, Separation of Duties, and Split Knowledge. Really, any storage of data encryption keys on the same server as protected data is going to be a compliance problem. Newly trained IT staff now understand this and are taking action to fix the problem.

So, did they fall out of compliance? No, they weren’t in compliance before and now they are moving towards better security. And that is a good thing.

I don’t mean to minimize the effort that it takes to stay in compliance with PCI DSS. It’s a lot of work and it takes on-going attention. And security and IT departments are under the same budgetary pressures that all of us feel. They are trying to make do with fewer people and smaller budgets. 

But perhaps the news is not as bad as we think. If you haven’t taken a look at your key management strategy lately, now is the time to do it.

Fore more information, download our podcast "Key Management Best Practices: What New PCI Regulations Say" and learn about encryption key management best practices, as well as what PCI has to say about integrated key management (why it isn't a good thing), dual control, separation of duties, and split knowledge.

Patrick

As “The Encryption Company,” we often blog about meeting PCI DSS with encryption and key management.  Our NIST-certified technologies will help your organization satisfy Section 3 of PCI DSS, as well as other privacy regulations.  But there is another section of PCI DSS that Townsend Security can help you with – Section 10.

Section 10 states the requirements for tracking and monitoring access to network resources and cardholder data.  Some things that this section speaks on is procedural – daily reviewing logs for all system components and retaining an audit trail history for at least one year.  Section 10 also specifies how your logging solution needs to perform.  This includes automating audit trails for all system components and securing audit trails so that they cannot be altered.

This regulation is especially important for organizations using IBM i’s.  The state of logging on most IBM i’s is not good.  The IBM i doesn’t log information like your other systems and the security logs that it does produce are often an enclave inside the IT organization.

So what does this mean?  Only the IBM i administrators can know what is happening on that machine – all the valuable logging information is sequestered on the IBM i.  Network originated threats to the IBM i are often not noticed or responded to by the security team.  This puts a lot of sensitive data at risk and your organization not meeting compliance regulations.

There is an answer.  Townsend Security has been helping customers meet section 10 of PCI DSS with Alliance LogAgent.

Alliance LogAgent

• A complete solution that can capture and forward all IBM i security events
• Built by IBM i experts specifically for SIEM integration
• Robust filtering capability minimizes network impact
• Strong encryption between IBM i and SIEM console
• Seamless integration with ANY SIEM console
• Integrated User Monitoring and log forwarding 

To learn more, we recently recorded a webinar titled “Understanding Log Management on the IBM i.”  View this 30-minute webinar and learn how to meet compliance requirements with real-time security event logging across your Enterprise.