Townsend Security Data Privacy Blog

Three questions to ask yourself when choosing encryption key management for vCloud

Businesses are moving more and more data to the cloud, and in our world, more data floating around in the cloud means more concern about securing sensitive data. It is no surprise to anyone that a single business can processes millions of pieces of sensitive data every day. From credit card numbers to social security numbers and protected health information (PHI), retail, financial, and healthcare organizations are processing this data in greater numbers than ever before.

Storing data in the cloud is one way businesses are conserving resources. Another way they are doing this is with platform virtualization. VMware is one of the most popular and widely used virtualization solutions currently used by enterprises. Alongside their virtualization software, VMware also supports the vCloud architecture that allows users to seamlessly move their workloads to a hosting or cloud vendor that supports this architecture.

Securing data in a virtualized environment introduces new security concerns, simply by the fact that applications processing sensitive data share resources such as memory, disk storage, and central processing units (CPU) with other applications on a physical machine. If a business decides to move their data to vCloud, this introduces even more concerns around the fact that a cloud environment shares these resources with other people and businesses as well.

Security professionals agree that security should be the number one concern for businesses moving data to the cloud. No one should ever assume that their cloud provider is protecting their data, especially if you need to meet compliance regulations such as PCI-DSS, GLBA/FFIEC, or HIPAA/HITECH. The only way to protect sensitive data in the cloud is by implementing a data security plan that includes strong encryption and encryption key management.

Townsend Security recently released Alliance Key Manager for VMware. This encryption key management solution is identical to our FIPS 140-2 compliant Alliance Key Manager hardware security module (HSM) for database encryption and is compatible with vCloud architecture to provide powerful data security for data in the cloud. This versatile instance of our encryption key manager works with any cloud or hosting provider that supports VMware vCloud architecture.

When choosing a third-party encryption key management provider to secure your data in vCloud, it is important to ask yourself these three questions:

1. Is it cost effective?
Businesses are looking towards simplified and scalable data storage solutions to reduce cost and conserve resources. Virtualization and cloud services serve businesses by providing cost-effective options for data storage and processing. Your encryption and key management should not thwart your goals to reduce cost and complexity in your business. You need solutions that will scale with your transition to virtualization and the cloud and that will work seamlessly in these environments. One of our fundamental beliefs is that budget should not be a barrier to good data security!

2. Will your encryption key management move with you to the cloud?
Not all businesses have moved to the cloud. However, as the cloud becomes more and more prevalent as well as cost effective, it’s important to keep in mind that you might decide to migrate to the cloud in the future. This migration can either be relatively simple or a huge headache depending on how cloud-compatible your software and hardware providers are. Choosing sophisticated solutions that are prepared to move with you to the cloud and will provide you with thorough technical support is critical to your success.

3. Will your key management prepare you for a breach?
In today’s data climate, a data breach for most businesses is no longer a matter of “if,” but, “when.” The only way to secure a breach, prevent data loss, and avoid data breach notification is by using strong, industry standard, and certified encryption and encryption key management. You’ll want your encryption key management solution to implement key management best practices that go above and beyond industry certifications. Certifications are often a low bar in data security, and implementing best practices will increase your security posture tremendously. Your encryption key management should be NIST FIPS 140-2 compliant if you want your data security to stand up to scrutiny in the event of a breach.

To learn more about enterprise key management for VMware and vCloud, download our podcast "Virtualized Encryption Key Management."

This is in the category of people and organizations you should get to know:

If you are a Windows developer and work with Microsoft SQL Server, you should get to know the SQL Server Worldwide User Group (SSWUG). The web site is sswug.org and has 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. But 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 SQL Server.

I’ve had the pleasure of working with Stephen Wynkoop on a number of occasions and really appreciate his depth of knowledge on security topics related to SQL Server. While not defining himself as a security specialist, Stephen brings a seasoned and mature approach to the subject of database security and I am always impressed with his thoughts and perspective.

