Townsend Security Data Privacy Blog

Questions from the Tradeshow Floor  (Part 1)

November was a very busy month for tradeshows, conferences, and speaking engagements for the team at Townsend Security.  We love getting out to meet our current and potential customers and other than “giant Tetris”, our favorite things are the great questions we get asked at events. 

What if I lose an encryption key?

While the fear of losing a key is legitimate, the keystone of a successful encryption solution is encryption key management, which is the primary solution for managing, storing, and most importantly, protecting encryption keys. Unlike a “key storage” solution, a cryptographic encryption key manager is typically a NIST FIPS 140-2 compliant hardware security module (HSM) or virtual machine in the cloud that manages key storage, creation, deletion, retrieval, rotation, and archival. Many key management solutions are also produced in pairs, with one located in a different geographical location for high availability. If doing encryption key management right, you will never lose an encryption key.

Is there more to encryption key management than just storing my encryption keys?

There is far more to encryption key management than just storing the encryption key somewhere. Generally, a key storage device only provides storage of the encryption key, and you need to create the key elsewhere. Also, just storing your encryption keys “somewhere” doesn’t work very well for compliance regulations. With an encryption key manager, there is a whole set of management capabilities and a suite of functions that provide dual control, creates separation of duties, implements two factor authentication, generates system logs, and performs audit activities, along with managing the key life cycle. Beyond storing the encryption key, a cryptographic key manager manages the entire key life cycle. Some of the most important functions the key management administrator performs are the actual creation and management of the encryption keys. The keys are generated and stored securely and then go through the full cycle to become active, go into use, expire, retire (post-activation), and then be backed up in escrow, and then deleted (the “destruction” phase).  There is a very real need, and very specific compliance regulations & guidelines that require you to store and manage your encryption keys away from the data that they protect.

How easy is securing and protecting sensitive data on SharePoint?

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 encryption in SQL Server and integrates with ease.  SQL Server Enterprise and higher editions (starting with 2008) fully implement 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.

What impact does encryption have on SQL Server performance?

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. We 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.

Is there any limit to the number of servers that I can hook up to your encryption key manager?

There are no restrictions, and no license constraints on our encryption & key management solution. We don't meter or count the number of client-side platforms that connect to our Alliance Key Manager, so you can hook up as many client side applications, servers, and processors as you need to. This is one of the things I think is different about how we approach encryption and key management with our customers. We also know the applications you are running today may not be the applications you need to be running tomorrow and we really want you to deploy encryption to all your sensitive data and scale up when & where you need it.

I am collecting data in Drupal. What data do I need to encrypt?

Organizations starting an encryption project always have this question on their minds. It is a simple question, but can be hard to answer. Generally speaking, you should encrypt any information that alone, or when combined with other information, can identify a unique, individual person. This is called Personally Identifying Information, or PII. This should be your starting point, but you may need to address other information depending on the compliance regulations you must meet.

• PCI Data Security Standard (PCI DSS) applies to anyone, public or private, who take credit cards for payment. Primary account numbers (PAN) are specifically addressed.
• HIPAA/HITECH Act requires the medical segment (and any business associate) provide data protection for protected health information (PHI) of patients. 

• GLBA/FFIEC applies to the financial industry (bank, credit union, trading organization, credit reporting agency) for protecting all sensitive consumer information. 

• Sarbanes-Oxley (SOX) applies to public traded companies for sensitive data of personally identifiable information (PII).


In addition to these compliance regulations, the Cloud Security Alliance (CSA) has created the Cloud Controls Matrix (CCM) specifically designed to provide fundamental security principles to guide cloud vendors and to assist prospective cloud customers in assessing the overall security risk of a cloud provider.

We encourage all developers to check out Townsend Security’s Developer Program, it allows developers to design strong and secure applications from the ground up using NIST compliant AES encryption and FIPS 140-2 compliant encryption key management.

Real-time, Low-cost, Business Integration When and Where You Need It! 

Do you need a complete and affordable solution for implementing XML web services on your IBM i? Need a solution that won’t disrupt your existing applications and database so you can easily implement web services without complicated API programming or the deployment of external servers? Our Alliance XML solution includes all of the communications, XML parsing, data translation, and application integration components that you need. You can create XML documents from your existing database files and securely send them to remote web servers, and you can receive XML documents directly on your IBM i and process the data into your applications. 

QSA auditors and other security professionals focus on the protection of sensitive data after it traverses the Internet and then lands in a database on a hard disk drive. You need a solution that provides security at every level of processing and protects data in transit using session encryption. When sending or receiving XML documents Alliance XML can use the Transport Layer Security (TLS) protocol for strong encryption of the transferred data. The Alliance XML TLS support is based on the IBM Digital Certificate Manager and related IBM APIs for TLS sessions. This gives you an implementation that is compatible with native IBM i security. As an additional layer of security the Alliance XML HTTP servers provide IP address controls so that only known clients can use the servers.

