+1.800.357.1019

+1.800.357.1019

Feel free to call us toll free at +1.800.357.1019.

If you are in the area you can reach us at +1.360.359.4400.

Standard support
6:30am - 4:00pm PST, Monday - Friday, Free

Premium support
If you own Townsend Security 24x7 support and
have a production down issue outside normal
business hours, please call +1.800.349.0711
and the on-call person will be notified.

International customers, please dial +1.757.278.1926.

Townsend Security Data Privacy Blog

Saving Money with VMware vSAN Encryption

Posted by Patrick Townsend on Oct 16, 2019 7:30:02 AM

You may be using VMware’s vSAN technology and not even know it. vSAN is the core technology in most of the Hyper-Converged Infrastructure (HCI) solutions on the market today. If you are running VMware for your on-premise or cloud infrastructure, you have vSAN at your fingertips. So, how can you leverage vSAN to meet compliance regulations and save money? Let’s take a deeper dive.

First, why is it important to encrypt our data?

Encryption and Key Management for VMware - Definitive GuideAlmost all compliance regulations require that you protect the sensitive information of your customers, employees, and service providers. This includes the California Consumer Privacy Act (CCPA), the Health Insurance Portability and Accountability Act (HIPAA), the EU General Data Protection Regulation (GDPR), the New York Department of Financial Services act (23 NYCRR 500), the Gramm Leach Bliley Act (GLBA), and many, many others. As we now know a major data breach that loses unprotected sensitive data will have severe impacts on any organization whether public or private. Encryption is now a core requirement of any security strategy, so how do we get there?

Can’t I use the native encryption facility in my database?

Almost all commercial and open source databases provide a path to using encryption that is built right into the database. Unfortunately, getting access to the encryption feature usually means upgrading to the Enterprise version of the database—and this can be an expensive proposition. This is true of Microsoft SQL Server, Oracle Database, MySQL, and many others. Of course, an upgrade to the Enterprise version usually gets you a lot more capability than encryption. An upgrade brings a lot of additional value, but the reality is that a database upgrade is beyond the budget of many small to midsize companies. So what can you do?

How can vSAN encryption help?

Beginning with version 6.6, VMware vSAN provides for built-in encryption support and a link to vSphere for proper encryption key management. By default, vSAN virtual disks are not encrypted. However, it is really easy to configure a vSphere KMS Cluster, deploy a key management server (KMS), and turn on vSAN encryption. You don’t need to reload your vSAN virtual disks and it is fast to deploy. With very little time and effort you can achieve encryption at rest for your database and other files.

To enable vSAN encryption you only need a key management system that supports the OASIS standard Key Management Interoperability Protocol (KMIP). Our Alliance Key Manager fits the bill perfectly, and there are other solutions. You just deploy the key manager, grab the key manager certificate and private key, install them on your vCenter cluster, configure a KMS Cluster in vSphere, and enable encryption. Voila, you are done in a short period of time.

Do you know what else is cool? You can use the same KMS Cluster configuration to encrypt your VMs and to enable VMware vTPM in your virtual machines. That’s a lot of capability with very little time, effort and expense.

Is it risky to run my database in a vSAN volume?

The VMware vSAN facility is mature and now trusted by large and small Enterprises. As mentioned above, vSAN is a core component of almost all of the major Hyper-Converged Infrastructure (HCI) solutions. You may be using vSAN and not even be aware of it. There is also some good news—VMware has published a number of solution briefs and architecture guides to help you deploy Oracle Database, Microsoft SQL Server, and other databases directly on vSAN. Of course, you need to be aware of high availability requirements for both vSAN and for your KMS, but the existing vSAN documentation is quite good on this front. And deploying a high availability instance of our Alliance Key Manager solution is easy, too. More information here.

Today, you can confidently deploy your relational and NoSQL databases onto encrypted vSAN virtual disks safely and easily.

Saving money with vSAN encryption

We all live with constraints on our IT budget and our management team wants to see a good return on our IT investments. If you find that you don’t have the budget needed to upgrade your database for native encryption, deploying vSAN encryption is a great alternative. vSAN is a VMware facility that you already have and adding a key management solution is now very affordable. You can deploy our affordable Alliance Key Manager solution and avoid future upgrade and build-out costs. vSAN encryption and good key management is within the reach of every IT budget.

Ouch, I have vSAN but I don’t have a place to run a KMS

VMware vSAN is popular in many cloud and edge computing environments, but you might not be deploying VMs in that environment. Our key manager runs as a VMware virtual machine, so this can be a bit problematic in these environments. But there is an elegant solution to this—run the key manager in the cloud. For example, you can launch our Alliance Key Manager as an EC2 instance in AWS, or as a virtual machine in Azure, and use it to protect your vSAN volumes in edge environments. Alliance Key Manager works the same way in the cloud as it does as a VMware VM. And you can use one key management instance to serve multiple vSAN edge deployments. Problem solved!

Some precautions

There are some common sense precautions related to vSAN encryption. One is to be sure that you don’t deploy your KMS virtual machine onto a vSAN volume that it is protecting. If you have issues with the vSAN volume you don’t want it to impact the KMS, and vice versa. Also, as in all production environments where you deploy encryption and key management, be sure to deploy a failover key management server. It is easy to do with Alliance Key Manager and it will help you recover quickly and easily.

Alliance Key Manager for vSAN

Alliance Key Manager is certified by VMware for use with vSAN and vSphere encryption. All versions of vSAN and vSphere that support encryption are certified. In addition to VMware certification, Alliance Key Manager is validated to meet the PCI Data Security Standard (PCI-DSS), is KMIP compliant, and is FIPS 140-2 compliant. You can run Alliance Key Manager as a VMware virtual machine, as a cloud instance (Azure and AWS), in a Docker container, or as a hardware security module (HSM). No charge evaluations are available directly from the Townsend Security website, and we welcome partner inquiries. More information here.

New call-to-action

Topics: Encryption, VMware, vSAN

Encryption and Key Management - The SIX Mistakes that Startups and ISVs Make and How To Avoid Them

Posted by Patrick Townsend on Apr 18, 2019 1:27:59 PM

In our practice here at Townsend Security we engage with a lot of startups and mature ISVs who are trying to grow their business and customer base, leverage their technologies into new opportunities, and grow or migrate to the cloud. We know how difficult it is to start and grow a company, and what a wide set of business challenges have to be overcome. Our hats are off to every entrepreneur who has created a successful company, and every ISV who has kept it going!

Designing Applications with Encryption and Key ManagementI want to share a few thoughts on some pitfalls that can damage your ability to grow your company with a focus on the encryption of sensitive data. Too many promising companies flounder because of poor security implementations, and failing to get encryption right can lead to lost opportunities - maybe even the loss of that breakout sale you need to land a global company. Some early thought and planning about data security can help you weather your migration up the food chain and avoid such losses.

Number 1: Failure to encrypt sensitive data

