Townsend Security Data Privacy Blog

Here at Townsend Security we’re always engaging with businesses and organizations who not only need to meet data security compliance regulations such as PCI-DSS, HIPAA-HITECH, and GLBA/FFIEC, but are also deeply concerned about their customers’ data and the protection of their own company’s brand in the event of a data loss. Compliance is often the main driver of encryption and encryption key management, but these days the fear of a data breach weighs heavy on my peoples’ minds. 

I recently spoke with a prospect who downloaded our AES Encryption Standards White Paper, and then decided to contact us. He was eager to find out about pricing and how AES encryption could work with his company. He told me about their need for encryption: he is very concerned about meeting HIPAA/HITECH and SOX Acts (both recommend if not require encryption and key management), and he knows his company’s data is unprotected in many critical areas. As he put it, they’re just waiting for something bad to happen. Although they are already encrypting much of their sensitive data (a great first step), they have outgrown their current encryption solution, need to encrypt more data, and are still out of compliance.

He said to me point blank, “We are sitting here with our pants down, waiting to be exposed!” 

I asked the prospect, “Well let me ask you an easy first question to make sure our NIST Certified AES Encryption fits you and your company’s needs.  What system are you currently running on?”  

His reply: IBM i, Power 7.  

I told him: WE CAN DO THAT!!

Townsend Security has a deep history with IBM i.  We have been working with IBM i systems for over 20 years. With the new FIELDPROC capabilities in IBM i V7R1, our AES encryption solution installs into an IBM i customer’s environment, provides both our optimized and certified AES encryption libraries, and the encryption key management you need to be compliant. IBM has done the hard work of making this capability available, and we do the work of snapping in proper encryption and key management.

Later in our conversation, we discussed risk management, cost and what would happen to the company if they were exposed.  He told his boss that they were subject to fines and damage to their company brand and would spend time remediating the breach instead of growing the business.  Protecting the company’s sensitive data not only protects the business as a whole, it also protects your customers who rely on and trust your company to protect their personal information.

To learn more about Townsend Security’s easy and automatic encryption and key management solutions for IBM i contact us day at 1-800-357-1019. Or if you’re not into picking up that heavy phone, contact Kristie Edwards (kristie.edwards@townsendsecurity.com) today, and we’ll make sure we do the heavy lifting on our end. You might also enjoy watching a recording of our recent webinar, "Top 3 IBM i Security Tips,” presented by data security experts Patrick Townsend and Patrick Botz.

With data breaches in the news every week, and each bigger than the previous, security is a top concern for system administrators, as well as business leaders.  As we have seen, a data breach can cripple an organization.  While the IT team performs forensics and updates their systems, the management team has to explain to investors why they weren’t adequately prepared and break the news that “Those big plans we had to grow the business in the next two years? Yeah, those are on hold while we remediate this breach.” 

While the IBM i (AS/400) is considered by many to be a secure platform, it is not immune to data breaches.  As a data security company, we see plenty of organizations think they are doing the right things to keep their data safe, but are falling down on a few key areas.  Below are the top three tips to keep your IBM i (AS/400) secure and your data safe:

1) Encryption and Key Management

Did you know that many compliance regulations consider an email address personally identifiable information (PII) and require it to be encrypted?  Security experts recommend using NIST-certified AES encryption coupled with an external encryption key management hardware security module (HSM).  With the introduction of FIELDPROC in V7R1, IT teams can now encrypt their sensitive data without application changes – saving development resources and time coming up with excuses to company leaders on why the company is still at risk.

For organizations who have been encrypting their sensitive data, security audits often find they haven’t been properly managing their encryption keys.  Encryption keys should never reside on an IBM i with encrypted data. We help more enterprises than you would like to know after they fail a security audit for improper encryption key management.   

2) Password Management

