As a security architect, security administrator or database administrator, one of the first big questions you face with the encryption of data at rest is how to organize, plan, and implement encryption keys to protect that data. Should you use one key for everything? Or, should you use a different key for each application? Or, perhaps you should use a different key for every table and column? Or, should you use a different key for each department? It is hard to find good security best practice guidance on this topic, so let’s put some focus around this question and see if we can come up with some general principles and guidance.

First, I like to start by identifying any applications or databases that contain highly sensitive information such as credit card numbers, social security numbers, or other personally identifiable information. These sources will be the high-value targets of cybercriminals, so you will want to protect them with your best security. For each of these applications and databases, assign encryption keys that are not used by any other application or database, and carefully monitor the use of these keys. Your encryption key management solution should help you with monitoring key usage. The objective is to protect the highly sensitive data and the related encryption keys from unauthorized access. If you have multiple sensitive applications and databases, assign each its own unique key.

Second, identify all of your major applications that are used across a broad set of departments within your company. Since these applications span multiple departments and will have a broad set of users with different needs, you should assign each of these applications their own specific encryption keys. In the event one application or database is compromised, it will not affect all of the other applications and databases.

Third, the remaining applications and databases are probably those that are used by one specific department within your organization. You will probably find that most departments in the organization have a number of specialized applications that help them get their work done. In terms of raw numbers, this might be the largest category of applications. Assign each department its own set of encryption keys that are not used by other departments. You may find that you need to sub-divide the department and assign keys for each sub-group, but the goal is to use encryption keys for the department that are not shared with other departments.

Lastly, cloud implementations are a special category and should always have separate keys. In the event that a Cloud Service Provider experiences a security breach, you will want to be sure that your internal IT systems are not affected. Assign specific encryption keys for your cloud applications and do not share the keys with internal, non-cloud applications.

Over the years I’ve occasionally seen organizations create and use a very large numbers of keys. In one case a unique key was used for every column and row in a table. In another case a different key was used for every credit card transaction. Large numbers of keys present management problems, and probably lowers overall security. Keep the number of encryption keys to a manageable level.

The above guidelines should help you protect your sensitive data and easily manage your encryption keys. There is a summary table for the above guidelines:

There are always exceptions to general rules about how to deploy encryption keys for the best security. The above comments may not be appropriate for your organization, and you should always adjust your approach to your specific implementation. Hopefully the above will be helpful as you start your encryption project.

An excerpt from the latest white paper “How to Meet Best Practices for Protecting Information in AWS” by Stephen Wynkoop, SQL Server MVP, Founder & Editor of SSWUG.org

Working in the cloud presents several challenges unique to that environment, including significant growth and change in the area of data protection and encryption. There is much confusion about what is - and is not - encrypted and protected.  This encryption of information, and the management of the keys and access controls is a core objective of this paper. If you can render information useless if accessed illegitimately, you have successfully addressed a whole host of regulations, compliance and best practices.

The very definition of protection by cloud providers is an important part of understanding the requirements and challenges of your configurations and information protection. AWS approaches data protection in several ways that impact your systems. The first is the configuration and design of your infrastructure. This consideration includes establishing Virtual Private Clouds (VPC) and providing for encryption of some information stores. The challenge exists in understanding the protection of these information stores and determining what you need to do to bring these protections in line with your requirements and compliance areas.

As you consider your systems, data protection will come down to several important areas:

• Physical access controls – This refers to the doors, secure access controls and other protections at the physical server and server room level.
• Logical access controls for your systems – These are the controls you put in place to prevent unwanted access to information.
• Data access – Data access controls are typically enforced at the information stores level.
• Protection of data in case of a breach – This is addressed by making the information in your systems unusable if accessed in a way that is unwanted.

Stephen’s white paper also covers the impact on data protection in public vs. private clouds, security fundamentals in AWS, and the best practices for deploying an encryption key management solution including:

