Townsend Security Data Privacy Blog

As we discussed in the blog Secure Managed File Transfer on the IBM I – Part 1 protecting sensitive data on the IBM i (AS/400) can help you meet compliance requirements, and it can help you stop a data breach before it happens!  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 shouldn’t use PGP on Windows? I can just transfer the file from my IBM i to Windows and then PGP encrypt it there.

Patrick: That is a great compliance question. Transferring unencrypted data 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.

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

Patrick: 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 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 this to, whether its Windows, Linux, UNIX ,or IBM Mainframe, there are multiple readily available solutions that support those file transfer secure protocols. The 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 FTP Manager transfers.

Q: We occasionally need to create encrypted zip files on our IBM i and then transfer the files to our customers. Can FTP Manager do this?

Patrick:  There are commands in the product to zip with or without 256-bit AES encryption and unzip the same way. It can handle multiple files and multiple directories and it is all command based if you want to do that via commands. 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: SSH and sFTP implement a number of authentication mechanisms for transferring files. Public/private key structure is typical for secure sFTP transfers. We add utilities into FTP Manager to make the generation and exchange of those keys very easy to do. For example: as you’re setting up a new sFTP transfer we have utilities that will go out and pull the public key for that remote server down into your IBM i platform and add it to the appropriate key file. Additionally, Secure Shell sFTP does support a password type of authentication. It’s not used a lot, most people feel that public private key authentication and protection is the best mechanism. We know at least one major commercial bank that uses passwords as an authentication mechanism with sFTP. This is a real challenge for a command line facility that is being automated in batch, and we’ve solved that problem for our customers. There is architecture within sFTP that allows for password authentication. We found a way to make this fully work with these large commercial banks so that you can use password authentication with our sFTP product. It’s a big challenge. Very important: your first sFTP transfer may use public and private keys, which is probably more typical. But be sure that the solution can also handle password authentication. 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 sFTP transfers on the IBM i platform with the following objectives:

• Automatically transfer files using Secure Shell sFTP or Secure SSL FTP
• Send your first encrypted file in an hour
• Review detailed audit trails of all transfer activity
   

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

In their latest podcast, Paul Taylor with Security Insider Podcast Edition and Patrick Townsend, CTO of Townsend Security discuss using PGP encryption to secure data in motion for meeting compliance regulations, the OpenPGP standard, the differences between Open and Commercial PGP solutions, and ways to automate your managed file transfers on the IBM i.

PGP stands for “Pretty Good Privacy”, and it’s an encryption solution that originally started in the 1990s. Over 20 years ago, Phil Zimmerman and a group of developers decided to produce secure file encryption technology and felt that PGP should be used everywhere to protect data-in-motion, both for individuals and for companies who need to transfer data across networks. Originally, Phil Zimmerman’s development team offered a free, open-source version of PGP. Over the years, ownership of PGP was transferred from Network Associates to McAfee, and is now owned and commercially licensed by Symantec.  Throughout that development, Townsend Security has helped to bring this important encryption technology to IBM enterprise platforms. We have partnered with Symantec to offer the only commercial version of PGP Command Line on the IBM i.

In their podcast, Paul and Patrick discuss the OpenPGP standard and the two solution versions of PGP, Open and Commercial, and the confusion around them. OpenPGP is a standard (RFC 4880 & RFC 2440), not software, and that standard covers what an Open PGP solution is and should do. There are multiple open source editions for software, available from a number of different organizations, that should meet the OpenPGP standard.

The commercial version from Symantec was created and continues to be advanced by the original PGP developers. It conforms to the OpenPGP standard, and it adds additional functions that are important to enterprise customers.

For example:

• Additional decryption key support (the ability to encrypt a file for multiple recipients)

If you need to send and recover an encrypted file to yourself for due diligence, your ability to recover that encrypted file through additional decryption key support becomes an important regulatory component.

• Self-decrypting archives (the ability to encrypt data and send it to almost anyone for processing)

You can create an encrypted file on your system, even on IBM z mainframe or IBM i platform that can be decrypted as an executable on a Mac system, a Windows PC, or even a Linux box.

• Support for X.509 Certificates, external key management protocols, and the ability to actually store encryption keys on an external server.

With the Commercial PGP product comes full support for OpenPGP standard, as well as these additional features, which really make a difference for enterprise businesses. When you base your company reputation on something mission-critical like PGP encryption, you deserve the comfort of knowing that there’s a support team there ready to stand behind you.

