+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

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 Failures Locally 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

Speaking Words of Wisdom, Let it Key

Posted by Luke Probasco on May 27, 2016 8:57:00 AM

"This article was originally posted on Drop Guard’s blog. Drop Guard automates Drupal updates to ensure security of your site within minutes after a security release."


What Data Needs To Be Encrypted In Drupal?

Encryption has gone mainstream. Thanks to the numerous data breaches (781 during 2015 in the U.S. alone) data security is a top priority for businesses of all sizes. Semi-vague language like “we ensure our data is protected” from IT teams is no longer good enough to satisfy the concerns of business executives and their customers. CEOs are losing their jobs and companies are suffering financial losses/fines that reach into the millions of dollars when poorly encrypted or un-encrypted data is lost.

Fortunately, the recent 2016 Global Encryption Trends Study shows that there is a growing shift with businesses developing an encryption strategy – Germany (61%) and the U.S.(45%) are in the lead with the primary drivers including:

  • To comply with external or data security regulations
  • To protect enterprise Intellectual Property (IP)
  • To protect information against specific identified threats
  • To protect customer personally identifiable information (PII)

Before getting too much deeper, let’s first clarify a common misperception. Yes, while the big brands are in the headlines, they aren’t the primary target of hackers. A recent threat report from Symantec found that three out of every five cyber-attacks target small and midsize companies. These businesses are targeted because they have weaker security controls and have not taken a defense-in-depth approach to security. Even though some of these businesses may be encrypting their data, chances are they are not doing it correctly.

How do you then define what properly encrypting data involves? First, it means using an industry standard encryption algorithm such as the Advanced Encryption Standard (AES), alternatively known as Rijndael. Standards are important in the encryption world. Standard encryption algorithms receive the full scrutiny of the professional cryptographic community. Further, many compliance regulations such as PCI-DSS, HIPAA/HITECH, FISMA, and others are clear that only encryption based on industry standards meet minimal regulatory requirements. Standards bodies such as NIST, ISO, and ANSI have published standards for a variety of encryption methods including AES.

But wait, my web sites don’t collect credit cards or social security numbers. Why should I care about encryption?

You would be surprised at what can be considered Personally Identifiable Information and should be encrypted. PII now includes information such as (and not limited to):

  • Email address
  • Password
  • Login name
  • Date of birth
  • Address
  • IP address

For a moment, pause and consider how many websites you have built that collect this type of information. As you will quickly realize, even the most basic marketing websites that collect a name and email address should deploy encryption.

Key Management
The second part of properly encrypting data involves key management and understanding the important role that it plays. Your encryption key is all that stands between your data and those that want to read it. So then, what good is a locked door if the key is hidden underneath the “Welcome” mat?

Security best practices and compliance regulations say that encryption keys should be stored and managed in a different location than the encrypted data. This can present a challenge for Drupal developers as the standard has been to store it on the server outside the web root. While there is a suite of great encryption modules (Encrypt, Field Encryption, Encrypted Files, etc.), they unfortunately all stash the key in similar unsecure locations – in the Drupal database, settings file, or in a protected file on the server. Once a hacker compromises a site, they can then take the encryption keys and have access to all the sensitive data.

“Let it Key”
Let’s now bring this back to one of my favorite songs by the Beatles to paraphrase a line (excuse the pun), “Speaking words of wisdom, let it key.” The Key module provides the ability to manage all keys on a site from a singular admin interface. It can be employed by other modules (like the aforementioned encryption modules) to offload key management so the module is not responsible for protecting the key. It gives site administrators the ability to define how and where keys are stored, which, when paired with the proper key storage modules, allows the option of a high level of security and the ability to meet security best practices and compliance requirements. Drupal developers can now easily integrate enterprise level key management systems such as Townsend Security’s Alliance Key Manager or Cellar Door Media’s Lockr (both of these companies have been heavy sponsors of encryption module development).

Enterprise level key managers do more than just store keys outside of the Drupal installation. In addition to safeguarding encryption keys, they manage them through the entire lifecycle—from creation to destruction. Further, a key manager will allow for:

  • Key naming and versioning
  • Key change and rotation
  • Secure key retrieval
  • Key mirroring
  • Key import and export
  • Password and passphrase protection
  • User and group control for key access 

