Townsend Security Data Privacy Blog

In October of this year, IBM will end support of V5R4 of IBM system i. This decision will force their customers running on V5R4 to upgrade to either V6R1 or V7R1. Many customers are currently in the process of or have already completed this upgrade. For IBM i administrators out there who have not yet begun this critical upgrade, it's important to know the differences between V6R1 and V7R1. The most notable difference is the new FIELDPROC capability offered exclusively in V7R1. Short for field procedure, FIELDPROC allows automatic, column level encryption in the DB2 database without any program changes.

Patrick Townsend, CEO and Founder of Townsend Security, recently sat down with data privacy expert Patrick Botz at this year's COMMON exposition to discuss FIELDPROC, encryption key management, and what these changes mean for retail merchants who must comply with PCI-DSS. Here is an excerpt from that discussion:

Patrick Townsend: Patrick Botz, can you tell us why encrypting sensitive data is more important than ever, and how FIELDPROC can help IBM i customers easily encrypt sensitive data and meet compliance regulations?

Patrick Botz: I think encryption is something that we're realizing everyone should have been doing a long time ago. Today many businesses are required or recommended to encrypt sensitive data by data security regulations such as PCI-DSS, HIPAA/HITECH, GLBA/FFIEC, and many state laws. This is evidence that encryption is extremely important today, not just from a security point of view, but from a compliance point of view. FIELDPROC is an excellent tool that IBM has added in V7R1 that makes it easier for ISVs to provide efficient and easy to use encryption without having to change programs. This is huge for customers. In fact, I've worked with at least two customer groups so far who's primarily reason for upgrading to V7R1 is to be able to use products that use FIELDPROC.

Townsend: Jumping from V5R4 to V7R1 is a supported path, right?

Botz: Right!

Townsend: Patrick, I know that you're company, Botz & Associates, does a lot to help IBM i customers with their security projects, can you describe a typical  encryption project and how FIELDPROC has saved them time, money and aggravation in terms of getting the project done?

Botz: Yes, there is a pattern these projects tend to follow. Before they embark on their encryption project, the first discussion I have with and IBM i customers is to answer questions such as, how many programs am I going to have to change and how long is it going to take because we can't afford to have our systems down. Then when we start talking about the different products that take full advantage of FIELDPROC, and how they won't have to change their programs to do encryption with FIELDPROC. Once we get to that point, customers are ready to jump in and they're excited! The next step is to discuss if they want to encrypt just the fields with personally identifiable information (PII) or the whole database. From that point on it's a pretty easy process to get data encrypted.

I see many IBM i customers trying to do their own encryption, and one of the things I say to people is, "Have you heard the phrase 'it's not rocket science'? Well, with encryption, to make sure you get it right, it approaches rocket science." The fact is that customers really need to pick a solution that handles not only the encryption, but the key management as well. In my opinion the most important part of encryption is key management. I like to use the analogy of using a padlock: If you buy the world's best padlock for your backyard shed and then you pound the nail on the shed right next to the padlock and hang the key there, is that best padlock doing you any good...

In case you missed the presentation by Patrick Townsend and Patrick Botz, we recorded their session and have made it available for online listening. Download the podcast "FIELDPROC Encryption on the IBM i" to learn more about:

-Encryption Key Management with FIELDPROC
-The importance of certifications
-And what QSA and compliance auditors will look for in your key management system

Patrick Botz is an internationally known information security expert, specializing in security as a business requirement first, and as technology second. His passion for SSO began while working at IBM which he joined in 1989. He held several positions at IBM, including  Lead Security Architect and founder of the IBM Lab Services security consulting practice. He architected the SSO solution for OS/400 and i5/OS, and he holds several security-oriented patents.

In 2013 merchants should ask: Will we pass our PCI audit this year using the same technology and standards we used last year? The answer is possibly not.