“Pretty Good Privacy” is well recognized and accepted across a broad number of compliance regulations as a secure way to protect sensitive data as it is in transit to your trading partners. PGP encryption helps businesses meet PCI DSS by encrypting credit card numbers and other PII as required by HIPAA/HITECH Act, Sarbanes-Oxley, and FISMA compliance regulations.

Listen to the podcast for more in-depth information and a discussion on how PGP meets compliance regulations with it’s NIST certifications, and how Townsend Security, the only Symantec partner on the IBM i or AS/400 platform as well as the IBM z platform providing PGP Command Line 9, can help IBM i users with PGP!

If you have topics you would like to hear discussed in future podcasts, please email them to us at podcast@townsendsecurity.com or post your comments here in the blog!

Easily Meet Compliance Requirements...
...with Secure Managed File Transfer

We did a survey almost a year ago of IBM i customers and just about half of them said “yes, we’re transferring data”...
“no, we’re not protecting it”... “yes, we know we have a problem”!

One of the easiest ways for an organization to have a Big Security Win is to secure sensitive data using secure managed file transfers. When unencrypted sensitive data moves off your IBM i to internal servers, public networks, or service providers via the Internet, the data is vulnerable to malware and other attacks. Unencrypted data (also called “data-in-motion”) is extremely vulnerable to a breach. This is a critical issue for companies that must transfer sensitive data such as credit card numbers, financial information, and other personally identifiable information (PII). Sensitive data is covered under industry and many state data security regulations and any organization, no matter the size, collecting and transferring data is required to protect that information.

According to compliance regulations such as the Payment Card Industry (PCI-DSS version 2.0 Section 4), organizations must always encrypt credit card numbers as they are transferred from one location to another. PCI DSS applies to everyone - both public and private companies (large and small) - that accepts credit card payments.  PCI-DSS version 3.0 will be released this fall, and we will be talking about that more as that time approaches. While PCI-DSS applies to credit card information, other regulations cover different elements of PII.  HIPAA/HITECH Act addresses protected health information (PHI), but while it does not mandate encryption, it does state that the only safe harbor from data breach notification and severe penalties & fines is to protect PHI with encryption. Sarbanes-Oxley (SOX) applies to all publicly traded companies in the US and has a component (section 404) that applies to IT systems and best practices around protecting data. The Federal Trade Commission (FTC) has also been active in the area of data breaches where it applies to published privacy statements. They consider it an aspect of consumer fraud if companies are not following their published guidance around privacy.

So what are the “must-haves” for meeting compliance around securing sensitive data that will stand up to scrutiny in terms of any kind of outside audit, challenge, or data breach?  PGP (Pretty Good Privacy) encryption is the industry standard for encrypting data-in-motion. Secure file transfer protocol, also known as SSL FTP or SSH sFTP, is often combined with PGP whole file encryption as part of a core solution to ensure that the data-in-motion is encrypted and remains encrypted after being transferred to trading partners. While data is transferred via secure SSL connection, keep in mind it is important that the sensitive data lands encrypted at its final destination. For a much more technical look at all of these components, I’m sharing a recently recorded webinar on Secure Managed File Transfer with you, and as always, please post any additional questions you may have here in the comment section!

Specifically for IBM i users, the following webinar will cover how easy it can be to meet compliance regulations with a Secure Managed File Transfer solution. You can also learn more about how PCI-DSS, HIPAA, Sarbanes-Oxley, and new state/federal laws affect your company and discover real-life examples of how others are meeting these challenges with Alliance FTP Manager and the PGP solutions.

During this 45-minute webinar, Patrick Townsend will also discuss core components of a total encryption strategy and show you how to:

• Automatically transfer files using Secure Shell sFTP or Secure SSL FTP
• Send your first encrypted file in an hour
• Review detailed audit trails of all transfer activity

… just a reminder on our special offer in August:

For the remainder of the month of August, Townsend Security will provide additional help to our new customers, or customers licensing new modules of Alliance FTP Manager, by implementing their first secure FTP project.  This means our team of security experts will help you fully implement your first secure transfer.  Working with your IT team on your IBM i platform, we will help you do the configurations, do the transfer, set up DCM if that is required, and sFTP and SSL FTP configurations. This full set up will get your first transfer done very quickly and you will be able to see the success right away!

