Townsend Security Data Privacy Blog

Customers who need to encrypt data in Microsoft SQL Server databases know that they must protect the encryption key with appropriate controls to meet compliance regulations and to achieve safe harbor in the event of a data breach. Townsend Security's Alliance Key Manager solution provides the Extensible Key Management (EKM) software to make proper key management a breeze. Called Key Connection for SQL Server, this EKM Provider software is installed on the server hosting the SQL Server database and it talks seamlessly to one or more Alliance Key Manager servers running in a separate server instance. Customers get proper key management that meets compliance regulations such as PCI-DSS in an easy-to-deploy solution.

Performance is always a consideration when it comes to enabling encryption, so customers naturally ask us about key caching. Does Key Connection for SQL Server cache the encryption keys to enable better performance?

The short answer is Yes, it does.

How it does key caching depends on whether you use Transparent Data Encryption (TDE) or Cell Level Encryption (CLE). Let’s drill into each of these cases.

Transparent Data Encryption (TDE)
The implementation of TDE by Microsoft involves encrypting the entire table space and the database logs. It is the easiest type of encryption to deploy as it requires no changes to the actual application that uses the SQL Server database. You can implement TDE encryption by installing the Key Connection For SQL Server software and issuing four commands through the SQL Server management console. Restart logging to insure that it is encrypted and you are done.

So with TDE, how are keys managed? The TDE architecture involves SQL Server generating a symmetric key (usually a 256-bit AES key) and then asking Alliance Key Manager to encrypt it with an RSA key. This encrypted symmetric key is then stored on the server that hosts the SQL Server database. When you start SQL Server (or restart it, as the case may be) the SQL Server instance asks Alliance Key Manager to use RSA decryption to decrypt the symmetric key. Once that is complete the SQL Server instance has the key it needs and no longer needs to communicate with Alliance Key Manager. There is no need for key caching and the key will be decrypted the next time that SQL Server starts.

Cell Level Encryption (CLE)
The implementation of CLE by Microsoft SQL Server is quite different than for TDE. The EKM Provider software is still responsible for managing the symmetric encryption key, but it is accomplished in a different way. You must make small changes to your application SQL statements to request encryption and decryption of the cell contents. When CLE is activated the Key Connection for SQL Server software is called for each column and row that needs to be encrypted or decrypted. This means a lot more calls to the EKM Provider software and this is where key caching is very important.

The Key Connection for SQL Server software in this case does cache the symmetric encryption key (usually a 256-bit AES key) in order to improve performance. The key is cached using an equally strong RSA key to prevent key capture by malware. When SQL Server calls the Townsend Security EKM provider the software retrieves the key from the key server and will cache it locally for a 24 hour period. For the next 24 hours all subsequent requests for encryption or decryption are satisfied locally without the need to retrieve the key again. After 24 hours, the key is discarded and a fresh key is retrieved from the key server. If the connection to the key server is not available error messages are written to the Windows Event Log, but encryption processes will continue using the locally cached key, once the 24 hour period expires, network connectivity will need to be restored for a fresh key to be retrieved and operations restored. With key caching database encryption, performance is much better.

The architecture of the Alliance Key Manager EKM provider implements other core features needed to help protect your database. These include:

• Separation of Duties between Key Administrators and Database Administrators
• Dual Control for key management operations
• Built-in logging to the Windows Event Manager
• High availability failover to one or more secondary key servers
• Automatic recovery of failed EKM Provider services
• Security of credentials through Windows Certificate Store
• Easy key rollover using native SQL Server commands

Key caching is important for performance, but this is just one part of an overall key management strategy for Microsoft SQL Server.

As customers move to virtualized and cloud environments, Alliance Key Manager and the Key Connection for SQL Server EKM Provider software will move with you. In addition to traditional IT data centers, all Townsend Security encryption and key management solutions run in VMware (vSphere, ESXi, etc.), Microsoft Azure, Amazon Web Services, and in any cloud service provider vCloud environment.

