Townsend Security Data Privacy Blog

I am often asked about how one can restrict access to Alliance Key Manager (AKM), our encryption key manager.  There are a few different options available here in relation to locking down and controlling who has access to which keys.  This often is a concern for bigger organizations that have multiple departments authenticating to the encryption key manager and performing key retrieval operations, but I’ve known smaller companies as well that take advantage of the granularity AKM provides in this area.

One way you can restrict access to Alliance Key Manager is by restricting keys to specific users or groups of users. The users and group access can be defined on a system level, or at the level of each key. When you create a key you can define the restrictions on user and group access.

Since all connections to AKM are mutually authenticated over a TLS session, you as a client (key requestor) must present an X509 digital certificate to AKM that is signed by a trusted Certificate Authority (which needs to be known to the key server).  Within your client certificate are multiple fields of user data collectively known as the Distinguished Name (DN). Further, within the DN you'll define fields with information regarding who you are, what organization you are with and where you're located. There are two fields in particular that the AKM server will look at to determine your Group or User privileges. These are the Common Name (CN) field and the Organization Unit (OU) field. We look at the common name to determine user access and the organization unit to grant group authority.

Lets look at an example.  There is an AES encryption key available on an AKM server used to protect an employee's personal data. It is restricted so that only members of the Human Resources group can use that key. So any individual with "Human Resources" defined as their OU can successfully request that key, all others are turned away. This is Group Restricted Access.

To further this example, the director of Human Resources, Sam, needs access to a specific key only he can use. There would then exist an encryption key on AKM that has group and user policy defined as "Sam / Human Resources" and Sam's X509 digital certificate would have the CN of "Sam" and the OU of "Human Resources." This would ensure only he is allowed to access that key. This is strict group and user control of key usage and deters other "Sams" in the company from getting the key, as well as other individuals within the "Human Resources" department.

There are a few other ways to restrict access. You can specify just specific users who can access keys and ignore the group altogether. This would require defining a user table within AKM and tying specific keys to it. Then any user with the appropriate CN can authenticate and use those keys. The same can be done for groups as mentioned previously or any combination of group or user status as defined by the group or user table laid out on AKM.

And lastly you can allow anyone with an authenticated x509 digital certificate that can latch up to the key server successfully request a key. This method ignores the CN and OU altogether and is the least restrictive level of key access. However it still locks down key control as only authenticated clients with proper certificates can gain access to encryption keys.

For more information on the importance of encryption key management, download our white paper "Key Management in the Multi-Platform Envrionment" and learn how to overcome the challenges of deploying encryption key management in business applications.

I went to my first ever kickboxing class the other night, and it kicked my butt, LITERALLY.  I thought that because I work out on a daily basis and recently ran a 10K, that a 1-hour kickboxing class would be a nice cardio day for me.  Boy was I wrong.
I can imagine that PCI audits can be like this for others, maybe even you.  You think you have nothing to worry about (after all, you have been investing heavily for this day) and then WHAM, your auditor/kickboxing instructor knocks you down flat!

We hear this from companies as they go through their audits: “We thought we were doing everything correct.  All our cardholder data was encrypted!”

What these companies fail to realize, and what the auditor will quickly point out, is that proper encryption requires encryption key management!

“But wait, we are a level two merchant and you want us to do what?  Manage our encryption keys?  Since when do you have to manage your encryption keys separate from your appliance?  Doesn’t IBM offer a key store on your IBM i (AS/400, iSeries)?"  I was shocked the exact same way when my instructor said, “We’re going to do 2 punches, 1 hook, and a roundhouse kick to the bag, and you need to repeat this for the next 2 minutes!”  Are you kidding me?

Townsend Security works with you to meet PCI audit requirements.  We assist organizations both large and small obtain compliance in sections 3 & 4 with our AES encryption and encryption key management solutions.  We also address issues of section 10 by providing customers our Alliance LogAgent, the system logging solution for the IBM i.

Passing an audit, like kickboxing, is a lot of work and not something you can just wake up and do well.  They both take an investment of time and resources - and at the end of the day, you will be stronger and able to defend yourself.

If it weren’t for the great support and expertise of my teachers, I would not have survived my first class.  Cheers to them and cheers to Townsend Security helping companies of all sizes meet their PCI audits.

For more information on passing your PCI audit, download our white paper “Meeting the Challenges of PCI Compliance” and learn what will your auditor look for, how you can ensure your PII is secure, and why auditors are looking specifically at encryption key management.

