View Recorded Webcast: Automatic Encryption on IBM i View this webinar to learn how easy automatic encryption with FIELDPROC is on your IBM i. Click Here to View Now

Simplify your encryption project.  Encrypting data easily, automatically and securely on the IBM i is possible using the new encryption capabilities with V7R1 and AES/400. I recently sat down with Patrick Townsend, Founder and CEO of Townsend Security to ask, what are the five things customers need to know to help their organization automatically encrypt sensitive data on IBM i V7R1 with AES/400?  For even more information on automatic encryption on the IBM i, view our webcast below!

1.What is FIELDPROC?

In release V7R1 of the IBM i operating system IBM enabled it’s customers to implement automatic encryption using a new column-level API called FIELDPROC. FIELDPOC is an exit point that sits at the column level of the database and enable IBM i users to implement encryption and decryption without making any changes to their application source code.

2. We’re at V7R1, now what?

Upgrading your operating system is a start, however, IBM doesn’t provide the actual exit point software IBM i shops need to automatically encrypt and decrypt data - third party vendors and customers must do this.  Townsend Security’s AES/400 solution enables organizations to implement automatic encryption.

AES/400 and the FIELDPROC exit point in V7R1 give companies to easily encrypt sensistive data.  We call it automatic encryption, because it is the easiest, fastest and most secure way to encrypt data on the IBM i.

3. What types of data can be encrypted?

IBM i database applications use a variety of fields to store sensitive information. Encrypt fields that store data such as credit card numbers, SSN, birth dates, address, account numbers and other PII instantly without impacting applications.

Alliance AES/400 FIELDPROC support will protect any of the above mentioned fields without changing your database or your business applications. There is no need to reformat your database, or expand field sizes.

While most IBM i customers will use FIELDPROC encryption with legacy RPG and COBOL applications, FIELDPROC support also works with SQL applications, and Alliance AES/400 supports both program models concurrently. Your ILE and OPM applications will work well with FIELDPROC data protection. You do not have to have the source code for your application to implement Alliance AES/400.

4. Are there any security risks with automatic encryption using FIELDPROC?

Native IBM i object or user authorities will not protect encrypted data.  Automatic encryption and decryption works for all users and applications. Administrators cannot rely on native IBM i object or user authorities to control access to protected data, additional controls and policies must be put in place.

Data masking simplifies access control for security administrators.  It allows administrators to define which users and applications should have access to data and exclude users or applications that should not.  Security administrators can define users who should have access to the data, and define a default policy that masks the data for others

5. Will automatic encryption impact performance?

The IBM FIELDPROC exit point works by calling the exit program for each database insert, read, or update. The exit point program is also called on certain query and file positioning operations.  The right encryption solution can help minimize impact to system performance. Alliance AES/400 FIELDPROC support has been optimized for performance. The Alliance AES/400 encryption APIs are capable of encrypting 1 million credit card numbers in less than one CPU second. They are highly optimized for performance, and perform up to 100 times faster than equivalent IBM APIs on the IBM i platform. These same Alliance AES APIs are used for FIELDPROC encryption.

For more information on automatic encryption using FIELDPROC on the IBM i, view our webcast.

The modern enterprise runs on a variety of computing platforms. The concept of being "an IBM shop" has gone the way of the buggy whip. With cloud computing and virtual machine technology, you may not even know what your hardware base is. This has caused  those seeking to realize the benefits of standardization to shift their focus to the software.

Take, for example, the need for securely transferring files, both within the organization and between trading partners. In the UNIX-Linux-Windows world the de facto standard for secure file transfer is undoubtedly PGP. The technology is mature and it is implemented on every significant OS variant in common use. It is extensively documented and familiar to a very large number of programmers and administrators.

But while the IBM shop may have disappeared, IBM servers have not. The enterprise is often built around mainframes and mid-range servers. And these servers now need to inter-operate with not only desktop PCs, but mobile laptops and cell phones. This makes the ability to settle on a single secure file transfer standard for the entire company more important than ever.

Fortunately PGP has spread to both the mainframe and mid-range platforms; IBM series z and i. And not just in a quirky slapdash port to UNIX emulation environments, but as fully supported native z/OS applications integrated with RACF and controlled via JCL.

With PGP it is possible to have all the advantages of a uniform secure file transfer approach without sacrificing any of the security and scalability of enterprise level platforms.