With apologies to David Letterman, the category today is: Signs Your Encryption Strategy May Have a Problem.  Here they are, your Top 10!

Number 10:

Your decryption fails when you can’t remember where you placed the Annie Oakley decoder ring.

Number 9:

The photos of you in your unicorn costume at Comic-Con, yes, THOSE PHOTOS, are being posted on twitter by anonymous.

Number 8:

Managing encryption keys involves sticky notes on your desk and computer.

Number 7:

When you tell your CEO that the company has poor key management, and he fires you for being disrespectful.

Number 6:

Your encryption strategy is the ransomware that the CEO accidentally downloaded.

Number 5:

When you find out that Pig Latin is not a viable encryption strategy.

Number 4:

Your System Administrator installs new software from a compact disc that has "Totally Legit" written on it in sharpie.

Number 3:

Your passcode is 1234.

Number 2:

Your server password list is projected on a big screen as an example during a presentation at the RSA security conference.

And LAST but not LEAST - Number 1:

This is what your encryption key manager looks like:

And those are the Top 10 signs your encryption strategy may have a problem !!!

IBM made some news recently when they announced availability of Quantum computing capability via the IBM Cloud platform. You can find more information on their website at IBM.com and the press release is here.

Of course, organizations that protect data with encryption are asking if Quantum computing will break their encryption! It is a good question, but first a little explanation. Quantum computing is not the same as Quantum cryptography (quantum encryption). We are obviously in the early days of practical implementations of Quantum computing, but Quantum encryption is not yet practical and there are many problems to be resolved. So don’t be confused when people talk about Quantum computing. The impact on encryption is not dire right now, but it is good to stay aware of the technical progress of Quantum computing.

Recognizing that US government agencies needed some guidance on this topic, the NSA released an FAQ about Quantum computing and guidelines for national security systems (NSS). You can find that guidance here.

I know that many of you are skeptical about NSA guidance. The NSA has probably earned that skepticism based on its poor behavior around the EC-DBRG debacle as well as other activities. If it is any comfort I believe that the National Institute of Standards and Technology (NIST) will also be taking up this issue and involve the global cryptographic community. When that work is finished I believe they will release independent guidance around this question, too. But until then I think the NSA guidance is pretty good.

Because data is often stored for long periods of time, the NSA guidance attempts to insure data protection for several decades in the future. So what are the recommendations?

The encryption most often used for storage is AES. If you have a concern about long term storage the NSA recommends the use of 256-bit AES encryption. The implication is that 256-bit AES encryption will resist the advances of Quantum computing and keep your data safe for a long time to come. Remember that the concern is for data security many years in the future, so if you are using 128-bit AES encryption to protect data today you probably don’t need to panic. But as you move forward and replace backup and storage solutions I would recommend that you use 256-bit AES encryption for data protection.

Protecting data in motion is more affected by the strength of the asymmetric keys that are used to negotiate end-to-end connections. While 2048-bit RSA keys are now considered strong encryption, the NSA recommends moving to 3072-bit or larger RSA keys. Elliptic curve should move ECDH with NIST P-384, and Diffie Hellman should move to 3072-bit keys or larger. Again, there is no need to panic if you are using smaller keys, but if you are concerned about the capture of secure internet sessions and the security of those sessions some years from now you should move to the larger key sizes soon. Before you make any changes please be aware that larger RSA key sizes will impose a performance penalty. Look before you leap!

I believe that for the vast majority of non-governmental organizations the current recommended key sizes are adequate and you should not be overly concerned about the impacts of Quantum computing. The NSA guidance and the forthcoming NIST guidance will give us a good consensus on the recommendations for encryption key sizes.

Patrick