At Townsend Security, many of our customers are in the retail industry (a pretty big number of them, actually), which means that every day we’re working with these businesses to help them assess their data security posture so that they can meet compliance requirements for PCI-DSS. Often times a company will come directly to us for fear they may be about to go through a PCI audit, needing an immediate solution. These companies already know that they’re in trouble, and by the time they find us they’ve had to figure out their current security status and the PCI Compliance Level that they fall under.

[Learn More: PCI DSS 5 Take-Aways to Take Away the Pain!]

However, many merchants who are failing PCI audits are discovering this information about themselves too late. In fact, many businesses go a long time believing that they do NOT need to meet PCI DSS compliance for a variety of reasons. We hear things like: "Our business is too small, We’ll never get audited," or, perhaps worst of all, "Our data is secured using a firewall and passwords" (we actually heard this from a well-known restaurant chain, who two months later, suffered a data breach).

Here’s the truth: ALL merchants handling cardholder data (regardless of size) must comply with PCI DSS. The first questions a merchant needs to ask itself are these: What Merchant Level am I, Am I meeting compliance for my Merchant Level, and Would I pass a PCI audit?

Currently, PCI DSS is a national standard for payment card security, and although there is not a national standard for merchant levels, compliance rules are the same for all credit card companies. Merchant level definitions for all credit card companies are straightforward, and are centered around annual number of transactions. Here are VISA’s definitions, for example:

1 - Compromised entities may be escalated at regional discretion

2 – Merchant meeting Level 1 criteria in any Visa country/region that operates in more than one country/region is considered a global Level 1 merchant. Exception may apply to global merchants if no common infrastructure and if Visa data is not aggregated across borders; in such cases merchant validates according to regional levels.

[Mastercard’s Merchant Level descriptions can be reviewed here.]

If you’re a level 3 or 4 merchant, you will not have to go through a yearly PCI audit, instead you will fill out a yearly questionnaire regarding your security practices. The ONLY time a level 3 or 4 merchant gets audited is in the event of a data breach, or if they are found to be out of compliance with PCI DSS

However, level 3 and 4 merchants should never use this as an excuse to have weak security. Smaller businesses need to be aware that they are at a higher risk of a data breach simply because data security feels like less of a concern. It is now becoming increasingly more obvious that smaller businesses are being targeted by hackers more often than larger businesses because hackers know that they are in general more vulnerable. In the event of a data breach small and medium sized businesses may never recover from the financial penalties brought on by a data breach.

So how do you protect the cardholder data that you’re storing, processing, and or transferring to be PCI DSS compliant? It’s easy in these 5 steps....

Download our white paper "Meeting the Challenges of PCI Compliance" to learn what an auditor is going to look for, how you can ensure your data is secure, and why auditors are looking specifically at encryption key management.

Many compliance regulations require that you monitor critical system files, application configuration files, and sensitive file content for unauthorized changes. In the PCI Data Security Standard (PCI DSS) which applies to everyone who accepts credit and payment cards, here is what Section 11.5 says:

11.5 Deploy file-integrity monitoring software to alert personnel to unauthorized modification of critical system files, configuration files, or content files; and configure the software to perform critical file comparisons at least weekly.

Other compliance regulations also require this type of integrity monitoring and they are reflecting the security best practices in NIST’s Special Publication 800-53. Here are a couple of extracts on integrity monitoring from that guidance:

Section 3.4 – Monitoring Security Controls: Significant changes to the configuration of the information system through the removal or addition of new or upgraded hardware, software, or firmware or changes in the operational environment potentially degrade the security state of the system.

And:

SI-7 Software and Information Integrity

Control: The information system detects unauthorized changes to software and information.

Supplemental Guidance: The organization employs integrity verification applications on the information system to look for evidence of information tampering, errors, and omissions. The organization employs good software engineering practices with regard to commercial off-the-shelf integrity mechanisms (e.g., parity checks, cyclical redundancy checks, cryptographic hashes) and uses tools to automatically monitor the integrity of the information system and the applications it hosts.

What do IBM i (iSeries, AS/400) customers need to do to meet these file integrity monitoring compliance regulations? Here are the steps you should take to meet file integrity monitoring requirements:

• Identify, inventory, and monitor the application configuration files that control important security controls. You may need to work with your third-party software suppliers to know which files contain this information.
• Identify, inventory, and monitor the application database files that contain sensitive information. This would include files that have credit card numbers, social security numbers, and other Personally Identifiable Information (PII).
• Configure and enable system monitoring of changes to system values and network attributes. This involves setting up the system security journal QAUDJRN and initiating monitoring. IBM provides guidance on how to do this.
• Collect and transfer file integrity security events to an organization-wide security monitoring and alerting system. This will be a Security Information and Event Monitoring (SIEM) solution that you deploy in-house or through a Managed Security Services Provider (MSSP). It is impossible for humans to properly monitor file integrity events and this is the province of SIEM solutions.