• Segregation of Duties
• Dual Control and Split Knowledge
• Key Creation (and understanding strong keys)
• Key Rotation
• Protection of Keys
• Access Controls and Audits (Logging)

In his white paper, Stephen also discusses cloud-provider-based key management services and some of the important features, options, questions, and concerns that should be considered before selecting a service or a key management solution. Some important aspects to understand are:

• Control, Ownership, and Access - By managing your own encryption services and providing for industry-compliant key management and data protection practices, you help ensure that your data remains managed by your own secure keys.
• Multi-Tenancy and Key Management - In a worst case scenario it’s possible that keys could be compromised.
• Access to Keys - Many systems and architectures are based on hybrid solutions. Cases where there are systems on-premises combined with systems in the cloud are areas that will be problematic with the AWS services. Systems not on the AWS hosted services will not have access to the key management services on AWS.

There are many different considerations when thinking about the choices in your key management solution. Be sure to fully understand logs, key management, backups and other elements that provide the utility you require. Finally, be sure you’re checking for proper compliance and certification of the solutions you are considering. It is important that any solution you choose has been through a FIPS 140-2 validation, and that you have a full understanding of any PCI, HIPAA or other regulatory body requirements.

Please download the full document to learn more about protecting information in Amazon Web Services and how Townsend Security’s Alliance Key Manager for AWS provides a FIPS 140-2 compliant encryption key manager to AWS users who need to meet data privacy compliance regulations and security best practices.

Encryption, Key Management, and Data Security…Oh My!

This has been a busy year at Townsend Security with the addition of 2FA, the introduction of Key Management in AWS, Azure, and Key Connection for Drupal. Looking back over our data security blog and the most-viewed topics, I wonder... Did you miss out on any of these?  Take some time to check them out!

Heartbleed and the IBM i (AS/400)

by Patrick Townsend  (April 11, 2014)

Key take-away: It is important to understand that while the IBM i platform may not be directly vulnerable to the Heartbleed problem, you may have lost IBM i User IDs and passwords over VPN or other connections which are vulnerable. An exploit of Heartbleed can expose any information that you thought was being protected with session encryption.

From the blog article you can download additional content:  
Ebook: Turning  a Blind Eye to Data Security

What are the Differences Between DES and AES Encryption?

by Michelle Larson  (September 4, 2014)

Key take-away: Even Triple DES (3DES), a way of using DES encryption three times, proved ineffective against brute force attacks (in addition to slowing down the process substantially).

From the blog article you can download additional content:    
White Paper: AES Encryption & Related Concepts

Encryption & Key Management in Windows Azure

by Michelle Larson  (February 13, 2014)

Key take-away: In February 2014 we released the first encryption key manager to run in Microsoft Windows Azure. This blog highlights four of our most frequently asked questions about providing data security IN the Cloud.

From the blog article you can download additional content:    
Podcast: Key Management in Windows Azure 

Homomorphic Encryption is Cool, and You Should NOT Use It 

by Patrick Townsend  (October 6, 2014)

Key take-away: Homomorphic encryption is a promising new cryptographic method and hopefully the cryptographic community will continue to work on it. It has yet to achieve adoption by standards bodies with a proper validation processes.

From the blog article you can download additional content:  
eBook: the Encryption Guide

Authentication Called For By PCI DSS, HIPAA/HITECH, and GLBA/FFIEC

by Michelle Larson  (March 24, 2014)    

Key take-away: Two-factor authentication (2FA) plays a critical role in both meeting compliance regulations and following data security best practices. This trend will only grow within various industries and throughout the overall data security environment.

From the blog article you can download additional content:  
2FA Resource Kit: White paper, Webinar, Podcast

Encrypting Data In Amazon Web Services (AWS)

by Patrick Townsend  (August 28, 2014)

Key take-away: 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. This blog explores some of the ways that our Alliance Key Manager solution helps AWS customers and partners protect this sensitive data.

From the blog article you can download additional content:  
Podcast:  Encrypting Data in AWS