If you would like to download a free 30-evaluation of PGP for the IBM i or IBM z, let us know.  We'd be happy to show you how easy it is to encrypt with PGP and transfer to your trading partner.

We have made our plans to be at COMMON in Minneapolis. Have you?

It’s almost here, that time of year when IBM System i (AS/400, iSeries) customers gather as a community to learn and collaborate about what is new with the platform.  It's almost time for COMMON, the largest gathering of IBM i users in the US.  This year the event is in Minneapolis, not too far from Rochester, MN – best knows as the "home of the AS/400".   You could say the AS/400 faithful are returning to the mothership.

Of course we are planning on being at COMMON,  we look forward to attending it every year.  It’s a great opportunity for us to visit with many of our customers,  catch up with our peers and meet new members of the IBM i community.   In addition to exhibiting at COMMON, John Earl and Patrick Townsend will be presenting sessions on data privacy.  John and Patrick are regulars at COMMON and their sessions are always well attended.  Here are some details about what they are presenting and when.

Encryption 101, John Earl 
May 1, 11AM – 12:15PM
101 H Minneapolis Convention Center

Security Challenge: Let's Break In!, John Earl
May 3, 2PM – 3:15PM
101 H Minneapolis Convention Center

Data Security and Encryption, Patrick Townsend
May 3: 9:30AM – 10:45AM
101 H Minneapolis Convention Center

Tokenization, Patrick Townsend
May 3:  5PM – 6:15PM
101 H Minneapolis Convention Center

So, as you make your plans on who to visit in the Expo be sure to include us on your list -- booth #511.   We are anxious to talk to our customers and old friends and look forward to making a few new friends as well.  

There are a lot of exciting things happening with Townsend in 2011, new products are on the horizon and updates to our most popular products; AES/400, FTP Manager and Key Manager will be coming soon.  Be sure to stop by and learn more!   If you would like to schedule a one-on-one with John or Patrick, send an email to marketing@townsendsecurity.com and we’ll make sure to accommodate your request.

See you in Minneapolis.

Emerging Data Privacy Regulations

Organizations need to comply with an increasing number of data privacy regulations.  In addition to regulations such as PCI, HIPAA/HITECH, GLBA/FFIEC, and Sarbanes-Oxley, states are passing their own privacy laws.  For example, Massachusetts says that if you are doing business with anyone in their state, you must comply with their privacy law – even if your business is located across the country.  NIST-certified encryption and key management can help meet these emerging regulations.

I recently sat down with Patrick to discuss the emerging data privacy regulations - as well as how to meet them and what it is like to have an audit. 

There are lots of different data privacy regulations for people dealing with sensitive information.  Can you speak a little about each one?

You are right.  There are a lot of regulations and companies are finding themselves falling under more than just one.  Probably the one that most people know about is the PCI Data Security Standards (PCI DSS).  Any organization that accepts credit cards for payment falls under these regulations.  In the medical segment we have the HIPAA and HITECH Act, which sets the standards for protecting patient information.  In the banking and financial area we have the GLBA and FFIEC regulations which cover a broad set of financial institutions.  FERPA is for educational institutions.  Sarbanes-Oxley (SOX) covers any publicly traded company.  Finally, we have state privacy laws on the books and there are about 44 or 45 of them.  So you are right, there are a lot of different privacy regulations and there are over-lapping and different requirements for each regulation.

So, an organization can be faced with several different compliance regulations, is there any common solution?

You need to be aware of each one, though there are some overlapping definitions of what constitutes Personally Identifiable Information (PII).  It is important to follow proper encryption and key management best practices and make sure your solutions are NIST certified.  State Privacy Laws are starting to follow PCI guidance.  It is important to note that State Privacy Laws are now starting to extend beyond the boundaries of the state.

Do any of these regulations have any real “teeth”?

Oh, yes!  A data breach can have lasting financial and business impacts.  Just ask the companies who have had major data breaches.  One credible study by the Ponemon Institute estimates that TJ Maxx may eventually spend a total of about 9 billion dollars (yes, that’s billion with a “B”) as a result of their data breach.  There have been numerous fines levied against merchants, medical providers, and businesses related to data security breaches.  There are real financial penalties for these breaches.