When receiving XML documents with sensitive data you can enable field level encryption to protect the data. For example, if you receive a document with a credit card number or social security number, you can use strong encryption of the data to protect it before it is written to your database table. User APIs provide a means of decrypting the data so that it can be used in your RPG and Cobol applications.

The web protocols HTTPS and FTPS provide for the ability to encrypt the data in transit, and Secure Shell SSH also provides strong encryption. But after the data reaches the end point of its journey it lands in a database somewhere, and it is often exposed to loss at that point. I believe that’s why security auditors put emphasis on making sure that data is encrypted when it hits it’s destination.

Many companies have implemented web services in combination with the XML data standard to take advantage of low cost, real time integration with their customers and vendors. When you combine the ubiquity of the web HTTPS protocol with the W3C XML standard you get a powerful incentive to use this platform for business integration.

Care should be given to what happens to data when it leaves the realm of encrypted transit and lands on server hard drives. The right thing to do is encrypt sensitive data at the very beginning. This means that the tools you are using have to support encryption as a natural part of the process of converting XML data. Standard XML processing tools such as Xerces and Xpath do not have built-in encryption. The same is true for XML toolkits and APIs provided by IBM, Microsoft, and others. This leaves it to developers to try to intercept data after it is transformed from XML and before it lands in a database table or on a hard drive. That’s a real challenge.
 

In our Alliance XML/400 web services product on the IBM platform we built encryption right into the data transformation process. Alliance XML/400 customers can protect sensitive data by enabling the encryption option on a translation map. The solution does the rest. The data is encrypted before insertion into the database and there is no exposure as the data lands in the database on the hard drive. Our customers are taking advantage of this feature to meet PCI and other compliance regulations.

Encryption can help protect against another common threat, too. At the annual PCI SSC standards council meeting a few years ago, forensics expert Chris Novak of Verizon talked about how more than 75 percent of data loss events begin with a well known weakness that hasn’t been patched, and half of these are based on SQL injection attacks, this is still true today. With SQL injection, the attack on your servers starts with bad data inserted into a database in the clear, leaving open a later exploit. There are ways to prevent SQL injection through programming techniques, but encryption will also help defeat them.

Will encrypting your data provide all of the security protection you need? No, but it should be a major part of your defense-in-depth strategy to protect sensitive data.  

To view a replay of a webinar we presented on XML & Web Services, click below

 

Beyond meeting compliance regulations, it is the right thing to do!

In the past, encryption has had a reputation for being difficult to do, complex, and time consuming, we hope to show you how that has changed. If you are new at protecting data in Microsoft SQL Server environments, generally compliance regulations are what drive an encryption project.    

Since it wasn’t thought of as something that improved the “Bottom line” by increasing revenue or decreasing expenses, encryption has historically been a project solely driven by the need to meet compliance regulations. There are a large variety of compliance regulations that most, if not all, businesses fall under. One common misconception about compliance regulations is that they don’t equally apply to both private and public companies. To clarify, these regulations apply to all companies, of all sizes, whether they are privately-held or publicly-owned. 

For example, if you take credit cards for any reason, you fall under Payment Card Industry - Data Security Standards (PCI-DSS). Other common regulations are:

• HIPAA Data Security & HITECH Act of 2009 which applies to Medical Providers and the healthcare industry.
• GLBA/FFIEC apply to banks, credit unions, credit reporting agencies, and anyone in the financial industry.
• FISMA is for Federal US Government Agencies.
• The Federal Trade Commission (FTC) also gets involved with anyone who issues a privacy statement.

More than 45 states also have their own privacy rules, in addition to the ones listed above, that strongly recommend encryption of any personally identifiable information (PII).

So, beyond compliance with regulations, why should you care about encryption… and what is it anyways? First of all, your customers, clients, and suppliers all expect you to protect their sensitive data. Hackers and data thieves are targeting mid-sized companies because, as larger companies get better at securing sensitive information, the hackers see smaller companies as better targets. Financial fraud and data breaches become more common in those businesses that might not be as prepared without the resources to have an internal security team. Data loss can have a big impact on a company's reputation as well as their financial health.

AES encryption is a mathematical formula for protecting data.  It is based on a proven, well-known algorithm and standards published by NIST. Since that formula is a open and vetted standard use, it is not the mathematical algorithm that is the big secret. It is what happens with the “Key” that locks and unlocks the data that all the fuss is about.