Contact us about how to take advantage of this limited time offer: Just fill in the fields below, click the blue button... and Ken will contact you!

Data security has come a long way within just the past few years.  

Information is the lifeblood of business, and strong protection of your customers personalrecords is a constant task since data always gets out. When data is breached, business executives and organizational leaders come under immediate scrutiny for their commitment to secure and protect sensitive data.

This vital information requires continuous and effective protection while it is stored or transferred during any dynamic transaction all the way through to storage, archival, and successive retrieval.

Data security is a daily dilemma for CSO’s, IT & risk management departments, regulatory and compliance auditors. These security professionals are experiencing the ramifications of data breaches due to aging implementations, lack of consistently implemented controls and processes, and risk management evaluations.

Organizations no longer have to continue to maintain current patchwork methods because there are cost-effective, interoperable solutions available that can easily solve their problems and security needs.

Top Three Needs to Solve

• I need a solution that’s affordable and quick-to- deploy.
• I need an encryption key manager that distributes encryption keys across all my system platforms.
• I need an implementation with known costs and no additional professional service or connectivity fees.

When data is accessed without authorization, the details are illegible in encrypted format without access to the secure encryption key.  Encryption key management is essential within an enterprise or cloud-computing environment to ensure protection and privacy for your customers and your business.  Fortunately, encryption and encryption key management are now industry standards and work across both legacy and newer business systems, multi-platform and multi-tenant networks, remote access workstations, geographical offices, data centers, and third-party business partners.

Need to learn more about the principles of effective encryption key management?

• Encryption Methodology
• FIPS 140-2 HSM Certification
• Separation of duties and dual-control
• Encryption keys (type/size, creation, lifecycle)
• Authentication options
• System logging and file integrity monitoring

You are invited to download the latest white paper Industry Must-Haves for Effective Encryption Key Management authored by Joan Ross. Ms. Ross is a well known security expert, who participates and presents at a number of cyber security, key management, and encryption conferences and seminars. She holds numerous security certifications including the NSA IAM-IEM, CISSO-ISSAP, HISP, and FTK.

This white paper will discuss the top three security needs businesses must address. It will then outline how businesses can meet these needs using ‘must-haves’ such as industry standard encryption and key management, key management best practices, and solutions that are easy to use and cost-effective.      

As we discussed in the blog Understanding System Logging on the IBM i – Part 1, secure system logging on the IBM i (AS/400) can not only help you meet compliance requirements, it can help you stop a data breach before it happens!  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: Can you pick which group of users to audit?

Patrick: In our current version of Alliance LogAgent, our IBM i system logging solution, you can define a list of “excluded users.”  So you can actually tailor events on the IBM i platform and exclude particular user profiles.  We also provide some basic filtering capability allowing you to filter based on IBM event type and on User event type.  So yes, there is a fair amount of filtering capability in the product.  From a security posture, it would be a mistake to filter out significant security events, however the solution allows you to easily choose and select the events you want.  We have an option that maps straight to the security system values so you can easily set LogAgent to process those or you can establish and select any and all of the event types in the product that you want to monitor.

Q: With all the different IBM system events, is it possible to set up filtering of just the IBM security event types?

Patrick: Yes, In our solution, collection of the system security events is set as the default “out of the box” setting.  You have total control over the events you collect, and with just a few keystrokes, you can re-map your collection and filter in additional events, or leave it set to what IBM identifies as the security type events being collected in QAUDJRN.

Q: Can File Integrity Monitoring (FIM) also monitor read access to a database file? What about a user that comes in from another server doing just a select in SQL?

Patrick: The File Integrity Monitoring component in LogAgent is based on a database journal. A record-level read event is not collected in a database journal; but a file open and closed event is collected.  So if a user does access a file through read and there’s no update, insert, or add type of event, it may not appear in the journal. We capture all the information that the system makes available to us in the file integrity monitoring component on significant changes or access to any protected file.

Q: You mentioned File Integrity Monitoring. Can you further explain how an organization would use it?

Patrick:  File Integrity Monitoring is designed to monitor configuration changes and highlight them for early detection.  Generally, when an attack happens on an application it often involves changes to configuration files in an attempt to escalate privileges and give the attacker more authority or access than they should have.  For example if a new user is suddenly granted authority in the HR application to print checks, that is an important indicator of a potential problem!  Another common use for File Integrity Monitoring is to monitor the use of stored sensitive information (credit card information or social security numbers) on your IBM i platform, you would want to use FIM on those databases or applications in order to strengthen your security stance and identify those potential attacks early on.

