Townsend Security Data Privacy Blog

Great Q&A session from the latest webinar from Townsend Security!

As we discussed in the blog on Secure Managed File Transfer and PGP Encryption, using the core components of a total encryption strategy can help you meet compliance requirements, and improve your data security posture!

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: Is there any reason why I can’t just transfer my file from my IBM i platform to Windows and then PGP encrypt it there.

Patrick: That is a great compliance question.  Transferring unencrypted data from your IBM i to a Windows platform and then encrypting it and moving it from there will put you out of compliance for PCI DSS.  You should not transfer unprotected data to any system or across any network that’s not fully protected.  If you move it from the IBM i platform to Windows platform, it’s going to land in an unencrypted format and that will put you out of compliance.  That kind of unprotected transfer will also put you out of best practices alignment in terms of just pure security.  The security principle here that comes into play is always encrypt at the source, decrypt at the target or the destination, and don’t let the data be unprotected in-between.  Remember, data should never be moved “in the clear”.

Q: Can manage file transfer software be used on just one side, or do all sides of the transfer have to have the same software?

Patrick:  Partners/customers would certainly want a managed file transfer solution to be based on open standards.  You would not want to install proprietary software to process file transfers and then expect your partners to have to install it as well.  We base all of our secure transfer encryption components on open standards like a SSL FTP and Secure Shell sFTP and PGP encryption.  This means is that right out-of-the-box you will interoperate with all the major financial institutions and insurance agencies.  

Q: Does the Alliance FTP Manager solution run on the IBM i or Windows server?

Patrick:  Alliance FTP Manager is a fully native IBM i application.  It runs strictly on the IBM i platform and uses industry standard protocols. So there is no proprietary component on Alliance FTP Manager where you would have to distribute special software to someone who is receiving the files in order to process them.  We use industry standard pipeline encryption SSL FTP and Secure Shell sFTP.  No matter who you’re transferring data to, whether its Windows, Linux, UNIX ,or IBM Mainframe, there are multiple readily available solutions that support those secure file transfer protocols.  The commercial PGP that we provide is fully compatible with industry standards, it interoperates seamlessly, and we test it against multiple other PGP solutions as well as open PGP solutions.  Your customers and vendors (the people you’re transferring the data to) will appreciate that they do not need special software to process PGP encrypted files or your Alliance FTP Manager transfers.

Q: We occasionally need to create encrypted zip files to transfer files to our customers, can FTP manager do this?

Patrick:  We certainly do provide a command based zip file encryption and zip file decryption (compression and decompression) that implements 256-bit AES encryption.  It will process with wildcards and so if you have multiple files in an IFS directory you can compress all those into one zip archive.  Our directory scan automation component will automatically process data right into your application. So yes, there is an implementation of secure encrypted zip in FTP Manager.  

Q: A public/private key pair is needed for SSH and sFTP transfers. Does FTP Manager exchange keys with the destination server?

Patrick:  Secure Shell sFTP supports a number of authentication and privacy mechanisms, the most common is using a public and private key pair.  You do have to execute a key exchange with your training partner/bank before exchanging encrypted data. We have developed utilities and interactive options to help you load your trading partners public key on the IBM i platform.  For example, a menu option will allow you to put in the DNS name for that particular server, then it will find, retrieve, and install that key in your system.  Normally these steps are time and labor intensive, but we have automated the exchange to simplify that particular administrative setup function.
Very important: Typically sFTP transfers use public and private keys, just be sure that the solution you choose can also handle password authentication. Alliance FTP Manager CAN do that!

To learn more, view the complete webinar - Secure Managed File Transfer on the IBM I -which examines the security principles, compliance requirements, and technical challenges for secure FTP transfers on the IBM i platform with the following objectives:

• Automatically transfer files using Secure Shell sFTP or Secure SSL FTP
• Protect data using strong PGP encryption
• Review your total encryption strategy

If you have further questions, please list them here in the comment section and we will be sure to get you an answer!

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.

What exactly is data security and encryption & key management, and why care about it? 

Interesting conversation this morning as I walked from the parking lot to my office building.  Another person from one of the eight companies that occupy this building and I walked in together and chatted... first it was just “looks like the weather is getting better”... then it moved to “what floor are you on?  what company?” and when I told her ‘Townsend Security’, she said “oh, I’ve always wondered what you folks do”...