Key management is so important because the encryption keys are THE secret that must be protected. Without access to the key, a hacker that accesses encrypted data has no way to read it. Industry standards and best practices for encryption key management, as well as compliance regulations that require proper encryption key management, all state that storing encryption keys on the server with the protected data is a poor security practice. Encryption keys are unique and cryptographically secure, and once created, protecting the key is the core practice that will protect the sensitive data. It will not be defensible in the event of a data breach if the keys were stored in the same server as the data. This would be like leaving the key to your house in the door lock and being surprised that someone entered uninvited!

Our solutions help Microsoft SQL Server customers really protect their data. Alliance Key Manager, our encryption key management solution, is NIST FIPS 140-2 compliant. This means it meets Federal standards that private enterprises expect around key management. We provide encryption key management solutions for every version and edition of SQL Server starting with SQL Server 2005. In addition, you can choose between a hardware security module (HSM), Cloud HSM, VMware virtual appliance, or a cloud instance in AWS or Azure. Easy. Efficient. Cost-Effective.

Please join our founder and data security expert, Patrick Townsend, in this 30-minute webinar that will cover encryption and key management best practices with Microsoft SQL Server!

As always, your comments and feedback are appreciated! 

From the PASS Summit to the Worldwide User Group (SSWUG)

From Developers to Database Administrators, we have met another amazing group of people at the PASS Summit 2014. Over 5,000 members of the Professional Association for SQL Server converged on Seattle, WA and we got to talk about security with people from all over North America and from as far away as Norway, Spain, Australia, Colombia, Germany, and even Iceland.

We spent most of our time talking about the importance of encrypting sensitive data, and about using an encryption key management solution to protect encryption keys away from the database. There is a huge need to meet compliance regulations, and with all the options now available (Hardware appliance, Cloud HSM, VMware virtual environment, and cloud instances in AWS or Azure) there is a solution for each scenario we encountered.

If you are working with SQL Server, we hope you are familiar with the SQL Server Worldwide User Group (SSWUG).  If you don’t know about them, please allow me a moment to introduce you to Stephen Wynkoop who is the founder and editor for SSWUG.org. This website is a wealth of information about everything you would want to know about SQL Server (and they are even branching out to other database systems like Oracle and IBM DB2). The emphasis at SSWUG has been on SQL Server and you will find a large number of articles, blogs, videos and other content on wide variety of topics related to it. Stephen features weekly video programs about the database and IT world, webcasts, articles, online virtual community events and virtual conferences several times a year. He is a Microsoft SQL Server MVP and the author of more than 10 books, translated into at least 7 languages. Stephen has been working with SQL Server since the very first version, with a prior experience in database platforms that included dBase and Btrieve.

SSWUG has dedicated a section of their web site to the SSWUGtv Security Edition “Townsend Security Series” where they present videos of Stephen and our own industry expert, Patrick Townsend, discussing security topics ranging from securing data with encryption and key management on SQL Server (not just with EKM) to protecting data in the cloud. Additionally, they post a new security segment just about every week on their homepage, so there is always something fresh. A few of the sessions include topics such as What top industries do Hackers focus on and why? and Cross-platform security: How do you have a hybrid environment and keep it secure?  

Check out this one on: PCI Compliance and Security in the Cloud - (11 minutes) 

Stephen and Patrick have a great time recording these videos, and if you haven’t seen any yet, I urge you to check them out. In addition to all the great content on the SSWUG website, SSWUG also holds virtual conferences and Summer Camps that are great online resources for developers.

You are also invited to download this latest white paper, authored by Stephen Wynkoop, on understanding options and responsibilities for managing encryption in the Microsoft Azure Cloud.

Taking Security Beyond Usernames and Passwords

Security professionals understand that passwords alone are just not good enough protection, and the on-going flood of data breach reports just confirms this on a daily basis. Enterprise IBM i users aren’t going to stop using passwords to login to their IBM i platforms, and hackers aren’t going to slow the flood of attacks any time soon. But now, we can take a giant security step forward by implementing two-factor authentication (2FA) to dramatically reduce the risk of a security breach.

Compromised email, social media, online gaming, ecommerce, financial services and other types of cracked accounts continue to threaten both personal and corporate interests. Out of all the threats that face individuals and companies, account compromise stands out as one of the most easily addressed with available and mature security technologies.