Implementing all of the components of a file integrity monitoring system on the IBM i system is a huge task. Almost all IBM i customers will turn to off-the-shelf solutions to help them achieve compliance with data security regulations.

Our Alliance LogAgent Suite provides the full set of functions and capabilities you need to meet compliance regulations for file integrity monitoring. It monitors system configuration changes through the QAUDJRN security journal and from system history file QHST. It monitors and reports changes to your application configuration files. It monitors and reports changes to sensitive data such as credit card numbers, social security numbers, or any field you want to monitor. It applies user and application whitelists to minimize the volume of events.  And it securely reports events to a SIEM solution using industry standard formats. It is affordable, easy to deploy, and is easy on system resources.  We encourage you to try a free 30-day evaluation of our file integrity monitoring solution and see for yourself. We can get you up and running within an hour.

Because file integrity monitoring is crucial to your security posture, I will be talking more about the functions and features of Alliance LogAgent Suite for the IBM i platform in future posts.

Patrick

The task of deploying encryption key management into your infrastructure to meet security and compliance best practices can be overwhelming at first.  To help give you a 'bird's eye view' of the core components of our Alliance Key Manager (AKM), our encryption key management HSM, I want to breakdown the three major components to it.  Having this understanding in your back pocket as you roll out AKM can help smooth out the process.

First up, your security team can utilize our AKM Java GUI console to create and manage AES encryption keys for use in your applications.  This is a program that you install on a Windows machine that communicates directly with the key server via a secure TLS session.  Here, keys can be created, expired, revoked, rolled or even deleted – requirements of PCI DSS and other compliance regulations.  You can also define a key access policy for each key that is created, specifying what groups or individuals can request and use it.  Alternatively, you can also use our Linux command line facility to completely automate encryption key management through scripting calls.

The second component focuses on your application that's doing encryption and requires access to an external key manager.  You’ll need to make some minor coding changes to your application layer to enable it to make API calls to our shared library that does key retrieval portion.  To help you succeed here we offer sample code in a variety of programming languages for your development team to work with.  All of these samples can be found on the AKM product cd.

If you need Extensible Key Management (EKM) for Microsoft SQL Server 2008 Enterprise Edition and above you can take advantage of Transparent Data Encryption (TDE) or Cell Level Encryption.  We see many organizations use TDE and EKM because they can easily implement encryption without changing any of their applications - and can be deployed relatively quickly.

Finally you have the ability to physically manage the key server appliance itself.  By using a web browser directed at the IP address of the appliance on your network you can create system and database backups, define mirrored servers, and enable Syslog to meet PCI-DSS and other compliance requirements.

Download our “Encryption Key Management Simplified” resources kit to find more information on meeting PCI DSS and HIPAA, encryption key management best practices, and more.

I was teaching a class in the basics of encryption and key management this last week and was reminded again of one deadly attitude that sometimes circulates in the executive ranks of some organizations.

At the beginning of a class I often take an informal poll to see how many attendees are storing sensitive data unencrypted. In this particular class, I was expecting to see about half the class raise their hands, and I wasn’t disappointed. I then asked the “why” question: What is preventing you from making progress in getting your sensitive data encrypted? I know that there is still a strong perception that encryption and key management are difficult and expensive (they aren’t), and I know how hard it is to educate senior management.

But it’s always a bit surprising to hear someone say “Our management says they will just pay the fine for a data breach.”

I thought about it a moment, then shared with the class that I’ve had that same exact attitude about parking tickets. In any large city you can experience the nearly impossible task of finding a parking space. In frustration, I’ve parked illegally and just paid the fine. So, I know where this attitude comes from.

But, a data breach is not like a parking ticket.

For the class I started to tick off the types of costs associated with a data breach:

• Yes, there is a fine. And yes, most organizations can pay the fine. But the fine is sometimes a small part of the total cost. Most recent numbers show a data breach costs an organization on average $5.5 million.
• If credit card information was lost, you may see an increase in your fee structure. That’s going to hurt if you do a big percentage of your business through credit card transactions.
• You are likely going to be required in the settlement process to agree to on-site audits by an external security auditing company for a number of years. That’s going to be really expensive.
• The data breach may impact bottom line through list customers. When customers no longer trust a company to protect them from fraud, they go elsewhere. Sometimes they only have to point their browser somewhere else. Lost profits can really hurt.
• There may be significant costs associated with the forensics that must be done to identify individuals impacted by the lost data. I know of one company that spent $17 million on the forensics before they even got around to paying the fine.
• You will likely be required to purchase credit monitoring services for everyone whose information was compromised. That may be for just a year, or it may be longer.
• There are often litigation costs. If your data breach caused banks to have to re-issue cards, you can bet they are going to want to recover that cost from you.
• Your IT management and technical team will probably lose a year of productive time dealing with the breach. This cost may seem intangible, but it is real. Think of the impact on your company if you can’t make any progress on your strategic plans. The opportunity cost can be huge.
• Lastly, careers are often damaged or ended by a data breach. Especially if the original attitude was “We’ll just pay the fine.” In retrospect, that attitude is going to look like negligence. And people get burned out dealing with the stress of mitigating their systems under pressure. So, add personnel costs to the list.