Businesses that accept credit cards have to meet PCI-DSS compliance requirements and encrypt credit card numbers using industry standard encryption and good encryption key management practices. They are often shocked and surprised when, after passing a compliance audit for a number years, they suddenly fail an audit around encryption key management practices. Audit failure due to poor encryption key management has begun to happen more frequently within the past year.

Let’s take a look at one scenario of a customer we helped this year.

A large retailer with a Level 1 merchant designation processes tens of thousands of credit card transactions every year. Card transactions originate through point-of-sale (POS) terminals in stores, through web-based eCommerce applications, and telephone orders. A pretty typical retail operation in many ways. This Level 1 merchant had passed on-site QSA audits for several years. Suddenly, this year they failed their PCI-DSS audit.

Why did this happen? Because the encryption key used to protect credit card numbers was stored on the same server as the protected data.

In the last year or so, failing PCI-DSS audit due to poor encryption key management is actually far more common than you might think. In this case a new QSA auditor was assigned to the merchant, and the auditor was quite knowledgeable about security practices in general, and key management in particular. The previous auditor had granted the merchant “compensating controls” for their encryption key management strategy - but the new auditor found that the compensating controls were inadequate for proper encryption key protection. Thus the audit failure and the need to remediate encryption key management.

Here are a few thoughts that might be helpful to merchants reviewing their encryption key management practices:

• PCI DSS standards are not set in stone. The PCI Security Standards Council has been very transparent in letting merchants know that the standards can and will evolve as security threats evolve. What you are doing today may not be adequate to protect your systems tomorrow.
• QSA auditors vary in their assessment of risk and requirements to meet the standards. And as the security threat environment changes, they can revise their assessment practices and requirements for merchants. Compensating controls that might have been appropriate in the past, may no longer be appropriate.
• In the early years of PCI audits, the focus may have been more on basic compliance with high priority security tasks given priority. As time has gone by, attention is now more focused on tightening up critical components like encryption key management. Weak encryption key management practices and compensating controls are falling by the wayside.
• QSA auditors are a lot more educated on the issues of Dual Control and Separation of Duties for encryption key management systems. It is almost impossible to implement a encryption key management system on the same platform as protected data, and meet these security requirements. Protecting encryption keys with purpose-built key management hardware security modules (HSM) is now a typical requirement for PCI DSS compliance.

So what can a merchant do if they want to make sure they will pas their PCI-DSS audit this year?

• Review your encryption key management implementation now. If your implementation does not meet security best practices for encryption key management, start planning on what you will do to remediate the problem.
• Ask yourself: Were we operating under compensating controls for encryption key management? It would be wise to assume these won’t be renewed at some point in the future.
• Ask yourself: Are we storing our encryption keys on the same server as the credit card number? Start planning now on how you will respond in the event of an audit failure.

Good encryption key management is no longer a time-consuming, expensive proposition. Our Level 1 merchant was able to remediate the problem in under 30 days with their own IT team and without the need for on-site consultants from Townsend Security. To learn more about encryption key management and meeting PCI-DSS, download our White Paper, Encryption Key Management for PCI-DSS.

Townsend Security recently asked business executive and mid-market expert Todd Ostrander to contribute his expertise and thought leadership on C-level risk management to our most most recently published eBook, Turning a Blind Eye to Data Security (Mending the Breakdown of Communication Between CEOs and CIOs).

In his article, Todd Ostrander discusses several key points around data security and business risk including:

• The roles and responsibilities of a CEO around data security
• The high costs associated with a data breach
• How unencrypted data represents a significant business risk
• Why proper encryption key management is needed to prevent a breach

In addressing these issues, Todd Ostrander urges us to implement the solution that many businesses have yet to adopt.

Read an excerpt from his article below:

“In any organization, the CEO has many jobs. At the macro level, a CEO’s job is to instill a high level of confidence in his or her stakeholders, including customers, investors, employees, suppliers and partners. To accomplish this, a CEO must establish a level of trust with these stakeholders in order to inspire, encourage, and engage them to take part in the entity’s vision and pursuits. Ultimately, the organization uses its stakeholders’ trust—their confidence in the CEO and his or her team’s ability to execute—to grow and build its value.

Every business has inherent risks in its execution—such as hiring dependable employees and maintaining financial stability. In order for a CEO to instill the kind of confidence that increases a business’ value, he or she must be able to identify and address each of the risks in the business.  Therefore, risk mitigation by nature becomes a core component of a CEO’s job.

In a pre-internet world, the risk of data loss was limited to a physical breach of an actual building. Security guards, fences, and access control systems were established to keep people away from sensitive information. However, as today’s world has become electronically connected at virtually every level, businesses need to focus not only on preventing access to data but also on protecting the data itself. This is where a comprehensive data protection strategy comes in to play.

Most CEOs are well aware that encryption methodologies were created for their CIOs to be able to protect data in their networks. However, encryption is such a new field that few CEOs understand all of the risks associated with unprotected data as well as evolving industry-based regulations which they must comply with.

CEOs may not know that even if their data is encrypted, without proper encryption key management, they are still at risk and do not comply with many industry regulations. Without good key management practices, you are practically inviting hackers to break in to your system…"

Todd Ostrander is a professional with over 25 years of F1000, mid-market and emerging market startup experience. Throughout his career, he has been at the forefront of groundbreaking changes that create new markets and opportunities. While he has a broad range of skills from finance to procurement, strategic marketing and product strategy, his core functional expertise is in exploiting existing markets as well as identifying and creating new market opportunities with specific focus on go-to-market, intellectual property, and capitalization strategies. Within the technology industry, he has specific expertise in workflow management, Software as a Service (SaaS), wireless, digital marketing, and mobility.

Like any business, for a solution provider to succeed they must meet the evolving needs of their customers.  In the IT world, we all know that data management is one of the most important, complex, and fast growing needs of businesses. From disk backups to managed hosting and cloud services, solution providers are moving towards offering more of these services and at lower costs. Unfortunately, with the amount of data storage and management growing at an exponential rate every year, a major need of most businesses that goes overlooked is data security.

Today almost every business must adhere to data security regulations set forth by industry standards groups. In retail, these standards are Payment Card Industry Data Security Standards (PCI-DSS). In the medical vertical, HIPAA/HITECH Act mandates the protection of sensitive patient data. Other regulations such as SOX, FISMA, and GLBA/FFIEC cover most other entities. All of these regulations mandate or recommend the use of AES encryption and encryption key management.

We would all like to think that IT directors and executives of every business adhere to these standards and recommendations and choose solution providers that provide them with encryption key management. However, as we witness easily preventable data breaches every week in the news, we know that this is simply not true.  

What IT executives and solution providers don't seem to realize yet is that in the event of a major data breach, at least two parties will take the fall: The IT executive and the solution provider(s).

Take for example the Utah Department of Health data breach that occurred in March of last year. This highly publicized breach was caused by a hacker who accessed 280,000 social security numbers as well as other private health information (PHI) and personally identifiable information (PII) such as birth dates, home addresses, and taxpayer ID numbers.

This attack was considered easily preventable.

How are these kinds of attacks easily preventable? When encryption and key management best practices are used, this kind of data is rendered totally unusable by hackers. That's why encryption and key management are considered the highest standard of data security and why they are mandated by industry regulations such as PCI-DSS and GLBA/FFIEC. If AES standard encryption and encryption key management best practices were used in Utah's Department of Health IT center, it is unlikely that the data breach would have occurred.

In the end, Utah's CTO was pushed to resign and the technology used to process data totally overhauled.

Unfortunately, companies in general are pretty confused about when, where, and how to encrypt sensitive data, even though both encryption and encryption key management are recommended, if not mandated, by most industry regulations. Worst of all, many companies who know they should be encrypting their data don't do it because of budget (a direct indicator of priorities)! This results in a LOT of unprotected sensitive data.