In addition to providing NIST-compliant AES encryption and FIPS 140-2 compliant key management, an encryption key manager also allows administrators to store their API keys outside of Drupal. Private API keys are frequently used within Drupal by services like Authorize.net, PayPal, MailChimp, etc., and all these modules store their keys in the database in the clear. If your site gets hacked, so does access to the services that you have integrated into your site. For example, if your Amazon S3 API key were in your stolen database, hackers would have access to your entire offsite S3 storage. Consider how detrimental it would be for a client to find out that a hacker has gained access to their PayPal account - after all, they were using PayPal because they didn’t want to deal with the security risks and liability of hosting their own payment processing.

By routing all keys within Drupal to a central key management location, it is now possible to have total control over all encryption keys, API keys, external logins and any other value needing to remain secret. This gives developers and site builders a useful dashboard to quickly see the status of every key, and control where it is stored.

Summary
By now, I have hopefully conveyed the importance of encryption and key management. Everyone from developers to site owners need to understand the importance of data security and the proper steps they can take to keep their site, and their businesses safe. More secure encryption also has an effect on the Drupal platform as a whole. Whether Drupal is being used to create the most basic brochure site or advanced enterprise web application, encryption and API key management are critical to ongoing success. Many businesses don’t care whether their web site is built with Drupal, WordPress, Joomla, or even Microsoft Word (yes this is still possible) as long as it is secure. By integrating the proper security controls, including encryption and key management, Drupal will continue to proliferate and be the tool of choice for enterprises looking for the highest level of data and site security.

What Data Needs Encrypted In Drupal?

Topics: Key Management, Drupal

Encryption Key Management & Your IT Strategy

Posted by Luke Probasco on May 24, 2016 7:25:00 AM

Excerpt from the eBook "2016 Encryption Key Management: Industry Perspectives and Trends." 


Virtualization Will Continue to Dominate IT Strategy & Infrastructure

2016 Encryption Key Management Industry Perspectives and Trends eBook Large and small enterprises will continue to grow their virtualization footprints at the same time that they are looking to migrate applications to the cloud. The cost reductions provided by the market leader VMware will ensure that the VMware customer base will continue to consolidate applications and servers on their virtualization technology and that they will continue to be a powerful player in the IT infrastructure space for many years.

While VMware is the dominant technology provider for virtualization, we will see Microsoft attempt to increase their footprint with Hyper-V, and OpenStack solutions will also expand. We expect that all of the virtualization solution providers will attempt to de ne a clear path to the cloud based on their technologies. VMware is already moving in this direction with their vCloud Air initiative, and Microsoft uses Hyper-V as the foundation for the Azure cloud.

Encryption key management solutions that only run in hardware, or that only run on cloud platforms, present substantial obstacles for businesses with virtualized data centers. The rich set of management and security tools are not able to work effectively with solutions that are outside the virtualization boundary. Customers are looking to reduce their hardware footprint, not increase it. And solutions that can’t be managed or secured in the usual way represent additional risk and cost. Encryption key management solutions should be able to run within the virtualization boundary as an approved security application. Key management vendors vary greatly in their ability to support the range of deployments from traditional IT data center, to virtualized plat- forms, to the cloud. Organizations will continue to struggle with key management across these environments.

Take Aways

  • Encryption key management solutions should be able to run as fully native virtual machines in a VMware or Hyper-V environment.
  • Encryption key management solutions should be compatible with security and management functions of the virtual platform.
  • To maintain maximum business flexibility, deploy a key management solution that works well in virtual, cloud, and traditional hardware platforms.
  • Look for key management solutions that carry industry security certifications such as PCI Data Security Standard (PCI DSS), etc.

Key Management Vendor Stability Loses Ground

Merger and acquisitions in the security community continue at a rapid pace. Encryption key management vendors are being absorbed into larger organizations and this trend will likely continue. The public relations around such mergers and acquisitions is always accompanied with glowing prognostications and happy talk. Unfortunately, as often happens with any merger, key management vendors may experience disruption in their organizations as a result of a merger or acquisition. A key management solution may not be strategically important to an acquirer and this can result in disinvestment in the solution negatively impacting customer support. Key management is a part of an organization’s critical infrastructure and these changes can be disruptive.

Organizations can work to minimize the potential impact of key management vendor consolidation by understanding the vendor’s organizational structure, corporate history, and financial basis. Venture backed organizations can be expected to experience an exit through a merger, acquisition, or public offering. Vendors with solutions that are not strategically important to their product mix can also experience change and disruption. Using care in key management vendor selection may be one of the most important efforts you can make. This will be a continuing challenge in the years ahead.

