Townsend Security Data Privacy Blog

2012 was a big blogging year for Townsend Security.  By the close of December we published a grand total of 285 blogs!  Wondering what data security compliance regulations your organization faces?  We covered it.  Do you need to learn more about securing your SharePoint server with encryption and key management?   We’ve got 490 words on it.  Did you know email addresses can be considered Personally Identifiable Information (PII) and need to be encrypted?  Patrick Townsend, Founder and CEO, wrote about that in “Protecting PII – Passwords, Bank Accounts, and Email Addresses?”

With all the great blogs on protecting sensitive information, examining data breaches, and how to meet data privacy compliance regulations, our bloggers created some great content that we hope you found valuable. Without further ado, here the three top read blogs from 2012:

#1 Skip V6R1 on IBM i and Upgrade to V7R1 – A Security Note

IBM provides a new automatic encryption facility in V7R1 for DB2/400 called FIELDPROC.  This new facility gives IBM i customers their first shot at making encryption of sensitive data really easy to do. With the right software support you can implement column level encryption without any programming.  The earlier trigger and SQL View options were very unsatisfactory, and the new FIELDPROC is strategically important for users who need to protect sensitive data. [More]

#2 How LinkedIn Could Have Avoided a Breach – And Things You Should Do

The loss of passwords by LinkedIn, eHarmony, and Last.FM should be a wakeup call for CIOs, security auditors, and IT security professionals everywhere.  Let’s take a look at what probably happened, what you can do, and why you need to look beyond passwords on your own systems. [More]

#3 What is the Difference Between AES and PGP Encryption?

AES encryption is the standard when it comes to encrypting data in a database.  Advanced Encryption Standard (AES) has been adopted as a standard by the US government and many state and local agencies.  AES is the recommended encryption method for PCI, HIPAA/HITECH, GLBA and individual state privacy regulations.  AES encryption uses an encryption key to encrypt the data. [More]

As compliance regulations get tighter, data breaches get more sophisticated, and security best practices advance, Townsend Security will be here to blog on what is new and what you need to know about.  Here is to 2013 being the most secure year yet!

Are you free on January 30th at 10:00am Pacific?  We will be presenting a webinar titled “Top IBM i Security Tips for 2013” with Patrick Botz, former Lead Security Architect and founder of the IBM Lab Services security consulting practice and discuss:

• Using FIELDPROC for automatic encryption
• Key Management best practices – and what to look out for
• A practical way to  implement Single Sign On (SSO)
• How to easily collect IBM i logs and transmit them to ANY SIEM

Encryption key management has a bad reputation. How bad? I once heard a SQL Server professional describe encryption key management as so costly and difficult to implement, it is a “nightmare.”  It’s hard to imagine that attempting to simply manage your encryption keys evokes images of terrifying dreams that wake you up at night in a cold sweat. However, for many database administrators who must encrypt data, the idea of incorporating a good encryption key management strategy (dual control, separation of duties, etc.) really does sound like a daunting task. Most DBAs assume that a key management project is time consuming, expensive, incredibly complicated, and requires specialized third-party consultants. Simply getting the encryption key manager up and running is a huge headache.

We don’t believe good encryption key management needs to be difficult. In fact, we believe that good encryption key management should have these 9 easy features:

1. Easy to Install: A single-use (1U) server plugs right into your IT infrastructure and requires no on-site technician to install.
2. Easy to Configure: Install your license, certificates and keys, configure options, and start the server all within a standard, secure web browser and administrator console.
3. Easy to Manage: Operate your console within secure and authenticated TLS sessions, use two admins for dual control, collect logs, manage multiple servers as well as manage local and remote key servers, all through one interface.
4. Easy to Evaluate: Evaluating a product before you buy shouldn’t be difficult. You should be able to evaluate the product without any hardware on a ready-to-use VMware instance or an internet-based demo server, pre-configured with licenses, certificates, and keys.
5. Easy on Developers: Developers should be provided with a rich library of documentation and sample code to use in their applications for any platforms that need more development to get key management running smoothly.
6. Easy to License: You should not need to license every end point that connects to the key server. The cost and complexity of licensing all endpoints is unnecessary and can be a huge barrier to getting data protection up and running quickly across the organization.
7. Easy to Own: Key management should be affordable to small and mid-sized businesses. The solution should be scalable to each organization’s needs.
8. Easy to Deploy: Customers should always have access to direct shipping, a simplified order process, remote configuration, and installation services.
9. Easy to Sell: Integrating a key management solution should be easy for partners and include easy software integration, thorough technical and sales training, multiple support plans, and flexible and tiered solutions!