Historically, companies used physical tokens to provide authentication on the IBM i beyond username and password. Even if someone hacked a user’s password, they still could not login without the physical token. Tokens represent another layer of protection, which is a step in the right direction. Unfortunately, tokens increasingly do not make fiscal sense for Enterprise IT departments who have to deploy, manage, and troubleshoot large numbers of tokens. There is a better way for organizations to quickly and cost-effectively roll out two-factor authentication to a large and sometimes global user base. Solutions that leverage the mobile phone as a reliable means of authentication have become readily available for the IBM i platform. For example, instead of tokens, businesses can simply send an SMS or voice message that contains a one-time authentication code to the individual user’s phone. This means cyber criminals cannot log into the IBM i without physical control of the actual phone.

Mobile phones and landlines present key advantages for verification and authentication regimes:

• They possess unique identifiers – phone numbers, electronic identifiers and account numbers
• They remain in the possession of users or near at hand most of the time
• They are difficult to spoof
• If stolen or otherwise misappropriated, they are easy to disable
• Their association with actual individuals is verifiable through the operators that provide phone service

While none of these attributes alone are sufficient, together they provide a compelling basis for verification and authentication. The goal is to reduce fraud and actual theft of sensitive information by implementing something much harder to defeat than a login password. Combining something the person knows with something they have, or something they are, which can then be used for two factor authentication.

1. Something you know - a password. Even “strong” passwords can still be fairly weak from an attacker's point of view. With malware that easily detects them, passwords alone are a weak defense in relation to log-in security if that's all you have.

2.  Something you have - a mobile phone. It is now becoming quite common for companies to leverage what everyone already has in the way of the mobile phone or standard phone, and use that device as a mechanism for two factor authentication.

3. Something you are – biometric authentication options.  Physically scanning for an iris pattern or fingerprint.

By using 2 of those 3 things you can authenticate more securely to the system.

Here are a couple examples of things that are not two factor authentication:

• Requiring two passwords: using one factor twice is not 2FA!
• Using shield questions of which are actually fairly easy in our social world to determine.

The IBM i platform has a well-earned reputation for security, but security is only as strong as the weakest point in the enterprise network. User PCs, internal and external web servers, and network applications represent points of attack. These systems are not safe from:

• Memory scraping
• Keyboard logging
• Stolen vendor credentials
• Stolen user passwords from external web services

Due to the nature and the extent of these security threats on the IBM i, two factor authentication has become a viable solution for meeting compliance regulations and safeguarding the vast amount of data and numbers of users with access to sensitive information on the IBM i. We're seeing Google, Facebook, Yahoo, and almost all large commercial banking websites implementing a two factor authentication system based on SMS text and or voice verification to give additional security to their users accounts and IBM i users now have an affordable solution for their platform. Find out more by downloading this white paper:

It’s not just “Target”… everyone has a bullseye painted on their information!

Forget about vampires, werewolves, and other things that go bump in the night.  If you want to be truly frightened this Halloween, just take a look at some of the 395 data breaches reported in the first half of 2014 alone.

According to the Identity Theft Resource Center there has been a 21% increase in breaches (and that is just the ones that have already been reported to regulators) in the same period as last year.  Some of these you may be familiar with, others might surprise you:

• eBay - online retailer
  The breach is thought to have affected the majority of the 145 million members when a database containing customer names, encrypted passwords, email addresses, physical address, phone numbers, and dates of birth was compromised.
• Home Depot
  In a large nationwide malware attack, 56 million card records were stolen through point-of-sale systems. In a second attack in Atlanta, 20,000 employees personal information was stolen and used to open fraudulent credit cards by 3 human resource employees.
• Michaels Stores - craft stores nationwide
  The point-of-sale (POS) systems at 54 stores were attacked using malware and up to 3 million payment card numbers and expiration dates were obtained.
• Snapchat (online photo app and delivery service)
  4.6 million accounts were hacked and millions of images stolen. The information (phone numbers and user names) database posted online at Reddit and another site that has now been taken down.
• Neiman Marcus (retailer)
  1.1 million payment cards were compromised over a period of 8 months as hackers repeatedly breached the point-of-sale systems through a central processing server.
• AIG (American International Group)
  774,723 customers - The insurance provider confirmed the theft of a file server and two laptops that held personal information was by a former financial adviser.

Those are some pretty significant numbers, and most likely everyone that reads this blog has been affected in some way by at least one of these events. What we all need to remember is that cyber crime isn’t limited to “Black Hat” hackers that only go after the big piles of data.  Sometimes it is a disgruntled employee that destroys or releases sensitive data. Sometimes it is an unintentional employee error, or loss of an employee’s laptop/thumbdrive that thieves go after.  Often it is the smaller company or mid-sized Enterprise that hasn’t yet implemented security steps, like encryption and authentication, to protect their sensitive information.  

If the first list didn’t give you a fright, here is another that might make you tremble with fear. However, we would prefer if it resulted in the topic of data security brought up at your next security and risk management meeting!

