I recently had a conversation with one of our customers about the automatic encryption webinar they attended.  The webinar demonstrated how companies can implement AES encryption on their AS/400 without making application changes. This customer currently has our managed file transfer solution, FTP Manager with PGP encryption, and was confused as to why they would need AES encryption if they were using PGP. I explained that PGP encryption protects data in motion - when it is transferred outside his company. If he was storing data on his AS/400, he would need AES encryption to protect his data at rest.

AES Encryption
AES encryption is the standard when it comes to encrypting data in a database. Advanced Encryption Standard (AES) has been adopted as a standard by the US government and many state and local agencies. AES is the recommended encryption method for PCI, HIPAA/HITECH, GLBA and individual state privacy regulations. AES encryption uses an encryption key to encrypt the data. Typically, this key is stored on the AS/400 and used when the data needs to be decrypted.  To side track here a little, this is not a good idea. Leaving your encrypted data and keys in the same place is like leaving the key to your house under your door mat. If you want to learn more about why this is a bad idea, take a look at this blog article on the topic.

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 financial, medical, industrial, and services companies. Also know that when encrypting a file with PGP, you may be using AES encryption.  

AES encryption and PGP encryption solutions work together to ensure that all your sensitive data is secure. AES will protect data at rest within your organization and PGP encryption keeps it secure when it is sent outside your company.

I hope this has been helpful in better understanding the differences and similarities of PGP encryption and AES encryption. Learn more about AES and PGP encryption with the webinar "Automatic Encryption on the IBM i" that spurred this conversation or the whitepaper "AES Encryption and Related Concepts". 
 

 

 

At Townsend, we have a lot of conversations with customers and prospects about data privacy, compliance requirements and best practices for IT security in general.  We have written numerous articles on these topics and posted them on our blog.  As the end of 2011 quickly approaches, we thought it would be worthwhile to list out our most read articles of the year.

Listed below are the top five read articles from the past year:

• AES Encryption Flaw - Calm Down
  
• PCI DSS 2.0 and Encryption Key Management
  
• Encryption and Key Management in a .NET World
  
• IBM i FIELDPROC Surprises
  
• RSA Encryption Key Size Requirements Change in 2011

We aren’t surprised that the articles on these topics; encryption, key management and PCI compliance are some of the most read on the blog.  We spend the majority of our days talking to people about these topics and helping them solve challenges around data privacy and compliance.  In fact, many of the conversations we have lead to new products and product enhancements.    

In 2012, we encourage you to talk to us about what you need and what you are doing at your company to protect sensitive data.  Subscribe to our blog, like us on Facebook, follow us on Twitter or join us on LinkedIn.

We hope you find the articles listed useful and that it inspires you to think of topics you would like us to write on for 2012. Thank you for your readership in 2011!

We are already preparing and looking forward to sharing more about data privacy in 2012.  

Happy Holidays!!

In V7R1 of the IBM i (iSeries, AS/400) operating system, IBM introduced support for automatic, column-level encryption in the DB2 database call FIELDPROC (short for “Field Procedure”). For customers who are familiar with other automatic database encryption implementations such as Microsoft SQL Server Extensible Key Management (EKM) and Oracle Transparent Data Encryption (TDE), the new DB2 database implementation can be confusing. The encryption implementation in DB2 is quite different from other vendor implementations. Here are a few highlights of those differences:

FIELDPROC is not encryption, it is an exit point. What IBM is providing with FIELDPROC is the opportunity for you, the customer, to implement encryption at the column level. You have to enable the option, provide the IBM i AES encryption software, and do the implementation yourself. This is different from SQL Server and Oracle TDE where the database does the encryption for you.

Operations are on encrypted data. In SQL Server and in Oracle, the database is decrypted and then the SQL operations take place on the plaintext values. Not so in DB2 FIELDPROC. The necessary information is first encrypted, and the operation takes place using the encrypted value. This can lead to some surprises if you are not careful about your approach to AES encryption and Initialization Vectors.

Decryption might not be called on a read operation.  Some IBM i customers are surprised that FIELDPROC may not be called when doing a “read equal” type of operation. In SQL this can happen in a SELECT clause with a WHERE statement. In the RPG language this can be a CHAIN operation with a key value. The DB2 database will call the FIELDPROC application to encrypt the search value, but not call the FIELDPROC application if the search is satisfied. That will defeat your attempt to do data masking on decryption!