Q: How do you keep QAUDJRN entries from flooding the network?

Patrick: With the large volume of events that can be collected by QAUDJRN, you can really help minimize network impacts by filtering out events that are not security related.  You can still collect those events, but exclude them from being transmitted to your SEIM console.  Because LogAgent works in real time it helps reduce the impact on your network because you are not transmitting millions of events all at once. We also provide metering capabilities so you can reduce the number of events per second that are being transmitted.

Q: How do these logs get stored?

Patrick: When it comes to log storage, you want them off of your IBM i platform as quickly as possible to avoid potential tampering or corruption.  With LogAgent, we do not make a copy of the events, we take the filtered events out of QAUDJRN in real time, format and transfer them to your log collection server or SEIM.  Since some compliance regulations require the events are stored for a defined period of time, SEIM consoles compress, store, and protect those log events so you have the ability to do forensics, queries, and reporting on them.

To learn more, view our webinar "Understanding Log Management on the IBM i" which examines the security principles, compliance requirements, and technical challenges for log collection and forwarding on the IBM i platform with the following learning objectives:

• Security principles of log collection and monitoring
• Compliance requirements of PCI DSS, HIPAA/HITECH, SOX, GLBA/FFIEC
• Communicating with log collection and SIEM servers
• File Integrity Monitoring and log collection
• IBM i log collection challenges

Secure system logging on the IBM i (AS/400) can not only help you meet compliance requirements, it can help you stop a data breach before it happens!  Intruders may start with a password hack that gives them access deeper into the system.  There is usually a long trail, visible within system logs. Everything from the original breach can be detected and identified with proper monitoring of the system logs.  What really is driving the need to collect and monitor system logs centers around how often breaches are easily detected with log management.  For example:

• Less than 1% of the breaches were discovered through active log analysis
• Forensics showed 69% of these breaches were detectable via log evidence

PCI Section 10 requires logging for anyone who collects credit card data

Requirement 10:  
 “Track and monitor all access to network resources and cardholder data”

• 10.1 Establish a process for linking all access to system components (especially access done with administrative privileges such as root) to each individual user.
• 10.2 Implement automated audit trails for all system components to reconstruct the following events:
• 10.3 Record at least the following audit trail entries for all system components for each event:
• 10.4 Using time-synchronization technology, synchronize all critical system clocks and times
• 10.5 Secure audit trails so they cannot be altered.
• 10.6 Review logs for all system components at least daily.
• 10.7 Retain audit trail history for at least one year, with a minimum of three months immediately available for analysis.

GLBA / FFIEC recommends data security logs of actions that could affect financial reporting or fraud for financial institutions.

• Network and host activities typically are recorded on the host and sent across the network to a central logging facility.
• The logging facility may process the logging data into a common format. That process is called normalization. Normalized data frequently enables timely and effective log analysis.

(This Link provides more information about FFIEC recommendations for logging)

HIPAA / HITECH ACT requires system logs of access to Protected Health Information (PHI) in the medical sector

• LOG-IN MONITORING (A) - § 164.308(a)(5)(ii)©

…the covered entity must implement: “Procedures for monitoring log-in attempts and reporting discrepancies.”

• Access controls - § 164.312(b)

(section b) Standard: Audit controls. Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use electronic PHI.

There are other compliance regulations and protocols that apply, but they all say about the same thing … you should be collecting system logs, you should be monitoring them, and you should take action based on anomalies that you find in them.  It is not enough to assert that you are doing the right thing; you have to be able to prove it with system logs that are independent from the original system files and verifiable.

System logging is important across all operating systems, but we are going to look at IBM i with greater detail due to it’s complexity.  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.

Creating the QAUDJRN (Security Audit Journal) on the IBM i

QAUDJRN is not created or enabled by default on the IBM i platform.  If you have not set it up, you are not yet collecting system logs.  To implement system logging you create the journal and journal receiver, then set system values that control options about what information is collected. Once the values are set, the collection process begins.  QAUDJRN is non-modifiable and date-stamped and a large amount of useful information can be collected in each event.  However just running system log reports on the security audit journal are not enough. Centralizing events and monitoring them off the IBM i platform are crucial. The events need to be consolidated and correlated in a separate location (usually a SIEM Console) in order to see the whole picture and understand potential attacks on your system.  