Take Aways

  • Understand your key management vendor’s equity foundation and the likelihood of a merger or acquisition. If the key management vendor is largely funded by venture capital it is almost certain that the company will experience a merger or acquisition event.
  • Understand your key management vendor’s management team. Have key employees been with the company for a longer period of time? This is one good indicator of organizational stability.

Vendor Customer Support is a Growing Concern

As mentioned previously, encryption key management vendors continue to be absorbed into larger organizations and this trend will likely continue. Unfortunately, as can happen with any merger, key management vendors may experience disruption in their organizations as a result of a merger or acquisition. This can directly a effect the customer support organization and your ability to get timely and reliable technical support for your encryption key management solution. Deteriorating customer support can put your organization at risk. Key management solutions are a part of your critical infrastructure and proper customer support is crucial to operational resilience.

Another side affect of reduced or under-funded customer support is the inability of your organization to expand and invest in new applications and systems. These impacts on customer support may not present short-term problems, but can impair long-term resilience and growth flexibility. Many organizations will continue to experience inadequate customer support from key management vendors.

Take Aways

  • Understand the customer support organization of your key management vendor. Does the vendor demonstrate a strong investment in customer support? Is there adequate management of the customer support team? 
  • Review the Service Level Agreement (SLA) provided by your key management vendor. Be sure you understand the expected response times provided by the vendor customer support team. 
  • How do other organizations experience customer support from your key management vendor? Be sure to talk to reference accounts who use the key management product and who have interact- ed with the vendor’s customer support team.
201

Topics: Encryption, Key Management, cloud

Linux and Encryption and Key Management! Oh My!

Posted by Patrick Townsend on Apr 5, 2016 7:25:00 AM

Encryption for Data at Rest
Linux applications use a variety of database and storage methods that include MySQL, MongoDB, PostgreSQL, Amazon S3 and RDS, and many others. Like any application deployed on any operating system and storage mechanism, Linux applications need to protect sensitive data at rest using strong encryption. Compliance regulations, state and federal laws, customers, employees, and stockholders expect data to be protected and Linux developers know this.

Defending Data on Linux Podcast

The most common method of encryption for data at rest is the Advanced Encryption Standard, or AES. Sometimes call Rijndael, reflecting the names of the original authors Joan Daemen and Vincent Rijmen, AES is now an international standard. Using AES encryption will align you with these standards and with all major compliance regulations. Fortunately, AES is now available in a wide variety of development languages and software libraries. On the Linux platform, you will find ready-to-use AES encryption support in development languages like Java, PHP, Python, Perl, Ruby and many others. The OpenSSL software library also provides access to AES encryption.

Using the Right Mode of Encryption
AES encryption can be implemented via several modes of operation. Electronic Code Book (ECB) is the basic raw mode of operation, but you should avoid it for business applications. It can leak information when encrypting repetitive data. Probably the most common mode of operation for protecting business data with AES is the Cipher Block Chaining (CBC) mode. It takes a random Initialization Vector (IV) which helps prevent leaking information when encrypting repetitive data. You will find support AES CBC mode in all of the primary languages and software libraries. There are other modes of encryption that use IVs, but you will find AES CBC is most commonly used in business applications.

Initialization Vectors
Assuming you are using a mode of AES encryption that uses an initialization vector such as CBC, be sure that you are using a good random number generator to create the IV and that it is unique for each item that you encrypt. In other words, don’t use a fixed IV and don’t re-use an IV in your application. If you use this practice for generating unique IVs you won’t need to protect the IV with encryption as it is not considered cryptographic material. However, if you have especially sensitive data or a lot of it, it won’t hurt to take the extra precaution of encrypting the IV.

Encryption Key Management
Now we get to the hard part that most developers get wrong about encryption - the protection of the encryption keys. A good encryption strategy depends on the use of strong encryption keys, and the protection of that key. Encryption keys that are weak or that are stored on the same server as the sensitive data are likely to provide little real protection. Common poor practices include:

  • Using a password as an encryption key.
  • Using a flawed or non-standard random number generator to create a key.
  • Storing the encryption key in the application code or in a SQL statement.
  • Storing the encryption key in a file or table.
  • Storing the encryption key with poor protection (XOR with weak data, etc.).
  • Storing the encryption key with password-based encryption protection.
  • Storing the encryption key on a mounted drive.