Key Connection - The First Drupal Encryption Key Management Module

by Michelle Larson  (February 21, 2014)

Key take-away:  Working together to solve the Drupal data security problem, the security experts at Townsend Security and Drupal developers at Cellar Door Media have released the Key Connection for Drupal solution, which addresses the need for strong encryption and encryption key management within the Drupal framework. Now personally identifiable information collected during e-commerce checkouts and user account that contain names and e-mail addresses can be easily encrypted, and the encryption keys properly managed, by organizations that collect and store that sensitive information.

From the blog article you can download additional content:   
Podcast: Securing Sensitive Data in Drupal

Nine Guidelines for Choosing a Secure Cloud Provider

by Patrick Townsend  (July 8, 2014)

Key take-away:  Security professionals (CIOs, CISOs, compliance officers, auditors, etc.) and business executives can use the following set of key indicators as a way to quickly assess the security posture of a prospective cloud provider and cloud-based application or service. Significant failures or gaps in these nine areas should be a cause for concern and suggest the need for a more extensive security review 

From the blog article you can download additional content:  
eBook: The Encryption Guide 

Never Lose an Encryption Key in Windows Azure       

by Patrick Townsend  (March 7, 2014)

Key take-away: This blog discusses backup/restore, key and policy mirroring, availability sets, and mirroring outside the Windows Azure Cloud.  Alliance Key Manager in Windows Azure goes the distance to help ensure that you never lose an encryption key. You might be losing sleep over your move to the cloud, but you shouldn’t lose sleep over your encryption strategy.

From the blog article you can download additional content:    
Free 30-day Evaluation of Alliance Key Manager for Microsoft Azure

3 Ways Encryption Can Improve Your Bottom Line

by Michelle Larson  (May 20, 2014) 

Key take-away: In a business world that is moving more towards virtualization and cloud environments, the need for strong encryption and proper key management is critical. Due to all the recent and well-publicized data breaches, we all know about the ways your brand can be damaged if you don’t encrypt your data. This blog takes a look at the benefits of encryption, and three of the ways it can have a positive effect on your business.

Additional content:  You’ll also discover that this is the third time in this Top-10 list that the eBook: The Encryption Guide is offered… so if you haven’t read it yet… what are you waiting for?

An Introduction to Townsend Security's VMware Guidance Document

VMware customers benefit from the many operational, and cost efficiencies provided by VMware virtualization technologies both in traditional IT infrastructure and in cloud environments. As VMware customers deploy data encryption solutions as a part of their defense-in-depth strategy, the need for encryption key management can present barriers to a good encryption implementation. This article provides high-level guidance, general in nature, on how deploy and protect Alliance Key Manager for VMware within your VMware environment. Actual VMware deployments of Alliance Key Manager for VMware will use different VMware applications and architectures to meet specific user, application, and security needs.

General VMware Recommendations

Identify and Document Trusted and Un-Trusted Applications

Properly identifying application groups based on the level of trust is critical for a secure implementation of virtualized applications and encryption key management services. Create and isolate a management cluster for your core VMware applications such as vSphere, vShield, etc. Identify application groups and their associated level of trust, and isolate applications into appropriate application workgroups. Avoid mixing trusted and untrusted applications in a workgroup.

You should consider creating a security workgroup to contain your third party security applications such as encryption key management, authentication services, active directory, system logging, and other applications whose primary function is to assist in securing your VMware environment. Encryption key management services provide by Alliance Key Manager should be implemented in this separate security workgroup used for critical, non-VMware security applications.

In preparation for properly securing these environments, create an inventory of all Virtual Machines managed in each workgroup. For each workgroup and virtual machine, identify the security controls that will be required for each one (network segmentation, storage segmentation, system logging, active monitoring, etc.). VMware flow tools can assist with this documentation.

Restrict Physical Access