Database joins need special care. Database joins take place on the encrypted values, not the decrypted values. This means that identical values in different tables need to have the same encrypted value. This runs counter to normal encryption thinking in database tables.

FIELDPROC applications are dynamic calls.  The FIELDPROC applications that you or your vendor creates are going to be called dynamically from the database engine. This means that when you develop the FIELDPROC application you have to take special care that they perform exceptionally well, and that your encryption library is optimized (see next item).

Not all AES encryption libraries are equal. There are big performance differences between AES encryption libraries and it can mean a really big difference to your FIELDPROC application performance. We’ve noted before that AES encryption library performance can vary by a factor of 116. That difference can mean a batch job that takes 10 hours or 10 minutes. Be careful!

For further information view our webinar "Automatic Encryption on IBM i V7R1" and learn how Automatic Encryption is now possible on IBM V7R1 with AES/400.

Patrick

For most organizations, the entire impetus to encrypt is closely tied to the need to be compliant with one regulation or another.  There is the PCI regulation, the HITECH act of 2009, HIPAA, Sarbanes-Oxley, and a whole host of state privacy laws.  If you are going through the due diligence of database encryption, you sure as heck want to get it right the first time.

A big part of getting it right is using the right encryption tool.  There are plenty of tools on the market that claim to do encryption, and you probably know a clever programmer or two who thinks he can come up with a nifty little data scrambling algorithm that no-one has ever seen before. But encryption — real encryption — demands that we reach for a higher standard.

The U.S. Department of Commerce publishes the definitive encryption standard on its National Institute of Standard and Technology (NIST) website and to date, hundreds of cryptographic providers have achieved this high standard.  As of this writing, NIST has certified over 1,300 AES encryption implementations.

A Fundamental Truth
Cryptographers do not suffer fools lightly.  Their science is mathematically based and their algorithms are well known and well vetted.  A fundamental truth of cryptography is that real encryption cannot rely on keeping the algorithm secret.  Instead the secret that protects the data is the encryption key, and only the encryption key.  Anyone who says different may find themselves on the receiving end of an extra-long mathematical dissertation on the mathematical correctness of accepted encryption algorithms.

When you stop to think about it, this makes perfect sense.  If the world used a secret algorithm to encrypt data, if that algorithm were ever to be discovered then all the world’s data would be at risk.  But if the key is the one-and-only secret that unlocks the data, then a compromised key only puts the data at risk that was encrypted with that particular key.  All the other data that has been encrypted with other keys is still safe.  This demonstrates both the wisdom of strong (and open) algorithms, but also the essential importance of strong key protection.

Another benefit of open algorithms is that they are peer reviewed and extremely well vetted.  The AES standard that is the de-facto standard for encrypting data at rest is well known in cryptography and mathematical circles and is recognized the world over as the most effective method for encrypting business data.  Its modes of encryption are well known and proven. And there is a strong body of knowledge about how to correctly implement the AES standard.  From the perspective of a cryptographic (encryption) provider, encryption libraries are not easy to write, but they are known to be solid when implemented according to accepted standards.

Homegrown Encryption
Unfortunately, some software providers seemed to have taken a different road. AES encryption must have seemed too difficult, or too cumbersome, so instead they found loopholes and/or shortcuts to simplify their implementation.  Some software providers use untested software, or unique and un-vetted methods of encryption.  These data scrambling methods aren’t (and never could be) NIST or FIPS certified, but if their customers never ask about certification or independent validation, those providers are not likely to raise the topic.

So we are seeing a raft of uncertified, and un-vetted cipher methods introduced in the market place.  Some, like OMAC, CS, and CWC have languished on the NIST list of “Proposed Modes” for years, while others like CUSP have never even been submitted as a proposed standard.  And while it is possible that one or more of these upstart modes could be better than one of the current, standard modes, there is no way to know this because these new modes have not been properly tested and crypto-analyzed.  Without testing and peer review, each of these modes is just another premature idea that is statistically more likely to be a bad encryption method than a good one.

