The risk of data loss, and legal issues resulting from application security breaches is high on the list of concerns for any IT organization, but it is of particular concern for organizations hosting their apps in the cloud. Because most users and IT administrators are well aware of these issues, the quick growth of cloud computing has led many organizations to place layer upon layer of security controls on their systems.

Unfortunately, these security measures can put a drag on application performance, and can even affect availability.

It's a delicate tradeoff: You must strike the right balance or you'll end up with a very secure application with subpar performance, and no one will want to use it. So how do you balance application security with application performance?

Encryption vs app performance: Worth the hit?

Most companies choose to adopt federated computing systems, where some applications reside on a public cloud, some on a private cloud, and some legacy applications are accessible only over a virtual private network. In this scenario, organizations typically layer in monitoring and management technology to monitor operations performance, with alerts triggering when performance drops below a predefined threshold.

Following the fundamentals of data security, these organizations typically deploy a layer of encryption technologies to secure sensitive data. But encryption usually comes at the expense of application performance. So, how do you address the issue of encryption versus performance?

The answer depends on how you use encryption, how you measure performance, and how your applications use encryption. It's a common misconception that encryption will consistently cause performance issues when used to protect sensitive data. But when configured right, encryption has little impact on performance at both the application and the platform levels.

Why is that? Because not all encryption techniques are the same.

For example, let's say that you want to perform a straightforward operation, such as encrypting a single row in a database. This operation would consist of the following set of high-level steps:

Communicate with the key server to gather an encryption key

Encrypt the data

Persist the data

Record the event in a log

The National Institute of Standards and Technology's Advanced Encryption Standard (AES) uses a block size of 128 bits, but three different key lengths: 128, 192, and 256 bits.

Why is this important?

Let's assume that you are fetching a 128-bit AES key, as defined in step 1 above. That will incur both network overhead and disk I/O, keeping those components busy for a short period of time.

The actual encryption of the sensitive data is probably the fastest part of the steps listed above, and actually takes relatively little time. Most performance engineers don’t worry about the overhead of the actual encryption process.

Most believe the act of encrypting the data causes the most performance degradation, but fetching the encryption key from the key server is what actually causes the largest amount of latency.

A connection to the key server that goes over a transport layer security or secure sockets layer connection further complicates matters. To get the same level of security as with a 128-bit AES key, you would need to use a large public key to set up the secure connection. In some cases, you'd need a 3,072-bit RSA key to match the security of a 128-bit AES key. The overhead is higher because the key is larger.

Even logging is more time consuming with encryption. When you request a key from a key server, that event, and others, are logged in a database. That includes each key request, as well as whether the request was successful. There's a huge overhead associated with writing those events to the database, including the I/O and associated network overhead.

How to bridge the divide between app sec and performance

The only way around these performance issues is to streamline your operations as much as you can. Turning off or turning down logging is a good place to start, as is reducing the key size, if your security requirements will allow it. Other tips include:

Use encryption only when needed. Many organizations decide that everything must be encrypted, and this is an especially common demand when you store data in and transmit it to the cloud. While credit card data and personally identifiable information do require some encryption, most other data does not, since its loss would have a low impact on the business.

Use logging that writes to memory, not to disk. By reducing disk I/O in encryption operations, you can reduce much of the overhead associated with encrypting your data. Software is available that can facilitate memory-only-type logging systems.

Test for performance with security turned on. In many instances, the testing processes, including those in the context of DevOps, do not examine the effect of security on performance. You need to test security's overall impact on performance, and use that as a baseline for performance tuning. Keep in mind that performance will change as the data set grows, so you need to plan for that when setting performance expectations.

Good app security ensures good performance

Many people believe that security is counterproductive for systems that have good performance: Good security means you give up performance, right? That’s really not the case. It’s a matter of tradeoffs and watching out for unneeded uses of security.

Fortunately, many organizations are weighing the performance tradeoffs that security presents, and as systems and tools evolve, performance issues are becoming easier to solve. Eventually, the use of newer hardware and cloud-based systems will reduce performance problems through sheer compute power, aided by such technologies as advanced caching systems and in-memory persistence. The industry is already beginning to apply to security many of the same performance improvements used in the world of big data and the Internet of Things.

The core takeaway in balancing security against performance is diligence. You need to monitor your performance, and you should always ask how you can improve it. Keep your eye on the ball, and you'll have far fewer security-related performance problems.

Keep learning