Fundamental to all IT security implementations is proper security of the physical environment. This means proper physical security controls and physical monitoring of the data center as well as good auditing and procedural controls. These physical controls should also apply to access to VMware management and security applications. You can look to the PCI Data Security Standards and guidance for information on appropriate physical controls. You can also refer to standard security guidance in SOC 2 and SOC 3 assessments for information on physical controls. When deploying on a cloud platform it is always a good idea to ask the Cloud Security Provider (CSP) for a copy of the PCI letter of attestation, or an SOC 2 / SOC 3 report.

Isolate Security Functions

Because security applications are often a target of cybercriminals, you should isolate them into their own security workgroup and implement the highest level of VMware security. Only trusted VMware administrators should have access rights to Alliance Key Manager, system logs, and audit reports. Be sure to actively monitor access to and use of all encryption key management, key retrieval, and encryption services.

Change VMware Default Passwords

Review all VMware applications used to secure and manage your VMware environment and change the default passwords as recommended by VMware. The failure to change default passwords is one of the most common causes of security breaches.

Implement Network Segmentation

Network segmentation is easy to accomplish with VMware network management and security applications and you should implement network segmentation to isolate applications that process sensitive information from applications that do not require as high a level of trust. Additionally, you should provide network segmentation for all third party security applications such as Alliance Key Manager. Network segmentation should include all high availability and business recovery infrastructure. Do not rely on virtual network segmentation alone; use firewalls that are capable of properly securing virtual networks.

Implement Defense in Depth

The VMware management and security applications provide for a high level of security and monitoring. They also provide hooks and integration with third party security applications that provide system log collection, active monitoring, intrusion detection,etc. Encryption is a critical part of a defense-in-depth strategy, and protecting encryption keys is the most important part of an encryption strategy. Regardless of the operating systems in your application Virtual Machines, Alliance Key Manager will provide encryption key management, key retrieval, and encryption services for your business applications and databases running in your VMware infrastructure.

Monitor VMware Administrative Activity

Use an appropriate SIEM solution to collect VMware application and ESXi hypervisor system logs and perform active monitoring. The log collection and SIEM active monitoring solutions should be isolated into a security workgroup that contains other third party security applications such as Alliance Key Manager.

For more detailed information, read the entire VMware Guidance Document and other materials available in this VMware Resource Kit: 

Understanding PCI Merchant Levels and how an assessment can help your business

If your business takes credit cards for payment, then you are subject to the Payment Card Industry – Data Security Standards (PCI-DSS).

Companies of all sizes must comply with PCI DSS to ensure that their customers' data is protected during the processing and transmission of credit or debit card transactions and securely stored within any internal databases. PCI categorizes businesses into different classification levels based on the number of transactions and dollar amounts they processes each year.

Level 1 – All merchants processing more than 6 million card transactions annually

Level 2 – All merchants processing between 1 million and 6 million card transactions annually

Level 3 – All merchants processing between 20,000 and 1 million card-not-present only transactions annually

Level 4 – All other merchants

Level 1 companies are most likely well versed in the annual PCI audit process as they have a certified onsite audit annually with a Qualified Security Assessor (QSA). Level 2, 3, 4 merchants are not required to hire an onsite QSA, but can have a certified Internal Security Assessor (ISA) do the PCI self assessment annually. However, a small business preparing a self-assessment to participate in their first PCI review may find it a little daunting. If you're feeling that the PCI assessment process is overwhelming and complicated, understanding this process may be the first step toward putting your mind at ease. If you are a Level 1 merchant, the PCI assessment is a process carried out by a QSA to establish whether or not a business is compliant with security standards relating to the processing of transactions made via a credit or debit card (payment card). PCI compliance assesses your business point of sale system, payment applications, and all interconnecting systems with these goals in mind: (1) to examine your system, (2) to identify vulnerabilities, and (3) to prevent data from being compromised.

It’s not a matter of “IF”, but “WHEN”