Show Me the Cert!
Many software vendors are beginning to recognize the value of certifications.  Some claim certifications they don’t actually have (HINT: PCI does not certify encryption software) and some will use confusing language to infer they have achieved levels of certification they haven’t.  Recently I visited a website that claimed (I’m paraphrasing):

Our stuff uses FIPS 140-2 certified algorithms to ensure the highest level of data security.

The NIST AES website displays no record of this company ever having received a certification for any encryption software.  Clearly they recognize the value of certification, but have not yet knuckled down to do the hard work to make it so.  And if you don’t check their supposed “facts,” it’s likely that you’ll soon regret it.

My advice?  When someone claims to be certified for any type of encryption, ask a simple question: “Can you show me the cert?”  It ought to be available on the web, or in paper form that they can show to you so that you know this software has passed an independent evaluation.  If they have a cert, then you can dig down deeper and find out whether the software will fit your needs.  But if they are claiming a certification that they cannot prove, my advice is to keep your hand on your wallet and then run.

For more information on encryption and key management, download our white paper titled "AES Encryption and Related Concepts."

 

 

View Recorded Webcast: Automatic Encryption on IBM i View this webinar to learn how easy automatic encryption with FIELDPROC is on your IBM i. Click Here to View Now

Simplify your encryption project.  Encrypting data easily, automatically and securely on the IBM i is possible using the new encryption capabilities with V7R1 and AES/400. I recently sat down with Patrick Townsend, Founder and CEO of Townsend Security to ask, what are the five things customers need to know to help their organization automatically encrypt sensitive data on IBM i V7R1 with AES/400?  For even more information on automatic encryption on the IBM i, view our webcast below!

1.What is FIELDPROC?

In release V7R1 of the IBM i operating system IBM enabled it’s customers to implement automatic encryption using a new column-level API called FIELDPROC. FIELDPOC is an exit point that sits at the column level of the database and enable IBM i users to implement encryption and decryption without making any changes to their application source code.

2. We’re at V7R1, now what?

Upgrading your operating system is a start, however, IBM doesn’t provide the actual exit point software IBM i shops need to automatically encrypt and decrypt data - third party vendors and customers must do this.  Townsend Security’s AES/400 solution enables organizations to implement automatic encryption.

AES/400 and the FIELDPROC exit point in V7R1 give companies to easily encrypt sensistive data.  We call it automatic encryption, because it is the easiest, fastest and most secure way to encrypt data on the IBM i.

3. What types of data can be encrypted?

IBM i database applications use a variety of fields to store sensitive information. Encrypt fields that store data such as credit card numbers, SSN, birth dates, address, account numbers and other PII instantly without impacting applications.

Alliance AES/400 FIELDPROC support will protect any of the above mentioned fields without changing your database or your business applications. There is no need to reformat your database, or expand field sizes.

While most IBM i customers will use FIELDPROC encryption with legacy RPG and COBOL applications, FIELDPROC support also works with SQL applications, and Alliance AES/400 supports both program models concurrently. Your ILE and OPM applications will work well with FIELDPROC data protection. You do not have to have the source code for your application to implement Alliance AES/400.

4. Are there any security risks with automatic encryption using FIELDPROC?

Native IBM i object or user authorities will not protect encrypted data.  Automatic encryption and decryption works for all users and applications. Administrators cannot rely on native IBM i object or user authorities to control access to protected data, additional controls and policies must be put in place.

Data masking simplifies access control for security administrators.  It allows administrators to define which users and applications should have access to data and exclude users or applications that should not.  Security administrators can define users who should have access to the data, and define a default policy that masks the data for others

5. Will automatic encryption impact performance?

The IBM FIELDPROC exit point works by calling the exit program for each database insert, read, or update. The exit point program is also called on certain query and file positioning operations.  The right encryption solution can help minimize impact to system performance. Alliance AES/400 FIELDPROC support has been optimized for performance. The Alliance AES/400 encryption APIs are capable of encrypting 1 million credit card numbers in less than one CPU second. They are highly optimized for performance, and perform up to 100 times faster than equivalent IBM APIs on the IBM i platform. These same Alliance AES APIs are used for FIELDPROC encryption.

For more information on automatic encryption using FIELDPROC on the IBM i, view our webcast.