Recently SSWUG dedicated a section of their web site to “Townsend Security Tips” where they present videos of Stephen and I 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. Upcoming sessions include meeting evolving compliance regulations and how to make sure your data is secure when you when trusting it to a hosting company. We 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 the content on the SSWUG website, SSWUG also holds virtual conferences and Summer Camps that are great online resources for developers.

SSWUG - Get to know them!

Patrick

As we discussed in the blog Understanding System Logging on the IBM i – Part 1, secure system logging on the IBM i (AS/400) can not only help you meet compliance requirements, it can help you stop a data breach before it happens!  Hopefully you were able to watch the webinar resource provided (if not, you can request it HERE).  After the webinar, we had a number of questions asked by attendees and answered by security expert Patrick Townsend.

Here is a recap of that Q&A session:

Q: Can you pick which group of users to audit?

Patrick: In our current version of Alliance LogAgent, our IBM i system logging solution, you can define a list of “excluded users.”  So you can actually tailor events on the IBM i platform and exclude particular user profiles.  We also provide some basic filtering capability allowing you to filter based on IBM event type and on User event type.  So yes, there is a fair amount of filtering capability in the product.  From a security posture, it would be a mistake to filter out significant security events, however the solution allows you to easily choose and select the events you want.  We have an option that maps straight to the security system values so you can easily set LogAgent to process those or you can establish and select any and all of the event types in the product that you want to monitor.

Q: With all the different IBM system events, is it possible to set up filtering of just the IBM security event types?

Patrick: Yes, In our solution, collection of the system security events is set as the default “out of the box” setting.  You have total control over the events you collect, and with just a few keystrokes, you can re-map your collection and filter in additional events, or leave it set to what IBM identifies as the security type events being collected in QAUDJRN.

Q: Can File Integrity Monitoring (FIM) also monitor read access to a database file? What about a user that comes in from another server doing just a select in SQL?

Patrick: The File Integrity Monitoring component in LogAgent is based on a database journal. A record-level read event is not collected in a database journal; but a file open and closed event is collected.  So if a user does access a file through read and there’s no update, insert, or add type of event, it may not appear in the journal. We capture all the information that the system makes available to us in the file integrity monitoring component on significant changes or access to any protected file.

Q: You mentioned File Integrity Monitoring. Can you further explain how an organization would use it?

Patrick:  File Integrity Monitoring is designed to monitor configuration changes and highlight them for early detection.  Generally, when an attack happens on an application it often involves changes to configuration files in an attempt to escalate privileges and give the attacker more authority or access than they should have.  For example if a new user is suddenly granted authority in the HR application to print checks, that is an important indicator of a potential problem!  Another common use for File Integrity Monitoring is to monitor the use of stored sensitive information (credit card information or social security numbers) on your IBM i platform, you would want to use FIM on those databases or applications in order to strengthen your security stance and identify those potential attacks early on.

Q: How do you keep QAUDJRN entries from flooding the network?

Patrick: With the large volume of events that can be collected by QAUDJRN, you can really help minimize network impacts by filtering out events that are not security related.  You can still collect those events, but exclude them from being transmitted to your SEIM console.  Because LogAgent works in real time it helps reduce the impact on your network because you are not transmitting millions of events all at once. We also provide metering capabilities so you can reduce the number of events per second that are being transmitted.

Q: How do these logs get stored?

Patrick: When it comes to log storage, you want them off of your IBM i platform as quickly as possible to avoid potential tampering or corruption.  With LogAgent, we do not make a copy of the events, we take the filtered events out of QAUDJRN in real time, format and transfer them to your log collection server or SEIM.  Since some compliance regulations require the events are stored for a defined period of time, SEIM consoles compress, store, and protect those log events so you have the ability to do forensics, queries, and reporting on them.

To learn more, view our webinar "Understanding Log Management on the IBM i" which examines the security principles, compliance requirements, and technical challenges for log collection and forwarding on the IBM i platform with the following learning objectives:

• Security principles of log collection and monitoring
• Compliance requirements of PCI DSS, HIPAA/HITECH, SOX, GLBA/FFIEC
• Communicating with log collection and SIEM servers
• File Integrity Monitoring and log collection
• IBM i log collection challenges