The single biggest failure of data security is not doing it at all. Even in this age of massive public data breaches, and the damage that they do to companies of all sizes, most startups and ISVs are not implementing encryption of sensitive data. When product managers and developers work on their next big idea, they focus on exciting features in their product and often ignore the work it takes to implement encryption. They instead rely on access control lists and other mechanisms to protect data. These are, of course, important things to do. But the failure to encrypt sensitive data leaves a big hole in your security strategy.

What can go wrong if you haven’t implemented encryption? LOTS !!!

  • The publicity around a data breach can tarnish your reputation and kill opportunities.
  • The lack of encryption may cause compliance regulation failures making it impossible to enter new markets.
  • You may not be able to pass a security review of your software by that large global Enterprise.
  • You may not be able to enter government channels where encryption is a mandate.
  • If your customer experiences a data breach you may encounter substantial litigation costs that damage your financial resources and delay critical development.
  • You may fail to secure that next round of funding when an investor discovers the security gaps in your product.

When these kinds of events damage your ability to grow your company, it can be hard to mitigate them in a timely fashion. And you often won’t know about these dangers until you get fairly far down the road with your business plan.

Number 2: Failure to get key management right

For startups and ISVs who DO understand the need for encryption of sensitive data, the next biggest pitfall is the failure to protect encryption keys properly. Almost every database that supports encryption also supports the ability to protect the database encryption keys with a key manager. But that doesn’t mean that good key management is the default! In most cases the default database key management option is to store the encryption keys on the same server as the sensitive data. Sometimes the database will even store the encryption key locally and in the clear! So getting encryption key management right is critical to your security strategy. It won’t help to have encryption of your data enabled, and then have a cybercriminal steal your data along with the encryption key.

Related to key management here are some things to look for when you consider databases for your application:

  • Does your database have built-in encryption? Relying on third-party encryption solutions at the file/folder level will certainly cause deployment and scalability problems.
  • Does your database support integration with third-party key managers? If there is no easy way to integrate proper key management into the database, this will also cause deployment and technology delays.
  • Does your database support open standards for key management? For example, the Key Management Interoperability Protocol (KMIP) defines how applications like databases can easily integrate a key manager.
  • Does your database support key management failover? Remember that protecting encryption keys with a key manager also brings along the question of high availability and failover.

HINT:

If you are a startup be sure to choose a database that supports built-in encryption and proper key management. You have lots of good choices in both commercial and open source solutions. So go with a database with native, built-in encryption and key management!

Number 3: Failure to get FIPS 140-2 right

There are important standards and certifications for key management solutions. The most important of these is the National Institute of Standards and Technology’s (NIST) FIPS 140-2 standard. In addition to being a published standard, there is also a validation process for key management systems. The standard, and the validation to that standard, are critically important to your data security strategy. All professional key management solutions have been validated to the FIPS 140-2 standard and you should be sure to deploy a validated key management solution. This will help you avoid failing a security audit by that important new customer!

In addition to ensuring that your key manager is validated to FIPS 140-2, be sure that the entire key management solution is validated. There are many cases where the encryption library alone is validated to FIPS 140-2, but the key management application is not. It is good to have validated encryption, but that is just the start! Encryption key management has its own validation points and you will need both.

Snake Oil Alert !!!

Unfortunately, there are some key management solutions that make unwarranted claims about FIPS 140-2 compliance and validation. Here are a few warning signs to look for when you evaluate a key management solution:

  • A vendor makes compliance claims, but there is no validation. Some vendors claim to be “FIPS 140-2 compliant” but in fact have never completed a FIPS 140-2 validation. Security is hard, and unsubstantiated claims should be a red flag.
  • A vendor claims FIPS 140-2 compliance, but the validation is “in process”, but not complete. A security product can be “in process” for many months or even years. A claim of FIPS 140-2 compliance without actual completion should also be a red flag.
  • A vendor makes some claims of FIPS 140-2 validation, but research shows that the key management solution was not validated by that vendor.
  • A vendor makes a claim of FIPS 140-2 compliance, but the solution is only compliant when backed by a third party validated key management solution. In this case the vendor solution itself is not validated, but relies on the validation of another solution. You may be fooled into thinking that the solution itself is compliant when it is not. Especially watch for this pitfall with open source solutions.

You can always check a vendor’s claims of FIPS 140-2 compliance. Ask for the NIST FIPS 140-2 certificate number, and then Google it. NIST makes the validation certificate available to the public on their website. Copy and paste this into Google search:

NIST FIPS 140-2 certificate number 1449

That was easy!

Number 4:  Failure to make encryption and key management easy and invisible

Now that you are on the road to getting encryption and key management right, it is important to also make it easy and invisible. Your customers have a lot on their agendas, and becoming a key management expert is probably not one of them. So even if you follow the above advice and implement encryption and key management, do your customers a favor and make key management easy. The best way to do this is to bundle a key management solution into your product, and make key management automatic. You can still enable the configuration of an external key management system (some customers will want this), but you can really make it easy for most of your customers if you automate the key management tasks.

Automating key management is a great competitive advantage! One of our partners in the archival and backup space implemented this strategy and make great competitive wins on this feature alone! Their message was simple:

“We have encryption and key management. It is FIPS 140-2 validated. It is completely automatic so you don’t have to spend time fiddling around with a complex key management system.”

This strategy won them a lot of competitive deals and it was easy to talk about - and it shortened the sales cycle.  Of course, be sure that your key management solution supports this type of integration and automation!

Number 5:  Failure to segment customer data

As you move to the cloud and create shared, multi-tenant SaaS solutions, be sure to plan for and architect data segmentation into your solution. You will encounter large customers who will not want to have their data in the same space as other customers. They will want the additional security of segmenting their data into a virtual private cloud. With planning, your technical team can meet this kind of requirement, and help you close that very large deal.

Of course, a data segmentation plan requires a key management segmentation plan. For the same reasons customers want to segment their data, they don’t want to share key management with other customers. And they want to maintain full control of the key management implementation. So be sure to plan for customer-specific deployments of encryption key management and failover key management servers. A properly implemented data and key management segmentation plan will even allow for on-premise deployments that are “cloud ready.”

Number 6:  Failure to develop new market opportunities

Think about Amazon (the company) for a moment. At one point in their history they were an online bookstore. Today the company is very different. Amazon first leveraged its technologies to sell all kinds of products, and then created Amazon Web Services (AWS) to enable all of us to benefit from cloud technologies.

Are you thinking like Amazon? If not, you might be missing some big opportunities. Now that you have secure applications, are there lateral opportunities or technology licensing opportunities available to you? When you approach new opportunities and partners, don’t be afraid to talk about security. Regardless of what you’ve heard:

SECURITY SELLS!

Developing Applications with Encryption & Key Management

Topics: Encryption, Encryption Key Management, ISV, Partner

RSA vs AES Encryption - A Primer