Password management continues to be a challenge for all organizations.  Poor management leads to insecure passwords and inconsistent policies – which in turn leads to more data breaches.  Fortunately for IBM i administrators, IBM realized this and made a Single Sign On (SSO) option as part of the OS – all administrators have to do is enable it.  Patrick Botz, former lead security architect and founder of the IBM Lab Services security consulting practice, regularly helps organizations enable SSO and eliminate 80% or more of an organization’s password management problems just using tools that IBM provides as part of the OS.  Additionally, there is a clear return on investment when an organization enables SSO, which makes you a hero when you tell management “I have a way to make our jobs easier and save money at the same time.”

3) Secure System Logging and File Integrity Monitoring

A recent study shows that 69% of data breaches could have been detected before any data was lost if proper system logging was in place. Maybe that is why most compliance regulations (PCI DSS, HIPAA/HITECH, etc.) require it.  So why isn’t system logging a common practice on the IBM i?  Simply put, the IBM i doesn’t log information like other systems.  There are some big challenges getting security information into a usable format and transmitted to a SIEM for monitoring.  Challenges an administrator faces with propriety IBM i logs:

• Data format – IBM security events are in internal IBM format, not syslog format.
• Multiple sources – Security events get collected in a variety of locations, almost always in an internal and proprietary IBM format.
• Timeliness – Tools are lacking to collect security events in real-time, increasing the security exposure.
• Communications – There are no native syslog UDP, TCP or SSL TCP communications facilities.
• Data completeness – While it is possible to print security information using IBM tools, critical information is missing from reports.

Fear not, there is a solution – Alliance LogAgent Suite with File Integrity Monitoring (FIM).  Alliance LogAgent Suite can send system logs to any collection server that is listening for messages.  Additionally, the FIM tools allow system administrators visibility right down to the field and column level, record-by-record, in their databases.

While this is by no means a comprehensive list of everything security-related an administrator should do to their IBM i, these three areas are where we recommend you start. If you are currently encrypting data, we challenge you find out where your encryption keys are being stored (it might scare you).  If you aren’t securing your systems with SSO, what are you waiting for?  Are you under a compliance regulation that requires system logging?  A complete system logging solution like our Alliance LogAgent Suite can be installed and running in an hour. To hear security experts Patrick Townsend and Patrick Botz elaborate on these three IBM i security tips, view our webinar “Top 3 IBM i Security Tips.”

When a solution integrator assesses a company's IT and data security needs, most solution integrators know that almost every single business will need to meet at least one set of data security compliance regulations. If it's a retail business, they'll need to meet PCI-DSS. If it's a bank or financial company, they'll need to meet FFIEC and GLBA. If the company is a healthcare organization, they'll need to meet the data security requirements of HIPAA-HITECH. 

All of these regulations require that entities protect their sensitive data. From names and addresses to credit card and protected health information, these regulations say that the only way to truly secure this data is with encryption--not just firewalls and strong passwords--but with AES encryption. Even more importantly, most industry regulations and laws state that if a company is using encryption and proper encryption key management, should that company have a data breach, they don't always have to report it.

Do you think the companies who had major data breaches last year wish they had known that little fact? We're guessing, yes. 

Unfortunately, there's a lot of false information out there about encryption and encryption key management. A common misconception is that hackers can break encryption. The truth is, hackers don't break encryption, they find the encryption keys. How do they find the keys? If the keys are stored on the same device that the encrypted data is stored on, or the keys are stored in an unsecured location that the hacker gets access to, once the hacker has the keys, he or she can "unlock" the encrypted data. 

It's a little bit like taping your house key to your front door and hoping that a thief won't find it there. It's wishful thinking. 

That's why encryption is considered only half of a solution. All companies encrypting data also must implement good encryption key management. 

Of course solution integrators want to know how offering their customers encryption key management services can grow their business. There's actually still a lot of hesitation around encryption key management as a service because managing keys was once a very difficult and costly thing to do. It even had a reputation for causing severe performance impacts on a network. Maybe that was true 10 years ago, but today encryption and key management technology is: 