Is your VMware Instance PCI DSS Compliant? Look to PCI and VMware for Guidance.

Platform virtualization is becoming a more and more popular solution for companies trying to conserve resources, and VMware is leading this transition as the most popular virtualization platform available. However, there are still many concerns around data security in virtualized environments. Naturally, many people are concerned about PCI compliance when running in a VMware environment. In this case, most of the questions about PCI compliance are in the context of the PCI Data Security Standard (PCI-DSS) and PCI Payment Application Data Security Standards (PA-DSS).

Fortunately, the PCI Security Standards Council (PCI-SSC) has already weighed in on this question and has published clear guidance on running payment applications in a virtualized environment. Version 2.0 of the document is available from the PCI website and directly accessible here.

Of course, this guidance does not mention VMware specifically. It is designed to address the issues related to any virtualization technology such as Microsoft Hyper-v, Xen, and any others. However, VMware is the de facto standard for virtualization in data centers and is deployed by many cloud service providers who support the vCloud architecture. So it is natural that there are many questions about PCI compliance with VMware.

First it should be said that anyone running VMware for their line of business applications should read the PCI guidance BEFORE they start to deploy applications that store or process payment transactions. The procedures you use to deploy business applications in a VMware context are almost certainly not going to meet PCI requirements. So, if you are thinking about doing this, take a deep breath and do some research first.

Fortunately, we have some good guidance from PCI as well as VMware on the topic of PCI compliance. VMware worked with CoalFire, a QSA auditing firm, to create guidance on how to deploy payment applications in a VMware environment. The document follows closely the PCI virtualization guidance, and will be an invaluable resource as you start your project. You can access the CoalFire document from the VMware website here.

With these two documents in hand, and with the guidance of  your QSA auditor or security consultant, you can achieve good compliance with PCI recommendations.

PCI also offers guidance on running encryption key management solutions in a VMware context. There are some obvious points such as the recommendation that you NOT run your key management application in the same hardware and VMware hypervisor context. You will be glad to know that Townsend Security’s Alliance Key Manager for VMware solution meets the PCI recommendations when deployed properly in a VMware environment. We recently released our Alliance Key Manager solution as a VMware appliance, and we are committed to helping businesses achieve PCI compliance with industry standard encryption and encryption key management.

Patrick

Businesses are virtualizing their IT infrastructure to save time, money, and manage many other resources that often go unused in IT environments. Virtualization of data centers evolved from the basic principles of resource sharing used in hosting and cloud environments. Virtualization enables businesses to have more efficient data center operations. With multiple operating systems running on a single server, multiple applications can also run on that server which in the long run allows a company to reduce the number of servers that they run and maintain. 

However, virtualization introduces new security concerns for companies that must protect sensitive data. Because virtualization allows businesses to run multiple applications on the same server, the encryption of sensitive data must work in conjunction with the virtualization platform. For businesses such as retailers and banks who run payment and financial applications on virtualized operating systems, they must encrypt sensitive credit card and financial information on their virtualized platforms, which requires a specialized third-party security solution.

Previously, companies would encrypt data on a server by server basis, using a single key management server to securely provide encryption keys to multiple servers on the network. The new infrastructure that virtualization brings into play, however, has caused encryption key management to need a different approach. New security concerns such as shared disk storage, network infrastructure, processing CPU components, need to be addressed.

Townsend Security has addressed the concerns in a new version of our encryption key manager, Alliance Key Manager for VMware. Alliance Key Manager for VMware is a NIST and Payment Card Industry (PCI) compliant virtual instance, identical to our original Alliance Key Manager hardware security module (HSM) that is in use by over 3,000 customers worldwide.

Simplified and Cost Effective Data Security

If you’re trying to reduce costs by moving to virtualized environments, implementing powerful data security that helps you meet compliance regulations doesn’t have to negate those efforts. Just like you choose virtualization to reduce costs in the long run, you can choose an encryption and key management solution that does the same, at a lower upfront cost. Townsend Security’s Alliance Key Manager for VMware is a specialized version of our key manager that allows you to encrypt data and securely manage encryption keys in a virtualized environment.