These are just a few of the practices that can set you up for a data breach and compliance audit failure. Use a good key management system that is designed for that purpose and which meets industry standards like FIPS 140-2.

Retrieving a Key vs. Using an Encryption Service
Assuming you are protecting the encryption key properly, you need to decide if you want to retrieve an encryption key from a key manager and then use it to perform encryption, or if you want to use an encryption service provided by the key manager. If you are developing an application in a more exposed environment such as a cloud platform, or an internet-facing web server, you may want to reduce the risk of encryption key loss by using an encryption service on the key manager. All encryption is performed on the key manager and the key never leaves the key management server. This can provide additional protections against the loss of the key.

If you are encrypting large amounts of data, or making many encryption requests in your application, retrieving the encryption key once and using it many times can provide a boost in encryption performance. Remember to securely erase the key when you are finished with it.

Key Management and Business Continuity
When you use a key management system it becomes a part of your critical infrastructure. This means that it is particularly important that the key management system provide a high level of redundancy and implement best practices related to backup and restore. If you are using a hardware security module (HSM) it should implement redundant power supplies, hot swappable RAID disk drives, and redundant network interfaces for maximum resiliency. All key management systems should implement real-time, active-active key and policy mirroring, automatic recovery from network failures, manual and automated backup, and a high availability failover strategy. The ability to implement geographic redundancy between primary and secondary key servers should be fully supported, and this can be a challenge on some cloud platforms.

Key Management and Key Custody
Who has access to your encryption keys is becoming a hot-topic issue for many organizations. In many regulated environments you must insure that unauthorized access to keys or compromised keys can be detected and managed by your organization. This is not always possible with some cloud service provider key management services. Additionally, access to encryption keys by law enforcement or government agencies may happen without your knowledge. Be sure that your key management strategy gives your organization exclusive access to encryption keys and prevents the key management vendor, cloud service provider, or another other entity from accessing encryption keys. You should be able to receive clear and unambiguous assurances from your key management vendor or cloud service provider on this question.

Key Management and Virtualization
Most organizations now deploy their Linux and Windows applications in virtualized environments such as VMware. Almost all encryption libraries and language implementations of encryption are compatible with VMware and other virtualization platforms. The same is not true for key management solutions and vendor-provided SDKs. Even if your Linux application will not be deployed on VMware today, be sure that you implement an encryption key management strategy that will allow deployment of the key manager in a secure workgroup in VMware. The key manager should be fully virtualized and able to support a no-hardware approach to deployment in VMware.

Key Management and the Cloud
If your Linux applications will be deployed on a cloud platform it can be tempting to use the key management services of the cloud service provider. These services are very low cost or free, and are therefore attractive. Think hard about this before you make this decision. Besides key custody issues (see above) most key management services on cloud platforms use proprietary interfaces to their key management services. This locks you into the particular cloud service provider and makes it difficult to migrate to other platforms. It also makes it extremely difficult to implement dedicated key management services outside of the cloud platform. As attractive as cloud key management services appear to be, there are definite downsides to binding your Linux application to one specific cloud platform.

Key Management, Developers, and SDKs
Linux developers need maximum flexibility as they deploy applications and web services. One application may be based on the Java language, another on Python, another on Ruby, and so forth. There is a rich ecosystem of development languages available to Linux developers. When deploying encryption key management to protect encryption keys be sure that you have access to a rich set of SDKs that work naturally across all of these environments. When you deploy a Java application you want a Java SDK to enable key management. Attempting to cobble together a solution using different language SDKs is going to be a difficult and unpleasant process, not to mention the problems with supporting hybrid language environments.

Key Management for Linux ISVs
If you are developing a Linux application to take to market you have a number of other issues to consider. Your customers will want to run your solution in a variety of ways. Some will be happy with a low cost, multi-tenant cloud solution. Others will want to deploy in a dedicated virtual private cloud. Others will want a traditional IT data center approach, perhaps with VMware infrastructure. And key management requirements will be all over the map. Shared multi-tenant key management, dedicated cloud key management, dedicated virtual cloud key management, and true hardware HSMs will all come into play. Be sure that your key management solution works well in all of these environments and bridges them in hybrid deployments. Getting this right from the beginning will be important to your success as a Linux ISV.

Def

Topics: Encryption, Key Management, Linux

5 Ways CEOs Can Limit Liability, Manage Risk with Encryption

Posted by Liz Townsend on Oct 27, 2014 11:05:00 AM