• Easier than ever to implement on legacy platforms such as IBM i and Microsoft SQL Server 

• Cost effective

• Has very little impact on performance. 

That’s why offering encryption key management to your customers is always a good idea. Offering these technologies will not only grow your business. Encryption key management service will protect your customers and help them meet compliance (which they’ll be thankful for).

Townsend Security is a Microsoft Silver Partner and an Advanced partner with IBM, providing the only FIPS 140-2 certified key management solution for Pureflex. Want to learn more about encryption and key management for IBM platforms? Download the podcast on automatic encryption for IBM i below!

Anyone active in the IBM i community knows Patrick Botz from his time as the Lead Security Architect for the IBM i group in Rochester, Minnesota. Patrick worked for years promoting security best practices, and worked diligently to solve one of the more perplexing and complex issues for large accounts – Single Sign On (SSO). Everyone with a large number of users has felt the pain of managing lots of user accounts and passwords across a lot of different types of systems. For any organization with more than a few users, managing user accounts and passwords has traditionally been an expensive proposition.

But it is one that you can now tackle very effectively.

Because of a lot of work that Patrick did during his stint at IBM, IBM i customers now have the technology they need for Single Sign On (SSO). Yes, you have the technology you need, you just didn’t know it.

Patrick is now in private life providing services to customers who want to reduce their help desk costs for managing user accounts and passwords. You can actually get to an SSO solution without purchasing additional software, and Patrick can help you achieve this. His company, Botz and Associates, has an affordable, packaged services solution called SSO stat! that will get you up and running with SSO very quickly. And this is not a drive-by engagement. He focuses on knowledge transfer during the engagement so that you can make it on your own, and he provides a support offering in case you want to have his expertise on demand.

Password management continues to be a challenge for all organizations. Poor management leads to insecure passwords and inconsistent policies – and these lead to more data breaches. We can do better. And Patrick Botz can help you get there.

By the way, Patrick worked for years at IBM, but before that he was a UNIX kind of guy. Today his expertise spans UNIX, Linux, Windows, Mac, and IBM servers. We all have multiple technologies in our organizations and he can help you stitch them all together.

We just did a podcast together with Patrick on Single Sign On (SSO) that I am sure you will find interesting and I encourage you to listen to it now.

Disclaimer: Neither I nor Townsend Security has a financial relationship to Botz and Associates. We’ve hoisted a beer together, and I’ve seen his work at mutual clients. He’s someone I think you should get to know.

Patrick

1. Increased security of sensitive data

The number one advantage of File Integrity Monitoring (FIM) is increased security in your database(s). When you look at how data breaches happen, we often see a very similar chain of events. First, the data breach is discovered by someone inside the company, or a third party investigator. Second, the breach was discovered to have happened weeks, if not months ago. Third, the security holes in the IT infrastructure take several more weeks to plug. And finally, the database administrators discover that the breach could have been completely avoided using tools, such as file integrity monitoring. I won’t even go into the subsequent steps which also include data breach notification and paying hefty fines (an average data breach costs $5.5 million, by the way).

FIM allows you to see potentially harmful changes made in your database in real time. FIM helps you to detect early events by monitoring for changes to access controls, configurations, and all sensitive data at both database and application levels. For example, if you are storing social security numbers, credit card numbers, or other personally identifiable information (PII) on your IBM i, you can subject those fields to file integrity monitoring to catch any changes to that data immediately when it happens.

2. Comply with Industry regulations to pass your next audit

You should always know which data security regulations your organization must comply with. PCI DSS directly requires File Integrity Monitoring controls to prevent unauthorized access or changes to sensitive data (section 11.5). File Integrity Monitoring is also a critical component of the Sarbanes-Oxley (SOX) act for publicly traded companies. The Federal Information Security Management Act (FISMA) as well as the National Institute of Standards and Technology (NIST) also mention File Integrity Monitoring as a recommended security control.

3. Not a Matter of If, but When