Less well known is the fact that an embarrassing data security breach can sink your business.  If a big part of your business is based on Internet sales, for example, you can find your business disappearing in the event you have a data breach.

What is the process of undergoing an audit like?

Don’t panic.  It can be painful, but in most cases and audit involves a routine set of questions.  You can actually prepare for that experience.  It is good to know the configuration of your network and where things stand in terms of data protection.  Having good documentation on your policies, procedures, your network, and your business applications is going to be very helpful in an audit.  Also, you should see your auditor as an important partner in compliance.  A good relationship with an auditor will help get you through the process.  You can see your auditor as someone who can really advise you on best practices for securing data.

Also, your software supplier can be an important partner.  For example, we offer a lot of questions about compliance regulations and best practices when we work with our customers and prospective customers – trying to get them educated on what really is best practice.

Are there any emerging regulations that our listeners should be aware of?

Congress is working on a Federal Privacy law that would replace the 44 or 45 state privacy regulations. Businesses struggle to keep up with the differences between all of the state laws, and there is business support for passing a federal law. A version has passed the House of Representatives, and there are two or three versions pending in the Senate. These will have to get consolidated into a single law, and then rationalized with the House bill. But eventually I think this will happen.

I think we can make some predictions about how a new federal law will affect businesses. We already have a template in the HITECH Act of 2009. I suspect that the FTC or some other federal agency will be tasked with defining the data security regulations. It is highly likely that the National Institute of Standards and Technology (NIST) will be the basis for standards and certification of solutions. Then there will be published rules and guidelines on how to implement data protection.

If I am right about this, it will prompt businesses to be sure that their data protection solutions meet NIST standards. And I don’t mean sorta, kinda, maybe. You need to find solutions are NIST certified to FIPS-140-2 or similar standards with the paper certificates to prove it.

Download a 30-day evaluation of NIST-certified AES database encryption from Townsend Security

AES Encryption Performance: Avoid the High Cost of Poorly Performing Encryption Solutions

AES encryption has become the de facto standard for protecting data at rest in databases and unstructured data such as flat files, messages, EDI, and XML documents.  As enterprises deploy data security solutions to meet compliance requirements, they are frequently surprised by the performance impacts of encryption. Inadequate attention to encryption performance can lead to increased costs, delayed or failed projects, compliance failure, reduced flexibility to meet competitive challenges, and exposure to legal liability.

Whether you're evaluating an encryption solution or already encrypting data, these tips about encryption and performance will help ensure you have the right solution in place. 

Encryption - A Resource Hungry Application

By its very nature, encryption and decryption are resource intensive processes. Encrypting a simple credit card number requires many thousands of computer instructions. These instructions merge the input data with an encryption key using a large number of computer instructions to produce the secured data (called the “cipher text”). Because of the large number of computer instructions, an enterprise customer will experience increased utilization of computer resources and a need to consider adding additional capacity.

Ask for performance metrics

Armed with the knowledge that encryption performance is important, you can take action to avoid potential problems. Before acquiring an encryption solution, ask your data security vendor to provide performance metrics for their solution. How long does it take to encrypt one million credit card numbers? Can they provide you with source code and demonstrate this performance on your server?

The Hidden Costs of Encryption

Poorly performing encryption solutions can come with steep price tags as you secure more data in more places. You may have to add additional memory and increase the number of processors to handle the demands of encryption. As you upgrade your server hardware, the operating system vendor and application software vendors may increase the license fees they charge for their software. These cost increases may ripple through your backup and high availability systems. On top of increased hardware and software, your human resource costs also increase as you deploy larger and more powerful servers.

Are Network Encryption Devices a Good Idea?

Some security vendors provide encryption solutions on an external server as an encryption appliance. Each time your application needs to encrypt or decrypt data, a connection to the server is created and the data is transferred to the server for the encryption operation. Be sure to understand the maximum encryption rate of these types of appliances when doing a large number of operations. if it takes 5 milliseconds to transfer data to a server for encryption,
and 5 milliseconds to return the encrypted data, that 10 milliseconds can represent a performance problem.

Test Drive - not all AES encryption solutions are the same

Townsend Security's proven AES encryption solution encrypts data 94x times faster than the competition.   Request a free 30-day trial of our popular Alliance AES Encryption and see for yourself.

But don't just take our word for it, read what Staples has to say about their experience with our AES encpryption solution.