As the newest staff member, I wasn’t sure I had perfected my 30 second elevator pitch, but I told her that we were a data encryption company and design the software (and provide hardware) that almost everyone needs to protect themselves from a data breach. At first her response was “oh, we don’t need that, we have a guy that takes care of our computers”. Then we talked about how high the statistics are for people who would experience a data breach ("In 2010, if you received a data breach notification, your odds of being a fraud victim were one in nine. Last year, that jumped to one in four."), and after asking if they had a database and if they kept any records that held personally identifiable information (PII) or credit cards, it quickly became “I think we need that!”.

It reminded me that when I started working here, I wasn’t fully aware of many of the reasons or regulations that make data encryption so important.  I’m not sure I will ever have a complete technical understanding of all the nuances, but I’m working on it... Luckily I work with incredibly brilliant people who daily do all of the hard programming work and are very passionate about encryption.

I am lucky enough to be working with a company that I believe in, doing work that I know is important and can really make a difference in peoples lives. One of the main reasons I love this job... all the wonderful people that I work with, people so passionate about data security and the positive impact we can have on other people’s lives!

The founder, Patrick Townsend, impressed me so much at our last staff meeting when he reminded everyone to really think about why we are here, why we do what we do.  “It isn’t about selling a product.  It isn’t about the bottom line.  It is about protecting people from the devastation that a data breach can have on their individual lives.  It is about making sure we help companies protect their customers and clients.  It is about stopping the bad guys from wrecking havoc by making it impossible for them to get what they are after.  That is why we are here, remember that”.

Think about what your company does with the data you collect.  Is it encrypted and secure when it is “data at rest” (just sitting on your server)? How about when it is “data in motion” (being transferred to someone else)?  Look into what is happening with your information, and if you depend on someone else to take care of it, make sure they are doing it right.

Data gets out. Period. Either by accident or by design (someone hacking into your information). Make sure that when it does get out (and unfortunately it is “when”, not “if”) that it can’t be read.  You can make that data useless by encrypting it.   Remember to keep the encryption key stored in a different location than the data (encryption key management 101) because you wouldn’t lock up your house and then tape the key to the front door or leave it under the welcome mat!...  Would you?

If you aren’t sure what encryption or key management is all about.  We have a wonderful resource section on our website, and I’ve gathered a collection of some great Key Management resources right here.

Check out the information we have on data security and encryption key management and then contact us with questions, we are here to help!

What Standards for PCI Encryption You Need To Know and Why They Matter

Payment Card Industry - Data Security Standards (PCI-DSS) require you to encrypt credit card account numbers stored in your database and ensure data stays secure when transferred outside your company.

In order to understand these PCI encryption requirements, we first should know the source of industry best practices for encryption key management. Here in the US, the National Institute for Standards and Technology (NIST) is the most common source for guidance on best practices. The NIST special publication SP-800-57 provides specific pointers on how best practices for both procedurally managing encryption keys, and what to look for in key management systems. In these documents you will find the genesis of most standards regarding encryption key management, including the following concepts in PCI DSS 2.0 Section 3.  Next, it is important to understand the security best practices concepts of Dual Control, Separation of Duties, and Split Knowledge. I’ll simplify them here from the point of view of encryption key management:

1. Dual Control means that no one person alone should be able to manage your encryption keys. Creating, distributing, and defining access controls should require at least two individuals working together to accomplish the task.
    
2. Separation of Duties means that different people should control different aspects of your data protection strategy. This is the old adage “don’t put your eggs in one basket”. The person who creates and manages the keys should not have access to the data they protect. And, the person with access to protected data, should not be able to manage encryption keys.
    
3. Split Knowledge applies to the manual generation of encryption keys, or at any point where encryption keys are available in the clear. More than one person should be required to constitute or re-constitute a key in this situation.

In order to meet standards for PCI encryption, you need to make sure you protect these three things properly:

1. Protect your data at rest with AES Encryption
   Advanced Encryption Standard (AES) has been adopted as a format standard (FIPS -197) by the US government and many state and local agencies when it comes to encrypting data in a database. AES is the recommended encryption method for PCI-DSS, HIPAA/HITECH, GLBA/FFIEC and individual state privacy regulations. Encryption methods approved and certified by the National Institute of Standards and Technology (NIST) provide assurance that your data is secured to the highest standards.  
    