There’s a really, really good reason why governments and industries are imposing more and more stringent data security regulations on both public and private organizations: the number of data breaches occurring every year is not slowing down. It’s speeding up! A common sentiment these days is that a data breach within your company isn’t a matter of “if”, but “when”. Think about it this way: How many times have you received a call from your bank informing you that your credit card has been compromised and they are issuing a new number? Once? Twice? Three times? More? The unfortunate reality is that even though data breaches run rampant like wildfire, many businesses are doing too little or nothing at all to protect their data. When the fire hits your business, I bet you won’t be thinking, “good thing I didn’t waste my time on fire alarms and home owner’s insurance!”

For more information on file integrity monitoring and meeting data security compliance regulations, check out our podcast, “File Integrity Monitoring on the IBM i”, featuring Patrick Townsend, founder and CEO of Townsend Security.

I had the pleasure of meeting Alison Burkill at the Help/System user conference recently and spending a few minutes talking with her about Power Systems security. Alison is the IBM Product Manager for software on Power Systems, and delivered a keynote speech at the user conference. The keynote was about all of the great new features of the Power Systems platform and it highlighted the security features that IBM has incorporated into the base Power Systems platform.

In our sit-down in the demo center I asked Alison one of my favorite questions - “What do you think is the biggest security pain point that IBM Power Systems customers face today?”

I was expecting a discussion about the security technologies that often trip up Enterprise customers – encryption, key management, system logging, log monitoring, and nitty-gritty stuff like that.

Nope.

She said that IBM customers are always taken by surprise when they fail a security audit. IBM systems have a reputation for great security and when IBM customers fail a security audit they are dumbfounded that it can happen to them.  Education, she said, might be our biggest need.

I agree. And I think I know why IBM customers are often shocked when they fail an audit:

• IBM Power Systems do have a great reputation for security and that can lead to a false sense of comfort. I can assure you that IBM systems are not immune from security breaches and data theft.

• Compliance regulations are not written on a platform-by-platform basis. There is no carve-out that exempts IBM customers from meeting data security requirements. A compliance auditor expects you to meet the same requirements as every one else on every other platform.

• It is a rare security auditor who has deep experience with the IBM Power Systems platform. They are going to be skeptical of your claims that the IBM platform is more secure than any other.

• IT professionals often do not have a lot of background and training in regulatory compliance. This is a gap in our education, and Alison is right that we are often only vaguely aware of what regulations require.

• Lastly, as technologists we have a tendency to program first and ask questions later. We can make simple mistakes, like storing encryption keys on the same server as protected data and not realize that we’ve violated a core precept of data protection. We might be using the latest and greatest API from IBM, but not be meeting compliance requirements. It happens a lot.

And there you have it, the perfect setup for the compliance audit surprise! In fairness, this doesn’t only happen to IBM customers, we find the same surprises happening to Windows and Linux users. But it seems that IBM customers are always a bit MORE surprised when it happens to THEM!

I think Alison Burkill is right – Education might be our biggest security need in the IBM Power Systems community. Ignorance is not bliss when the compliance auditor comes calling. 

Download our White Paper "PCI Data Security - Meeting the Challenges of PCI DSS" that discusses PCI compliance and answers some of the common questions companies have about PCI adits.

Patrick

FIELDPROC has been out for just over a year and there have been several Program Temporary Fixes (PTFs) that affect the FIELDPROC implementation issued by IBM. These PTFs are related to data masking, triggers, and other aspects of FIELDPROC. Although there haven’t been many changes within the past few months, administrators need to be aware that in order to be up-to-date and current on V7R1, cumulative patches (PTFs) need to be applied.

Issues in the program can occur if you are not up-to-date. For example IBM added a new parameter in a PTF that is utilized in a called FIELDPROC program. As an encryption provider, we had to make changes to support that additional parameter. If your V7R1 system has different updates than your encryption vendor, you may run into usability issues. If you are just now updating your V7R1, it is good to know that all PTFs have been rolled up into the most recent cumulative PTF package which is available on the IBM website.