If you have already suffered a data breach, working closely to review your assessment and put data security best practices into place will provide you with a roadmap to help avoid future losses. If you have not yet been breached, undergoing an assessment and reviewing your risk tolerance can still be stressful. Understanding the process may alleviate some of that stress and help you to maximize your use of the information in the PCI DSS assessment report

How can a PCI audit help my business?

PCI compliance auditing helps businesses to ensure they are providing the most secure environment for their customers to process payments and ensures that transactions are less likely to result in a compromise in the customers' data.

Ensuring that you meet PCI compliance and have a solid infrastructure for managing data security will increase customer confidence in your business and ensure that you're not exposed to security breaches that could have been avoided. 

To learn more about meeting PCI compliance requirements, download the whitepaper Meet the Challenges of PCI Compliance and find the answers to the following questions (and more):

• What will my auditor look for?

• How can I ensure my customers' data is secure?
• What is the difference between tokenization and encryption?
• What is encryption key management and why are auditors looking at this?

Taking Security Beyond Usernames and Passwords

Security professionals understand that passwords alone are just not good enough protection, and the on-going flood of data breach reports just confirms this on a daily basis. Enterprise IBM i users aren’t going to stop using passwords to login to their IBM i platforms, and hackers aren’t going to slow the flood of attacks any time soon. But now, we can take a giant security step forward by implementing two-factor authentication (2FA) to dramatically reduce the risk of a security breach.

Compromised email, social media, online gaming, ecommerce, financial services and other types of cracked accounts continue to threaten both personal and corporate interests. Out of all the threats that face individuals and companies, account compromise stands out as one of the most easily addressed with available and mature security technologies.

Historically, companies used physical tokens to provide authentication on the IBM i beyond username and password. Even if someone hacked a user’s password, they still could not login without the physical token. Tokens represent another layer of protection, which is a step in the right direction. Unfortunately, tokens increasingly do not make fiscal sense for Enterprise IT departments who have to deploy, manage, and troubleshoot large numbers of tokens. There is a better way for organizations to quickly and cost-effectively roll out two-factor authentication to a large and sometimes global user base. Solutions that leverage the mobile phone as a reliable means of authentication have become readily available for the IBM i platform. For example, instead of tokens, businesses can simply send an SMS or voice message that contains a one-time authentication code to the individual user’s phone. This means cyber criminals cannot log into the IBM i without physical control of the actual phone.

Mobile phones and landlines present key advantages for verification and authentication regimes:

• They possess unique identifiers – phone numbers, electronic identifiers and account numbers
• They remain in the possession of users or near at hand most of the time
• They are difficult to spoof
• If stolen or otherwise misappropriated, they are easy to disable
• Their association with actual individuals is verifiable through the operators that provide phone service

While none of these attributes alone are sufficient, together they provide a compelling basis for verification and authentication. The goal is to reduce fraud and actual theft of sensitive information by implementing something much harder to defeat than a login password. Combining something the person knows with something they have, or something they are, which can then be used for two factor authentication.

1. Something you know - a password. Even “strong” passwords can still be fairly weak from an attacker's point of view. With malware that easily detects them, passwords alone are a weak defense in relation to log-in security if that's all you have.

2.  Something you have - a mobile phone. It is now becoming quite common for companies to leverage what everyone already has in the way of the mobile phone or standard phone, and use that device as a mechanism for two factor authentication.

3. Something you are – biometric authentication options.  Physically scanning for an iris pattern or fingerprint.

By using 2 of those 3 things you can authenticate more securely to the system.

Here are a couple examples of things that are not two factor authentication:

• Requiring two passwords: using one factor twice is not 2FA!
• Using shield questions of which are actually fairly easy in our social world to determine.

The IBM i platform has a well-earned reputation for security, but security is only as strong as the weakest point in the enterprise network. User PCs, internal and external web servers, and network applications represent points of attack. These systems are not safe from:

• Memory scraping
• Keyboard logging
• Stolen vendor credentials
• Stolen user passwords from external web services