Case Study

A large multi-brand retailer, that sells its products online and in traditional retail outlets needed to meet PCI Data Security Standards for protecting customer credit card information. After evaluating several different vendors for performance they decided on AES Encryption from Townsend Security.  They deployed the Alliance AES/400 Encryption solution to protect sensitive data in DB2 database files and in a variety of unstructured data files and were able to achieve PCI compliance in record time.

Townsend Security Can Help

The best way to secure sensitive information is with strong encryption and key management. Townsend Security provides NIST validated encryption and logging solutions for the enterprise. Our encryption, key management, tokenization, and logging solutions protect sensitive data from loss, whether it is at rest or in motion.  With NIST validated and FIPS 140-2 compliant certified solutions, Townsend Security meets or exceeds the standards in PCI, HIPAA/HITECH, and state privacy laws.  Click here to download a free 30-day trial of our popular Alliance AES Encryption.

The Importance of NIST Certification for AES Encryption

Download a Free Trial Now

All Encryption is Not Created Equal

The National Institute of Standards and Technology (NIST) defines the standard for AES encryption, and provides a rigorous testing process for software vendors. The certification process is carried out by independent testing labs who report the results to NIST for validation.  The AES certification process tests every aspect of encryption and involves millions of encryption and decryption operations. Only the most dedicated security vendors are able to pass the tests and achieve NIST certification.  Townsend Security has achieved AES Validation for all key sizes and modes of operation, on every major Enterprise platform. 

How important is NIST validation?

Steve Tenore, a Senior IBM i Consultant for Staples, says "Staples wouldn’t even consider a vendor solution that didn’t have NIST certification. The fact that Townsend Security has NIST certified solutions on the major Enterprise server platform was a big plus."

Need encryption done right?  Insist on NIST.

In a study of the certification program, NIST found nearly 50 percent of software vendors had errors in their encryption solutions. It isn’t easy to get encryption right. A certificate of validation from NIST is your assurance that AES encryption does what it is supposed to do. Every time.

Certification Means Stronger Encryption

NIST certification is your assurance that a vendor’s AES encryption solution implements data encryption the right way. There are many ways to use encryption and a wide variety of modes of encryption. Improperly implemented solutions may work for one type of task, but fail under different application requirements. All software vendors claim they implement strong encryption. Can they prove it? Ask them for their NIST certification.

Certification Means Reliability

The NIST testing process is designed to exercise a vendor’s encryption solution under stress conditions. Large numbers of repeated encryptions are performed with the output of one encryption used as input for the next encryption. Failures in memory management or reliability will be exposed in the testing process. Encryption software may work without errors for 100 or 1,000 encryptions, but will it work on 1 million encryptions? How about 100 million encryptions?

No one wants the unpleasant experience of a system failure due to unreliable software. NIST certification helps provide some assurance of a reliable implementation. 

Download a free trial of our AES Encryption (available for IBM i, IBM z, Windows, Linux, and UNIX) and be guaranteed that you are using the most secure and best performing encryption available.

5 Commonly Asked Questions About Data Privacy

The job to protect sensitive data often falls in the hands of IT security administrators and their teams because of their technical expertise. We feel data protection is everyone's responsibility because every employee has an invested interest in maintaining their organization's good reputation with customers and partners.

We have compiled questions from discussions over the years with  customers and prospects to help people understand the basics of data privacy and why responsibility of maintaining data integrity goes beyond the IT department.  In addition to this list, we have produced a podcast with more information - download it here.

1. What constitutes personal information that we have to protect and how do businesses protect this information?

The first things people think of are credit card or social security numbers.  However, other pieces of information are equally as important.  Think about the things your bank asks you when you call them to talk about your account. Can you verify your phone number? The last four digits of your social security number? Your birthdate? Maiden name? These pieces of information can be used to commit fraud. 

The banks are using that information to identify you. And the fraudsters will use that information to impersonate you. The technical term for this kind of information is Personally Identifiable Information, or PII.

Businesses can protect data with a few different techniques involving third-party software solutions and implementing internal policies around who has access to data.

Vendor solutions can provide the ability to control who has access to data inside the company and prevent potential hackers from gaining access to your network.   Companies can also use vendor solutions to encrypt their data. Encryption is a process that takes sensitive information and runs it through a scrambling process. Once encrypted, your data can only be deciphered with a special key.  The data is useless to the person that attempts to steal it, unless they they have the key.