2. Protect your data in motion with PGP Encryption
   PGP encryption is the standard when it comes to encrypting files that need to be transferred.  Pretty Good Privacy (PGP) is the standard for encrypted file exchange among the world’s largest retail, finance, medical, industrial, and services companies.  Also know that when encrypting a file with PGP, you may be using AES encryption.  Transmit sensitive files over the internet using trusted encryption technologies. (AES, SSH, SSL, and PGP). Encryption solutions work together to ensure that all your sensitive data is secure even after the transmission is complete.  AES will protect data at rest within your organization and PGP keeps it secure when it is sent outside your company.
    
3. Protect your encryption keys and your data by keeping them apart!
   Leaving your encrypted data and keys in the same place is like leaving the key to your house under your welcome mat.  Security best practices require that you store encryption keys separately from your encrypted data and managed with an encryption key manager. It is also important to note that. In regards to the cloud, PCI SSC recently offered this guidance:
   In a public cloud environment, one Customer’s data is typically stored with data belonging to multiple other Customers. This makes a public cloud an attractive target for attackers, as the potential gain may be greater than that to be attained from attacking a number of organizations individually. Strong data-level encryption should be enforced on all sensitive or potentially sensitive data stored in a public cloud. Because compromise of a Provider could result in unauthorized access to multiple data stores, it is recommended that cryptographic keys used to encrypt/decrypt sensitive data be stored and managed independently from the cloud service where the data is located.

Download the whitepaper Meet the Challenges of PCI Compliance and learn more about protecting sensitive data to meet PCI compliance requirements.

At Townsend Security, we ensure our customers data is secured to the highest level for compliance. Our AES encryption solutions are NIST validated and our encryption key management solutions are FIPS 140-2 certified.  Our HSM appliances integrate seamlessly with Windows, Linux, UNIX, IBM Power Systems and Microsoft SQL Server 2008/2012 (enterprise edition) and can also work with earlier/non-enterprise editions of SQL Server.

As always, if you have comments or questions about PCI encryption, please list them here

In the world of PGP encryption, we often hear from users who tell us, “My trading partner says they need my private key for encryption. Is it ok to send it to them?” The simple answer to this question is no. Your private key is aptly named “private” because it should never be shared with others. The key intended for distribution is also aptly named as the “public” key.

The longer and more technical explanation of why you shouldn’t give out your private key is a little more confusing.

The PGP process requires that encryption be performed with a public key that your trading partner gives to you to use, if you are going to send encrypted data to them. You cannot encrypt the data with a private key. If your partner requires that the file be signed as a part of the process, then you will use your private key as a signature. In order to read that signature you must give your trading partner your matching public key to your private key. You should never give them your private key.

On the other hand, if someone wishes to send encrypted data to you, you must provide them with your public key in order for them to send you files. Your system should automatically recognize the key that was used to encrypt the file and will select the appropriate private key for the decryption process. You only need to provide the passphrase for the key to validate that you are authorized to the unencrypted data.

Here’s an example: XYZ Productions uses the services of ABC Personnel Services for payroll management. Each month YXZ sends payroll files to ABC for processing. Due to the confidential nature of the information in the file, XYZ and ABC have agreed to use PGP encryption to protect the data. Both companies export their public keys and send them to one another. As the originator of the file, XYZ uses the ABC public key to encrypt the file before sending it.  By doing so, the file can only be decrypted by the holder of the private key. XYZ then uses their private key to sign the file as a means of verifying the origin of the encrypted file. When the file is received by ABC, they validate the signature by comparing it to the XYC public key they have been given, then use their private key to decrypt the file for processing.

The safety of the confidential data in the example is protected because the encrypted files can only be read using the private key, which has never left the trust of the key generator.      

Remember, when exporting a key to send to a customer, one should always remember that the key type identifies if the key should be shared. Public keys are for sharing; whereas a private key should always be kept close to home.

Going Beyond Compliance Requirements with Encryption Key Management

If you are new at protecting data in Microsoft SQL Server environments, generally compliance regulations are what drive an encryption project.   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.  

To start us off, here are a few definitions and acronyms that may help:

• AES – Advanced Encryption Standard – this is the most common standards based encryption that is used to protect data whether that is in SQL Server or any other environment where data-at-rest is protected.
• EKM – Extensible Key Management – within the Microsoft SQL Server environment EKM is a part of the Enterprise edition 2008/2012 and higher
• HSM – Hardware Security Module – the Townsend Security HSM encryption key management product is Alliance Key Manager
• FIPS – Federal Information Processing Standard
• NIST – National Institute of Standards in Technology

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.  But 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.  (Akin to leaving the key to your house in the door lock and being surprised that someone has entered uninvited!)

Our solutions help Microsoft SQL Server customers really protect their data.  Alliance Key Manager, our encryption key management hardware security module (HSM), is FIPS 140-2 certiied.  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.

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! 

In October of this year, IBM will end support of V5R4 of IBM system i. This decision will force their customers running on V5R4 to upgrade to either V6R1 or V7R1. Many customers are currently in the process of or have already completed this upgrade. For IBM i administrators out there who have not yet begun this critical upgrade, it's important to know the differences between V6R1 and V7R1. The most notable difference is the new FIELDPROC capability offered exclusively in V7R1. Short for field procedure, FIELDPROC allows automatic, column level encryption in the DB2 database without any program changes.

Patrick Townsend, CEO and Founder of Townsend Security, recently sat down with data privacy expert Patrick Botz at this year's COMMON exposition to discuss FIELDPROC, encryption key management, and what these changes mean for retail merchants who must comply with PCI-DSS. Here is an excerpt from that discussion:

Patrick Townsend: Patrick Botz, can you tell us why encrypting sensitive data is more important than ever, and how FIELDPROC can help IBM i customers easily encrypt sensitive data and meet compliance regulations?

Patrick Botz: I think encryption is something that we're realizing everyone should have been doing a long time ago. Today many businesses are required or recommended to encrypt sensitive data by data security regulations such as PCI-DSS, HIPAA/HITECH, GLBA/FFIEC, and many state laws. This is evidence that encryption is extremely important today, not just from a security point of view, but from a compliance point of view. FIELDPROC is an excellent tool that IBM has added in V7R1 that makes it easier for ISVs to provide efficient and easy to use encryption without having to change programs. This is huge for customers. In fact, I've worked with at least two customer groups so far who's primarily reason for upgrading to V7R1 is to be able to use products that use FIELDPROC.

Townsend: Jumping from V5R4 to V7R1 is a supported path, right?

Botz: Right!

Townsend: Patrick, I know that you're company, Botz & Associates, does a lot to help IBM i customers with their security projects, can you describe a typical  encryption project and how FIELDPROC has saved them time, money and aggravation in terms of getting the project done?

Botz: Yes, there is a pattern these projects tend to follow. Before they embark on their encryption project, the first discussion I have with and IBM i customers is to answer questions such as, how many programs am I going to have to change and how long is it going to take because we can't afford to have our systems down. Then when we start talking about the different products that take full advantage of FIELDPROC, and how they won't have to change their programs to do encryption with FIELDPROC. Once we get to that point, customers are ready to jump in and they're excited! The next step is to discuss if they want to encrypt just the fields with personally identifiable information (PII) or the whole database. From that point on it's a pretty easy process to get data encrypted.

I see many IBM i customers trying to do their own encryption, and one of the things I say to people is, "Have you heard the phrase 'it's not rocket science'? Well, with encryption, to make sure you get it right, it approaches rocket science." The fact is that customers really need to pick a solution that handles not only the encryption, but the key management as well. In my opinion the most important part of encryption is key management. I like to use the analogy of using a padlock: If you buy the world's best padlock for your backyard shed and then you pound the nail on the shed right next to the padlock and hang the key there, is that best padlock doing you any good...

In case you missed the presentation by Patrick Townsend and Patrick Botz, we recorded their session and have made it available for online listening. Download the podcast "FIELDPROC Encryption on the IBM i" to learn more about:

-Encryption Key Management with FIELDPROC
-The importance of certifications
-And what QSA and compliance auditors will look for in your key management system

Patrick Botz is an internationally known information security expert, specializing in security as a business requirement first, and as technology second. His passion for SSO began while working at IBM which he joined in 1989. He held several positions at IBM, including  Lead Security Architect and founder of the IBM Lab Services security consulting practice. He architected the SSO solution for OS/400 and i5/OS, and he holds several security-oriented patents.