At the end of this discussion there were people in the room just shaking their heads in agreement. They had been through it and knew exactly what it was like.

The next time you hear someone say they will just pay the fine, hand them this blog. I am pretty sure they are underestimating the impact of a data breach.  Download our White Paper "AES Encryption Strategies: A White Paper for the IT Executive" to learn more identifying key issues in data security, how to choose the right data security partner, and how to develop a strategy that insures some early success.

Patrick

One of our customers recently submitted a support ticket related to a question asked by their QSA Auditor.  Just a quick background on our customer - they have an all IBM i environment and are using AES/400, our NIST-certified AES encryption among other data privacy solutions we offer.  This customer needs to comply with PCI because they are accepting credit cards and store personally identifiable information (PII). The question was: How does your AES encryption software prevent unauthorized substitution of cryptographic keys?

At Townsend Security we stress the need for encryption any time you have sensitive data, but that is only half of the battle.  You also need to protect the encryption key with a key manager.  Did the question about substitution of cryptographic keys surprise us? No, it didn’t.  This is a great example of what is happening out in the business world.

If your encryption is weak (did you know there is weak encryption?), this is a legitimate concern. There is a “key store” on the IBM i that stores encryption keys, but it’s like putting your house key underneath the welcome mat to your front door.

If you are using our Alliance Key Manager (our encryption key management HSM), we use NIST FIPS 140-2 best practices for detecting key substitution or key corruption. This involves the use of an HMAC mechanism with each key stored in the key management appliance.

What kind of questions are your QSA Auditor’s asking?  We would love to hear from you, whether you are a current customer of ours or not.  If you are interested in hearing more download our podcast on compliance and encryption key management.

I had the pleasure of meeting Alison Burkill at the Help/System user conference recently and spending a few minutes talking with her about Power Systems security. Alison is the IBM Product Manager for software on Power Systems, and delivered a keynote speech at the user conference. The keynote was about all of the great new features of the Power Systems platform and it highlighted the security features that IBM has incorporated into the base Power Systems platform.

In our sit-down in the demo center I asked Alison one of my favorite questions - “What do you think is the biggest security pain point that IBM Power Systems customers face today?”

I was expecting a discussion about the security technologies that often trip up Enterprise customers – encryption, key management, system logging, log monitoring, and nitty-gritty stuff like that.

Nope.

She said that IBM customers are always taken by surprise when they fail a security audit. IBM systems have a reputation for great security and when IBM customers fail a security audit they are dumbfounded that it can happen to them.  Education, she said, might be our biggest need.

I agree. And I think I know why IBM customers are often shocked when they fail an audit:

• IBM Power Systems do have a great reputation for security and that can lead to a false sense of comfort. I can assure you that IBM systems are not immune from security breaches and data theft.

• Compliance regulations are not written on a platform-by-platform basis. There is no carve-out that exempts IBM customers from meeting data security requirements. A compliance auditor expects you to meet the same requirements as every one else on every other platform.

• It is a rare security auditor who has deep experience with the IBM Power Systems platform. They are going to be skeptical of your claims that the IBM platform is more secure than any other.

• IT professionals often do not have a lot of background and training in regulatory compliance. This is a gap in our education, and Alison is right that we are often only vaguely aware of what regulations require.

• Lastly, as technologists we have a tendency to program first and ask questions later. We can make simple mistakes, like storing encryption keys on the same server as protected data and not realize that we’ve violated a core precept of data protection. We might be using the latest and greatest API from IBM, but not be meeting compliance requirements. It happens a lot.

And there you have it, the perfect setup for the compliance audit surprise! In fairness, this doesn’t only happen to IBM customers, we find the same surprises happening to Windows and Linux users. But it seems that IBM customers are always a bit MORE surprised when it happens to THEM!

I think Alison Burkill is right – Education might be our biggest security need in the IBM Power Systems community. Ignorance is not bliss when the compliance auditor comes calling. 