Take Away:
If you are properly collecting and monitoring your system logs, you can detect a breach before data is lost.

To delve deeper into this topic, we are sharing this newly recorded webinar in which, security expert Patrick Townsend talks about system logging on the IBM i today and how the capabilities of Alliance LogAgent can provide you with a high performance, affordable solution that will communicate system logs securely between your IBM i and Security Information and Event Management (SIEM) Console.

As always, we welcome your questions and comments posted here!

Four steps to better encryption key management in the retail environment

When the PCI Security Standards Council released the Payment Application Data Security Standard (PA-DSS) in 2008, the security of payment applications took a big leap forward. Today, All retail ISVs providing payment applications must certify their products with PA-DSS (which requires encryption and encryption key management for applications that process credit card data). Merchants expect this level of certification in payment applications they use, and their customers expect personal information to be secured.

Yet time and time again we see news reports about retailers experiencing data breaches through their payment application software. These breaches tell us that PA-DSS certifications alone don’t always equal good security.  

Here are four steps you can take on the road to better security:

1 ) Be Aware of Security Issues

In the rush to meet PA-DSS requirements for credit card encryption, many payment applications incorporated just enough technology to pass the certification requirements around encryption of sensitive data, but not enough to stay current with encryption key management best practices.

Do your payment applications incorporate critical components of encryption key management including:

• Tested and certified encryption key generation techniques
• Physical and logical protection of data encryption keys (DEK)
• Protection of data encryption keys by key encryption keys (KEK)
• Proper management of the life-cycle of encryption keys
• Certification of key management solutions to international 
standards such as NIST, FIPS 140-2, and KMIP

2) Use Security Best Practices

In order to protect customers from data breaches and prepare for evolving compliance requirements, retail ISVs should strive to meet these encryption and key management best practices:

• Use Strong Encryption
  The Advanced Encryption Standard (AES) is the standard when it comes to data encryption. AES has been adopted as a standard by the US government and is the recommended encryption method for PCI, HIPAA/HITECH, GLBA and individual state privacy regulations.

• Use Key Management Best Practices
  Your encryption is only as good as how well you protect the encryption keys. Encryption keys should be secured away from the encrypted data using an external piece of hardware such as a hardware security module (HSM).

• Use Certified Solutions
  Always use NIST validated AES encryption and FIPS 140-2 certified encryption key management. These certifications ensure that their key management has been tested by a third-party against government standards and will stand up to scrutiny in the event of a breach.

3) Pick Your Partners Wisely

Townsend Security has redefined what it means to partner with a security company:

• With our NIST validated and FIPS 140-2 certified encryption and encryption key management solutions, retail ISVs can offer their customers easy, affordable, and powerful data security.
• Our dedicated team provides our partners with extensive training, back end support, marketing materials, and a cost effective licensing model. You focus on what you do best, and we’ll help you turn encryption and encryption key management into a revenue generating option to help build your business and protect your valued customers.
• We have more than 20 years of experience supplying encryption and key management solutions to over 3,000 companies worldwide.
• We help our customers achieve data privacy compliance at an affordable price and with a personalized touch.

4) Download the eBook “Overcoming Critical Security Issues”

This eBook resource is designed to give you the tools and information needed to have a high-level discussion about data security in your company. Click the button below to request your complimentary download!

What exactly is data security and encryption & key management, and why care about it? 

Interesting conversation this morning as I walked from the parking lot to my office building.  Another person from one of the eight companies that occupy this building and I walked in together and chatted... first it was just “looks like the weather is getting better”... then it moved to “what floor are you on?  what company?” and when I told her ‘Townsend Security’, she said “oh, I’ve always wondered what you folks do”...

As the newest staff member, I wasn’t sure I had perfected my 30 second elevator pitch, but I told her that we were a data encryption company and design the software (and provide hardware) that almost everyone needs to protect themselves from a data breach. At first her response was “oh, we don’t need that, we have a guy that takes care of our computers”. Then we talked about how high the statistics are for people who would experience a data breach ("In 2010, if you received a data breach notification, your odds of being a fraud victim were one in nine. Last year, that jumped to one in four."), and after asking if they had a database and if they kept any records that held personally identifiable information (PII) or credit cards, it quickly became “I think we need that!”.