Posted by Patrick Townsend on Mar 25, 2019 8:10:41 AM

If you are new to encryption you might be asking yourself, "what is the difference between RSA encryption and AES encryption, and when should you use them?" It’s a great newbie question, so let’s go exploring.

eBook: Definitive Guide to Encryption Key ManagementAES stands for Advanced Encryption Standard and is in wide use around the world. It falls into a class of encryption methods called “symmetric” encryption. That is, the same secret (an encryption key) is used to encrypt the data, and also used to decrypt the data. AES encryption is probably the most widely used encryption method for protecting data at rest. You will find it used in self-encrypting disk drives, database encryption, storage encryption, and so forth. It’s been around since about 2002, and it is an international standard. Roughly speaking, when you encrypt with AES you put data and the secret encryption key into software that implements AES encryption, and out comes the encrypted data. When you want to use that data you put the encrypted data and the same encryption key into the software, and out comes the original data that you can use.

There are other symmetric key encryption algorithms, and we’ll discuss that a bit below.

RSA encryption is named after the three inventors of the encryption method: Ron Rivest, Adi Shamir, and Leonard Adleman. RSA falls into a class of encryption methods called “asymmetric” encryption. The name asymmetric follows from the fact that there are two related secrets, or keys, used for encryption. One is called a public key, and the other is called a private key. The keys are related in the sense that if you encrypt with the public key, you can only decrypt with the related private key. And the reverse is true, too - If you encrypt with the private key, you can only decrypt with the associated public key. The math is pretty amazing and involves very large prime numbers and factorization. RSA keys are usually used when you have two physically separate endpoints. RSA encryption is often used in web browsers to connect to your favorite websites, in VPN connections, and in many other applications. We use asymmetric encryption every day.

There are other asymmetric encryption algorithms, and we’ll mention a few later.

So, when do we use AES encryption?

AES encryption is great when we have a constrained environment. For example, if we encrypt data in a database, we will decrypt data when we need to access the database. Another example is hard drive encryption - we encrypt the data written to the disk, and decrypt it when we read from the disk. Encryption and decryption will take place on the same platform and in the same context. AES encryption is great for this particular use case. That is why it is commonly used for protecting data at rest.

When do we use RSA encryption?

RSA encryption is really great when we have two physically or geographically different end-points. If I am encrypting data in San Francisco, and you are decrypting it in Dubai, I am likely to use RSA encryption because it is ideal for two separate end-points. I can encrypt data with an RSA public key at the originating end-point, send it over an unsecure web connection, and decrypt it with the RSA private key at the destination end-point, and not worry about who might intercept it in the middle. The unique public / private key aspects of asymmetric encryption helps us be secure when we are separated by many miles of insecurity and hostile internet territory.

Performance and how this affects the use of RSA encryption

RSA encryption is great for protecting the transfer of data across geographic boundaries. But we have a bit of a problem with RSA encryption - it is really poor from a performance perspective. I might want to send you my sensitive file, but encrypting that with RSA is going to be difficult due to the low performance of RSA encryption. No problem! You can combine RSA encryption with AES symmetric encryption to achieve the security of RSA with the performance of AES. This is normally done by generating a temporary, or session, AES key and protecting it with RSA encryption.

Other symmetric algorithms

AES is not the only symmetric encryption method. The older, and still standard, Triple DES (Data Encryption Standard) method is still in wide use. Triple DES is an accepted standard even though it is older than AES. However, for any new applications you should avoid the use of TDES (also called TDEA) encryption and it is likely to be deprecated as a standard soon.  Other encryption algorithms exist, such as Two Fish, Blow Fish, Ghost, and others. While they may be good encryption algorithms, they have not achieved the status of accepted standards, and so you should avoid them.

Other asymmetric algorithms

RSA is the granddaddy of asymmetric algorithms. But is is not the only accepted standard for asymmetric encryption. Elliptic Curve Cryptography (ECC) is also in wide use (usually combined with a symmetric algorithm) and is an accepted standard for asymmetric encryption. It performs better than RSA, but still lags AES in terms of performance. You should feel comfortable using ECC for asymmetric encryption needs.

AES encryption and modes of encryption

While AES encryption is the most commonly adopted encryption method, you should be aware that there are multiple modes of operation that can be used with AES. These are also specified in the standards. The raw AES mode of operation is called Electronic Code Book, or ECB. Because raw AES in ECB mode can leak pattern information when encrypting large amounts of data, it is common to use a mode of encryption that incorporates an initialization vector. The Cipher Block Chaining (CBC) mode of AES encryption is very common, as is Counter (CTR) mode. For storage devices it is common to find the XTS mode of encryption used. If data corruption is of concern, you might find the Galois Counter Mode (GCM) in use.

The evolving world of encryption

The world of encryption is always evolving. Cryptographers are working on new algorithms and improvements to existing algorithms to meet the challenges of high performance computing and quantum computing. It is an exciting time for cryptography and encryption key management. For now, you should always stick to published standards like AES, RSA and others mentioned here. Doing so brings the benefits of a consensus among a world-wide group of cryptographers, and keeps you in alignment with many compliance regulations.

Please let me know if you have any questions.

Patrick

eBook: Definitive Guide to Encryption Key Management

Topics: Encryption

Protecting Data with vSphere & vSAN Encryption

Posted by Luke Probasco on Sep 28, 2018 2:35:36 PM

VMware allows customers to use native vSphere and vSAN encryption to protect VMware images and digital assets.  But as we know, to truly protect private data, encryption keys must also be properly stored and managed. I recently sat down with Patrick Townsend, Founder and CEO of Townsend Security, to talk about vSphere and vSAN encryption, deploying multiple, redundant key servers as a part of the KMS Cluster configuration for maximum resilience and high availability, as well as meeting compliance regulations and security best practices for your organization.  Additionally, we talked about Alliance Key Manager for VMware and how it is helping businesses protect their sensitive data.

Podcast: Protecting Data with vSphere & vSAN EncryptionVMware virtualization has been a game-changing technology for IT, providing efficiencies and capabilities that have previously been impossible for organizations constrained within a traditional IT data center world.

It is really great to see VMware, as a company, stepping up to embrace encryption for vSphere and vSAN.  Introduced in vSphere 6.5 and vSAN version 6.6, encryption allows users to protect data at rest. Additionally, there is a really great key management interface, which provides an excellent path to store and manage keys.  While these versions have been out for a while, many customers are just now getting around to upgrading and can take advantage of VMware's native encryption. With VMware, organizations are able to reduce hardware costs, lower operational cost, and provides a clear a path to move to the cloud. With the addition of encryption, you can deploy secure environments where there is less risk of data loss in the event of a breach.

Let’s dive in a little more and talk about vSphere and vSAN encryption.  Can you walk me through how an organization might deploy encryption and key management?