Ultimately, consumers assume that the businesses they patron are protecting their personal data, but the truth is, not all of them are!

The threat of data breaches and cyber attacks is not going away. In fact, these events are increasing every year. Solution providers offering data management tools to companies in retail, healthcare, finance/banking, and many other industries should absolutely be offering their customers encryption and encryption key management. Several solution providers currently offering encryption and encryption key management are already at a competitive advantage to providers that don't.

To learn more about how easy encryption key management can be, download the podcast, “Simplifying Encryption and Key Management: Removing Complexity and Cost” featuring data privacy expert Patrick Townsend.

Nearly every week I get asked the same question about IBM i (AS/400) upgrades by our current Alliance AES/400 and Alliance FTP customers who are in the process of updating their operating system:

Q: “I am running Alliance FTP Manager with Commercial PGP.  Do I need to upgrade this to your latest version before I upgrade my IBM i to V7R1?”

A: Always upgrade the software you are currently running to the latest version first, then upgrade your operating system second.  IBM made changes in V6R1 and V7R1 and we have builds specific to these Operating Systems.  If you upgrade your software first to the most recent release, you will avoid larger issues around transferring your data when you upgrade to one of the newer IBM i versions.

Another related question I’m often asked is:

Q: “Should we do a system backup before a major OS update?” 

A: Yes, you should always do a full system backup before making changes to your system. System upgrades and other changes to your OS are often a challenge and can result in data loss, system crashes, and other major issues if you’re not careful. You never know what could happen, and you don’t want to be left piecing your system back together while your customers are waiting. Because it’s such a critical component we always remind our customers to backup their current application library. If something does go wrong during the upgrade, you’ll want the option to revert to the backup.

To help with these sorts of issues we provide a customer service portal with an extensive list of solutions and frequently asked questions. 24/7 support is often an important need for many customers upgrading their IBM i or other operating system, and we provide that as well. We know that planning a move like this takes lots of time and if we can help, we are happy to assist.

To learn more about IBM i security, check out our recent webinar, TOP 3 IBM i SECURITY TIPS FOR 2013, featuring data privacy experts Patrick Townsend and Patrick Botz.

Since it's release in 2001, Microsoft SharePoint has quickly become one of the most widely used applications for document storage and collaboration.

SharePoint originally stored and organized documents and other critical information about those documents in rows and columns. However, as the use of SharePoint began to quickly grow, administrators began to notice that the huge number and size of the documents being stored began to impact the performance of SharePoint, slowing down the application until it was fairly unusable. To rectify this issue Remote Blob Storage (RBS) was introduced to store the documents themselves outside of the SharePoint database so that the size of the documents wouldn't impact SharePoint performance. Now, when a SharePoint administrator starts to see performance impact from documents stored in SharePoint, they can store the files themselves separately, and SharePoint talks to the remote server in order to retrieve the files.

Now that SharePoint is so widely used, protecting data stored in SharePoint has become a big issue. Many companies use SharePoint to track customers, retail orders, personal health information, and other personally identifiable information (PII) that most industries (PCI-DSS, HIPAA/HITECH, GLBA/FFIEC, etc.) and many state laws mandate the protection of. Typically these regulations mandate the protection of this data using encryption and encryption key management.

The good news is that encrypting data in SharePoint is pretty easy, and it's often only a two-step process. SharePoint administrators must:

1. Encrypt the SQL Server database SharePoint runs on
2. Encrypt the Remote Blob Storage (RBS) used to store documents.

Encrypting SharePoint on SQL Server is easy with transparent data encryption (TDE) for SQL Server 2008/2008 R2/2012. Extensible key management (EKM) also allows admins to manage encryption keys and meet compliance regulations using an external third-party encryption key management hardware security module (HSM).