University of Maryland
307,079 individuals - personal records
*Hackers broke in twice and stole data

North Dakota University
291,465 student and staff records

Sutherland Healthcare Solutions
168,000 patients
*Stolen computer equipment containing personal health & billing information

Sally Beauty Holdings (retailer)
25,000 customers lost credit card data to a hacker

Catholic Church - Archdiocese of Seattle
90,000 employees and volunteers - database records

Goodwill Industries (charitable resale)
868,000 customers from approximately 330 stores

Jimmy John’s (national sandwich shop)
*undisclosed number of customers from 216 corporate and franchised locations

Internal Revenue Service (IRS)
20,000 individuals affected
*Employee incident - loaded an unsecure drive into insecure home network

Assisted Living Concepts
43,600 current and former employees in 20 states, had their payroll files breached when the vendor’s system was hacked.

Coco-Cola
74,000 people lost unencrypted personal information to a former employee from Atlanta who stole 55 laptops. Company policy requires laptops to be encrypted, but they weren’t.

The Montana Department of Public Health and Human Services
A server holding names, addresses, dates of birth, and Social Security numbers of approximately 1.3 million people was hacked.

Spec’s - wine retailer in Texas
Affecting as many as 550,000 customers across 34 stores, hackers got away with customer names, debit/credit card details (including expiration dates and security codes), account information from paper checks, and even driver’s license numbers.

St. Joseph Health System
Also in Texas, a server was attacked that held approximately 405,000 former and current patients, employees, and beneficiaries information.  This data included names, Social Security numbers, dates of birth, medical information, addresses, and some bank account information.

The US Department of Health and Human Services has a breach database of incidents related to exposure of personal health information.  Due to late entries, dates weren’t listed, but the following were reported:

• 25,513 records at Dept. of Medical Assistance Services in Virginia
• 22,511 records at Cook County Health & Hospital System
• 18,000 records at Terrell County Health Dept. in Georgia
• 10,000 records at Health Advantage in Arkansas
• 84,000 records at St. Francis Patient Care Services in Tulsa, OK
• 10,024 records at Missouri Consolidated Health care

A new study from researchers at Gartner indicates that it is markedly less expensive for companies to invest in new security and encryption technologies than it is for them to respond to a data breach. According to the analyst firm, businesses pay roughly $6 per year per user for encryption tools, or $16 per user per year for intrusion prevention software licenses, versus paying out an average of $90 per user to address problems after a breach has occurred.

Five steps you can take to make sure this doesn’t happen to you:

1. Have a defense-in-depth strategy that meets your level of risk tolerance
2. Make sure you know where all of your sensitive data is stored, and who has access to it
3. Use standardized encryption algorithms to make that data unreadable
4. Use an encryption key management solution to protect keys away from the data
5. Use two-factor authentication whenever possible, because passwords are no longer enough

To help open up the conversation around your conference table, download this eBook “Turning a Blind Eye to Data Security” and find out more about the tools & resources to begin discussions about data security in your company!

Best Practices for Deploying a Key Manager in AWS

The cloud has transformed the way most industries manage their data. With services that offer cost-effective, scalable, “pay-as-you-go” options, it is increasingly rare to find a company that doesn’t want to migrate business-critical applications from an in-house data center to the cloud. Companies will make different decisions based on industry risk assessment, their own tolerance for risk, and compliance regulations, however, some Enterprises have been holding back on their migration to the cloud until comfortable that they can properly protect their most vital information. Data security was a concern when we had a fully controlled hardware environment, and now that we are moving to shared, multi-tenant virtual environments it has become even more critical.

Data encryption has had a reputation of being the hardest security measure to achieve and yet it is the best way to secure digital information that needs protection. One of the most important elements of encryption is using encryption key management best practices to keep the encryption keys safely stored away from the data they protect. An Enterprise key management solution will also provide dual control, separation of duties, and proper rotation of encryption keys to ensure that you (and only you) control, manage, and have access to your encryption keys and the data they protect.

Any cloud platform brings with it an additional set of security concerns, including the ability to implement and demonstrate regulatory compliance, as applications and services move into the cloud. Whether Enterprises bring their own applications and operating systems into the AWS cloud, or use the variety of options and rich set of services supplied by Amazon, lets take a look at ways data can be encrypted and the use of appropriate technologies to protect those vital encryption keys.

Virtual machine migration:  Probably the most typical cloud deployment involves IaaS (infrastructure as a service) where the operating system, database, and everything is contained with an application. By using industry standard encryption and key management,  vulnerabilities are significantly reduced and organizations are able to enforce compliance requirements.

Data storage options: Whether you are encrypting an entire database, or using column-level encryption for a more granular approach, you have options for database (data-at-rest) encryption.