The File Transfer Protocol (FTP) has been with us since the dawn of the Internet. Amazingly it is still a critical component of electronic commerce and all large organizations use FTP for integration with their customers and vendors. As a critical part of your electronic commerce infrastructure you want to make sure that your FTP solution is reliable, secure, automated, and manageable. That’s where Managed FTP solutions come into play. Our Alliance FTP Manager falls into this category and helps IBM i (AS/400, iSeries) customers meet this critical need.

In this blog I want to look at just the security components of a Managed FTP solution. In a future blog we’ll look at the management components in more detail. But let’s start with security!

Secure Transfer Methods

Of course, we need to be sure that we are securing all of our FTP operations with strong encryption. Older FTP protocols did not encrypt FTP sessions and left organizations exposed to data loss both inside and outside of the corporate network. All of that is changed now. There are two types of secure, encrypted FTP methods in wide use:

• Secure Sockets Layer FTP (SSL FTP, or sometimes FTPS)

• Secure Shell FTP (SFTP)

SSL FTP is an extension of the original FTP protocol and is an Internet standard. As the need for secure eCommerce increased in the early 2000s the SSL FTP transfer method gained traction and large organizations transitioned to this secure and encrypted transfer method. Unfortunately, SSL FTP was difficult to implement in typical corporate networks and required modifications to firewall configurations. The complexity of the SSL FTP method made it difficult and expensive to implement and manage.

Secure Shell FTP, or SFTP, is a part of the Unix and Linux Secure Shell set of applications. While originally a Unix application, Secure Shell is now available on a wide set of operating systems and platforms. SFTP provides a secure implementation of file transfer and is much more friendly to the corporate network and network administrators. For this reason most organizations have transitioned to SFTP for their secure and encrypted file transfer needs.

While other open and proprietary solutions exist to transfer files, SSL FTP and SFTP remain the dominant methods of secure file transfer for ecommerce.

Additional Security Requirements

In addition to secure and encrypted transfer of files, a good managed FTP solution provides additional security controls. Let’s take a look at the ones you should find in a managed FTP solution:

File encryption: Many people are surprised to learn that encrypting a file transfer session is not an adequate level of security. When a file arrives at its destination it should also be protected at rest. This means encrypting the file before it is transferred with SFTP or SSL FTP. But doesn’t this mean the data is doubly encrypted? Yes it does. But protecting the file after it is transferred is crucial to a security strategy. Most organizations use Pretty Good Privacy (PGP) to encrypt a file before transfer, and to decrypt files that are received. Your Managed FTP solution should natively integrate PGP encryption into file transfers.

Configuration access control: Configuring managed FTP transfers involves setting local and remote configuration parameters, encryption parameters, and many other aspects of file transfer operation. Your managed FTP solution should implement configuration access controls and notify you of an attempted violation.

Two Factor Authentication (2FA): Control over the administrative functions of a Managed FTP solution should include Two Factor Authentication. This is now a requirement for administrative access to payment card systems by the PCI Data Security Standard (PCI-DSS), but is also a security best practice for any critical system. Be sure your Managed FTP solution provides for 2FA or that you implement 2FA on the IBM i system level.

Compliance audit: Sending and receiving files that contain sensitive data requires that you retain a clear file transfer history. This is a minimal level of audit reporting and you will want to be sure your Managed FTP solution provides clear and easy to read audit trails.

System logging: Actively monitoring your system is a critical security control. On the IBM i server it means monitoring security events and transferring them in real time to a log collection server, or better yet, to a SIEM solution. FTP is often the mechanism by which cyber criminals steal information from your system, so a Managed FTP solution should be logging file transfers to the IBM security audit journal QAUDJRN. The security audit journal provides an un-modifiable repository of security events, and your file transfer information should be recorded there. Look for this feature in your Managed FTP solution.

Software updates and patching: Secure FTP protocols are periodically subject to the need for security patching. A recent security flaw in the SFTP protocol required updates for all systems that implement this Secure Shell protocol. Fortunately, on the IBM i platform IBM provides the SSH implementation as a no-charge licensed product, and updates are available through normal system patching procedures. Be sure that your Managed FTP solution integrates with the IBM solution, or that the Managed FTP vendor has an adequate strategy to provide you with security updates.