Alliance Key Manager for VMware manages encryption keys throughout the key lifecycle from the generation of those keys to their activation and use all the way through to retirement and deletion of keys.

Meet Compliance Regulations

By themselves, applications running VMware aren’t PCI compliant. Companies using VMware to reduce costs and consolidate their IT infrastructure still need to take responsibility for their own PCI compliance. Thankfully, VMware has made achieving PCI compliance through third-party security solutions easy with open architecture and standard APIs. VMware also recognizes the need for security in virtualized environments and has gone so far as to team up with CoalFire, a QSA auditing firm to publish guidelines for achieving PCI compliance in a virtual environment.

Many people believe that their hosting company is protecting their sensitive data. In actuality, it is never safe to assume your hosting company is doing this. Individuals and companies are responsible for protecting their own sensitive data. If you’re hosting in a virtualized environment, there are some hosting companies who have passed an infrastructure certification for compliance regulations, but they are few and far in between. In order to achieve compliance, businesses must review PCI standards and implement data security controls such as encryption and key management

Alliance Key Manager for VMware works in vCloud as well as any hosted environment that supports vCloud.  If you are moving your virtualized environment in the cloud, Alliance Key Manager for VMware will support this migration and can provide you with powerful encryption key management for the cloud.

If you’re an independent software vendor (ISV) who sells payment applications to retailers, what does it mean when your payment application meets PCI standards, but doesn’t actually protect your customers? A lot of people out there, especially consumers, wouldn’t even think the security of the software that handles their credit card data is an issue. Many people don’t realize that there’s a huge problem with data security in point-of-sale (POS) and retail software applications. However, time and time again we see major data breaches occurring through cash register systems that process credit card data, which invariably means that those systems aren’t adequately protecting consumer data.

The problem with data security in payment applications arises when retail ISVs and POS vendors certify their payment applications with the Payment Card Industry Security Standards Council (PCI-SSC). The PCI-SSC requires that these businesses use strong encryption and encryption key management in their payment applications. Although most payment application vendors incorporate encryption and encryption key management into their solutions, many of them do it poorly, skating by with the minimum requirements. In the end, their applications pass certifications but would not protect their customers--or themselves--in the event of a data breach.

And data breaches are happening every day! Today data breaches are considered a matter of “when,” not “if.” It is almost a certainty that it is only a matter of time before a data breach affects one of your customers.

Unfortunately, encryption and encryption key management are complicated tools for ISVs to build on their own--in fact, doing a “home grown” encryption project is almost never recommended by encryption experts. Because many ISVs don’t have the resources to create their own encryption and encryption key management, Townsend Security offers an encryption key management solution that retail ISVs and POS vendors can integrate into their applications to provide their customers with industry standard, certified data security solutions.

We recently published an eBook titled, “Overcoming Critical Security Issues - a Guide to Proper Encryption Key Management,” for POS vendors and Retail ISVs. Read an excerpt written by Townsend Security Founder and CEO Patrick Townsend and download the eBook now:

“Merchants are very worried about data breaches and the potential effect of a breach on their business. The average data breach costs a company $5.5 million, which includes the cost of fines as well as the costs associated with lost business, litigation, and brand damage. A successful exploit of poor data security can destroy years of work building brand reputation. Smaller businesses may never fully recover from a well-publicized data breach. Payment application vendors with poor encryption and key management are subjecting not only their customers to these risks, but themselves as well.”

Good encryption and key management for credit card numbers will also give payment application vendors an advantage over their competitors. PCI standards are not set in stone; data security is constantly evolving to meet new challenges and threats. CEOs and Product Managers in the payment application industry should be having a high-level discussion about data security. Now is the time to move to a second generation data security strategy for protecting customer credit card information. You need a solution that doesn’t just look good on paper, but will protect you and your customers in the event of a breach.”

To read more, download the eBook now.

Key Lifecycle & Rotation Explained