It reminded me that when I started working here, I wasn’t fully aware of many of the reasons or regulations that make data encryption so important.  I’m not sure I will ever have a complete technical understanding of all the nuances, but I’m working on it... Luckily I work with incredibly brilliant people who daily do all of the hard programming work and are very passionate about encryption.

I am lucky enough to be working with a company that I believe in, doing work that I know is important and can really make a difference in peoples lives. One of the main reasons I love this job... all the wonderful people that I work with, people so passionate about data security and the positive impact we can have on other people’s lives!

The founder, Patrick Townsend, impressed me so much at our last staff meeting when he reminded everyone to really think about why we are here, why we do what we do.  “It isn’t about selling a product.  It isn’t about the bottom line.  It is about protecting people from the devastation that a data breach can have on their individual lives.  It is about making sure we help companies protect their customers and clients.  It is about stopping the bad guys from wrecking havoc by making it impossible for them to get what they are after.  That is why we are here, remember that”.

Think about what your company does with the data you collect.  Is it encrypted and secure when it is “data at rest” (just sitting on your server)? How about when it is “data in motion” (being transferred to someone else)?  Look into what is happening with your information, and if you depend on someone else to take care of it, make sure they are doing it right.

Data gets out. Period. Either by accident or by design (someone hacking into your information). Make sure that when it does get out (and unfortunately it is “when”, not “if”) that it can’t be read.  You can make that data useless by encrypting it.   Remember to keep the encryption key stored in a different location than the data (encryption key management 101) because you wouldn’t lock up your house and then tape the key to the front door or leave it under the welcome mat!...  Would you?

If you aren’t sure what encryption or key management is all about.  We have a wonderful resource section on our website, and I’ve gathered a collection of some great Key Management resources right here.

Check out the information we have on data security and encryption key management and then contact us with questions, we are here to help!

What Standards for PCI Encryption You Need To Know and Why They Matter

Payment Card Industry - Data Security Standards (PCI-DSS) require you to encrypt credit card account numbers stored in your database and ensure data stays secure when transferred outside your company.

In order to understand these PCI encryption requirements, we first should know the source of industry best practices for encryption key management. Here in the US, the National Institute for Standards and Technology (NIST) is the most common source for guidance on best practices. The NIST special publication SP-800-57 provides specific pointers on how best practices for both procedurally managing encryption keys, and what to look for in key management systems. In these documents you will find the genesis of most standards regarding encryption key management, including the following concepts in PCI DSS 2.0 Section 3.  Next, it is important to understand the security best practices concepts of Dual Control, Separation of Duties, and Split Knowledge. I’ll simplify them here from the point of view of encryption key management:

1. Dual Control means that no one person alone should be able to manage your encryption keys. Creating, distributing, and defining access controls should require at least two individuals working together to accomplish the task.
    
2. Separation of Duties means that different people should control different aspects of your data protection strategy. This is the old adage “don’t put your eggs in one basket”. The person who creates and manages the keys should not have access to the data they protect. And, the person with access to protected data, should not be able to manage encryption keys.
    
3. Split Knowledge applies to the manual generation of encryption keys, or at any point where encryption keys are available in the clear. More than one person should be required to constitute or re-constitute a key in this situation.

In order to meet standards for PCI encryption, you need to make sure you protect these three things properly:

1. Protect your data at rest with AES Encryption
   Advanced Encryption Standard (AES) has been adopted as a format standard (FIPS -197) by the US government and many state and local agencies when it comes to encrypting data in a database. AES is the recommended encryption method for PCI-DSS, HIPAA/HITECH, GLBA/FFIEC and individual state privacy regulations. Encryption methods approved and certified by the National Institute of Standards and Technology (NIST) provide assurance that your data is secured to the highest standards.  
    
2. Protect your data in motion with PGP Encryption
   PGP encryption is the standard when it comes to encrypting files that need to be transferred.  Pretty Good Privacy (PGP) is the standard for encrypted file exchange among the world’s largest retail, finance, medical, industrial, and services companies.  Also know that when encrypting a file with PGP, you may be using AES encryption.  Transmit sensitive files over the internet using trusted encryption technologies. (AES, SSH, SSL, and PGP). Encryption solutions work together to ensure that all your sensitive data is secure even after the transmission is complete.  AES will protect data at rest within your organization and PGP keeps it secure when it is sent outside your company.
    