Backup and Recovery: As the new EU General Data Protection Regulation (EU GDPR) correctly points out, backup and recovery is a part of your security strategy. If you can’t recover from a system failure in a reasonable period of time you risk losing data that is critical for your customers and employees. We hold that data in trust for them, and protecting it also means resiliency in the event of system failures. Be sure your Managed FTP solution fits into your backup and recovery strategy for the IBM i platform.

These are critical security components of a Managed FTP solution. Some organizations we work with transfer thousands of files every day. I believe we’ve addressed the core security requirements in our own Alliance FTP Manager solution and we continue to invest in R&D to make these features better going forward. I will address other aspects of Managed FTP in future blogs.

Patrick

The news has been heavy recently with stories of Ransomware attacks on hospitals, businesses, and even police departments. The basic Ransomware attack usually starts with a user clicking on a poisoned link or opening an infected document or file. A trojan program installed on a user PC or server then runs and denies access to that data until a ransom is paid.

The denial of access to data is often done through the encryption of all of the files on a PC. CryptoLocker is an example of this type of access denial, but there are now many variants of encrypted access denial. Other methods of access denial have been used, but encryption is now the most common method. Strong encryption is readily available to anyone including cybercriminals, and unless the attack uses poor encryption methods there is no way to unlock the data without paying the ransom to receive the decryption key.

A disturbing trend has developed with Ransomware over the last few months. In addition to encrypting a user’s PC or a single server, Ransomware has taken to encrypting network and mounted drives, even drives that are mirrors to cloud storage services. The mounted drives might even include your backup storage! The encryption of network drives affects a much larger group of users and can be devastating to the organization as a whole. And when the backup network drive is affected there is no way to even restore from that backup. Many organizations can afford to lose a single user PC - but imagine losing all of the company’s information on a central server!

Monetarily, ransoms are usually not very large, but there are exceptions. Cyber criminals know that a smaller ransom is more likely to be paid and they can then move on to the next victim. Ransom payments are usually done in Bitcoin to avoid tracking the payment through the normal banking system. While not a perfect strategy for cyber criminals, it usually works pretty well.

So, what can you do to avoid the catastrophic loss of your data from a Ransomware attack?

Old style, off-site, disconnected backup is back in fashion!

Whatever is connected to your network is at risk in a ransomware attack. Backup cartridges stored off-site at an archival service like Iron Mountain, or even stored at your local bank, can’t be damaged by Ransomware. I know that many organizations have migrated to cheaper online and virtual tape backup systems, but these may be accessible to a dedicated attacker. If your internal systems can “see” the backup storage, so can an attacker. You need to have backups that are not accessible to the attacker - put some airspace between your backups and the cyber criminals!

Tape, cartridge and disk-based backup systems have been around for quite some time, are reasonably priced, and can be quick to deploy. Here are some things to look for in backup systems:

• Tape or disk physical media can be stored off-site
• Backups should be encrypted - don’t risk the loss of an unencrypted tape or cartridge
• Don’t share keys across individual backups - every backup should have a unique key.
• Create documented procedures for backups.
• Create documented procedures for restoring from backup.
• Test your restore! Your backup strategy is only as good as your proven ability to restore from the backup.You don’t have a backup strategy until you’ve tested it with an actual restore!
• Schedule your backups so that they are automatic.

Because old-style off-site backup has been around for a while you will find good documentation and best practices about backup and recovery. You don’t have to reinvent the wheel here. Mature and proven solutions are available right now.

Addressing off-site backup may seem old-fashioned to you right now. You won’t think so if your organization falls victim to a Ransomware attack! Here at Townsend Security we use a cartridge backup solution from Quantum who are one of our partners, but you have lots of choices. Get started now!

Patrick