2. We’ve been hearing a lot about encryption and key management. How do they relate to each other?

They go together, they are complementary technologies. In addition to the raw credit card number, another very important input to the encryption is the secret key.  Without the key, no one can read the encrypted data. Many people think that an encryption algorithm itself is a secret mechanism, but that’s not the case. Encryption is well understood, there are standards for it and they’re readily available.  The secret that prevents malicious users from stealing data is the encryption key.

At home, the key to your front door is what protects you. Companies that use encryption have to create a key that is unique and strong, and then protect it to ensure it doesn’t get into the wild. Anyone who has the key can get the data. In the real world of protecting data with encryption, the encryption key is what users are taking care to protect.

3. What happens when the encryption is not done correctly?

There are many ways that encryption can be done incorrectly or poorly. We see that particularly around the area of encryption key management. One big mistake many people make is storing an encryption key on the same platform where the data are stored. Sometimes you hear the term integrated key management to describe this practice. Even if you lock down the database, keeping it on the same partition as your data leaves it readily accessible for potential cracking.

Other examples are using nonstandard or proprietary encryption. It’s important that a company buying encryption technology should vet their vendors carefully. NIST certified encryption is the best assurance that a solution meets your compliance requirements.

4. Are there any laws or regulations requiring businesses to protect their sensitive data?

Yes, there are quite a few, and many companies find themselves complying with multiple regulations. If you take credit cards, you fall under the Payment Card Industry standard. That’s a private regulation promoted by the credit card vendors such as Visa and Mastercard. If you’re a bank or engaged in the banking industry, you fall under Gramm-Leach-Bliley Act and FFIEC regulation for protecting data. In the health care industry, you fall under the HIPAA/HITECH acts.  FIRPA is the regulatory environment around educational institutions.

Individual states have passed data privacy regulations and defined data breaches and the penalties for them. And the federal government is moving laws through Congress to define protections for personal information. There are quite a number of regulations that define data that needs to be protected.

5. How would my organization develop a data security policy?

It’s a real challenge especially if you’re starting for the first time, it’s easy to feel overwhelmed when hearing about data breaches on a daily basis. Keep it simple to start. There are some things you can do that are very effective up front.  Rank where the vulnerabilities are. Here are just a few to help get you started:

1. Make sure you have good antivirus software on Windows and Mac.
2. Use good strong passwords. “1234” or “admin” are not good passwords!
3. Understand where your data resides and who has access to it.

Here’s another interesting thing, if you have a problem, it’s going to be your problem, not the vendor’s problem. It’s going to be your headache, your upset customers, and your financial loss. So pay attention to your encryption solution! 

Something that inhibits people from taking action is just thinking they are not subject to a data breach.  That’s a dangerous attitude. We've been saying it for years beause it's true - Data Gets Out. Encrypt it! 

Download the complete podcast here.

How Much Data Can You Encrypt with RSA Keys?

When someone first begins to consider using encryption to protect business data, they discover that there are two general types: symmetric (AES) and asymmetric (RSA). At first glance, which one you would choose can be confusing.

One of the differences between the two is speed. Symmetric encryption is much faster than asymmetric. The exact difference is implementation dependent, but may be on the order of 100 to 1000 times faster.

It is widely known that AES encrypts a 16-byte block of data at a time. However, how much data can be encrypted at one time with an RSA key is usually only discussed in vague terms such as “use RSA to encrypt session keys.” This raises the question of how much data can be encrypted by an RSA key in a single operation.

The typical encryption scenario is to encrypt with a public key and decrypt with the private key. OpenSSL provides the RSA_public_encrypt and RSA_private_decrypt functions to implement this.

The first parameter to the RSA_public_encrypt function is flen. This is an integer that indicates the number of bytes to encrypt. Its maximum value depends on the padding mode. For OAEP padding, recommended for all new applications, it must be less than the size of the key modulus – 41 (all in bytes).

To get the size of the modulus of an RSA key call the function RSA_size.

The modulus size is the key size in bits / 8. Thus a 1024-bit RSA key using OAEP padding can encrypt up to (1024/8) – 42 = 128 – 42 = 86 bytes.

A 2048-bit key can encrypt up to (2048/8) – 42 = 256 – 42 = 214 bytes.