Download our White Paper "PCI Data Security - Meeting the Challenges of PCI DSS" that discusses PCI compliance and answers some of the common questions companies have about PCI adits.

Patrick

How easy is securing and protecting sensitive data on SharePoint?

Over time Microsoft has been moving SQL server underneath almost all of their core enterprise products (SharePoint, CRM, Dynamics, etc.), which is great news for IT administrators because SQL Server supports automatic encryption. This means that protecting your SharePoint database and meeting compliance regulations (PCI-DSS, FFIEC, HIPAA, etc) is easier than ever.

SQL Server Enterprise and higher editions (starting with 2008 through 2012) fully implements extensible key management (EKM) and encryption to protect data. Installing encryption on that platform is the first step--administrators can then leverage the automatic encryption capabilities of SQL Server with only a few commands and no application changes. The second step is to understand the importance of protecting your encryption keys using separation of duties and dual control on an external Hardware Security Module (HSM).

The path to implementing encryption and key management for SharePoint is one of the most straightforward and easy paths. Townsend Security’s Alliance Encryption Key Management solution fully supports automatic SQL Server encryption and integrates with ease.

What impact does encryption have on SharePoint performance? Should users and administrators be concerned?

Encryption will always be a CPU intensive task and there will be some performance impact due to extra processing power needed for encryption and decryption. However, the Microsoft encryption libraries as well as the .NET environment are highly optimized for performance. I have always seen very good performance on SQL Server and the native encryption capabilities that it provides. Microsoft reports that Transparent Data Encryption (TDE) on SQL Server may cost you 2-4% penalty in performance, and our own tests show similar results that fall on the 2% end of things. There are also several encryption and encryption key management solutions on the market, and each one performs a little differently. 

Ultimately, performance depends on the amount of data you’re storing, and I always recommend that a customer take into account all factors that affect performance including encryption, number of users, size of documents, number of documents, and the underlying platform they’re using.

Lastly, it’s important to note that using an external HSM for key management (a critical piece of compliance), like our Alliance Key Manager, does not affect the performance profile of the database that is under protection.

In the end, if you are storing sensitive information on SharePoint, then you likely fall under industry regulations and state privacy laws. Regardless of your industry segment, whether its medical, financial, retail, education, or government bodies, you have a lot of choices to get your sensitive data data properly protected.  At the end of the day, if data gets out and it’s unencrypted, you have a data breach on your hands.

To learn more about securing SharePoint with Encryption and Key Management, listen to our latest podcast here.

At Townsend Security we get all kinds of questions about PCI Compliance. A question we get asked frequently by healthcare professionals is:

As a medical healthcare provider, we accept payments via check or credit card through Point of Sale devices implemented by a third-party vendor. Are we responsible to comply with PCI DSS requirements?

Many people assume that if they use a third-party vendor, the vendor must be the one to comply with PCI DSS. Our CEO Patrick Townsend, has a different take on this subject. I asked Patrick if he could answer some of the common questions asked by healthcare providers concerned about PCI DSS compliance requirements.

Are we (healthcare providers) responsible for complying with PCI DSS?

Yes, every Merchant is responsible for PCI DSS compliance even if using an outsourced service. However, this type of arrangement can greatly reduce the amount of work that the Merchant has to do. Usually you will only need to complete and sign a Self Assessment Questionnaire (SAQ). You would get this from your outsourced authorization provider.

Okay, but if we do need to be concerned with PCI compliance, how is the PCI DSS processed managed?  Does the IT team tackle this? Our compliance team?

Typically the IT department takes the lead on coordinating any work that has to be done for PCI DSS. This might include things such as a vulnerability scan by an approved scan provider and similar types of tasks. An officer or director then reviews and signs the SAQ and letter. In medical organizations the Compliance Officer is typically more involved with various medical industry compliance requirements related to HIPAA and so forth and usually not involved with PCI DSS. But it never hurts to ask.

What about banks that process our clients’ credit card information?  What kind of reporting should we be getting from our bank confirming that they are compliant or following PCI DSS compliance?

Banks are under a different type of compliance requirement for PCI. You should just ask them for a letter assuring you that they meet all PCI data security requirements as an authorization provider.

Sometimes PCI compliance can be confusing. Hopefully, thanks to Patrick, you may now have a better understanding of PCI compliance and how you can outsource credit card information while remaining PCI DSS compliant. If you have questions about PCI compliance, send me an email at kristie.edwards@townsendsecurity.

If you want to learn more about PCI compliance and how Townsend Security can assist with the process, listen to Patrick speak about current best practices and encryption key management in the webinar, “Key Management Best Practices: What New PCI Regulations Say.”