Encryption key management refers to the ability of a system to administer an encryption key through the length of its crypto-cycle. From the creation of a key, through it’s use, and eventually to its deletion, an encryption key management system needs to be able to securely and efficiently handle the encryption keys. I will talk a little about each major part of the encryption key lifecycle and how our Alliance Key Manager manages and administers the key throughout the lifecycle.

Key Creation: First, the encryption key is created and stored on the key manager server. The key can be created by a sole administrator or through dual control by two administrators. Townsend Security’s Alliance Key Manager creates the AES key through the use of a cryptographically secure random bit generator and stores the key, along with all it’s attributes, into the key database (which is also encrypted). The attributes stored with the key include its name, activation date, size, instance, the ability for the key to be deleted, as well as its rollover, mirroring, and key access attributes. The key can be activated upon its creation or set to be activated automatically or manually at a later time. Alliance Key Manager can also create keys of three different sizes: 128, 192, or 256-bit. The encryption key manager also tracks current and past instances, or versions, of the encryption key. You can also choose whether or not the key can be deleted, mirrored to a failover unit, and by which users or groups it can be accessed. Alliance Key Manager also allows the change of many of the key’s attributes at any time.

Key Use and Roll: Alliance Key Manager will allow an activated key to be retrieved by authorized systems and users for encryption or decryption processes. It also manages current and past instances of the key. For example, if a key is rolled every year and the version is updated, then the key manager will retain previous versions of the key but will dispense only the current instance for encryption processes. Previous versions can still be retrieved in order to decrypt data encrypted with such versions of the key. Alliance Key Manager also uses transport layer security (TLS) connections to securely deliver the encryption key to the system and user requesting it, which prevents the key from being compromised. The encryption key manager will also roll the key either through a previously established schedule or manually by an administrator.

Key Revocation: An administrator can use Alliance Key Manager to revoke or deactivate a key so that it is no longer used for encryption requests. In certain cases the key can continue to be used to decrypt data previously encrypted with it, like old backups, but even that can be restricted. A revoked key can, if needed, be reactivated by an administrator, although this would be more an exception to the rule than common practice.

Key Deletion: If a key is no longer in use or if it has somehow been compromised, an administrator can choose to delete the key entirely from the key database of the encryption key manager. Alliance Key Manager will remove it and all its instances, or just certain instances, completely and make the recovery of that key impossible (other than through a backup). This is also an option if sensitive data is compromised in its encrypted state. If the key is deleted, the compromised data will be completely secure since it would be impossible to recreate the encryption key for that data.

To learn more about encryption key management, download our ebook, "Encryption Key Management Simplified.”

Secure system logging on the IBM i (AS/400) can not only help you meet compliance requirements, it can help you stop a data breach before it happens!  Intruders may start with a password hack that gives them access deeper into the system.  There is usually a long trail, visible within system logs. Everything from the original breach can be detected and identified with proper monitoring of the system logs.  What really is driving the need to collect and monitor system logs centers around how often breaches are easily detected with log management.  For example:

• Less than 1% of the breaches were discovered through active log analysis
• Forensics showed 69% of these breaches were detectable via log evidence

PCI Section 10 requires logging for anyone who collects credit card data

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

• 10.1 Establish a process for linking all access to system components (especially access done with administrative privileges such as root) to each individual user.
• 10.2 Implement automated audit trails for all system components to reconstruct the following events:
• 10.3 Record at least the following audit trail entries for all system components for each event:
• 10.4 Using time-synchronization technology, synchronize all critical system clocks and times
• 10.5 Secure audit trails so they cannot be altered.
• 10.6 Review logs for all system components at least daily.
• 10.7 Retain audit trail history for at least one year, with a minimum of three months immediately available for analysis.

GLBA / FFIEC recommends data security logs of actions that could affect financial reporting or fraud for financial institutions.

• Network and host activities typically are recorded on the host and sent across the network to a central logging facility.
• The logging facility may process the logging data into a common format. That process is called normalization. Normalized data frequently enables timely and effective log analysis.

(This Link provides more information about FFIEC recommendations for logging)

HIPAA / HITECH ACT requires system logs of access to Protected Health Information (PHI) in the medical sector