Those of us in the data security industry often wear technology blinders as we go about the business of trying to secure the sensitive data of the organizations we serve. Every organization has limited resources and it is hard to compete with line of business needs in terms of budget and human resources. It’s an ongoing struggle that comes with the territory.

Of course, any organization that has suffered a severe data breach quickly changes its attitude towards investing in security. The internal attitudes at Target, Anthem and Sony are different today than they were in the past, and for good reasons.

For those who’ve not experienced a data breach, the organizational costs remain vague and theoretical. I thought you might like to read how an attorney views the impacts of a data breach that involves the loss of credit card information. David Zetoony, an attorney with the legal firm Bryan Cave, has written several white papers discussing aspects of security. These are very readable works and well worth the time. Even if you are not processing credit card payments, I think this article is relevant to the loss of any sensitive data.

Here is his paper on the impacts of a data breach involving credit cards.

There is a bonus section in this paper about cyber insurance. In my eBook on Key Management Trends and Predictions I mention Cyber Insurance as an evolving industry. This paper by David Zetoony delves much deeper into the issues related to Cyber Insurance. He provides some very practical advice on how to think about Cyber Insurance and how to evaluate potential coverage. If you are new to the topic, or if you’ve not reviewed your Cyber Insurance policy for more than a year, you need to read the second part of David’s paper.

Neither I nor Townsend Security has any relationship with David Zetoony and the legal firm of Bryan Cave. I stumbled on this David’s work and thought you might find this informative. For those of you making the case for increased security, you might consider sharing David’s paper with your management team and legal counsel.

Patrick

MongoDB: Encryption Best Practices 

As the importance of encryption increases across the regulatory spectrum, it is heartening to see database vendors implementing encryption and encryption key management that meet security best practices. MongoDB Enterprise is one of the most popular modern databases and has given its customers the ability to quickly and effectively implement encryption and good key management at the level of the database itself. This means that MongoDB Enterprise customers can transparently implement encryption directly in the database without deploying third party file or volume based encryption products to accomplish this task. MongoDB customers enjoy rapid deployment of encryption, a unified management interface to the database, high performance encryption, and integrated encryption key management based on the industry standard Key Management Interoperability Protocol (KMIP).

By basing key management on the OASIS KMIP standard MongoDB is providing real benefits to their customers. These include:

• Rapid implementation of key management with no need for developer resources.
• No requirement for server-side software libraries, updates, and patching.
• Secure encryption key retrieval services based on TLS.
• Vendor neutrality for encryption key management services.
• Vendor portability and avoidance of vendor lock-in.
• Seamless migration from one key management solution to another.

MongoDB Enterprise is a case-study in the benefits of using open standards for encryption and key management. MongoDB’s customers can choose the key management solution that makes the most sense for them, and having choices reduces the cost of encryption key management.

MongoDB: Encryption Key Management Made Easy

Townsend Security's Alliance Key Manager solution works out of the box with MongoDB Enterprise to help customers meet compliance regulations which require encryption of sensitive data. It takes just a few minutes to deploy Alliance Key Manager and to configure MongoDB for key management. On first boot, Alliance Key Manager creates a set of strong encryption keys including a 256-bit AES key that can be used with MongoDB, and it creates a set of PKI certificates used for TLS authentication. The PKI certificates are copied to the MongoDB server to secure the connection to the key manager. A quick command or two from the MongoDB command line console and, Voila! Your MongoDB encryption key is now fully protected by a key encryption key on Alliance Key Manager. You have an encrypted MongoDB database and a highly redundant and recoverable encryption key management infrastructure. From the technical team at MongoDB:

“The encryption occurs transparently in the storage layer; i.e. all data files are fully encrypted from a file system perspective, and data only exists in an unencrypted state in memory and during transmission.”

After installing the key manager certificates on the server hosting the MongoDB database, here is an example of the command to enable encryption:

mongod --enableEncryption --kmipServerName akmmongo --kmipServerCAFile /etc/mongodb-kmip/AKMRootCACertificate.pem --kmipClientCertificateFile /etc/mongodb-kmip/AKMClientCertificate.pem --dbpath /var/lib/mongodb/

It’s that simple.

With Alliance Key Manager you have your choice of network-attached hardware security modules (HSMs), VMware virtual machines, and dedicated cloud instances in Microsoft Azure and Amazon Web Services. The key manager works the same way in all environments so you can even mix and match hardware, VMs, and cloud instances to achieve the level of security that is right for your organization. All instances of Alliance Key Manager are dedicated to you with no access by cloud service providers or third parties. Key custody remains exclusively under your control.

Many MongoDB customers deploy the database in VMware environments. Alliance Key Manager also runs in VMware as a virtual machine. You can deploy the key manager in a VMware security group and protect one or more instances of MongoDB across the entire VMware environment. If you are running on a VMware vCloud platform the same support is provided for key management.

For compliance, Alliance Key Manager is validated for PCI-DSS compliance in the VMware platform. This will help you achieve PCI-DSS compliance for your MongoDB database and applications. The PCI-DSS statement of compliance is here.

MongoDB is rapidly becoming the high performance, scalable, NoSQL database of choice for organizations large and small. As such it becomes a part of the critical infrastructure for business applications. Alliance Key Manager also implements high availability features such as automatic, real-time encryption key mirroring, and backup. For customers deploying the hardware version of Alliance Key Manager, there is redundancy at the hardware level with dual hot-swappable RAID disks, redundant power supplies, and redundant network interfaces. All of these features mean that your key management infrastructure will be resilient and reliable.

Alliance Key Manager will help you will meet common compliance regulations such as PCI-DSS, HIPAA, FFIEC, FISMA, the EU General Data Protection Regulation (GDPR), and other compliance schemes. Alliance Key Manager regardless of platform is based on the same FIPS 140-2 compliant software found in our enterprise level HSM. With no restrictions or license costs for client-side connections, you can protect as many MongoDB databases as you like with one Alliance Key Manager.

The product team at MongoDB did a great job of implementing encryption and key management for their customers. They deserve to be applauded for basing their solution on industry standards like KMIP. This will lower the bar for getting encryption right in the database. With Alliance Key Manager, getting encryption right means rapid deployment, conservation of developer resources, lower administration costs, and provable compliance.

A match made in techno-heaven.

Patrick

The new European Union General Data Protection Regulation (EU GDPR) has now passed both the EU Council and Parliament and replaces the earlier Data Protection Directive (Directive 94/46/EC). Unlike an EU directive, this regulation does not require individual countries to pass legislation and it goes into effect immediately. Organizations have a two-year transition period to comply with the new data protection regulations, but it would be unwise to delay. Smart organizations will start work immediately so that there are no gaps upon the arrival of the deadline, and so that their public reputation is preserved. A good overview of the regulation can be found here and it contains a link to the full regulation.

There are many aspects to the new GDPR, and if you are required to meet the regulation you should take a very close look at the entire publication. Let’s look at a few of the elements of the GDPR with a focus on data protection.

What information must be protected?

The regulation uses two terms that are important to understand. The term “data subject” means an individual person. The term “personal data” means any data that either directly identifies an individual person, or which can be used indirectly to identify an individual. A few examples of data that indirectly identify an individual would include a medical identification number, location data such as an IP address, or social identity such as an email address or Facebook account.

The definition of personal information is quite broad. It would be a mistake to narrowly focus on just a few fields of data in your database, you should look for all information about a person that you store. If any information uniquely identifies a person, or if information can be combined to identify a person, it should be protected.

What constitutes a data breach?

The definition of a data breach is much broader than defined in the US. It certainly includes the the accidental loss of data or the loss of data in the course of a data breach by cybercriminals. But it also includes other activities including the accidental or unlawful:

• Destruction of personal information.
• Alteration of personal information.
• Unauthorized disclosure of information, even without criminal intent.
• Access to personal information.

In other words, assume that the data you store about an individual belongs to them exclusively, and is valuable. You are holding it in trust, and you have a fundamental responsibility to preserve and protect that information! This will be a conceptual challenge for organizations more familiar with US data protection rules.

Non-EU organizations should pay special attention to this definition of a data breach. It goes far beyond what typical regulations in the US define as a data breach.

What are my breach notification requirements?

The data breach definition applies to all personal information that is transmitted (data in motion) or stored (data at rest) or in any other way processed by your organization. In the event you experience a data breach you must notify the appropriate authorities and the individuals who are affected. There are stringent time constraints on the notification requirements and this will require special preparation to meet those requirements.

Important note: If your data is encrypted you may be exempt from some notification requirements (from Article 32):

The communication of a personal data breach to the data subject shall not be required
if the controller demonstrates to the satisfaction of the supervisory authority that it has implemented appropriate technological protection measures, and that those
measures were applied to the data concerned by the personal data breach. Such
technological protection measures shall render the data unintelligible to any person
who is not authorised to access it.

Who is covered by the regulation?

The GDPR uses the special term “Controller” for an organization that transmits, stores, or processes personal information. You are a Controller of personal information if in any way you transmit, store or process personal information. This applies in equal measure to service organizations that receive personal information in a secondary capacity.

The GDPR also uses the special term “Processor”. You are a Processor if personal information flows through a system that you control. This applies to information you provide to other organizations and to third party computing service providers such as cloud service providers (CSPs).

Are non-EU organizations covered by the EU GDPR?

Yes, if you are located outside of the EU but are doing business in the EU or operating in the EU (you are a controller or processor of personal information of EU citizens), you fall under the requirements of the EU GDPR. This will surprise many organizations who do not have offices or employees located in the EU zone.

Are there any special categories for protection?

The EU General Data Protection Regulation establishes some special categories of individuals and information that come in for additional controls. Information about children and the information of medical patients require special attention on the part of organizations who process this type of information.

What are the penalties for non-compliance with data protection requirements?

While there is some flexibility in how fines are levied for unintentional non-compliance to the GDPR and depends somewhat on which rules you are out of compliance with, the penalties can be quite severe. The failure to protect sensitive data with encryption with appropriate technical controls is considered a severe violation. No one should ignore the potential impact of these fines. For example, an enterprise that fails to protect data can be subject to fines of up to 1,000,000 EUR (1 Million Euro) or up to 2 percent of annual worldwide revenue. You can see why this new regulation is getting a lot of attention in the European Union!

See Article 79 of the GDPR for more information about fines and penalties:

Is encryption a mandate?

This is from the GDPR recitals:

(23) The principles of protection should apply to any information concerning an identified
or identifiable person. To determine whether a person is identifiable, account should
be taken of all the means likely reasonably to be used either by the controller or by any
other person to identify the individual. The principles of data protection should not
apply to data rendered anonymous in such a way that the data subject is no longer
Identifiable.

The most common way of making data anonymous is encryption with good encryption key management.

And you should know this from Article 30 of the GDPR:

1. The controller and the processor shall implement appropriate technical and
organisational measures to ensure a level of security appropriate to the risks
represented by the processing and the nature of the personal data to be protected,
having regard to the state of the art and the costs of their implementation.

2. The controller and the processor shall, following an evaluation of the risks, take the
measures referred to in paragraph 1 to protect personal data against accidental or
unlawful destruction or accidental loss and to prevent any unlawful forms of
processing, in particular any unauthorised disclosure, dissemination or access, or
alteration of personal data.

It is likely that in almost all cases the only appropriate technical measure to ensure anonymization and security appropriate to the risk of loss is encryption with appropriate key management controls. When encryption is not specifically required we sometimes call this a “backdoor” mandate - you are not required to implement encryption, but in the context of a data breach anything else will be deemed inadequate, and subject the organization to fines. You don’t want that to happen to you.