Sure. I think in a typical VMware environment, organizations are already doing some encryption in their applications.  For example, they may be running Microsoft SQL Server in a VM and using Transparent Data Encryption (TDE) to protect the data.  With the new facilities, you now get the ability to encrypt right in the VMware infrastructure itself. There is one thing that I think VMware did really well, and they have proven this over and over again, is that they have laid out a certification process for key management vendors, which gives VMware customers confidence that they are purchasing and deploying a solution that has been vetted by VMware themselves.  Our Alliance Key Manager, for example, has been certified for vSphere and vSAN encryption.

In terms of deploying key management, it is easy. We recommend using both a production key server and a failover key server. vSphere supports KMS cluster configurations which allow you to have a resilient encryption and key management architecture.  Aside from just being a security best practice, we are seeing our customers deploy two servers because they never want to lose access to their encrypted data. The servers synchronize in real-time and have automatic failover capabilities.

You can’t talk about key management without talking about compliance.  Whether it is PCI DSS, GDPR, or state and federal privacy laws, who doesn’t fall under compliance these days?

Yes, good question.  That is probably a very short list these days.  When you look at all the existing compliance regulations around the world, including the new GDPR, you realize that everyone falls under some compliance regulation, and most of us fall under multiple regulations.  Enterprises, big and small, public and private, fall under the same compliance regulations. Additionally, I have heard more from privately held companies that they think they are exempt - which is not true.

So you are correct.  Compliance regulations are driving a lot of uptake in encryption and I would say that lately GDPR is driving the most interest.  If you look at Article 32 and related recitals, the requirement to protect a data subjects information, there is a clear call for encryption. GDPR has put a new focus on the need to protect private data, as well as to take a broad view at what should be considered sensitive data.  It is not just a credit card number or social security number. Information like a phone number or email address can be considered sensitive data.

How is your Alliance Key Manager helping VMware users protect their private data?

Well, we have been helping VMware customers for a number of years  who are encrypting at the application level. Our Alliance Key Manager for VMware runs as a virtual software appliance and is binarily the same as our hardware security module (HSM). What is new, is that VMware opened the vSphere and vSAN and products to support encryption key management. Now VMware users can leverage the same key management solution for both application and VMware infrastructure encryption.

People often ask us, “How is your key manager different than your competitors”?  One thing that makes us stand out is that we are very diligent about meeting compliance requirements (PCI DSS, GDPR, HIPAA, etc.) and industry standards (FIPS 140-2, KMIP, etc.). Years ago, when we partnered with VMware, one of the first things we did was work with VMware and a QSA auditor to achieve a PCI compliance statement.  Customers can now be assured that when they deploy our Alliance Key Manager in VMware that they are meeting PCI compliance.

What else do VMware customers need to know about Alliance Key Manager for VMware?

Alliance Key Manager is a mature product that has been on the market for more than 10 years. It uses the same software that runs inside our Hardware Security Module (HSM), so customers can be confident that they are running exactly the same key management software that is FIPS 140-2 compliant and in use by over 3,000 customers worldwide.  Additionally, the security posture that the key manager allows, as well as the reference architecture that VMware provides, really gives VMware customers a road map to doing a secure installation.

The other thing that I think a lot of people might not realize is, that when they deploy Alliance Key Manager, they have our entire library of client side applications, SDKs, and sample code available to them.  For example, we have a Microsoft SQL Server TDE encryption component, support for MongoDB via KMIP, and sample SDKs for languages like Java, PHP, Python, etc. All of that comes along with the key manager and makes it easy to address security requirements.

Finally, I’d like to mention our partnership with VMware.  We are diligent about maintaining our certifications with Alliance Key Manager.  Doing this brings a level of confidence to the product for our customers. Prior to starting an encryption project they may be a little leery of key management because they have heard that it may be complicated.  That was true in the past. In fact, today it is actually extremely simple to deploy. Another barrier that we have knocked down is the scalability issue. Our solution works across multiple platforms - AWS, Azure, VMware or as an HSM.  They all talk to each other, and if one goes down, another will automatically fail over. That gives VMware customers the ability to be extremely flexible about how they deploy key management. It is not uncommon that our customers will deploy an application in the cloud, deploy a key manager in AWS, and then mirror those keys back to their on-premise VMware infrastructure. All of this is really straightforward and simple to deploy.

To hear this conversation in its entirety, download our podcast Protecting Data with vSphere & vSAN Encryption and hear Patrick Townsend further discuss protecting data in vSphere and vSAN with encryption and key management.

Evaluation: Alliance Key Manager for VMware

Topics: Encryption, VMware, vSphere, vSAN

IBM i FieldPROC Encryption, IBM Query, and Encrypted Indexes

Posted by Patrick Townsend on Jan 29, 2018 8:31:08 AM

The IBM i DB2 database team implemented column level encryption through Field Procedures (FieldProc) in release 7.1 of the IBM i operating system. It was a great step forward for those IBM i customers who need to encrypt sensitive data to meet compliance regulations and to improve overall security. With release 7.1 it was now possible to implement DB2 encryption without modifying user applications.

IBM i Encryption with FieldProcPrior to this enhancement to DB2 in release 7.1, implementing encryption could be a laborious process of modifying applications and performing extensive regression testing. This approach did not work well with some types of fields (date, time, etc.) and many IBM and third-party query utilities just did not work correctly. So the DB2 enhancement for Field Procedures was a great step forward.

While FieldProc worked well with native SQL applications in release 7.1, there were limitations for older RPG and COBOL applications, and many IBM query utilities did not work correctly with encrypted indexes. Many IBM i customers use IBM and third-party query programs for rapid development of reports and displays of data. Some customers that I’ve talked to have thousands of queries in their application mix, so limitations of IBM query with FieldProc represented an insurmountable challenge for many. When FieldProc was used to encrypt an index or key field, queries just would not work correctly and data was missing or out of order in reports and displays.

But there is some good news!

Starting with the 7.2 release of the IBM i operating system, many of the IBM query applications were updated to work with the native DB2 SQL Query Engine (SQE) by default. The SQL Query Engine has never had a problem with encrypted indexes. This means that the IBM query applications now work seamlessly with data that is encrypted with FieldProc in DB2. You can fully deploy column level encryption across multiple index columns with FieldProc, and your queries will work fine.

Many IBM i customers experimented with FieldProc in the first release in version 7.1 of the operating system and decided to take a pass. If you had that experience it is time to take another look at DB2 FieldProc encryption. The current version of the IBM i operating system is 7.3 and most IBM i customers have upgraded to this release. You now have good support for IBM queries, the SQL Query Engine, and DB2 FieldProc encryption.

While some challenges remain for older OPM and ILE RPG applications, we’ve been able to help a number of customers meet these challenges.

Encryption of data is a core part of a defense-in-depth strategy. We have to do a lot of things to protect our IBM i data, and one of those things is to encrypt the data at rest with industry standard encryption algorithms. DB2 Field Procedures provides the path to achieving this.