• LOG-IN MONITORING (A) - § 164.308(a)(5)(ii)©

…the covered entity must implement: “Procedures for monitoring log-in attempts and reporting discrepancies.”

• Access controls - § 164.312(b)

(section b) Standard: Audit controls. Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic PHI.

There are other compliance regulations and protocols that apply, but they all say about the same thing … you should be collecting system logs, you should be monitoring them, and you should take action based on anomalies that you find in them.  It is not enough to assert that you are doing the right thing; you have to be able to prove it with system logs that are independent from the original system files and verifiable.

System logging is important across all operating systems, but we are going to look at IBM i with greater detail due to it’s complexity.  Because the IBM i system can handle multiple applications, it doesn’t log information like others do.  The IBM i collects logs simultaneously from multiple sources and deal with large volumes: Up to 3,500 events per second…250 Million of events per day!  The essence of good reporting is externalizing the systems logs and collecting them in a central repository which helps remove the risk of tampering. Compliance regulations recognize the need to watch all users – including the most powerful users, because network originated threats to the IBM i are often not noticed or quickly responded to by IT security professionals without close monitoring of system logs.

Creating the QAUDJRN (Security Audit Journal) on the IBM i

QAUDJRN is not created or enabled by default on the IBM i platform.  If you have not set it up, you are not yet collecting system logs.  To implement system logging you create the journal and journal receiver, then set system values that control options about what information is collected. Once the values are set, the collection process begins.  QAUDJRN is non-modifiable and date-stamped and a large amount of useful information can be collected in each event.  However just running system log reports on the security audit journal are not enough. Centralizing events and monitoring them off the IBM i platform are crucial. The events need to be consolidated and correlated in a separate location (usually a SIEM Console) in order to see the whole picture and understand potential attacks on your system.  

Take Away:
If you are properly collecting and monitoring your system logs, you can detect a breach before data is lost.

To delve deeper into this topic, we are sharing this newly recorded webinar in which, security expert Patrick Townsend talks about system logging on the IBM i today and how the capabilities of Alliance LogAgent can provide you with a high performance, affordable solution that will communicate system logs securely between your IBM i and Security Information and Event Management (SIEM) Console.

As always, we welcome your questions and comments posted here!

Four steps to better encryption key management in the retail environment

When the PCI Security Standards Council released the Payment Application Data Security Standard (PA-DSS) in 2008, the security of payment applications took a big leap forward. Today, All retail ISVs providing payment applications must certify their products with PA-DSS (which requires encryption and encryption key management for applications that process credit card data). Merchants expect this level of certification in payment applications they use, and their customers expect personal information to be secured.

Yet time and time again we see news reports about retailers experiencing data breaches through their payment application software. These breaches tell us that PA-DSS certifications alone don’t always equal good security.  

Here are four steps you can take on the road to better security:

1 ) Be Aware of Security Issues

In the rush to meet PA-DSS requirements for credit card encryption, many payment applications incorporated just enough technology to pass the certification requirements around encryption of sensitive data, but not enough to stay current with encryption key management best practices.

Do your payment applications incorporate critical components of encryption key management including:

• Tested and certified encryption key generation techniques
• Physical and logical protection of data encryption keys (DEK)
• Protection of data encryption keys by key encryption keys (KEK)
• Proper management of the life-cycle of encryption keys
• Certification of key management solutions to international 
standards such as NIST, FIPS 140-2, and KMIP

2) Use Security Best Practices

In order to protect customers from data breaches and prepare for evolving compliance requirements, retail ISVs should strive to meet these encryption and key management best practices:

• Use Strong Encryption
  The Advanced Encryption Standard (AES) is the standard when it comes to data encryption. AES has been adopted as a standard by the US government and is the recommended encryption method for PCI, HIPAA/HITECH, GLBA and individual state privacy regulations.

• Use Key Management Best Practices
  Your encryption is only as good as how well you protect the encryption keys. Encryption keys should be secured away from the encrypted data using an external piece of hardware such as a hardware security module (HSM).