If you are just updating to V7R1 now, you will get all of the PTFs automatically; however, if you installed V7R1 six months ago we recommend that you make sure you are up-to-date.

To learn more about FIELDPROC and V7R1, listen to "IBM i Security - Skip V6R1 and Updgrade to V7R1" - one of our most popular podcasts!

If you’re a company using an IBM operating system (AS/400, iSeries) to store your data, but you still haven’t upgraded to V7R1; or if you have upgraded but are not sure how to utilize the new FIELDPROC procedure to best protect your data, don’t be discouraged! I recently sat down with Patrick Townsend, President and CEO of Townsend Security to discuss what FIELDPROC is and how it aids in helping you secure your sensitive data.

What is FIELDPROC?
“FIELDPROC is a new feature in V7R1 that was not available in earlier releases of the AS/400 and iSeries. FIELDPROC stands for Field Procedures--it’s a column and field level exit point for the IBM i iDB2 database. There is no need for application changes to encrypt your data when using FIELDPROC.

As an Exit Point, FIELDPROC is not actually encryption software. FIELDPROC allows system administrators to select which data they want to encrypt on a column by column and row by row basis, however IBM does not provide actual encryption or key management software that is called on by the exit point. Encryption and Key Management must be implemented by vendors like us who have encryption solutions tailored for FIELDPROC.”

[Learn More: 10 Questions to Ask Your Key Management Vendor]

What Was Encryption on IBM i Like Before FIELDPROC?
“Before the implementation of FIELDPROC, encryption was almost always a complicated, multifaceted application software project involving many application changes. After identifying all fields needing encryption, IBM developers often used SQL views and triggers to implement encryption, but that was only a partial solution. Developers would have to modify their RPG or COBOL code, and then implement calls to an Application Programing Interface (API) to encrypt and decrypt data on an insert or update. All of those application changes had to be made using IBM’s encryption APIs or vendors like us who offer AES encryption solutions on the IBM i platform and offer independent APIs. After the application changes and encryption were implemented, IBM developers had to test the system over and over again to detect and eliminate points of failure. A grueling process.”

How do I Encrypt My Data With V7R1 FIELDPROC?
“When you encrypt with V7R1 FIELDPROC, the entire process is automated with no need for application changes. IBM i system administrators first need to identify all fields they want to encrypt. Next, install FIELDPROC exit point software, and then activate it. Used along side an encryption program, the DB2 database automatically, without application changes, calls on the FIELDPROC exit program to encrypt and decrypt, and retrieve encryption keys. One thing to remember is that using FIELDPROC only as an exit point is not by itself adequate for data security. IBM i administrators must also implement proper key management solutions if they want to not only secure their data but also be PCI DSS compliant.”

IBM customers are just now moving to V7R1 from earlier versions (V5R4, V6R1) due to the increased security features that can be implemented with FIELDPROC. In fact, these security features are in such high demand that many V5R4 customers skip V6R1 and go straight to V7R1, and IBM supports this migration. If you’re still running these applications on an older version of the IBM i, you can update to V7R1 and eliminate all of these time consuming application changes.

If you want to learn more about FIELDPROC and how to easily encrypt data on your IBM i, download our podcast “The Benefits of Automatic Encryption.”

The adoption of the Secure Shell (SSH) file transfer protocol has gained a lot of momentum over the last few months. Major financial institutions are migrating from proprietary transfer systems, and from the Secure Sockets Layer FTP protocol (SSL FTP) to Secure Shell implementations. We’ve had support for Secure Shell file transfer automation in our Managed File Transfer solution, Alliance FTP Manager, for many years and our customers are making the switch with no difficulties.

But what about running the Secure Shell server on the IBM i platform? What do you need to know about securing the SSH server when it runs on the IBM i?

One of the most important things you can do is create a CHROOT jail for the SSH server.