To read more about IBM i support for SQL Query Engine in query applications such as RUNQRY, OPNQRYF, and others, see this link.

Our Alliance AES/400 Encryption solution provides full support for DB2 Field Procedures, is easy to deploy, and affordable for every IBM i customer. 

For industry standard encryption key management you can deploy our Alliance Key Manager solution which is seamlessly integrated with DB2 Field Procedure encryption.

Patrick

IBM i Encryption with FieldProc

Topics: Encryption, IBM i, FIELDPROC

Why Encryption is Critical to FinTech

Posted by Luke Probasco on Jul 5, 2017 8:27:26 AM

FinTech is transforming the financial services industry. Everyone from banks and credit unions to insurance companies deal with huge amounts of private data on a daily basis - and the best way to secure it is with encryption. Not only are companies deploying encryption to meet compliance (PCI DSS, etc.), but also as a security best practice.

Why Encryption is Critical to FintechI recently sat down with Patrick Townsend, Founder and CEO, and discussed why encryption is critical to FinTech, meeting the various compliance requirements, as well as how Townsend Security is helping FinTech customers better secure their private data.

The financial world is rapidly changing. Innovations in technology are impacting payments, lending, insurance, and even compliance. Unfortunately, security often does not get as much attention as it should. Do you have any stories that you can share with our listeners about when security really wasn't thought all the way through?

Not only is security a consideration for new solutions coming to market, but it can also be a problem for businesses using legacy technology that was deployed many years ago. Encryption and data protection just were not on the top of anyone’s mind when the applications were built. I recently talked with a large global bank who is running a software package from a well known financial services software vendor and it DOES NOT implement security in the way that we think of it today. Encryption libraries didn’t even exist on some of these platforms when solutions were created, so we are left with applications without encryption, let alone proper key management. This is a ubiquitous problem across the financial services industry as a whole and has become a very big challenge.

Sometimes I wonder how secure our personal data would be if it weren’t for compliance regulations like PCI and GLBA. What are your thoughts on the impact of compliance and data security?

I think compliance follows threats and losses. When individuals suffer from cybercrime, they complain to their legislators and lawyers, and out of that come compliance regulations. For example, we are seeing new compliance regulations like those from the New York State Department Financial Services (NYDFS) requiring organizations to establish and maintain a “risk-based, holistic, and robust security program” that is designed to protect consumers’ private data.” Other compliance regulations like PCI DSS, GLBA, and not just regulations specific to the finance industry, have been created to protect individuals who may be cybercrime targets.

Financials organizations are responding to compliance regulations by further protecting data that they collect. They do it because they have to (to meet compliance requirements), but also because it is important to their brand and the trust that they have established with their customers. Today, no acquirer of FinTech would find it acceptable to have sensitive data not protected to industry standard encryption and security best practices.

The technologies around data protection are pretty straightforward. Encryption and key management are the fundamental compliance related controls required to protect non-public information (NPI) and personally identifiable information (PII) in financial services environments. Encryption can be deployed at the application or database level and allow organizations to provably meet compliance requirements for protecting data – both on premises and in the cloud.

What advice do you have when it comes to selecting and evaluating a FinTech vendor?

Security and compliance have to be top of mind. Businesses need to make sure that their FinTech is secure and that if it handles sensitive data, that it is protected with encryption and key management. Security needs to become an internal governance issue to be sure that solutions that are acquired and deployed or upgraded truly and provably meet compliance and industry standards.

Townsend Security is helping these organizations with Alliance Key Manager, our centralized encryption key management solution. We believe in compliance and standards and our key manager is FIPS 140-2 compliant, in use by over 3,000 customers worldwide, and is available as a hardware security module (HSM) or as a software appliance in VMware or the Cloud (AWS and Azure). Additionally, Alliance Key Manager has been validated to meet PCI DSS in VMware, giving businesses in the financial services industry a “compliance out of the box” solution.

To hear this interview in it’s entirety, download our podcast “Why Encryption is Critical to FinTech” and hear Patrick Townsend, founder and CEO of Townsend Security, further discuss encryption, key management, and meeting compliance requirements specific to financial services.

Why En

Topics: Encryption, FinTech

Trying to Outfox the Other - A Brief Look at Cryptography and Cryptanalysis

Posted by Ken Mafli on Mar 31, 2017 10:35:55 AM

 A few months ago I wrote a definitive guide to Cryptographic Key Management. In it I wrote a section: A Brief History - the Need for Encryption Key Management. I wanted to expand upon the Classical Era of cryptography a bit because the story of data security goes back for millennia, and the twists and turns of this story can be felt even today.

Introduction

eBook: Definitive Guide to Encryption Key ManagementThere has been a competition playing out through the centuries all the way from the highest corridors of power down to the shadiest back alleys. It is a struggle of those with a secret and those who want to uncover it. It is the story of cryptography and cryptanalysis.

As with every competition, each side is constantly trying to outfox the other. Peter Baofu described the competition this way, it is “the never ending cycle of replacing old broken designs” of cryptography and “new cryptanalytic techniques invented to crack the improved schemes.” In fact, “in order to create secure cryptography, you have to design against [all] possible cryptanalysis.” This means that both sides are in a never-ending arms race.

In his book, “The Future of Post-Human Mass Media,” Peter Baofu describes two main types of cryptanalysis: Classical and Modern Cryptanalysis. Let’s take a look at the Classical Period to see how this cat and mouse game has played out through the centuries:

The Classical Cat-and-Mouse Game

Classical Cryptography

One of the earliest forms of “secret writing” is the Substitution Cipher where each letter of the message is systematically replaced by another set of predetermined letters. In it’s most famous form, the Caesar Cipher, used by Julius Caesar himself (1st century, B.C.E):

“each letter in the plaintext is 'shifted' a certain number of places down the alphabet. For example, with a shift of 1, A would be replaced by B, B would become C, and so on.”

Another technique was Steganography, which literally means: “covered writing,” is the art of concealing a message in plain sight. Mehdi Khosrowpour recounts one of the first recorded instances (in the 5th century, B.C.E):

“Demaratus, a Greek who lived in Persia, smuggled a secret message to Sparta under the cover of wax.” It “ was to warn Sparta that Xerxes, the King of Persia, was planning an invasion ... by using his great naval fleet. He knew it would be very difficult to send the message to Sparta without it being intercepted. Hence, he came up with the idea of using a wax tablet to hide the secret message. In order to hide the secret message, he removed all the wax from the tablet, leaving only the wood underneath. He then wrote the secret message into the wood and recovered the tablet with the wax.”

Classical Cryptanalytic Response

While steganography is only hard to crack if you don’t uncover the message; substitution ciphers were meant to remain a secret even if the message fell into enemy hands. It remained a fairly reliable means of securing messages, so long as the cipher was not revealed.