• Use Certified Solutions
  Always use NIST validated AES encryption and FIPS 140-2 certified encryption key management. These certifications ensure that their key management has been tested by a third-party against government standards and will stand up to scrutiny in the event of a breach.

3) Pick Your Partners Wisely

Townsend Security has redefined what it means to partner with a security company:

• With our NIST validated and FIPS 140-2 certified encryption and encryption key management solutions, retail ISVs can offer their customers easy, affordable, and powerful data security.
• Our dedicated team provides our partners with extensive training, back end support, marketing materials, and a cost effective licensing model. You focus on what you do best, and we’ll help you turn encryption and encryption key management into a revenue generating option to help build your business and protect your valued customers.
• We have more than 20 years of experience supplying encryption and key management solutions to over 3,000 companies worldwide.
• We help our customers achieve data privacy compliance at an affordable price and with a personalized touch.

4) Download the eBook “Overcoming Critical Security Issues”

This eBook resource is designed to give you the tools and information needed to have a high-level discussion about data security in your company. Click the button below to request your complimentary download!

In the world of encryption there are many different names for encryption, but probably the two most common would have to be AES and PGP. But not everyone knows what these acronyms stand for. In today’s world of TLAs (Three Letter Acronyms) it’s easy to feel left behind in a data security conversation when they start replacing every other word. OMG!

First we’ll break both of them down a bit and then we’ll compare them to each other.

AES, or Advanced Encryption Standard, as we know it today is the dreamchild of two cryptographers’ proposal of a symmetric key encryption algorithm based on the Rijndael cipher. This algorithm was developed when NIST (National Institute of Standards and Technology) sent the call out to the cryptographic community to develop a new standard. NIST spent five years evaluating fifteen competing designs for the AES project and in 2001 announced the cipher developed by the two Belgians Joan Daemen and Vincent Rijmen as the adopted standard, known as FIPS-197, for electronic data encryption.

AES is a symmetric key encryption algorithm, which essentially means that the same key is used for the encryption and decryption of the data. A computer program takes clear text and processes it through an encryption key and returns ciphertext. If the data needs to be decrypted, the program processes it again with the same key and is able to reproduce the clear text. This method required less computational resources for the program to complete its cipher process, which means lower performance impact. AES encryption is a good method to protect sensitive data stored in large databases.

There is, however, a time when AES will not be your go-to encryption process. When you need to share sensitive information with trading partners or transfer information across networks, using AES has one downside when it comes to security: You would have to share your encryption key with your trading partners. Sure, they’d be able to decrypt the information you sent them, but they would also be able to decrypt anything else encrypted with that key, and if the key itself became compromised anyone in possession of it could decrypt your data.

Enter PGP. PGP stands for Pretty Good Privacy, and before you get too distracted by the name, I can tell you it is actually much better than just pretty good. PGP uses symmetric and  asymmetric keys to encrypt data being transferred across networks. It was developed by the American computer scientist Phil Zimmerman, who made it available for non-commercial use for no charge in 1991. To encrypt data, PGP generates a symmetric key to encrypt data which is protected by the asymmetric key. 

Asymmetric encryption uses two different keys for the encryption and decryption processes of sensitive information. Both keys are derived from one another and created at the same time. They are divided into and referred to as a public and a private key, which makes up the key pair. Data is only encrypted with a public key and thus can only be decrypted with the matching private key. The encryption PGP offers is just as strong as that of AES, but it adds the additional security that prevents anyone with just the public key from being able to decrypt data that was previously encrypted with it. Another benefit of asymmetric encryption is that it allows for authentication. After you have exchanged public keys with your trading partners, the private keys can be used to digitally sign the encrypted content, allowing the decryptor to verify the authenticity of the sender.

PGP does require more computational resources, which is why it is usually not recommended for encrypting data in large databases where information needs to be accessed frequently, and each record that you access needs to be ran through a cryptographic process.

When you are considering which encryption to use for your sensitive information choose whichever will suit your needs best. AES is fast and works best in closed systems and large databases; PGP should be used when sharing information across an open network, but it can be slower and works better for individual files.