Recently I traveled to Los Angeles to speak at a NetDiligence Cyber Risk and Liability conference on a panel focusing on technology to mitigate risk. I was eager to attend and speak at this conference since the area of data breach clean-up is a field that I rarely come in contact with. In our organization, we spend much of our time consulting with companies who are attempting to prevent a data breach or meet compliance by implementing encryption and key management technology, and rarely are we involved in any post-breach scenarios involving breach forensics, insurance payouts, or litigation.

encryption, key management, grc, governance, risk, compliance It is common knowledge, however, that for attorneys who wish to help limit their client’s liability when it comes to data breaches (and also make litigation easier should a data breach occur), advising them on processes and technologies that will mitigate risk and liability is essential.

From speaking to attorneys who attended this conference, this is what I learned: Executives don’t treat their data as an asset that needs to be protected as a part of governance and risk mitigation. This is a pervasive issue that is exemplified in highly publicized data breaches that seem to occur on a weekly basis. Negligence around data protection, I believe, simply stems from a lack of education. Twenty or 30 years ago, when most enterprise executives were in business school, governance of sensitive, electronic data was not taught, simply because the issue didn’t exist. Today, protecting data as a method of risk management is an entirely new field. Unfortunately, as data breaches become more and more serious, business leaders can no longer avoid the issue or fall back on an “I’ll just pay the fine” mentality, which is woefully inadequate since the cost of a data breach extends far beyond fines to respective governing industry regulators. The cost of a breach includes fines, brand damage, loss of customer loyalty, litigation, credit report monitoring for affected customers, and even job loss. Executives should take a note from the ex-CEO of Target to learn how a data breach reflects on leadership (or lack-there-of).

In the face of never-ending data breaches and an entire industry based on hacking complex networks, the question now becomes, how can executives effectively mitigate cyber risk and liability using technology?

1. Accept data is a critical part of governance, risk management, and compliance

Imagine a CEO walks into a room with his or her board of directors and says, “I’m going to cancel our errors and omissions insurance.” Any director would be terrified and livid to hear their CEO say such a thing, and likely begin to doubt his or her ability to govern. However, in a similar situation, if a CEO said, “I don’t think we’re going to encrypt our customers’ sensitive data this year,” historically no one would have blinked an eye. This is changing. The cost of a data breach has skyrocketed to a point where ignoring the risk of unprotected sensitive data is considered negligence. Executives need to understand that not encrypting sensitive data reflects on their ability to govern.

2. Know what data is considered “sensitive” and needs to be protected

Sometimes business leaders aren’t even sure which data needs to be encrypted. Overall, it is common knowledge that data such as credit card numbers and social security numbers need to be encrypted, especially under payment card and financial regulations such as PCI-DSS and GLBA/FFIEC; however, loyalty data such as email addresses, passwords, and phone numbers are considered sensitive and should be protected. Hackers are great aggregators and can derive very sensitive data from this kind of information. The recent JP Morgan Chase breach is a good example of a breach of customer data that landed a business in hot water. Executives need to examine which regulations they fall under, as well as consider what is now considered sensitive (even though it may not be listed as “sensitive” under regulation), and encrypt that data.

3. Learn to ask the right questions

Executives have learned to ask the right kinds of detailed questions to ensure their financial and business processes are limiting risk, but they still haven’t learned to ask the same kinds of detailed questions about their data security. In fact, it’s common for a CEO to simply ask their security or IT department, “are we secure”? Unfortunately, vague questions such as this get vague answers. While business leaders should work with a qualified security auditor to determine what kinds of questions they need to be asking their IT security team, here are a few examples that might be helpful:

Can I get an itemized list of all of the locations of our sensitive data, and the specific method in which we are protecting those sets of data?

Are we transferring sensitive data across networks? How are we encrypting that data?

Are we encrypting our data at rest? If so, are we using industry standard methods such as NIST AES encryption or RSA encryption?

How are we managing our encryption keys? Are they located in a secure, FIPS 140-2 compliant encryption key manager?

4. Know the limits of your technology

Assuming a certain amount of risk is common when that risk can’t be avoided. Unfortunately, it’s not very pleasant to realize you’ve assumed risk that you are unaware of. Many large retailers have been experiencing this recently with data breaches occurring in their point-of-sale systems. Understanding the limits of the technology you use is critical to preventing data breaches. Many organizations still rely on firewalls, strong passwords, and intrusion prevention software alone to protect sensitive data. These methods are certainly a component of a data security strategy, but they have limits, and are inadequate to protect sensitive data. Industry regulators know this which is why data security regulations require if not strongly recommend the use of encryption and encryption key management.