All that changed with the first recorded technique of cryptanalysis: Frequency Analysis. This technique “can be traced back to the 9th-century [C.E.], when the Arabian polymath Abu Yusef Yaqub ibn Ishaq Al-Kindi (also known as ‘Alkindus’ in Europe), proposed in A Manuscript on Deciphering Cryptographic Messages.” It comes from the observation that certain letters appear more often than others in a given language (the letter “E,” for example, occurs most often in English). There also also common letter pairings (like “TH” in English).

So, in the case of the Caesar Cipher where the plaintext message is :

meet me at the theater

If each letter is shifted one letter in alphabet, it becomes:

nffu nf bu uif uifbufs

Frequency analysis would note that the most common letter in the ciphertext is “f” (which would suggest it is an “e”) and only letter pairing is “ui” (which would suggest the “u” is “t” and the “i” is “h”). If we replace these portions of the ciphertext we reveal:

_eet _e _t the the_te_

With these two facts of frequency analysis alone we have more than half the message deciphered. With a few logical leaps we could decipher the remaining the five letters. The simple substitution cipher was rendered useless.

The Classical Cryptography Counterattack

Polyalphabetic.jpg

Over the centuries other ciphers were introduced like the Polyalphabetic Substitution Cipher where a repeating, offset key is used to encrypt the plaintext (see picture, courtesy of the Library of Congress). First perfected by Johannes Trithemius in 1518 (although other variants existed beforehand), the person encoding the message would switch alphabets for each letter of the message.

So, “meet me” would now become: “lcbp gy,” a ciphertext that simple frequency analysis could not break since most of the letter and pairing statistics of a given language are not easily recognized.

Although, in time, this type of cryptography was broken by the likes of Charles Babbage using modular arithmetic, the existence of his cryptanalytic techniques remained a military secret for some years.

Final Thoughts

Fascinatingly, it was the use of math to break a cipher that led to our current arms race in data security. The use of math and algorithms to break cryptography means you need longer keys to encrypt the data and prevent a brute force attack; which, in turn, means you need faster computers to break the encryption; which, in turn, means you need longer keys; etc.

Unlike today, however, it took centuries to break a cipher back then. Now, it is just decades. From the Hebern Electric Super Code Cipher Machine in the 1920s, to the Enigma Machine of the 1930s and 40s, to the Data Encryption Standard (DES) of the 1970s and 80s, each seemed invincible until enhanced cryptanalytic techniques or greater computing power toppled it. Our current cryptography is reliable and secure, but quantum computers loom on the near horizon and their non-binary logic could brute force attack our current public key cryptography and make them insecure.

And so the arms race continues. Fortunately, NIST has already forecasted this threat and called for replacements to our current standards, well before it is a crisis.  

eBook: Definitive Guide to Encryption Key Management

Topics: Encryption

SQL Server Column Level Encryption

Posted by Patrick Townsend on Feb 28, 2017 9:11:00 AM

Microsoft customers attempting to meet security best practices, compliance regulations, and protection of organization’s digital assets turn to encryption of sensitive data in Microsoft SQL Server databases. The easiest way to encrypt data in SQL Server is through Transparent Data Encryption (TDE) which is a supported feature in SQL Server Enterprise Edition. For a variety of reasons, TDE may not be the optimal solution. Microsoft customers using SQL Server Standard, Web, and Express Editions do not have access to the TDE feature. And even when using SQL Server Enterprise Edition, TDE may not be the best choice for very large databases.

Encryption & Key Management for SQL Server - Definitive GuideLet’s look at some approaches to column level encryption in SQL Server. The following discussion assumes that you want to meet encryption key management best practices by storing encryption keys away from the protected data, and retain full and exclusive control of your encryption keys.

Column Level Encryption (aka Cell Level Encryption) 
Starting with the release of SQL Server 2008, all Enterprise editions of the database have supported the Extensible Key Management (EKM) architecture. The EKM architecture allows for two encryption options: Transparent Data Encryption (TDE) and Column Level Encryption (CLE). Cell Level Encryption is the term Microsoft uses for column level encryption. SQL Server Enterprise edition customers automatically have access to column level encryption through the EKM architecture.

Encryption Key Management solution providers can support both TDE and Column Level Encryption through their EKM Provider software. However, not all key management providers support both - some only support TDE encryption. If your key management vendor supports Cell Level Encryption this provides a path to column level encryption in SQL Server Enterprise editions.

Application Layer Encryption
Another approach to column level encryption that works well for SQL Server Standard, Web, and Express editions is to implement encryption and decryption at the application layer. This means that your application performs encryption on a column’s content before inserting or updating the database, and performs decryption on a column’s content after reading a value from the database. Almost all modern application languages support the industry standard AES encryption algorithm. Implementing encryption in languages such as C#, Java, Perl, Python, and other programming languages is now efficient and relatively painless.

The challenge that developers face when implementing encryption at the application layer is the proper protection of encryption keys. Security best practices and compliance regulations require a high level of protection of encryption keys. This is best accomplished through the use of an encryption key management system specifically designed to create, securely store, and manage strong encryption keys. For developers, the primary challenge in a SQL Server encryption project is integrating the application with the key manager. Many vendors of key management systems make this easier by providing Software Development Kits (SDKs) and sample code to help the developer accomplish this task easily.

SQL Views and Triggers with User Defined Functions (UDFs)
Another approach to column level encryption involves the use of SQL Views and Triggers. Leveraging the use of User Defined Functions (UDFs) the database administrator and application developer can implement column level encryption by creating SQL Views over existing tables, then implementing SQL Triggers to invoke user defined functions that retrieve encryption keys and perform encryption and decryption tasks. This approach has the advantage of minimizing the amount of application programming that is required, but does require analysis of the SQL database and the use of User Defined Functions. Database administrators and application developers may be able to leverage the SDKs provided by an encryption key management solution to make this process easier.

SQL Server Always Encrypted
One promising new technology recently implemented by Microsoft is SQL Server Always Encrypted. This feature is new with SQL Server 2016 and can work with any edition of SQL Server. It is a client-side architecture which means that column data is encrypted before it is sent to the database, and decrypted after it is retrieved from the database. While there are many constraints in how you can put and get data from SQL Server, it is a promising new technology that will help some customers protect data at the column level. You can expect to see support for Always Encrypted being announced by encryption key management vendors in the near future.

SQL Server in the Azure Cloud
As Microsoft customers and ISVs move to the Azure cloud they are taking their SQL Server applications with them. And it is very common that they take full implementations of SQL Server into their Azure virtual cloud instances. When SQL Server applications run in a virtual machine in Azure they support the same options for column level encryption as described above. This includes support for Cell Level Encryption through the EKM Provider architecture as well as application layer encryption. As in traditional IT infrastructure the challenge of encryption key management follows you into the Azure cloud. Azure customers should look to their encryption key management vendors to provide guidance on support for their key management solution and SDKs in Azure. Not all key management solutions run in Azure and Azure is not a supported platform for all vendor SDKs.