Additional Resources for IT Developers and Professionals

We collaborate with developers and IT professionals around the world and know that they use a wide variety of languages and platforms to accomplish their work.  Our products include documentation, source code examples, and HOWTO guides for developers in order to help projects get done quickly. Visit our Developer Resources section of our web site to learn more and discuss your upcoming project with our development team.

 

 

The modern Enterprise deploys a variety of server platforms, operating systems, and programming languages.  A major barrier to deploying encryption has been the challenge of accessing encryption keys from these widely divergent environments.  Encryption key management solutions have the primary goal of managing and protecting encryption keys, and making them available to authorized applications in a secure fashion.

Key management solutions vary greatly in the complexity of the key retrieval process. The more complex the key retrieval interface, the greater the challenge for the Enterprise IT team in deploying key retrieval in applications. Understanding this fact can help IT decision makers assess different vendor solutions and the likely costs of deploying a solution in their enterprise.  Below is a list of questions that you should ask your key management vendor when assessing their solution.

Key Management Vendor Checklist

1.  Is your key manager FIPS 140 certified?  What is the certificate number?

2.  How would you describe the encryption key payload as retrieved from the key server?  Is it simple or complex?

3.  Is there a common key retrieval application interface on all platforms?  What are the differences?

4.  What platforms do you support for key retrieval?  (Note any gaps in platform coverage for your company)

5.  Do you provide working sample code for the platforms I need? (Windows, Linux, UNIX, IBM i, IBM z)

6.  Do you supply binary libraries for all Enterprise servers?

7.  Do you have a Java key retrieval class and examples? Is it standard Java or JNI?

8.  Do you charge separate license fees for each client operating system?

9.  Do you require that we purchase consulting services from you?  Why?

10.  I am an independent software vendor (ISV), can you brand the solution and certify the solution for us?
 
Once you have the answer to the above questions, it should be easier to choose the right key management vendor for your Enterprise. If you have any questions, click here and we will call you right back.

 

The new PCI Data Security Standards (PCI DSS v2.0) are here and we’ve gotten a lot of questions about the changes related to encryption key management. Because we work with a lot of companies going through PCI compliance audits and reviews, the new standards just confirm the trends we’ve seen over the last few months on how QSA auditors and security professionals view encryption key management, and what they see as the minimum requirements for managing keys. I recently sat down with Patrick Townsend, Founder & CTO of Townsend Security, to discuss the new PCI regulations in regards to encryption key management.  To hear an expanded podcast of our conversation, click here.

 

What is the source of industry best practices for key management?

 

The NIST special publication SP-800-57 provides specific pointers on 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 concepts in PCI DSS 2.0 Section 3.

Also, key management solutions are certified to the FIPS-140-2 standard for cryptographic modules. So FIPS-140 is a source of best practices and standards.

 

Dual control, separation of duties, and split knowledge have been buzz topics in the key management world lately.  What do they mean?

 

Well, 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.

 

Split knowledge is defined in the PCI DSS version 2.0 glossary as a “condition in which two or more entities separately have key components that individually convey no knowledge of the resultant cryptography key.”

 

Are there any standards or best practices regarding “integrated key management?”

 

“Integrated key management” is a term of art, and not a standard.  If “integrated key management” means “we store our encryption keys on the server where the data is,” then that is a bad thing, from a compliance and security point of view. 

 

So, what are the best practices for encryption key management?

 

First you should follow the key life-cycle and be able to document it.  You should always separate the keys from the data.  If you follow the PCI guidelines, you are in excellent shape.  Finally, I would recommend only using a FIPS 140 certified key management solution.

 

What are the practical implications of these best practices and core concepts such as “dual control” and “separation of duties?”

 

One of the practical implications follows from a common fact of system administration. On all major operating systems such as Linux, Windows, and IBM System i (AS/400) there is one individual who has the authority to manage all processes and files on the system. This is the Administrator on Windows, the root user on Linux and UNIX, and the security officer on the IBM i platform. In fact, there are usually multiple people who have this level of authority. In one study by PowerTech, the average IBM System i customer had 26 users with this high level of authority! You just can’t meet PCI and other industry standards for proper key management by storing the encryption keys on the same platform as the data you are trying to protect.

 

To download an expanded podcast of our conversation, click here.