Townsend Security offers FIPS 140-2 compliant encryption key management system for Microsoft SharePoint to help you protect SharePoint and meet compliance. To learn more about securing data in SharePoint, check out our podcast, “Securing SharePoint with Encryption & Key Management.”

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.

Managing risk is at the forefront of responsibilities that "C" level executives deal with on a daily basis.  Fire fighting--managing business risk--is part of the job description, and planning to prevent the fires is what successful companies do.  In his book Good to Great, management expert Jim Collins uses the analogy of a bus to analyze leadership of Great companies.  When you have the right people in the right seats, Collins says, the company is elevated to a new level.

However, if there is a wall between the driver of the bus (the CEO) and the rest of the passengers, then there ensues a serious lack of communication.  If the passengers know more than the driver about things such as weather conditions and the location of the destination, and there is no way to communicate effectively with the driver, then the navigators can't warn the driver of severe risks that lie ahead.

One of the areas where I continuously see this disconnect is in the area of IT Security. Because technology is an always evolving component of businesses, protecting sensitive data will always be an issue, and hackers will always be trying to find a way “in”.  Chief Information Security Officers (CISOs) are hired to manage this risk.  But when the CEO is ignorant of the risks due to a lack of understanding or an unwillingness to take the time to learn the risks, then the lines of communication between the CEO and CISO are obscured, and important decisions about data security do not get made.

In a published study by CIO magazine recently and PriceWaterhouseCoopers stated that, "only 1/3 of security policies were tightly aligned with business goals.”

Although there is a combination of factors that lead to this disconnect, two primary factors prevail: 1) The CEO, CFO, or COO isn't well informed of the risk of a data breach and what it will cost their organization in real dollars, company value, and publicly perceived value. And 2) The security professional (CISO) understands the vulnerabilities but can’t articulate them in terms of the business cost.  The result is that neither the CEO or CISO are able to effectively quantify the risk.  Risk unquantified is a risk ignored.

Fortunately, the press has provided us with significant examples over the past several months to help us educate both the CEO and the CISO of the risks associated with unprotected data.  In 2012 alone, there were multiple data breaches that cost individual companies BILLIONS of dollars in lost value and recovery cost.

These are the costs resulting from a publicly disclosed data breach:

1. Cost to fix the issues that led to the breach
2. Cost to protect the individuals data / company data that was compromised from future breaches
3. Cost of future audits that will be required to maintain compliance in the future
4. Cost of the fines that can be levied depending on the type of breach
5. Cost of customers no longer willing to trust the organization
6. Cost of the negative press / PR associated with the breach
7. Cost of combatting the negative PR with a new PR / Social Media campaign to assure customers / vendors that everything is okay

At the end of the day, we want to see CEO's succeed by increasing the value of the company in the eyes of the shareholders while reducing the risk of value erosion.  We also want to see CISOs who are confident in educating their CEO's to these risks.  As long as this issue continues to go unrecognized, the CEO has one more fear to keep him up at night.

Can you afford it?

Download our white paper "AES Encryption Strategies - A White Paper for the IT Executive" to learn more about key issues in data security, how to choose the right data security partner, and how to develope a strategy that insures early successes.

If you're starting an encryption key management project, you should always know the warning signs of obstacles that might make your project way more difficult and costly than it needs to be. We often see companies who have recently failed a data security audit, or realize that they are about to, because they didn't watch out for these pitfalls before they began an encryption key management project.

1. Complicated Project Requiring Outside Consultants and Time
If you find yourself bogged down by hiring outside consultants (beyond your encryption key management vendor) to help you set up and run your encryption key management system, you're probably headed for trouble. Encryption key management should be simple, straightforward, and easy to deploy.

2. No Certifications
NIST certifications are a must when it comes to implementing good encryption key management. In order to meet compliance for PCI-DSS, GLBA/FFIEC, FISMA, and other compliance regulations, always use NIST-certified AES encryption and FIPS 140-2 compliant encryption key management. Your QSA or other data security auditor will look for these certifications.