Looking for key management as easy as this? View our webcast, “Encryption Key Management Simplified - Removing Complexity & Cost” to learn more. Or contact us for a technical overview on Alliance Key Manager, our encryption key manager, with one of our technical sales support representatives.

If you knew that something was going to happen to your business that would cost you not only your clients' trust but also $13 million (the average cost of a healthcare data breach), would you try to prevent that thing from happening?

According to the Ponemon Institute study, Third Annual Benchmark Study on Patient Privacy & Data Security, healthcare data breaches cost the industry $7 billion dollars annually. Unfortunately, that's not the most shocking number of the study. As it turns out, 94% of healthcare organizations have experienced at least one data breach over the past two years. Almost half of all healthcare organizations have experience at least five data breaches each over the past two years. This means that almost 100% of healthcare organizations have lost patient data such as private health information, names and addresses, credit card information, and social security numbers. If you're wondering how identity theft happens, this is it!

In a recent article published by Forbes, Rick Kam of ID Experts and Larry Ponemon of the Ponemon Institute pointed four major issues around data security in the healthcare industry:

1. Cost of a data breach: "Data breaches cost the U.S. healthcare industry nearly $7 Billion annually."

The cost to the industry includes losing patient trust, providing patients with credit monitoring services, as well as paying out hefty fines to HHS. The cost to patients often comes in the form of identity theft.

2. Electronic records: "The rise of electronic health records (EHRs) is putting patient privacy at risk."

Using computers to store and organize patient data is a blessing to most healthcare providers. However, maintaining electronic records not only causes healthcare organizations to fall under state and industry data privacy regulations, it also opens up the door to data breaches caused not only by external hackers looking to make a buck, but also employee mistakes which account for about one third of all data breaches.

3. Mobile devices and the cloud: "The rise of mobile and cloud technology threaten the security of patient data."

These days many doctors and healthcare providers use personal mobile devices to access patient data. How are these devices protected? Often they are not. Since many organizations include healthcare are now using cloud providers to store data, cloud security has also become a hot topic. How do you secure your data stored in the cloud, when it may be accessed by other users? Encryption and encryption key management is the best place to start. [Blog: 3 ways to manage encryption keys in the cloud]

4. "Little time, even less money"

Budget is one of the biggest factors that goes in an organization's data security plan. The tools needed for a comprehensive data security plan such as encryption and encryption key management may seem expensive and complicated, but the solutions out there today are in fact cost-effective and easier than ever. In the end, a company's security posture really comes down to priorities. Is preventing a multi-million dollar data breach a priority? Or will you leave it up to chance?  

Encrypting your data at rest and data in motion is the first critical step to protecting your database. Always look for NIST and FIPS certifications to ensure you are using the best encryption and key management tools available.

View our webcast “Protecting PHI and Managing Risk – HIPAA/HITECH Compliance” to learn how your organization can manage their risk of a data breach and achieve breach notification safe harbor status.

These are the last two myths in our installment “5 Data Security Myths Debunked.” With the rise of data breaches occurring all over the world, we’ve been watching closely to see how company leaders are responding to these incidents. To say the least, we have been shocked by what some government leaders and CEOs have said surrounding data security in their own organizations. We believe that some of these sentiments are highly misleading, if not downright false. That is why we have decided to compile these statements into five "myths" of data security. These myths come from direct quotes by CEOs and government leaders.

Myth #4: There is nothing you can do to prevent your company from being hacked

Fact:
There are many actions a company can take to protect its network and prevent a data breach:

• Know which parts of your data is considered “sensitive”, and know where all of your sensitive data is stored. Is it on one server or many servers? Is it stored in applications or databases? Do you have multiple data centers that store sensitive information?
• Use file integrity monitoring (FIM) or system logging to be alerted to changes in system configuration, sensitive data, or unauthorized access in real time.
• Develop and enforce a unified, proactive data security policy to protect data at rest and in transit across your company’s entire network.
• Use AES standard encryption to encrypt sensitive data at rest and FIPS 140-2 compliant key management to protect your encryption keys.
• Automate updates to firewall configurations, password changes, and system patches.
• Restrict employee access to sensitive data.

Myth #5: CEOs do not need to be concerned about data security.

Fact:
Data security isn’t just the Chief Information Security Officer’s (CISO) problem, it’s a business problem that affects both the C-level and the IT level of an organization. IT security is often not made a priority due to the disconnect of perceived vulnerability and actual vulnerability within a company’s IT infrastructure. A recent survey by CORE Security found that approximately 75% of CEOs surveyed didn’t believe their networks were under attack or already compromised, while 60% of CISOs felt very concerned about attacks and believed their systems were already breached.

Poor data security is a business risk. The consequences of a data breach include loss of reputation, loss of customer trust, and hefty fines. In 2011, the average data breach cost an organization $5.5 million. Despite these often highly publicized repercussions, 65% of CEOs surveyed by CORE Security reported that they did not have the information they need to translate IT risk into business risk.

With the rise of data breaches occurring all over the world, we’ve been watching closely to see how company leaders are responding to these incidents. To say the least, we have been shocked by what some government leaders and CEOs have said surrounding data security in their own organizations. We believe that some of these sentiments are highly misleading, if not downright false. That is why we have decided to compile these statements into five "myths" of data security. These myths come from direct quotes by CEOs and government leaders.

Myth #1: Encrypting social security numbers is not a standard in most industries, including banks. 

Fact:
Most banks and financial institutions adhere to state laws and industry regulations (such as FFIEC and GLBA) regarding the protection of social security numbers.

For example, California data privacy laws identify Social Security numbers as a critical piece of personally identifiable information (PII) that must be protected using “reasonable security procedures and practices appropriate to the nature of the information” such as encryption or redaction (1798.81.5) . The law upholds businesses within the state, financial or otherwise, to the same data security laws that the state itself must adhere to which state that any business owning or licensing computerized data containing personally identifiable information (PII) such as names and Social Security numbers must protect that data using encryption, redaction, or other methods that render the data unusable in order to avoid data breach notification (1798.29). The average cost of a data breach is $5.5 million (Ponemon, 2012).

The FFIEC IT Handbook action summary states that “Financial institutions should employ encryption to mitigate the risk of disclosure or alteration of sensitive information in storage and transit. Encryption implementations should include: Encryption strength sufficient to protect the information from disclosure until such time as disclosure poses no material risk, effective key management practices, robust reliability, and appropriate protection of the encrypted communication endpoints” (ithandbook.ffiec.gov).

Myth #2: Encryption is too complicated for my IT and database administrators.