AES Encryption Performance: Avoid the High Cost of Poorly Performing Encryption Solutions

AES encryption has become the de facto standard for protecting data at rest in databases and unstructured data such as flat files, messages, EDI, and XML documents.  As enterprises deploy data security solutions to meet compliance requirements, they are frequently surprised by the performance impacts of encryption. Inadequate attention to encryption performance can lead to increased costs, delayed or failed projects, compliance failure, reduced flexibility to meet competitive challenges, and exposure to legal liability.

Whether you're evaluating an encryption solution or already encrypting data, these tips about encryption and performance will help ensure you have the right solution in place. 

Encryption - A Resource Hungry Application

By its very nature, encryption and decryption are resource intensive processes. Encrypting a simple credit card number requires many thousands of computer instructions. These instructions merge the input data with an encryption key using a large number of computer instructions to produce the secured data (called the “cipher text”). Because of the large number of computer instructions, an enterprise customer will experience increased utilization of computer resources and a need to consider adding additional capacity.

Ask for performance metrics

Armed with the knowledge that encryption performance is important, you can take action to avoid potential problems. Before acquiring an encryption solution, ask your data security vendor to provide performance metrics for their solution. How long does it take to encrypt one million credit card numbers? Can they provide you with source code and demonstrate this performance on your server?

The Hidden Costs of Encryption

Poorly performing encryption solutions can come with steep price tags as you secure more data in more places. You may have to add additional memory and increase the number of processors to handle the demands of encryption. As you upgrade your server hardware, the operating system vendor and application software vendors may increase the license fees they charge for their software. These cost increases may ripple through your backup and high availability systems. On top of increased hardware and software, your human resource costs also increase as you deploy larger and more powerful servers.

Are Network Encryption Devices a Good Idea?

Some security vendors provide encryption solutions on an external server as an encryption appliance. Each time your application needs to encrypt or decrypt data, a connection to the server is created and the data is transferred to the server for the encryption operation. Be sure to understand the maximum encryption rate of these types of appliances when doing a large number of operations. if it takes 5 milliseconds to transfer data to a server for encryption,
and 5 milliseconds to return the encrypted data, that 10 milliseconds can represent a performance problem.

Test Drive - not all AES encryption solutions are the same

Townsend Security's proven AES encryption solution encrypts data 94x times faster than the competition.   Request a free 30-day trial of our popular Alliance AES Encryption and see for yourself.

But don't just take our word for it, read what Staples has to say about their experience with our AES encpryption solution.

Case Study

A large multi-brand retailer, that sells its products online and in traditional retail outlets needed to meet PCI Data Security Standards for protecting customer credit card information. After evaluating several different vendors for performance they decided on AES Encryption from Townsend Security.  They deployed the Alliance AES/400 Encryption solution to protect sensitive data in DB2 database files and in a variety of unstructured data files and were able to achieve PCI compliance in record time.

Townsend Security Can Help

The best way to secure sensitive information is with strong encryption and key management. Townsend Security provides NIST validated encryption and logging solutions for the enterprise. Our encryption, key management, tokenization, and logging solutions protect sensitive data from loss, whether it is at rest or in motion.  With NIST validated and FIPS 140-2 compliant certified solutions, Townsend Security meets or exceeds the standards in PCI, HIPAA/HITECH, and state privacy laws.  Click here to download a free 30-day trial of our popular Alliance AES Encryption.

As compliance regulations start mandating encryption and key management, we are seeing more and more companies stepping up their data security policies.  One important thing to realize is, that just because you are implementing encryption, it doesn’t necessarily mean that you are doing it correctly and will meet regulations such as PCI DSS, HIPAA/HITECH, State Privacy Laws, etc.

We have compiled a list of the top ten encryption pitfalls that your enterprise needs to be aware of.

 

1) Encryption Key Management

Encryption requires a proper key management strategy. This means protecting and isolating encryption keys from the data that they protect. For most companies this means using a proper key management solution across all of their servers and applications.  Townsend Security offers Alliance Key Manager to help meet key management and compliance regulations.

 

2) Completeness and Compatibility