5. Encrypt data everywhere, including in the cloud

The internal network of any businesses can be incredibly complex. With many points of entry in many departments, a network can be easily breached. Encryption and key management are defense-in-depth technologies used to stop data breaches before they happen. Since data moves across multiple applications and networks, in every location where that data moves or stays it needs to be encrypted. Any sensitive data processed or stored in the cloud should always be considered in danger of greater risk, due to the inherent insecurities of a multi-tenant cloud solution. Assume that any holes in your encryption strategy will attract a breach.

Managing risk by implementing the right technologies is critical to mitigating the effects of a data breach. To learn more about encryption and risk mitigation, download the podcast, “Encryption, Key Management, and GRC: Technology to Mitigate Risk

encryption, key, management, grc

Topics: Encryption, Key Management, GRC

Encrypting Data In Amazon Web Services (AWS)

Posted by Patrick Townsend on Aug 28, 2014 9:31:00 AM

Amazon Web Services is a deep and rich cloud platform supporting a wide variety of operating systems, AWS services, and third party applications and services. It is a bewildering array of capabilities with lots of places to store sensitive data. Let’s explore some of the ways that our Alliance Key Manager solution helps AWS customers and partners protect this data. This is a bird’s eye view, and we’ll dive into this in more depth in future blogs:

Amazon AWS Services

Encrypting data in AWS - What You Need to Know Amazon Relational Database Service (RDS)
Alliance Key Manager provides encryption key retrieval and an on-device encryption service to make it easy for your applications to encrypt data in RDS. Townsend Security SDKs can easily be used to provide encryption at the application layer.

Amazon Simple Storage Service (S3)
Alliance Key Manager lets you retrieve 256-bit AES keys in Base64 encoded format ready for use with RDS customer supplied encryption key services. You can easily deploy an AKM dedicated key management service to support encrypting and decrypting files in S3 storage.

Amazon Elastic Block Storage
Amazon Machine Instances (AMIs) provide access to EBS for simple unstructured storage requirements. Townsend Security SDKs can easily be used to provide encryption at the application layer.

Amazon DynamoDB (NoSQL)
The AWS NoSQL implementation does not provide encryption services, but you can easily implement encryption at the application layer using the Townsend Security SDKs. With support for many programming languages you can implement the encryption and key management services you need to meet compliance regulations.

Application Databases:

Microsoft SQL Server
Alliance Key Manager includes a license for Townsend Security’s Key Connection for SQL Server application that supports Transparent Data Encryption (TDE) and Cell Level Encryption for Enterprise edition. This EKM provider installs in your Windows SQL Server environment and enables encryption without any programming. For SQL Server Standard and Web Editions Alliance Key Manager includes a license for the Townsend Security Windows Client for snap-in encryption support.

Oracle Database
Oracle Database encryption support is provided through SDKs that are free of charge with Alliance Key Manager. Java, Perl, PHP, Python, Ruby and C# SDKs and sample code enable rapid deployment of encryption in Oracle environments. Sample PL/SQL code is also available for Oracle Linux platforms.

MySQL, SQLite, PostgreSQL, etc.
Open source database encryption support is provided through SDKs that are free of charge with Alliance Key Manager. Java, Perl, PHP, Python, Ruby and C# SDKs and sample code enable rapid deployment of encryption in these environments.

Software SDKs for Amazon Web Services:

A rich set of application SDKs are available for many programming languages. These SDKs provide support for Java, Microsoft .NET languages (C#, VB.NET, etc.), Perl, Ruby, Python, PHP, and others. These SDKs are provided at no charge to Alliance Key Manager customers.

Application Plugins for Amazon Web Services:

Drupal Encryption and Key Management
Alliance Key Manager integrates naturally with the Drupal web CMS using the Drupal Encrypt module and Townsend Security’s Key Connection for Drupal module available on Drupal.org. Drupal users can retrieve encryption keys for use with local encryption, or use the Alliance Key Manager Encryption Service to encrypt and decrypt data in the key manager with NIST-validated AES encryption.

SQL Server Transparent Data Encryption
Alliance Key Manager integrates directly into the Microsoft SQL Server Enterprise edition database to provide Transparent Data Encryption (TDE) support using the Townsend Security Key Connection for SQL Server application.

SQL Server Cell Level Encryption
Alliance Key Manager integrates directly into the Microsoft SQL Server Enterprise edition database to provide Cell Level Encryption support using the Townsend Security Key Connection for SQL Server application.

Encryption & Key Management in AWS

Topics: Alliance Key Manager, Encryption, Key Management, Amazon Web Services (AWS)

Encryption: Do I Need Key Storage or Key Management?

Posted by Michelle Larson on Aug 4, 2014 11:48:00 AM

Is there more to encryption key management than just storing my encryption keys?

There is far more to encryption key management than just storing the encryption key somewhere… as it turns out, there is a whole encryption key lifecycle that is (or should be) handled by a certified encryption key management solution. Generally, a key storage device only provides storage of the encryption key, and you need to create the key elsewhere. Also, just storing your encryption keys “somewhere” doesn’t work very well for compliance regulations. With an encryption key manager, there is a whole set of management capabilities and a suite of functions that provide dual control, create separation of duties, implement two factor authentication, generate system logs, and perform audit activities, along with managing the key life cycle (including storage). There is a very real need, and very specific guidelines that require you to store and manage your encryption keys away from the data that they protect.

The Encryption Key Life Cycle

key lifecycle

Beyond storing the encryption key, a cryptographic key manager manages the entire key life cycle. Some of the most important functions the key management administrator performs are the actual creation and management of the encryption keys. The keys are generated and stored securely and then go through the full cycle to become active, go into use, expire, retire (post-activation), and then be backed up in escrow, and then deleted (the “destruction” phase). Let’s take a closer look at the phases of a key life cycle and what a key management solution should do during these phases:

Key Generation & Pre-Activation:
First, the encryption key is created and stored on the key management server (which can be a hardware security module (HSM), virtual environment (VMware) or a true cloud instance). The key can be created by a sole administrator or through dual control by two administrators. The key manager produces the AES key through the use of a cryptographically secure random bit generator and stores the key, along with all it’s attributes, into the key storage database (which is also encrypted). The attributes stored with the key include its name, activation date, size, instance, the ability for the key to be deleted, as well as its rollover, mirroring, and key access attributes. The key can be activated upon its creation or set to be activated automatically or manually at a later time. The key manager should also be able to create keys of three different sizes: 128, 192, or 256-bit. The encryption key manager should also track current and past instances, or versions, of the encryption key. You can also choose whether or not the key can be deleted, mirrored to a failover unit, and by which users or groups it can be accessed. Your key manager should allow the administrator to change many of the key’s attributes at any time.

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

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

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

Crypto Period:
This encryption key life cycle, which is defined by the National Institute of Standards and Technology (NIST), also requires that a crypto period be defined for each key.  A crypto period is the length of time that a key should be used and is determined by a number of factors based on how much data is being protected and how sensitive that data is. While NIST has defined and provided some parameters on how to establish crypto periods (see special publications 800-57 - there are 3 parts) and provided guidance on best practices. Each key management administrator needs to determine how long a particular encryption key should be actively used before it is rotated or retired.

These are a few of the factors that go into establishing the crypto period for a key (which maybe a few days or weeks or longer up to one or two years it really depends on the data that you're trying to protect):

  • How is the data being used
  • How much data is there
  • How sensitive is the data
  • How much damage will be done when the data is exposed or the keys are lost

You can see that there is a significant difference between a key storage device and an encryption key management solution. Remember to always look for NIST validated and FIPS 140-2 compliant solutions to meet compliance requirements and follow security best practices!

To learn more about encryption key management download our ebook on Encryption Key Management Simplified.

Encryption Key Management Simplified eBook  

Topics: Alliance Key Manager, Key Management, eBook, Encryption Key Management

Would You Pass a Data Security Audit? - Part 2 - Q&A

Posted by Michelle Larson on Dec 27, 2013 9:28:00 AM

Still Have Questions About Meeting Compliance Requirements?

The question “Would You Pass An Audit?” was posed in our last blog and companion webinar series.  We discussed compliance regulations and how protecting sensitive information was more than just a good security strategy. While the webinar title is directed at IBM i users, the content is really applicable to most all platforms! Hopefully you were able to watch the webinar resource provided (if not, you can request it HERE).  After the webinar, we had a number of questions asked by attendees and answered by security expert Patrick Townsend.  Here is a recap of that Q&A session: How-to-Guide Key Management Best Practices eBo

Q: If I have my sensitive data stored off site with a hosting company or in the cloud am I responsible if they have a data breach?

A: The short answer is yes you are. When you have sensitive data and are moving it into a cloud solution you are still ultimately responsible for protecting that data. This can be confusing because cloud vendors make a lot of statements about encryption and compliance, however you are responsible for your overall data protection strategy.  

When looking for a hosting vendor or to move applications outside of your environment, a part of the process should be assessing their ability to meet PCI or other compliance regulations. As part of your due diligence, ask for a QSA letter of attestation from a qualified QSA auditor to confirm the security of the infrastructure of that hosting company and that they are:

  • Securing the data center to PCI standards
  • Securing racks properly
  • Placing proper controls and vulnerability scans in place for their own infrastructure

It is your responsibility to make sure your data security meets compliance regulations. Any loss will also be your responsibility, so it is worth the time to make sure you have a strong strategy in place and are using industry standard encryption and proper key management to protect your data wherever it resides. 

Q: A vendor told me that tokenizing data will make us PCI compliant is this true?

A: This is a more complex question to answer. Tokenization is a great technology and there has been a lot of work done in this field the past few years.  Personally, I believe it can be done well and can help you meet compliance regulations.  If you are planning to generate non-recoverable tokens (when the original data does not need to be recovered) using a separate token server, that can eliminate the need to store the original data in an encrypted format. Non-recoverable tokens can help minimize the impact of regulations such as HIPAA, PCI, HITECH , GLBA and individual state privacy laws by taking the server out of scope for compliance.  However if you plan to recover the data and are consolidating sensitive information into the tokenization solution, you must make sure the tokenization solution itself is PCI compliant and using industry standard encryption such as AES when using recoverable tokens. The basic concept for tokenization is that you replace the data in your database with a token that has no value; however, sensitive data (for retrieval) has been transferred into the tokenization solution.  Because all of this sensitive information has been consolidated into one place, it becomes even more of a high value target.  Tokenization is very effective as long as you are using industry standard encryption within that solution and also using best practices for encryption key management.  Make sure you are using a tokenization solution that integrates with a NIST validated and FIPS 140-2 compliant key management solution that will properly store your encryption keys on a designated hardware security module (HSM) and not in the same server as the pool of data. 

Q: A vendor we are considering for key management advertises an integrated key management solution, would this be PCI compliant?  

A: Only a QSA auditor can determine PCI compliance of vendor solutions, however being educated on industry best practices is very important.

Storing the key within the same server where the data is located is not a defensible practice, and security best practices recommend using an HSM to store encryption keys away from the data you are protecting. Best practices for encryption key management also recommend that you implement separation of duties and dual control.  I highly recommend that you look for NIST validations and make sure the approach to encryption and key management has been done correctly.

To help you plan your data security strategy, we’ve created a great How-to-Guide on Encryption Best Practices and you can download your complimentary copy by clicking on the link below.   

Request the Key Management Best Practices How-to-Guide

As always, we welcome your questions and comments!


Topics: Key Management, eBook, Best Practices, Encryption Key Management, Webinar

Q&A: Secure Managed File Transfer and PGP Encryption

Posted by Michelle Larson on Nov 22, 2013 11:26:00 AM

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

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

Hopefully you were able to watch the webinar resource provided (if not, you can request it HERE). After the webinar, we had a number of questions asked by attendees and answered by security expert Patrick Townsend.  Here is a recap of that Q&A session:

Q: Is there any reason why I can’t just transfer my file from my IBM i platform to Windows and then PGP encrypt it there.

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

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

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

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

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

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

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

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

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

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

  • Automatically transfer files using Secure Shell sFTP or Secure SSL FTP
  • Protect data using strong PGP encryption
  • Review your total encryption strategy
Webinar: Secure Managed File Transfer on IBM i

 

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

Topics: Encryption, Alliance FTP Manager, Key Management, Secure Managed File Transfer, FTP Manager for IBM i, SFTP

What is Encryption Key Management?

Posted by Victor Oprescu on Jul 15, 2013 2:46:00 PM

Key Lifecycle & Rotation Explained

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

eBook - Encryption Key Management Simplified

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

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

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

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

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

Encryption Key Management Simplified eBook

Topics: Alliance Key Manager, Key Management, eBook, Encryption Key Management


Subscribe to Email Updates

Posts by Topic

see all