Today there are so many ways to lose control over sensitive data. Hackers are constantly trying to access networks, laptops get stolen out of cars, and unauthorized employees are given access to data that they were never meant to see. With so many ways to lose data, no wonder so many IT execs bury their heads in the sand at the idea of data security. It seems like there's nothing they can do.

Unfortunately for those people who ignore the pressing need for tighter data security (and are probably setting themselves up for a data breach), there is something they can do. They can encrypt their data, and they can use key management best practices to protect their encryption keys.

Encryption and key management are considered the highest standard in data protection, and are required or recommended by most industry regulations such as PCI-DSS, GLBA/FFIEC, FISMA, and HIPAA-HITECH Act.

But what exactly is encryption and why do you need key management?

I recently talked with data security expert Patrick Townsend, founder and CEO of Townsend Security, to find out. Watch the video of that discussion here.

What is encryption?

Encryption is a means of encoding data using an encryption algorithm to render data unreadable. AES encryption is a standard put forth by the National Institute of Standards and Technology (NIST). It is accepted as the strongest method to secure sensitive data. Encrypted data looks like gibberish. For example, an encrypted version of the name "John Doe" might look like "Ue%#KD#@". In order to read the gibberish, someone must have access to the encryption key, which unlocks the encrypted data to make it readable.

What is an Encryption Key?

When you encrypt data, an encryption "key" is created. Each encryption key is unique.  Encryption keys are the secret that must be protected. Encryption keys are a lot like the keys you use to lock your house. It's likely that you and several of your neighbors use the same kind of lock on your door, but each of you owns a unique key. Like a house lock, encryption uses the same algorithm to encrypt data, however in each instance, a unique key is created to unlock each piece of data. Losing your encryption key to a hacker is like losing your house key to a thief.

Hackers don't break encryption. They find the keys.

A lot of IT executives have dug themselves into a hole because they know they need encryption and key management, but they don't want to admit to their bosses that they've been ignoring the issue--and putting the company at risk--for years. It can be a very difficult subject to talk about, especially when budget has played a role in the decision making.

If you’re ready to begin having this discussion with your IT team, you should arm yourself with the right questions. We recommend you check out this video, “What is Encryption Key Management?” featuring Patrick Townsend, Founder & CEO of Townsend Security.

We’ve heard a lot of different excuses and reasons for a company to decide not to encrypt sensitive data — ”it’s not in our budget”, “a data breach won’t happen to us”, etc. For the companies out there who are taking responsibility to protect their customers’ sensitive information with encryption, we also often see these companies fall prey to a few common pitfalls that make their encryption strategy weak. A weak encryption strategy isn’t much better than having no encryption strategy at all. Here are the top 10 encryption pitfalls to avoid in order to implement strong encryption:

1. Failure to Asses Risk

We are still finding today a lot of organizations and companies that have not implemented any type of data protection at all. When we talk to a company taking credit cards and not encrypting that credit card information, we know that they've not properly done risk assessment on what it  means to fail a PCI-DSS audit or have a breach when you're not meeting PCI-DSS standards. The risks associated with a data breach not only include fines paid to the government, but also the cost of credit monitoring for your customers with compromised data, loss of trust from stakeholders, and damage to your brand name.

2. Encryption Key Management

Once you start an encryption project you’ll be faced with the one, core technical requirement: protecting the encryption keys. One of the biggest causes of audit failure for encryption is not adequately protecting those keys. Getting a secure, FIPS 140-2 compliant key management device in place to protect your encryption keys will help you avoid having to go back and re-do your encryption project using proper key management.

3. Client Side Support

Does your vendor supply you with all of the tools you need to implement encryption and key management? Choosing a vendor the provides poor client-side support can be a huge detriment to your encryption project. That is why it’s important to choose a vendor that will provide sample code and applications that snap into client-side environments to make your encryption project faster and easier.

4. Virtual and Cloud Environments

Today, security is the number one concern for companies migrating to the cloud. The principles of encryption and key management remain largely the same, but the question of how to manage keys for encrypted data in the cloud is still debated. Hosting encryption keys “in-house” is currently the most common model. Even if you’re managing your encrypted data in-house, be aware that you may choose to move to a virtual cloud environments in the future, and you will want to make sure that your encryption strategy and key management strategy can migrate with you to the cloud