Azure SQL Database
In the Azure cloud Microsoft offers the SQL Server database as a cloud service. That is, Microsoft hosts the SQL Server database in the cloud and your applications can use this service rather than a full instance of SQL Server in your cloud instance. Unfortunately, Azure SQL Database only supports Transparent Data Encryption through the EKM Provider interface and does not yet support Cell Level Encryption. It also restricts encryption key management to only the Azure Key Vault facility requiring you to share key custody with Microsoft.

Column level encryption at the application layer is fully supported for Azure SQL Database. As in the traditional IT infrastructure your C#, Java, and other applications can encrypt and decrypt sensitive data above the database level. Again, check with your key management solution provider to insure that application level SDKs are supported in the Azure cloud.

AWS Cloud and SQL Server
The Amazon Web Service (AWS) implementation of cloud workloads parallels that of Microsoft Azure. You can deploy a full instance of SQL Server in an AWS EC2 instance and use the features of SQL Server as in traditional IT infrastructure. Amazon also overs a database service called Amazon Relational Database Service, or RDS. The RDS service offers multiple relational databases including SQL Server. As with Azure there is no support for key management solutions other than the Amazon Key Management Service (KMS) requiring a shared implementation of key custody.

As you can see there are many ways to implement column level encryption in SQL Server and use good encryption key management practices. I hope this helps you on our journey to more secure data in SQL Server.

Patrick

Encryption

Topics: Encryption, SQL Server, Cell Level Encryption

New York Department of Financial Services (NYDFS) and Encryption - 8 Things to Do Now

Posted by Patrick Townsend on Dec 12, 2016 10:27:38 AM

The New York Department of Financial Services (NYDFS) surprised the financial services industry by fast tracking new cybersecurity regulations in September of 2016. Due to go into effect in January of 2017 with a one-year transition period, it takes a very prescriptive approach to cybersecurity which includes a mandate to encrypt data at rest. The financial sector is broadly defined as banks, insurance companies, consumer lenders, money transmitters, and others. The law is formally known as 23 NYCRR 500 and you can get it here.

eBook The Encryption GuideThere isn’t much wiggle room on the requirement for encrypting sensitive data. You can use compensating controls if you can show that encryption is “infeasible”. But I am not sure how you would show that. All modern database systems used by financial applications support encryption. It would be hard to imagine a financial database where encryption would not be feasible. Don’t plan on that being an excuse to delay encrypting data at rest!

The time frame is short for implementing the encryption mandate. One year seems like a long time, but it is extremely aggressive given the development backlog I see in most banks.

Here are some things you should start doing right now:

1) Inventory All of Your Financial Systems

This seems like a no-brainer, but you might be surprised how many organizations have no formal inventory of their IT systems that contain financial data. This is a top-of-the list item on any cybersecurity list of recommendations, so making or updating this list will have a lot of benefits.

2) Document Storage of All Sensitive Information (Non-Public Information, or NPI)

For each system in your inventory (see above) document every database and storage mechanism that stores NPI. For database systems identify all tables and columns that contain NPI. You will need this documentation to meet the NYDFS requirements, and it is a roadmap to meeting the encryption requirements.

3) Prioritize Your Encryption Projects

You won’t be able to do everything at once. Following all modern cybersecurity recommendations, prioritize the systems and applications that should be addressed using a risk model. Here are a few factors that can help you prioritize:

  • Sensitivity of data
  • Amount of data at risk
  • Exposure risk of the systems and data
  • Compliance risk
  • Operational impact of loss

It is OK to be practical about how you prioritize the systems, but avoid assigning a high priority to a system because it might be easiest. It is better to tackle the biggest risks first.

4) Establish Encryption Standards

Be careful which encryption algorithms you use to protect sensitive data. In the event of a loss you won’t want to be using home-grown or non-standard encryption. Protect data at rest with NIST compliant, 256-bit AES encryption. This will give you the most defensible encryption strategy and is readily available in all major operating systems such as Windows, Linux, and IBM enterprise systems.

5) Establish Key Management Standards

Protecting encryption keys is the most important part of your encryption strategy and the one area where many organizations fail. Encryption keys should be stored away from the encrypted financial data in a security device specifically designed for this task. There are a number of commercial key management systems to choose from. Be sure your system is FIPS 140-2 compliant and implements the industry standard Key Management Interoperability Protocol (KMIP).

Hint: Don’t fall into the project-killing trap of trying to find a key management system that can meet every key management need you have in the organization. The industry just isn’t there yet. Pick a small number of key management vendors with best-of-breed solutions.

With encryption standards well defined and an encryption key management strategy in hand you are ready to get started with your encryption projects.

6) Analyze Performance and Operational Impacts

Encryption will naturally involve some performance and operational impacts. Encryption is a CPU intensive task, so plan on doing some performance analysis of your application in real-world scenarios. If you don’t have test environments that support this analysis, get started now to create them. They will be invaluable as you move forward. Modern encryption is highly optimized, and you can implement encryption without degrading the user experience. Just be prepared to do this analysis before you go live.

There are also operational impacts when you start encrypting data. Your backups may take a bit more storage and take longer to execute. So be sure to analyze this as a part of your proof-of-concept. Encrypted data does not compress as well as unencrypted data and this is the main cause of operational slow-downs. For most organizations this will not be a major impact, but be sure to test this before you deploy encryption.

8) Get Started

Oddly (to me at least) many organizations just fail to start their encryption projects even when they have done the initial planning. A lack of commitment by senior management, lack of IT resources, competing business objectives, and other barriers can delay a project. Don’t let your organization fall into this trap. Do your first project, get it into production, and analyze the project to determine how to do it better as you move forward.

Fortunately we have a lot of resources available to us today that were not available 10 years ago. Good encryption solutions are available and affordable for traditional on-premise environments, for VMware infrastructure, and for cloud applications.

You can meet the NYDFS requirements and timelines if you start now. But don’t put this one off.

Patrick

 

Resources:

New York Department of Financial Services:

http://www.dfs.ny.gov/legal/regulations/proposed/propdfs.htm

 

Harvard Law School analysis of NYDFS:

https://corpgov.law.harvard.edu/2016/09/24/nydfs-proposed-cybersecurity-regulation-for-financial-services-companies/

The Encryption Guide eBook

 

Topics: Compliance, Encryption

Dangers of Encryption on the IBM i (AS/400, iSeries): Avoid These Pitfalls

Posted by Patrick Townsend on Nov 14, 2016 8:35:13 AM

IBM has done a good job of implementing security from the ground up on the IBM i platform. But that doesn’t mean that it is immune from data breaches. All of the PCs and servers on your network with the IBM i server are potential attack points for a data breach. And make no mistake, cyber criminals know that the IBM i server is a rich target. Implementing encryption in IBM i DB2 is an essential part of a defense in depth strategy. But there are lots of pitfalls to avoid. Let’s take a look at some of them (I am shamelessly plugging our Alliance AES/400 solution, too):