Amazon Relational Database Service (RDS) While RDS does not support encryption key retrieval and on device encryption services internally, it does to make it easy for applications to encrypt data going into and out of the RDS. You can retrieve encryption keys for application-level encryption or use on-device encryption before writing to, or reading data from, the RDS.

Amazon Simple Storage Service (S3) is very popular for video, audio, and large files now with server-side customer supplied encryption and key management support. Each file can have it’s own encryption key, or you can use the same key to encrypt multiple files. With recent enhancements by Amazon, you can easily “bring your own key” and integrate a key manager to encrypt data being stored in S3 and decrypt data that is retrieved from S3 storage.

Amazon Elastic Block Storage (EBS) is available for any virtual machine running in an Amazon context to retrieve encryption keys and encrypt data in very straightforward application environment.

Choosing an Encryption Key Management Solution

Make sure your key management solution provides a rich set of SDKs and client-side libraries all of which run in cloud platforms and can be used through all of the storage services that Amazon provides. You should be able to choose to host the key manager in the AWS cloud as an Amazon Machine Instance (AMI), or in a hosted cloud HSM (which is gives you a dedicated HSM in a SOC 3 audited data center with a PCI DSS letter of attestation for compliance) or within a physical HSM under your full control within your own data center. Look for a key manager solution that runs exactly the same way in all of these environments, and ensures that you maintain ownership of your encryption keys at all times. So if you deploy in one location and then need to migrate, you can easily store your data in the appropriate locations. Also, using industry standard encryption and certified solutions for key management are critically important for meeting compliance regulations and following security best practices. Using a third party Cloud HSM gives you the assurance that your encryption keys are kept safely apart from your sensitive data. It is very important to make sure no one else has administrative access, because above all, encryption keys are the secret that must be protected within your encryption strategy.

With options for fee-based encryption key management services, as well as bring-your-own-license solutions, Townsend Security's Alliance Key Manager (AKM) for AWS allows Enterprises to properly manage their encryption keys while meeting security requirements in less time and at a lower cost. While it is not possible to perform FIPS 140-2 validation in a cloud service provider context, Alliance Key Manager uses the same FIPS 140-2 compliant key management technology available in Townsend Security's HSM and in use by over 3,000 customers worldwide. Alliance Key Manager for AWS provides full life-cycle management of encryption keys for a wide variety of applications to help organizations meet PCI DSS, HIPAA, and PII compliance at an affordable price.

To learn more about protecting your data in AWS, download this recent podcast by industry expert Patrick Townsend:

It seems like everyday there is a new data breach in the news.

From malicious hackers to unintentional employee mistakes, loss of sensitive data is skyrocketing. Risk management has brought the data breach issue out of the IT department, and into the offices of Enterprise executives. Data loss is considered such a critical issue that encryption and encryption key management is mandated not only by many industry compliance regulations, but also by most state and governmental laws.

Here are a few key thoughts to consider:

5 Misconceptions About Data Security That Put You At Risk

1   If we have a breach, we’ll just pay the fine.

In many cases there will be fines for a data breach, but it is only a small part of the total cost. The cost of a breach also typically includes a forensics investigation, credit monitoring for customers, lost sales due to brand damage, and litigation costs.

2   We’ve never had a problem, so things are probably OK.

This type of thinking is not a form of risk assessment. Since data breaches often take months to discover, you may not know that a breach has already occurred. Wishful thinking won’t help you prevent a breach.

3   My software vendors and consultants say they have everything under control.

Today, many software vendors have not moved quickly enough to add encryption to their core products. It is not wise to rely on vague statements about data security from vendors and consultants. Make sure their solutions have been through a NIST FIPS 140-2 validation, using best practices, and based on industry standards such as AES.

4   My IT staff says we’ve done everything we can.

IT departments may not have the resources or management directives they need to accurately assess and address data security issues. Meeting management’s goals and objectives within a set of operational and budgetary constraints is not the same as meeting security best practices.

5   We are encrypting our data, we are doing everything we should.

If you are encrypting your sensitive data, you’ve already made a good step forward. Do you know how and where your encryption keys are stored? Making sure your keys are not stored with your data is only the first step.  Good key management practices will truly protect your data.

5 Steps to Take to Reduce Security Risk

1   Talk About It

Discuss the importance of data security as it relates to risk management with all members of the organization’s leadership team. Data security is an ongoing process that involves every member of the organization, and will extend beyond your organization’s boundaries to vendors and service providers. Responsibility for data security belongs to everyone.

2   Assess Your Current Data Security Posture