3. Protect your encryption keys and your data by keeping them apart!
   Leaving your encrypted data and keys in the same place is like leaving the key to your house under your welcome mat.  Security best practices require that you store encryption keys separately from your encrypted data and managed with an encryption key manager. It is also important to note that. In regards to the cloud, PCI SSC recently offered this guidance:
   In a public cloud environment, one Customer’s data is typically stored with data belonging to multiple other Customers. This makes a public cloud an attractive target for attackers, as the potential gain may be greater than that to be attained from attacking a number of organizations individually. Strong data-level encryption should be enforced on all sensitive or potentially sensitive data stored in a public cloud. Because compromise of a Provider could result in unauthorized access to multiple data stores, it is recommended that cryptographic keys used to encrypt/decrypt sensitive data be stored and managed independently from the cloud service where the data is located.

Download the whitepaper Meet the Challenges of PCI Compliance and learn more about protecting sensitive data to meet PCI compliance requirements.

At Townsend Security, we ensure our customers data is secured to the highest level for compliance. Our AES encryption solutions are NIST validated and our encryption key management solutions are FIPS 140-2 certified.  Our HSM appliances integrate seamlessly with Windows, Linux, UNIX, IBM Power Systems and Microsoft SQL Server 2008/2012 (enterprise edition) and can also work with earlier/non-enterprise editions of SQL Server.

As always, if you have comments or questions about PCI encryption, please list them here

The way organizations are managing encryption keys is falling under more scrutiny by Payment Card Industry (PCI) Qualified Security Assessor (QSA) auditors.  Companies must demonstrate they are enforcing dual control and separation of duties in order to protect sensitive data. 

Here are the answers to three of our most frequently asked questions about encryption key management on the IBM i:

Is it still effective to use an integrated key management solution that stores encryption keys in the same partition as the encrypted data?  
The short and simple answer is No. There are many reasons why storing an encryption key on the same server that contains protected data is not advisable. This is not just an IBM i issue - it spans all of the current major operating systems. Let's explore this a bit more in the following sections.

How do IBM i users manage encryption keys according to PCI requirements with an encryption key manager?
Payment Card Industry - Data Security Standards (PCI DSS) requirement states the following requirements for encryption key management:

• Dual Control means that at least two people should be required to authenticate before performing critical key management tasks.

• Separation of Duties means that the individuals managing encryption keys should not have access to protected data such as credit cards, and those that have access to protected data should not have the authority to manage encryption keys.

How are the “dual control” and “separation of duties” requirements achieved on IBM i?
On the IBM i you simply can't achieve these PCI requirements if you store the encryption key in the same partition as the protected data.  

The QSECOFR user profile (and any user profile with *ALLOBJ authority) will always have complete access to every asset on the system.  An *ALLOBJ  user can circumvent controls by changing another user's password, replacing master keys and key encryption keys, changing and/or 
deleting system logs, managing validation lists, and directly accessing database files that contain encrypted data.  

From the perspective of PCI, an integrated key management system puts too much control into the hands of any one single individual.
The only way to comply with PCI requirements for key management is to store the encryption keys off of the IBM i.  Take users with *ALLOBJ authority out of the picture completely.  When you use a separate appliance to manage encryption keys you can grant a user access to the protected data on the IBM i and deny that same user access to the key manager.  Now you have enforced separation of duties.  And with the right key management appliance you can require TWO users to authenticate before keys can be managed, and have dual control of encryption keys.

Now it’s time to ask yourself a few questions!

• Is your organization encrypting data on IBM i?  

• If so, how are you managing the encryption keys?

• If you store the keys on a separate partition, have you had a recent PCI audit?  

• What did your auditor say?

If you aren’t sure of the answers, or if this still seems foreign to you, take a few minutes to download our eBook "Encryption Key Management Simplified”.

Whether you are an IT administrator or a business executive, this resource will help you learn the fundamentals of:

• What is encryption key management

• Key management best practices

• How to meet compliance regulations (PCI-DSS, HIPAA/HITECH, GLBA/FFIEC, etc.) with encryption key management

• How encryption key management works on every platform including Microsoft SQL Server '08/'12, Oracle, and IBM i

  As always, we welcome your comments and suggestions!  Let us know what you think of the eBook!