It’s not uncommon for some encryption solutions to only implement a partial specification of AES encryption. There are nine encryption modes (five for business data) that can be used with AES encryption. An incomplete solution that encrypts with one mode — such as CBC — will leave you unable to decrypt with another mode like ECB. This incompatibility makes transferring encrypted data from one server to another difficult or impossible.  Townsend Security’s Alliance AES Encryption is NIST-certified on all five modes for business data.

 

3) NIST Certification

As regulators refine the requirements for encryption and key management, the certification of products to NIST standards is more important. The recent 2009 HITECH Act makes specific reference to the NIST standards for encryption and key management. Many vendors of encryption solutions ignore NIST certification leaving their customers exposed to these evolving regulations.

 

4) Performance

The impact of encryption on servers and applications is often an unpleasant surprise as companies implement their data security plans. There are large differences in the performance of vendor solutions. The performance impact of encryption can delay or derail data security efforts.

 

5) Application Modifications

Implementing encryption at the database level often involves some application redesign and modification. This requires work by companies and their vendors. This work is often unplanned and unbudgeted, causing financial and human resource problems.  It is important to make sure your application modifications are minimal.

 

6) Quality Assurance and UAT Testing

When applications and databases are modified to implement encryption, there is a need to re-certify them for accuracy, reliability and performance. Many companies find this effort larger than the effort to implement encryption.

 

7) Data Leakage to QA and Test Environments

Every company that maintains business applications must keep a set of data available to the developer and user acceptance teams so that changes can be adequately tested. Often the data used in these test environments contains sensitive information. Good practice requires proper protection of this information using encryption, masking, or tokenization.

 

8) System and Compliance Logging

A common question asked by auditors is “How do you know who decrypted a credit card number?” Unless your encryption solution has integrated compliance logging, you may not know who is viewing sensitive data in your database systems. Compliance logging is often overlooked by vendors of encryption systems, leaving companies perplexed in the event of a data loss.  Townsend Security offers Alliance LogAgent for the IBM i or Syslog-ng as both an application or appliance.

 

9) Key Access Controls

Encryption and key management access controls are essential to an encryption strategy. Can you specify who has access to the HR encryption key for payroll processing? The ability to restrict the use of encryption to specific users and groups is an essential security control.

 

10) Virtual and Cloud Platforms

Encryption and Key Management in VM and Cloud environments pose special challenges. The PCI SSC virtualization group indicates that security concerns are much higher in these environments.  Currently there is no standard for implementing key management in the cloud environment.

In conclusion, there are many factors involved when choosing the right encryption and key management solution for your enterprise.  Additionally, once chosen, it is also important to make sure that it is implemented correctly.  For more reading on encryption and PCI, we have written a white paper titled Encryption Key Management Requirements for PCI.

Your Encryption Project Just Get Easier!!

Automatic database encryption is possible with IBM i V7R1 and AES/400

No one wakes up in the morning and says they want to encrypt their data, other than those of us at The Encryption Company.   We   love to help companies get started with encryption and we love to talk about it.  Those facts aside, much of the IT world views encryption as an onerous project and one they will avoid until an auditor says they have to meet a compliance requirement for PCI, HIPAA,  etc.

The good news for IBM i shops is that the latest release of the O/S, V7R1, just made it easier for them to embrace an encryption project, instead of avoiding it.  The most significant update in V7R1 is the introduction of the FIELDPROC exit point, which provides for an exit point at the column level of the database.  We were so excited about what FIELDPROC does for IBM i customers that we updated our AES encryption solution, AES/400 to support FIELDPROC. This enhancement enables future and current AES/400 customers to implement automatic database encryption on the IBM i.

AES/400 version 6.0 allows administrators to apply instant field (or column level) encryption routines without impacting applications.  Administrators can also enforce what users and what applications are allowed access to the protected data.  Rather than rely on native IBM object level security, which is often not implemented correctly, simply specify which user and which program has access and exclude all others.  That’s it!   Around the office we are calling it push button encryption because it really is that simple to implement encryption at the database level.

To paraphrase Staples (a long-standing Townsend Security customer), Automatic encryption – that was easy! 

Request a demonstration today and let us show you how your company can be encrypting and decrypting data in a matter of hours rather than weeks.

It's user group time and I am hitting the road!