Key Management for IBM i - Audit FailuresLocally Stored Encryption Keys and Key Management

One of the surest ways to defeat your encryption strategy is to store encryption keys on the same system that stores sensitive data. The IBM i server is no exception. Compliance regulations and security best practices require that you store encryption keys away from the IBM i server in an encryption key vault designed for this purpose. Why is this a security best practice? Cybercriminals are often able to achieve privilege escalation on a compromised IBM i server and then get access to locally stored keys. Storing encryption keys off of the IBM i server makes the compromise of the sensitive data much harder.

How Townsend Security Can Help

The Townsend Security Alliance AES/400 product integrates seamlessly with Townsend Security's Alliance Key Manager solution for protection of encryption keys and key management best practices. Alliance Key Manager stores encryption keys in a hardware security module or VMware instance that is attached to the IBM i server by a secure, authenticated TLS connection. As a FIPS 140-2 compliant key management solution, Alliance AES/400 with Alliance Key Manager solves the key management problem!

High Availability and Key Mirroring

Encryption key management is a part of your critical infrastructure. The loss of an encryption key means the loss of your data! Your encryption key management solution should implement real-time key mirroring and real-time security policy mirroring. In the event the key manager is unavailable due to a hardware or network failure, the failover to a secondary key server should be automatic without business interruption. A key management solution based on the IBM i master key facility cannot achieve real-time mirroring and protection from these failures.

How Townsend Security Can Help

Alliance Key Manager implements real-time key mirroring to one or more backup key servers. The mirroring implementation is active-active meaning that any changes you make to keys or access policies on the secondary server will be mirrored to the production server when it comes back online. This perfectly matches your IBM i high availability failover strategy if you use MIMIX, iTera, Vision, or IBM DataMirror.

Encryption and Insider Threats

Insider threats include both intentional and unintentional access to and loss of sensitive information. Unintentional losses of data represents the largest insider threat. Accidentally copying data to a PC or development environment can lead to a reportable data breach event. This is especially true when access controls to sensitive data are only controlled by native IBM i object level security. You should certainly use native IBM i security mechanisms, but access to decrypted sensitive data should also be controlled using a “whitelist” approach. This will help minimize the intentional and unintentional access by security administrators. Note that it is not only the security profile QSECOFR that has all access to sensitive data: all users with All Object (*ALLOBJ) authority or who adopt this level of authority through a group profile or supplemental group are at risk for intentional or unintentional loss of sensitive data.

How Townsend Security Can Help

Alliance AES/400 implements a whitelist approach for controlled access to decrypted sensitive data. All configuration changes to security policies are logged to the IBM security audit journal QAUDJRN. You can achieve effective Separation of Duties between managers of the encryption keys and security administrators on the IBM i platform.

Poorly Performing Encryption Libraries

Encryption can also present an operational risk to IBM i customers. In order to meet service level expectations of end users encryption and decryption operations must be efficient. Unfortunately for IBM i customers the native AES encryption software libraries provided in the operating system may not provide an adequate level of performance. Even with the new IBM i POWER8 servers with on-chip encryption, the performance of AES encryption and decryption tasks is poor. It is important to assess the size of your protected databases and the nature of batch operations that require access to unencrypted data in order to avoid negative impacts to both interactive and batch applications.

How Townsend Security Can Help

Alliance AES/400 uses the Townsend Security NIST-validated AES encryption library for encryption and decryption tasks. This optimized AES encryption library is more than 100x faster that native IBM i encryption libraries on POWER7 processors, and more than 50x faster on POWER8 processors.

Encrypted Indexes

Many IBM i customers are surprised to learn that their RPG applications will not work correctly with DB2 FieldProc for encrypted indexes (key fields). FieldProc is IBM’s automatic column level encryption feature implemented at the DB2 database level. FieldProc is attractive to IBM i customers because it does not require modifications to applications. While native SQL applications can easily handle encrypted indexes, RPG applications do not use the native SQL Query Engine (SQE) and will not work properly with encrypted indexes. Most IBM i customers exclusively use RPG or have a mix of RPG and SQL applications. The issue with RPG and encrypted indexes represents a major roadblock to encryption. Be sure that your encryption strategy can support encrypted indexes, or be prepared to modernize RPG applications to use native the SQL Query Engine.

How Townsend Security Can Help

Townsend Security tackled the problem of encrypted indexes and offers a solution to the RPG challenge through its Open Access for RPG SQL library. Changing one line of code in your RPG application can automatically use the native SQL Query Engine for database access. This eliminates the challenges of encrypted indexes with FieldProc encryption.

Data Masking

Compliance regulations such as PCI Data Security Standard (PCI-DSS) and security best practices require that we only allow authorized users access to fully decrypted sensitive data. But other users must have access to our database applications. This means that intelligent data masking should be built into your IBM i applications. As noted above, data masking should be based on a whitelist approach and not purely based on object or database level authority. You should have the ability to define masking rules (mask all but the last 4 characters, etc.) and you should be able to define a default masking rule that applies to all unauthorized users. While Row and Column Access Controls (RCAC) can provide some data masking capability, you must manage individual user level authorities to implement this control.

How Townsend Security Can Help

Alliance AES/400 fully implements data masking using a whitelist approach and provides protections from users with All Object (*ALLOBJ) or Security Administrator (*SECADM) privileges. Data is masked in the internal decryption routines and fully exposed data is never visible in the application program.

System Audit Logs

No security policy or solution can be effective on a stand-alone basis and this includes encryption and key management. A good encryption and key management strategy involves monitoring all access to sensitive data, monitoring changes to encryption and key management configurations, monitoring all use of encryption keys, and storing audit logs for future forensic reference. The use of Security Information and Event Management (SIEM) solutions is highly recommended as a part of your monitoring and alerting strategy. Be sure that all access to encryption and encryption keys is fully audited and logged.

How Townsend Security Can Help

Alliance AES/400 and Alliance Key Manager implement system logging and audit for all aspects of administration, configuration and use. Alliance Key Manager implements full logging of all aspects of key management and the server it runs on, and transmits logs to a SIEM solution in real time. Alliance AES/400 fully logs all administrative operations and decryption tasks to the IBM i security audit journal QAUDJRN. The optional Alliance LogAgent solution transmits these logs as well as all IBM i security events to a SIEM solution or log collection server.

Encryption and key management don’t have to feel dangerous or scary! I hope the above points about encryption and key management for the IBM i help you develop a roadmap for successful (and safe!) encryption.

Patrick

Key Management for IBM i - Sources of Audit Failures

Topics: Encryption, Key Management, IBM i

The Definitive Guide to AWS Encryption Key Management
 
Definitive Guide to VMware Encryption & Key Management
 

 

Subscribe to Email Updates

Recent Posts

Posts by Topic

see all