I hope this helps you understand the basic data protection requirements of the new EU General Data Protection Regulation. I know that the regulation is complex and there remain some ambiguities. In future blog posts I will go into more detail on various aspects of the GDPR and how our solutions at Townsend Security are helping EU organizations meet the data protection requirements.

Capturing administrative credentials as a path to stealing sensitive credit card data is becoming a more common method used by cybercriminals. It is not surprising, then, that the PCI Security Standards Council would address this rising threat in the new version of the PCI Data Security Standard (PCI-DSS). For some time now the PCI council has been telling merchants, service providers, and banks that it would more aggressively respond to emerging threats, and version 3.2 of the PCI-DSS standard reflects this.

One of the most effective ways of countering this threat is to implement two factor authentication (2FA or TFA). This is also sometimes call multi-factor authentication (MFA), and the two terms are used interchangeably. If you use Google, Facebook, Yahoo, or any number of other Internet services you are probably already aware of two factor authentication as a security mechanism. With two factor authentication you no longer just provide just a password to login as an administrator of an account, or to make administrative changes to your systems. You must supply a 5 or 6-digit PIN code to complete the login sequence. The PIN code is generated separately from your signon prompt and thus is harder for cybercriminals to capture.

A password is something you know, so the second factor for authentication must be something you have such as a cell phone or token, or something you are such as a fingerprint or iris image. Secret questions don’t qualify as as second factor as they are also something you know, like the password. A general description of two factor authentication can be found here.

Prior to version 3.2 of the PCI Data Security Standard, remote users were required to use two factor authentication for access to all systems processing, transmitting, or storing credit card data. With version 3.2 this is now extended to include ALL local users performing administrative functions in the cardholder data environment (CDE). This makes sense as user PCs can be infected with malware that leads to the compromise of administrative credentials. It hardly matters anymore if the user is local or remote.

Why is this a big deal?

First, many companies processing credit card data do not have remote workers, and 2FA will be new technology. Even if you have remote administrators, they are probably authenticating with 2FA via a VPN session which will not work with internal administrators. This means evaluating new 2FA solutions, deploying them in all of your CDE environments, training employees on how to use the technology, and implementing new HR procedures to manage employees and access to 2FA.

Second, many 2FA solutions require deployment on hardware servers that must be deployed and maintained. There may be impacts on the company network and firewalls, and it means a new technology ramp-up. This includes addressing hybrid environments that may encompass traditional IT data centers, virtualized environments, and cloud applications. If the 2FA solution is based on hardware tokens that employees have to carry, you will have to manage the distribution, revocation, and replacement of tokens.

Third, many merchants have complex cardholder data environments and a 2FA project can be daunting. Think about a large box store retailer. Besides the normal check-out Point-of-Sale systems, they might have pharmacy, optical, automotive, and many other departments under the same roof. The CDE might be complex and extensive and the 2FA effort may be large depending on how much administrative work is performed locally.

Last, it is not enough to deploy a 2FA solution. It must be properly monitored in real time. An attacker may attempt to guess or brute-force attack the PIN code. A good 2FA solution will log both successful and unsuccessful PIN validation requests. The logged failures should be monitored by a SIEM solution so that the security team can react to the threat quickly.

Here at Townsend Security we provide a solution to IBM i (AS/400, iSeries) customers that is based on mobile, voice, and optional email delivery of PIN codes. Alliance Two Factor Authentication integrates directly with the global Telesign network to deliver PIN codes. A customer who needs to deploy two factor authentication can install, configure and verify a 2FA PIN code sequence in less than 30 minutes. There is no hardware to install or maintain, and there are no individual tokens to distribute and manage. We think that this solution will help many IBM i customers quickly achieve compliance with version 3.2 of PCI-DSS and PA-DSS. More information here:

In future blogs I will talk more specifically about our solution.

Patrick