5. NIST and FIPS Certifications

Industries that deal with sensitive client information such as credit card numbers, social security numbers, and private health information must adhere to regulations (some of them governmental) in order to protect individuals’ personal and sensitive information. These regulations follow recommendations by the National Institute of Standards and Technology (NIST). When protecting data at rest, you should be using Advanced Encryption Standard (AES) encryption, which is a standard put forth by NIST. You should also look for a key management device with FIPS 140-2 validation, also a NIST standard.

6. Performance - What are the Performance Impacts?

It’s possible to encounter serious performance impacts when you implement encryption. That’s why we not only recommend you use only AES and NIST certified solutions, but that if you’re the IT person dealing with the encryption, that you do some preliminary testing of the encryption on a sample database the same size as the actual database you will be encrypting. Your encryption and key management vendor should be able to help you do this with ease.

7. Ease of Use

An encryption and key management solution that is difficult to use can lead to a slowed project, unexpected costs, and delays. This can be a huge roadblock, especially if you are struggling to address a data protection problem or meet deadlines imposed by compliance regulations. To avoid ease-of-use problems, look for a solution with a GUI interface designed to run on your platform and allows you the necessary points of access to your encrypted data and encryption keys.

8. Data Leakage to Quality Assurance (QA) and Test Environments

Segmenting your critical data apart from non-critical data is an important step in preventing leakage of the critical data onto unprotected environments such as testing and development environments. Simple employee mistakes make up a large portion of data breaches that occur every year. Knowing which servers your sensitive data is located on and making sure that data doesn’t accidentally get moved to and unsecured location is critical.

9. System and Compliance Logging

Most compliance regulations including PCI-DSS recommend if not require some sort of system logging of your critical data. Whether it is file integrity monitoring or system logging to collect and store security events, these tools help you to catch changes to your database in real time. This is actually one of the most important parts of data security, and many data breaches can be immediately detected with system logging.

10. Budget Should Not Be a Barrier

When implementing encryption and key management, trying to save money by skipping steps will cause you a great deal of grief. Conversely, your encryption and key management vendor should be able to offer you a NIST certified,  scalable solution at an affordable price.

IBM i users have been reaping the benefits of IBM’s modernization efforts for some years now. The IBM i platform now has a number of new web and open source technologies including the PHP web development platform. With partner Zend Technologies, IBM has brought an industrial strength web development platform to the IBM i.

If you are using PHP on the IBM i, or if you are starting a new project with PHP, I would like to introduce you to NSC Software Solutions, Inc. headquartered in Brillion, Wisconsin. Started in 1981 by Larry Nies, NSC specializes in helping companies develop and deploy PHP web applications on the IBM i platform. They are specialists in PHP design and development, and create cross-platform PHP solutions for companies around the globe.

Web applications and data security? Yes, a big concern for companies of all sizes.

We turned to NSC for advice on how to help IBM i PHP customers do encryption and key management the right way. Wow, we got way more than advice!

Under the direction of Eric Nies, NSC created a professional PHP module to make it easy for IBM i customers to use our Alliance Key Manager for encryption key management in a PHP application. They also create a GUI application to make configuration easy to do.  So IBM i customers who need to meet PCI, HIPAA, GLBA, FISMA and other data security compliance regulations can now do this quickly and easily. For IBM i customers new to PHP, NSC can provide professional services to get that first project off the ground quickly.

If you are a PHP developer you might like to know that the NSC solution works well for both IBM’s DB2 database and for MySQL. The code that NSC developed for encryption key retrieval is a module that is easy to add to your PHP project. And applications can move from the IBM i platform to other platforms that support PHP.

Customers who develop PHP applications on the IBM i are also running legacy RPG and COBOL applications in the same environment. The same Alliance Key Manager appliance that protects data in the PHP environment can protect data in your legacy IBM i applications, and across the complete set of non-IBM technologies that you use including Microsoft SQL Server, Oracle Database, MySQL, and many other platforms.

PHP web application security? It’s a piece of cake - talk to NSC.

Disclaimer: We don't have any financial relationship with NSC Software Solutions, Inc.  They are just a great company that we think our readers should know about.

Patrick