If you have not had an external audit and assessment of your organization’s data security practices by a qualified security professional, now is the time to start. First, perform a data security assessment with an in-house consultant, security audit firm, or platform vendor to evaluate your current security posture. Find the location of all sensitive data. Lastly, evaluate the security of your backup tapes. The right security assessor will help you identify the most urgent problems, and help you prioritize your efforts.    

3   Invest in Encryption and Key Management

When you have located sensitive data that is not encrypted, start a project to encrypt it now. Don’t forget to invest in the necessary encryption key management devices to protect the encryption keys. If your risk assessment warrants, provide budgetary exceptions to address the problem. Invest where you need to, as soon as you can. When choosing an encryption and key management solution make sure it uses industry standard NIST compliant encryption and FIPS 140-2 compliant key management.

4   Strengthen your technology acquisition processes

Every organization relies on off-the-shelf software solutions to manage and run their business operations. If your core applications do not provide encryption and key management to protect data, put your vendors on notice that they must address this issue immediately, and ask for updates. All new technology acquisitions should incorporate data security requirements into the RFP process.

5   Create ongoing review processes and procedural controls

Performing one security assessment or passing one compliance audit will not provide the focus and attention needed to protect you from a data breach over time. You must conduct routine vulnerability scans, create new processes, and review points within the organization to ensure that you continue to monitor your security stance. Use good procedural controls to minimize the chances of fraud. Implement Dual Control and Separation of Duties to achieve a defensible data security stance.

To learn more, download the eBook, "Turning a Blind Eye to Data Security: Mending the Breakdown of Communication Between CEOs and CIOs", and authors Kevin Beaver, CISSP, Patrick Townsend, and Todd Ostrander will teach you about:

• Business risks associated with unprotected sensitive data 
• Tools and resources to begin the discussion about data security in your company 
• Actionable steps YOU can take

Download the ebook today!  

VMware and PCI DSS Compliance: Taking the right steps in a virtualized environment

As of vSphere 6.5, AES encryption has been added to VMware. With VMWare encryption, complying with PCI DSS, requirement 3 is even easier. And executives are taking note as they look to conserve resources by moving their organizations databases and IT environments to virtualized platforms and to the cloud.

Security best practices and compliance regulations call for sensitive data to be protected with encryption and that data-encrypting keys (DEK) be physically or logically separated from the sensitive data and protected with strong key-encrypting keys (KEK). Depending on what type of information is being stored and what industry guidance your project/company falls under, compliance regulations in addition to PCI DSS may apply.

The Payment Card Industry Data Security Standard (PCI DSS) is one of the most rigorous and specific set of standards established to date and is used by many organizations as a standard to secure their systems. PCI DSS applies to all organizations that store, process, or transmit cardholder data, regardless of volume. This includes merchants, service providers, payment gateways, data centers, and outsourced service providers.

Here is a high level look at all twelve items that must be met in order to be compliant, with three new requirements in PCI DSS 3.0 (**) that warrant mentioning as being most relevant to the use of VMware and cloud technologies in a PCI-regulated infrastructure:

Build and Maintain a Secure Network and Systems
Requirement 1: Install and maintain a firewall configuration to protect cardholder data


(3.0) **Req. 1.1.3: "[Maintain a] current diagram that shows all cardholder data flows across systems and networks."

Requirement 2: Do Not use vendor-supplied defaults for system passwords and other security parameters

(3.0)** Req. 2.4: "Maintain an inventory of system components that are in scope for PCI DSS."

Protect Cardholder Data

Requirement 3: Protect stored cardholder data*


* Requirement 3 specifically addresses the need for encryption and key management, stating:

“Protection methods such as encryption, truncation, masking, and hashing are critical components of cardholder data protection. If an intruder circumvents other security controls and gains access to encrypted data, without the proper cryptographic keys, the data is unreadable and unusable to that person. Other effective methods of protecting stored data should also be considered as potential risk mitigation opportunities. For example, methods for minimizing risk include not storing cardholder data unless absolutely necessary, truncating cardholder data if full PAN is not needed, and not sending unprotected PANs using end-user messaging technologies, such as e-mail and instant messaging.”

Requirement 4: Encrypt transmission of cardholder data across open, public networks

Maintain a Vulnerability Management Program

Requirement 5: Protect all systems against malware and regularly update anti-virus software or programs


Requirement 6: Develop and maintain secure systems and applications

Implement Strong Access Control Measures

Requirement 7: Restrict access to cardholder data by business need-to-know


Requirement 8: Identify and authenticate access to system components


Requirement 9: Restrict physical access to cardholder data

Regularly Monitor and Test Networks

Requirement 10: Track and monitor all access to network resources and cardholder data


Requirement 11: Regularly test security systems and processes

Maintain an Information Security Policy