Due to the nature and the extent of these security threats on the IBM i, two factor authentication has become a viable solution for meeting compliance regulations and safeguarding the vast amount of data and numbers of users with access to sensitive information on the IBM i. We're seeing Google, Facebook, Yahoo, and almost all large commercial banking websites implementing a two factor authentication system based on SMS text and or voice verification to give additional security to their users accounts and IBM i users now have an affordable solution for their platform. Find out more by downloading this white paper:

If you don’t get the SANS newsletter it would be well worth your time to sign up now. It is a mix of the latest security news, available training classes from SANS, and commentary. This was the leader in the last newsletter of 2013 (emphasis mine):

The top story at the end of 2013 could just as well have been the top
story ten years ago. Federal chief information security officers
continue to "admire the problem" by paying $250/hour consultants to
write reports about vulnerabilities rather than paying them to fix the
problem. Sadly most of the federal CISOs and more than 85% of the
consultants lack sufficient technical skills to do the forensics and
security engineering to find and fix the problems.  Paying the wrong
people to do the wrong job costs the U.S. taxpayer more than a billion
dollars each year in wasted spending plus all the costs of cleaning up
after the breaches.  How about a 2014 New Years resolution to spend
federal cybersecurity money usefully: either by ensuring all the
sensitive data is encrypted (at rest and in transit) and/or the
organization implements the Top 4 Controls on the way to implementing
the 20 Critical Security Controls?
- Alan Paller

The news of the Target data breach was tragic for both consumers and for the company. The story would have been quite different if the credit card numbers had been encrypted. But the sad truth is that many organizations, both public and private, are still vulnerable to the loss of unencrypted credit and debit cards.

Too often the Payment Card Industry Data Security Standard (PCI-DSS) is treated like a check-box exercise, and not like an active, on-going call to arms. And too many merchants remain vulnerable to this type of loss even today.

I agree with Alan Paller - we need to step well beyond PCI DSS and other compliance regulations and take a far more active and aggressive stance on protecting sensitive data. Minimally this should include:

• Encrypt all sensitive data with industry standard encryption (e.g. 256-bit AES)
• Store encryption keys away from the data they secure
• Protect encryption keys with an Enterprise Key Management system
• Actively monitor encryption and key management systems

Encrypting sensitive data is only one thing you need to do as a part of a security strategy. But as recent events demonstrate, you don’t have a security strategy without encryption and proper key management.

Best wishes for 2014!

Patrick

Every few years since its inception in 2006 the Payment Card Industry Security Standards Council (PCI SSC) has revised and updated the the Payment Card Industry Data Security Standards (PCI DSS) and Payment Application Data Security Standards (PA DSS) to improve security for the payment card industry worldwide. These revisions, clarifications, and new points of guidance are based on considerations and recommendations by experts in the field of data security as well as over 700 organizations that process cardholder data. At the end of their review period, the PCI SSC concluded that revisions needed to be made based on these problematic themes in the payment card industry:

• Lack of education and awareness of how to implement and maintain PCI standards - a major problem since the improper implementation of PCI standards leads to data loss and breaches
• Weak passwords and authentication
• Lack of consistency of responsibility when implementing necessary third party security features
• Slow detection of threats
• Inconsistency of PCI assessments¹

Since the release of v3.0 in November 2013, many organizations affected by PCI DSS and PA DSS are asking: Are there new revisions regarding encryption and key management in v3.0, and what do I need to do in order to meet new recommendations, regulations, and best practices? Luckily, much of version 3.0 hasn’t changed from 2.0. However, many important clarifications have been made. In section 3 of PCI DSS (the section pertaining to encryption and management of encryption keys), version 3.0 makes clarifications regarding these aspects of encryption and key management²:

• Stricter controls around the protection and deletion of authentication data
• Key management procedures must be both implemented and documented
• The requirement of PAN masking
• The critical use of dual control and split knowledge
• The mandate that logical access for disk encryption must be managed separately and independently of the native operating system authentication and access control mechanisms, and that decryption keys must not be associated with user accounts.