This month I have agreed to speak to 5 IBM i user groups in a seven day swing that will start in Seattle and then take me across the heart of the midwest.  It starts Thursday, March 10th at lunch in Seattle (a place I have spoken a lot, as you can imagine) at the Pacific Midrange Systems Association, and ends at a dinner engagement on St Patrick's day in Chicago at the OMNI user group. In between, I'll stop in Toledo Ohio then move on to Michigan, visiting user groups in Southfield, Lansing, and Kalamazoo. To see a complete list of cities and times, follow this link.

The flag ship presentation on this tour is a new creation called "Automated Encryption with V7R1."  As you can imagine, we're pretty excited about the new automated encryption capability that IBM has put in DB2/400.  Townsend Security customers who use our AES/400 encryption solution will be able to select sensitive fields in their databases and turn on encryption with just a menu option.  Townsend Security's AES/400 encryption then works with DB2/400 to automatically encrypt, and (based on rules you can specify) automatically decrypt data on your IBM i.  If you have been contemplating encryption on the IBM i, your encryption project just got a whole lot easier.

So if you're in the neighborhood of any of these user groups, be sure to stop by and say hello.  We love to meet and talk with our customers and learn how they are using our software.

Do you belong to a user group in another part of the country?
Drop us a line to see these presentations at your next meeting. Patrick or myself would enjoy coming out to your group and showing you how cool automated encryption is.

 

John Earl

I just listened to a discussion of database security hosted by Oracle that was very well done. At one point the discussion turned to current threats and how the Enterprise has lost the ability to use perimeter protection for sensitive data. This has been a topic of much discussion in the security area for the last few months. Perimeter protection is based on the use of Firewall and similar technologies to keep the bad guys out, but this approach is failing with the advance of more sophisticated attacks, the use of social media by large organizations, the advance of mobile technologies, insider threats, and the migration of applications to cloud platforms. The trend is called “de-perimeterization” and represents a bit of a challenge to organizations that need to protect sensitive data.

Vipin Samir and Nishant Kaushik did a great job of describing the how the process of de-perimeterization has forced companies to fall back on user access controls to protect data. But user access controls are notoriously weak.  Weak passwords and sophisticated password cracking routines make it almost impossible to properly secure a database. So what is a security administrator to do?

Here are the suggestions from the panel that are a part of a defense-in-depth strategy:

Use Encryption to Protect Data:
Companies should use encryption at the database level or column level to protect data. This will secure data at rest on backup tapes and on disk in the event a drive is replaced. Encryption is an important part of the data protection strategy, but it needs to be combined with other techniques.

Use Good Key Management:
Protecting encryption keys is the most important part of the encryption strategy. Good key management techniques are needed, and the keys must be separated from the data they protect. Without this separation from protected data it is impossible to implement separation of duties and dual control – important parts of the key management strategy. See our Alliance Key Manager solution for more information about securing encryption keys.

Separation of Duties:
Because the threat from insiders is rising, it is important that the management of encryption keys be separate from the management of databases. Database administrators responsible for our relational databases should not have access to encryption key management, and security administrators should not manage databases. This is a core principal in data security regulations such as PCI DSS, but is often overlooked.

Context Sensitive Controls and Monitoring:
The last important step is to be sure that data access controls are sensitive to the data and its context. Bill in shipping has access to the order database, but should he really be decrypting the credit card number? Does your encryption solution detect and block this type of event? How will you monitor this security event? Or, Sally is authorized to view HR data from the accounting application, but should she really be using FTP to transfer this data? Normal encryption functions would not provide adequate protection from these types of data access. Context sensitive controls are needed to augment encryption.

When we started planning for automatic encryption in our Alliance AES/400 product two years ago, we took care to implement context sensitive controls right in the decryption APIs. That is now available in V7R1 of the IBM i operating system. We avoided the error of basing these controls on user account authorities and native OS security. Just because the operating system says you have read access rights to a database table, doesn’t mean you should be decrypting the social security number or using FTP to transfer the file. I’m happy with our implementation that is based on explicit authorization by a security administrator, and application white lists.

You can get more information and request an evaluation version of our Alliance AES/400 solution here.

You can find the Oracle presentation here. Look for “How secure is your Enterprise Application Data?”

Patrick