Requirement 12: Maintain a policy that address information security for all personnel

(3.0) ** Req. 12.8.5: "Maintain information about which PCI DSS requirements are managed by each service provider and which are managed by the entity."

It can seem overwhelming at first, but the PCI Security Standards Council (PCI SSC) website contains this documentation along with a number of additional resources to assist organizations with their PCI DSS assessments and validations. Within the latest documentation by the PCI Security Standards Council (v3.0 released November 2013) specific testing procedures and guidance is given for Requirement 3 on pages 34-43.

Fortunately, there are also standards and published guidance on running payment applications in a virtualized environment:

Payment Card Industry Data Security Standard: Virtualization Guidelines and Cloud Computing Guidelines

NIST SP 800-144: Guidelines on Security and Privacy in Cloud Computing

Cloud Security Alliance: Security Guidance for Critical Areas of Focus in Cloud Computing

While virtual technology is not limited to VMware, it is one of the most commonly used and supported architectures by many cloud service providers. In addition to the PCI compliance and cloud guidelines above, VMware worked with CoalFire, a QSA auditing firm, to create guidance on how to specifically deploy payment applications in a VMware environment. You can access the CoalFire document  here.

As platform virtualization becomes a more popular solution, executives need to remain vigilant with their data security and meeting compliance requirements. We can help make the transition to VMware easy with our Alliance Key Manager for VMware solution, which meets the PCI recommendations when deployed properly in a VMware environment. We are committed to helping businesses protect sensitive data with industry standard NIST compliant AES encryption and FIPS 140-2 compliant encryption key management solutions.

Here is a sneak peek at the introduction for the latest regulatory guidance white paper from Townsend Security. For detailed information, download the entire document:

On March 25, 2014, the Article 29 Data Protection Working Party of the European Union issued new guidance on data breach notification and the use of data protection technologies such as encryption and encryption key management. Extending beyond just Internet Service Providers, the new regulations cover all organizations that process, store, or transmit private information of EU citizens. Along with these new regulations, there are substantial financial penalties for failing to protect sensitive information. These penalties can reach into the 10’s of millions of Euros depending on the organization’s size and amount of data compromised.

The European Union does not mandate that all organizations immediately encrypt sensitive data, but the only exclusion for subject data breach notification and financial penalties will be for those organizations who use encryption and other security methods to protect the data. Applying these security methods after a breach will not remove the notification requirements and penalties.

EU Data Protection Directive (also known as Directive 95/46/EC) is a directive adopted by the European Union designed to protect the privacy and protection of all personal data collected for or about citizens of the EU, especially as it relates to processing, using, or exchanging such data. The following guidelines will help meet these new EU objectives:

Encrypt Data at Rest

Make a full inventory of all sensitive personal information that you collect and store. Use strong encryption to protect this data on servers, PCs, laptops, tablets, mobile devices, and on backups. Personal data should always be encrypted as it flows through your systems, and when you transmit it to outside organizations.

Use Industry Standard Encryption

Use industry standard encryption such as Advanced Encryption Standard (AES, also known as Rijndael). AES is recognized world-wide as the leading standard for data encryption. Never use home-grown or non-standard encryption algorithms.

Use Strong Encryption Keys

Always use cryptographically secure 128-bit and 256- bit AES encryption keys and never use passwords as encryption keys or the basis for creating encryption keys. Encryption keys based on passwords will never meet minimum standards for strong encryption keys. Keys should be generated using a cryptographically secure random bit generator (CS-RBG) validated to international standards.

Protect Encryption Keys from Loss

Encryption keys must be stored away from the data they protect and must be securely managed. Manual procedures cannot accomplish the goal of proper encryption key management. Use a professional encryption key management solution to protect keys and provide different keys for different data protection needs. Key management solutions should implement key creation, management, and distribution and be compliant with the NIST FIPS 140-2 standard recognized and accepted worldwide.

Change Encryption Keys Regularly

Using one encryption key for a long period of time can expose you to a breach notification for historical data. Change your encryption keys on a quarterly or semi-annual basis. A good key management solution can automatically change encryption keys at an interval you define.

Use Strong, Industry Standard Hash Algorithms

Use strong, industry standard secure hash algorithms when protecting passwords and other information. Never use MD5 or other weaker hash methods. Use the SHA-256 or SHA-512 methods for your hash requirements.

Use Keys or Salt with Your Hashes

When using a strong secure hash algorithm, always use an encryption key or random salt to strengthen the resulting hash value. You can use the Hashed Message Authentication Code (HMAC) method with an encryption key or use a strong encryption key under the protection of a key manager as the salt for the hash method.

For details on the EU Data Protection Directive...