3. No Client-Side Support
Your encryption key management vendor should supply you with the appropriate client-side applications to make your encryption key management run as smoothly as possible. If you find yourself scrambling to find sample code, binary libraries, key retrieval and other tools, your encryption key management project time will almost certainly increase and not come to a complete halt.

4. No Dual Control and Separation of Duties
When it comes to doing your encryption key management right, one of the critical pieces to meeting compliance requirements such as PCI-DSS is using the principles of dual control and separation of duties. These are hard and fast guidelines when it comes to the handling of encryption keys, and are considered a "best practice" for encryption key management. If your encryption key management hardware system doesn't implement these policies, it will be difficult to pass your data security audit down the road. Some compliance regulations such as HIPAA/HITECH Act don't yet require these policies; however, you should expect these best practices policies to be implemented into regulations down the road.

5. Complex and Hard to Predict Licensing
When you don't know how much your encryption key managemer is going to cost, your project will stop in its tracks. When you don't know how many licenses your company will need over time and how your encryption key management vendor will charge you for them, estimating the cost becomes very complicated. Often a vendor might limit how many devices can connect to your key server or the number of keys the key server can create, resulting in unpredictable costs. As we all know, a project with an unpredictable cost never gets off the ground! The cost of licensing should not be a barrier to protecting your sensitive data.

To learn more about how encryption key management and how easy it can be, check out our webinar, “Key Management Simplified.”

XN3H7FQ298CU 

I recently read about a data breach that came into public light a few weeks ago in South Carolina at the Savannah River Site (SRS), a nuclear reservation owned by the U.S. Department of Energy. This breach exposed personal information of over 12,000 employees. The state of South Carolina has been in the news over the past few months because of a massive governmental data breach caused by an international hacker that exposed millions of credit card and social security numbers.

At first I thought the SRS breach might be similar or related to the other breach, but I quickly realized there was something different about this one. According to Carla Caldwell of the Atlanta Business Chronicle, officials at the site say that the breach wasn't caused by a cyber attack. However, despite the fact that there was no hacking involved, employees are still being told “to be vigilant in monitoring financial transactions and emails or phone calls relating to such personal transactions.”

What does this mean? It means that:

1. Despite the absence of a malicious hacker, a data breach still occurred, and
2. Because the breach had to be reported, it likely exposed employee financial data such as credit card information or social security numbers.

Many people think that all breaches are caused by vigilante hackers, and while cyber attacks are a real threat, the truth is that a HUGE proportion of data breaches are caused by simple employee mistakes and theft of devices such as disk drives, backup tapes and personal devices such as laptops and smartphones.

According to the PricewaterhouseCoopers 2012 Information Security Survey, over 80% of enterprise data breaches are caused by employee errors. Many of these breaches occur on unencrypted mobile devices. In the healthcare industry, the Ponemon Institute found that nearly 40% of data breaches were caused  by employee negligence.

Serious breaches occur inside companies simply because mistakes are made, thefts happen, and the right technology is not in place to protect sensitive data.  Some of these events include:

• Backup tapes and disk drives are stolen out of cars
• Laptops and other personal devices such as iPads and phones are stolen out of cars
• Tapes, drives, and personal devices are lost (Think lost luggage, leaving items on a train)
• Employees email files containing sensitive data to their home devices
• Unauthorized employees view sensitive data at work because the right protocols are not in place to protect that data.

However there's a way to protect data even if it gets into the wrong hands: Encryption. If the data is encrypted it will be completely unreadable if it is stolen or mishandled. Protecting your encryption keys is also a critical piece in protecting sensitive data. If your encrypted backup tapes get stolen out of your car, but you've stored your encryption keys on those tapes, the thief will be able to use the keys to access the information.

To learn more about protecting encrypted data with encryption key management, download our resources package, “Encryption Key Management Simplified.”