Version 3.0 has also split requirement 3.5.2 into two separate requirements to emphasize the importance of both storing encryption keys in a secure location (3.5.2) as well as in the fewest possible locations (3.5.3)²

Based on the themes they found and the revisions made, it is clear that the PCI SSC is moving toward making their regulations stricter. What’s even more interesting is that in this last review, more than half of the recommendations were taken from experts and organizations outside of the United States. This is likely because the United States is farther behind other countries such as the European Union in terms of credit card data security, and since the PCI SSC sets worldwide regulations, they must set standards that meet the highest expectations.

We recommend all organizations worldwide look to the highest standards and follow best practices and recommendations (whether they are required or not) since these evolving requirements are based on current conditions and threats in the data security world and indicate future hardened regulations.

To learn more about encryption key management best practices download NIST Special Publication 800-57 “Recommendations for Key Management: Parts 1, 2 & 3” 

¹ PA-DSS & PCI DSS change highlights

² PCI DSS 3.0 summary of changes

Our Top Five Blogs of 2013

As we start off 2014, take a look back at five of our most popular blogs from the past year. Great topics, great content… and more to come!

MySQL and Encryption Key Management - 3 Ways Alliance Key Manager Encrypts MySQL Database and Protects Encryption Keys

Summary: With a strong encryption key management solution you can encrypt data in a number of ways in MySQL databases to meet compliance regulations for proper encryption key management. MySQL is the most popular open source relational database system and is in wide use in commercial and non-commercial environments. It is natural that developers and security professionals want to know how to encrypt sensitive information stored in MySQL databases.
Download:  eBook – Encryption Key Management Simplified

AES vs PGP: What is the Difference?

Summary: AES is a symmetric key encryption algorithm, which essentially means that the same key is used for the encryption and decryption of the data. PGP uses symmetric and asymmetric keys to encrypt data being transferred across networks. The encryption PGP offers is just as strong as that of AES, but it adds the additional security that prevents anyone with just the public key from being able to decrypt data that was previously encrypted with it.  AES is fast and works best in closed systems and large databases; PGP should be used when sharing information across an open network, but it can be slower and works better for individual files.
Download:  Webinar – 4 solutions for Data Privacy Compliance

Understanding Log Management on the IBM i

Summary: System logging is important across all operating systems… Because the IBM i system can handle multiple applications, it doesn’t log information like others do.  The IBM i collects logs simultaneously from multiple sources and deal with large volumes: Up to 3,500 events per second…250 Million of events per day!  The essence of good reporting is externalizing the systems logs and collecting them in a central repository which helps remove the risk of tampering. Compliance regulations recognize the need to watch all users – including the most powerful users, because network originated threats to the IBM i are often not noticed or quickly responded to by IT security professionals without close monitoring of system logs.
Download:  Webinar – Understanding System Logging on the IBM i

Why Partner With Townsend Security? What To Look for in a Strong Technology Partner

Summary: Businesses only want to partner with a technology company that has a good reputation. Mark Foege (Business Development Consultant and Principal at the Colvos Group) recounted, “...and that’s why they were excited to partner with Townsend Security. We realize that everything we do impacts the reputation of our partners. That’s why it’s important to us to provide solid, high value products, to make sure we are offering consistently first class support, and we work with our partners to make sure that their customers are completely delighted." Watch the YouTube Video with Townsend Security CEO Patrick Townsend and Mark Foege, they outline the importance of building strong technology partnerships for success, and what to look for in a partner.

What is Encryption Key Management?
Key Lifecycle & Rotation Explained

Summary: 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.
Download:  eBook  - Encryption Key Management Simplified

Do you have topics you want to learn more about?  Let us know by leaving a comment here, we will get back to you with an answer... and probably blog about it too!

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:

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.   

As always, we welcome your questions and comments!