Fact:
Most database platforms such as SQL Server, Oracle, and IBM i are designed to easily implement encryption and encryption key management solutions. SQL Server and Oracle, for example, use Transparent Data Encryption (TDE) and Extensible Key Management (EKM) to easily encrypt data. IT professionals agree that these tools make encryption easier. “TDE is relatively straightforward” - Michael Otey, SQL Server professional (www.sqlmag.com). Encryption with TDE on SQL is “Easy to Implement and administer” -Brad M. McGehee, SQL Server professional, MCTS, MCSE+I, MCSD (https://www.bradmcgehee.com).

Learn how to set up TDE and EKM on SQL Server 2008/2012 in 10 minutes or less here.

Myth #3: Data breaches are usually caused by highly sophisticated hackers.

Fact:
The top four mechanisms for a hacker to break into a company’s network are: exploiting system vulnerabilities, default password violations, SQL injections, and targeted malware attacks (Symantec, 2009). These techniques are not considered highly sophisticated. They are used often to penetrate networks with inadequate security.

Curious what the final two data security myths are? View "5 Data Security Myths Debunked: Part 2" to find out if there is really nothing you can do to prevent your company from being hacked and whether or not CEOs should be concerned about data security.

At Townsend Security we get all kinds of questions about PCI Compliance. A question we get asked frequently by healthcare professionals is:

As a medical healthcare provider, we accept payments via check or credit card through Point of Sale devices implemented by a third-party vendor. Are we responsible to comply with PCI DSS requirements?

Many people assume that if they use a third-party vendor, the vendor must be the one to comply with PCI DSS. Our CEO Patrick Townsend, has a different take on this subject. I asked Patrick if he could answer some of the common questions asked by healthcare providers concerned about PCI DSS compliance requirements.

Are we (healthcare providers) responsible for complying with PCI DSS?

Yes, every Merchant is responsible for PCI DSS compliance even if using an outsourced service. However, this type of arrangement can greatly reduce the amount of work that the Merchant has to do. Usually you will only need to complete and sign a Self Assessment Questionnaire (SAQ). You would get this from your outsourced authorization provider.

Okay, but if we do need to be concerned with PCI compliance, how is the PCI DSS processed managed?  Does the IT team tackle this? Our compliance team?

Typically the IT department takes the lead on coordinating any work that has to be done for PCI DSS. This might include things such as a vulnerability scan by an approved scan provider and similar types of tasks. An officer or director then reviews and signs the SAQ and letter. In medical organizations the Compliance Officer is typically more involved with various medical industry compliance requirements related to HIPAA and so forth and usually not involved with PCI DSS. But it never hurts to ask.

What about banks that process our clients’ credit card information?  What kind of reporting should we be getting from our bank confirming that they are compliant or following PCI DSS compliance?

Banks are under a different type of compliance requirement for PCI. You should just ask them for a letter assuring you that they meet all PCI data security requirements as an authorization provider.

Sometimes PCI compliance can be confusing. Hopefully, thanks to Patrick, you may now have a better understanding of PCI compliance and how you can outsource credit card information while remaining PCI DSS compliant. If you have questions about PCI compliance, send me an email at kristie.edwards@townsendsecurity.

If you want to learn more about PCI compliance and how Townsend Security can assist with the process, listen to Patrick speak about current best practices and encryption key management in the webinar, “Key Management Best Practices: What New PCI Regulations Say.”

By now we’ve all had the experience of getting a letter explaining that our credit card information has been compromised, a sincere apology about the trouble this is going to cause us, and an offer of credit reporting services for a year. Yes, if you have a pulse and a credit card or bank account, you’ve probably gotten more than one of these.

Did you know that this happens to businesses, too?

We just got this type of letter from one of our customers. Let’s call them Well Known Company, Inc. (WKCI).  The letter from WKCI was contrite and apologetic and helpful. It explained that their service provider, let’s call them A Very Large Bank (AVLB) had experienced a data breach and our company information may have been compromised. Yes, WKCI outsourced some of their financial operations to AVLB, and AVLB had a data breach and our company information may have been lost.

Notice that the breach notification came from WKCI, and not from AVLB, the bank that lost the information.

What ??? !!!

Did Well Known Company have to bear all of the costs of breach notification, credit alerts, and potential litigation even though they didn’t actually lose the data?

Yes, it doesn’t seem fair, but that is how breach notification works. You are responsible for insuring that sensitive data is protected, even when it leaves your control and passes to one of your service providers.

Actually, WKCI is a company that I know is very diligent about protecting data within their IT infrastructure. They follow security best practices and are very diligent about encrypting and monitoring their systems. The IT security team is one of the best.  So, it seems doubly unfair that they bear the brunt of the data breach notification costs in this case. It is unfortunate that their bank was not so careful.

As a CIO or IT director, what can you do to protect your company from this type of data loss?

Here are three things you can do:

1. Educate the senior managers in your company about the risk of data loss through service providers. Once they understand that your company is at risk even after the data leaves your control, they will get on board with the following steps.
2. Work with your legal team to incorporate data protection language into all of your service agreements. Don’t sign any new service contracts that don’t explicitly require the service provider to certify that they encrypt data at rest and in motion, and use encryption key management best practices.
3. Encrypt sensitive data before you send it to service providers. Don’t just encrypt the transfer session (data in motion), but encrypt the actual data. This will force your service provider to have the necessary encryption infrastructure to protect the data.

We know that the average cost of a data breach is about $200 per record, sometimes adding up to millions of dollars. Unfortunately, that is a cost that you will bear even if you are not directly responsible for a breach.

Hopefully these suggestions will help you reduce the chances of being WKCI!

Patrick

Microsoft has announced that the October Windows update will change Windows support for certain RSA key sizes.  Our customers have asked:  How will this affect our use of your encryption key manager? Do we need to worry?

No, you don’t need to worry. Here’s why:

Microsoft operating systems will remove support for RSA keys smaller than 1024-bits. The use of 1024-bit and larger keys will still be supported without change. So, only RSA keys that are SMALLER than 1024 are affected.

Alliance Key Manager, our encryption key management HSM, enforces the use of 2048-bit keys and does not allow they use of keys smaller than 1024 bits. NIST has recommended that applications migrate to larger RSA key sizes for some years, and we built Alliance Key Manager to meet those key size best practices. Today, no application should be using an RSA key that is less than 1024 bits.

Our existing customers will not be affected by this Microsoft change. If you are using Alliance Key Manager for Microsoft SQL Server Transparent Data Encryption (TDE), Microsoft SQL Server Cell Level Encryption, Microsoft SharePoint 2010 with SQL Server TDE, Microsoft Dynamics CRM, or our Microsoft Windows .NET client applications, you will not be affected by this change.

We simply do not allow the use of insecure RSA key sizes.

Download our podcast "Encryption Key Management" to learn more about encryption key management and what auditors are looking for and how to easily manage your encryption keys.

Patrick

There are many misconceptions about data encryption in the IT realm, particularly in the field of tape encryption and tape back-ups.  When any organization storing Personally Identifiable Information (PII) or Protected Health Information (PHI) backs up their data on tapes, encrypting this information is crucial. Many companies already do this; however, they often stop here without realizing that tape encryption is just the first step in a comprehensive data security plan. Not only do database files need to be encrypted on backup tapes, but they also need to be encrypted on every device the data may be stored on—such as hard drives, laptops, USB drives, and mobile devices—as well as encrypted while moving from one device to another.  [Download the podcast: Tape Encryption - Not Enough]  Townsend Security helps encrypt and secure sensitive data that you may be storing in a database (Data at Rest) and data that you may be transmitting (Data in Motion).

I sat down with Patrick Townsend, CEO & Founder of Townsend Security, to discuss which technologies are critical to protect data at rest and data in motion. He discussed the fundamental technologies to protect sensitive data in each:

The two fundamental solutions for Data in Motion are:

1.    FTP with encrypted SSH (Secure Shell) capability
2.    PGP solutions to add an additional layer of protection


The fundamental solutions for Data at Rest are:

1.    Industry Standard Encryption such as AES
2.    Key Management that meets standards (FIPS 140-2 compliant)

Implementing all of these solutions where they are needed is the only way to fully protect your sensitive data and prevent your organization from experiencing a data breach. To learn more about technologies your organization can use to protect sensitive data, download our podcast “The Many Flavors of Data Protection.”

The last 20 years has seen a dramatic re-alignment of the Chief Information Officer’s (CIOs) responsibilities to match the business goals of their Organizations. The modern CIO is less likely to be a pure technologist, and far more likely to be imbued with a deeper knowledge of business issues such as organizational goals, strategic alliances, bottom line financial analysis, and even with merger and acquisition strategies. In the public sector, this means that CIOs are far more aligned with political and policy goals, and not just minders of the IT infrastructure.

This has largely been good for the competitive stance of business organizations, but I think it has led to some technology blind spots. CIOs today are far more dependent on their vendors, consultants, and shrinking IT staff for guidance on security issues, and data privacy in particular. And in today’s risk environment, that may not be a good thing.  Because when a data breach happens, the CIO is going to be the one on the hot seat to explain the problem and take responsibility.

And that is not a comfortable place to be.  Just ask anyone who has been there.

When CIOs try to assess their data privacy stance, they often question their IT staff questions like this:

• Do we have our data protected properly?
• Is our data protected according to compliance regulations?
• What assurances do we have from software and cloud vendors that our data is protected?

Patrick Townsend recently contributed this article to OneAccord's blog.  To read this article in it's entirety you can visit OneAcord's blog here.  If you are ready to learn more about encryption, download our white paper "AES Encryption Strategies - A White Paper for the IT Executive."