I can see you raising your collective eyebrows right now! Let’s talk about what a CHROOT jail is, why you would want to do this, and how you can make it happen.

Without creating some additional controls, your implementation of the SSH server will leave your system very exposed to abuse. For example, if you SSH to a server and log in, you will be presented with a command line. For any of you Linux geeks, you know what a command line means. It’s free reign to wander all over the system. On any SSH server without good controls, you can change directory (CD) to any library or IFS file on the system. And then you can do a lot of damage!

CHROOT to the rescue!

The Linux CHROOT facility is designed to keep users in a tightly controlled area, or “jail”. It’s been a part of UNIX and Linux for decades, and is very well implemented in those systems. But we also have it on the IBM i platform. If set up correctly, your IBM i SSH server with CHROOT implemented will keep those users from wandering around your system. They will only be able to see the directories you give them, and they won’t be able to change to other directories. They are in the little jail that you created.

Fortunately, the IBM i OpenSSH licensed software provides full support for implementing CHROOT jails. You can enable CHROOT support in the SSH server configuration file, and IBM provides a Shell script to create all of the directories and objects you need for each user. And there are good instructions on how to set this up.

But there is one little piece of CHROOT that can be a challenge. For CHROOT to work properly, the SSH server has to be running as “root” when it starts. On an IBM platform, that means it has to be running under the QSECOFR user profile. But you can’t submit the job and specify the QSECOFR profile, so how does this bit of logic get automated?

In Alliance FTP Manager we’ve solved that problem for you. When you specify that you want to run in a CHROOT environment, we submit the job and perform a profile swap to QSECOFR. Voila! You have everything you need to use the SSH server with CHROOT enabled.

If you want to run the SSH server on your IBM i you can contact our technical support group to receive the added software for the Alliance FTP Manager product. You can be up and running with CHROOT’ed SSH in no time at all.

Patrick

---

Townsend Security’s FTP Manager has been helping IBM i (AS/400) users meet compliance regulations by securing and automating their data in motion to trading partners, customers, employees, and internal systems. Download our podcast “Secure Managed File Transfer on the IBM i – An Introduction” for more information on how we can help your organization save time and money by securely automating your file transfers.

It seems like every day the media reports another data breach—a stolen laptop that contains patients’ private information, credit cardholders’ names and social security numbers hacked. Not only do the headlines prove to be public relations nightmares for the companies involved—especially if the stolen or hacked data isn’t encrypted—but they come with severe financial penalties, often reaching into millions of dollars.

When data is encrypted, companies can assure those whose data has been stolen or hacked that there is no reason to worry. Thieves may have the files containing the data, but the thief will be unable to access the data itself. This minimizes the public relations hit and reduces liability with compliance regulators. In today’s highly regulated business world, there is no excuse for not having encryption on your IBM i. Here are two types of encryption to make sure your data is secure:

NIST-Certified AES Encryption for Data at Rest
NIST sets non-military government standards for a wide variety of technologies including data encryption. Because NIST uses an open and professional process to establish standards, the private sector usually adopts NIST standards for commercial use. NIST is one of the most trusted sources for technology standards.

Since AES was introduced, it has been adopted by all U.S. government agencies as the gold standard for protecting sensitive data, and many software companies have made it available to consumers through encryption software. When selecting a data security service, looking for one that has NIST certification should be at the top of your list.

PGP Encryption for Data in Motion
In today’s world, data moves faster and further than ever. That’s why it’s important to ensure it’s secure whether it’s in a database, on a laptop, or sent via email.

PGP encryption is ideal for exchanging data with trading partners, banks, insurance companies, benefits providers, and many other external partners. It’s ability to run on any computing platform makes it ideal for this type of secure data exchange.

Data breaches and associated fines don't have to be a reality of doing business. By properly encrypting your sensitive information you remove the risk of seeing your name in the headlines, being fined millions of dollars, and trust of your brand by your customers.  Download our white paper "AES Encryption and Related Concepts" to learn more about industry best practices for securing your data.