Townsend Security Data Privacy Blog

4 Things a Point of Sale (POS) Vendor Can Do to Avoid a Data Breach

It was revealed earlier this month that the St. Louis-based supermarket chain, Schnucks, had a data breach that exposed at least 2.4 million customer credit and debit card numbers to an outside hacker. Schnucks is currently involved in a class action lawsuit over the breach and possible leak of credit card info by its card processing company.

Currently the news reports that this breach occured because:

1. Leaders in the company don’t think that anything is wrong with their data security. According to a survey by CORE Security only 15% of CEOs are very concerned about network vulnerability; however, 65% of security officers “admitted to not having the sufficient data needed to interpret how security threats translate to overall business risk.”
2. The point of sale (POS) and retail management software that retail companies use to process their customer’s card information often use inadequate security tools and minimal security best practices.

Data breaches caused by faulty security in credit card processing machines and software are surprising to most people because we expect credit card processing companies to protect our card information and personal data. In fact, credit card processing companies are mandated by the Payment Card Industry Data Security Standards (PCI-DSS) council to use encryption and encryption key management in order to sell their point of sales (POS) devices and retail management software to businesses such as Schnucks.

Despite the regulations, however, many POS and retail management vendors pass PCI-DSS audits by the skin of their teeth with data security solutions that have been cobbled together with the bare minimum requirements. If asked if they still felt exposed with their current data security solution, many database administrators will respond with a resounding, “YES.”  As we have seen over and over again, these piecemeal solutions are not good enough to prevent a data breach!

This has revealed a truth that is becoming more and more evident:

Just because a merchant or a POS vendor has passed a PCI-DSS audit does not necessarily mean they are protected from a data breach! Even though PCI-DSS is supposed to protect customers and prevent data breaches of this kind, loose interpretations by auditors of PCI-DSS and poor encryption and key management techniques leave businesses open and exposed to hackers.

Schnucks could have most likely prevented this data breach by having chosen a POS vendor and retail management software ISV who offered these guarantees:

1. Encryption - Always use industry standard encryption such as AES encryption.
2. Encryption key management - Companies encrypting data should always protect their encryption keys using an encryption key management hardware security module (HSM). This is a critical component to securing sensitive data.
3. System logging - A good system logging solution can help you catch and prevent changes to your network in real-time in order to prevent a data breach.
4. Certifications - Your POS and retail management software provider should have encryption and key management with NIST and FIPS certifications. These certifications ensure that your encryption and key management solution are up-to-date with the highest standards.

Unfortunately, these days passing a PCI-DSS audit is not enough. Merchants and retail software vendors need to stay ahead of the game by using data security tools that are going to protect their customers and protect themselves in the event of a data breach. The bare minimum will not cut it.

Townsend Security is a leading provider of encryption, key management, and system logging solutions. We partner with POS and retail management ISVs to help these companies protect and secure sensitive data fast, easily, and at a competative price. Here at Townsend Security our team works with our partners by providing hardware, training, marketing materials, and thorough back end support to help our partners and their customers achieve peace of mind.

Secure Your TrueCrypt Passwords With Encryption Key Management

With businesses handling so much sensitive data today, securing and protecting that data has become a critical part of managing risk and protecting customers. Credit card information, social security numbers, private health information (PHI), and even names, email addresses, and passwords must be protected under industry regulations and many state laws. Most businesses collecting large amounts of customer data store their data in databases--systems that have been around for years. Today, these databases have capabilities that allow for easy encryption and enterprise key management - often times without program changes.

However, there is a lot of sensitive data out there that doesn't fit neatly into databases. Word documents, images, and blueprints, for example, are typically stored on devices such as laptops and personal computers. In order to protect this data, many people opt for "whole-disk" encryption--an option that comes with most personal devices now-a-days. This might seem like the most obvious answer to encrypting unstructured data on a disk, but the performance impacts of encrypting an entire device can be a turn-off to some users. Because of this, they have opted to take on the risk of leaving their data unencrypted in order to maintain performance.

Today there is another option for disk encryption that encrypts only the files you want encrypted. TrueCrypt is an open source, on-the-fly whole disk or folder encryption solution for Windows, linux, and Mac systems. It allows users to protect applications and files on PCs, laptops, and servers running on traditional hardware programs or in the cloud.

By itself, TrueCrypt does not provide external encryption key management, which has been a challenge for TrueCrypt users who wish to use security best practices. Unlike a secure key manager, TrueCrypt normally protects data with a password. This type of one-password security lacks the advantages of a hardened security module-based encryption key management system.

Encryption key management is a significant part of data security that is recommended or required by most data security compliance regulations. Although TrueCrypt does not provide a key management device, the developers of TrueCrypt have provided a pathway to key management using a third-party key manager. This capability is essential for an enterprise level operation where at least one server is used for data management. For a single use instance of TrueCrypt, the single password created by TrueCrypt is pretty easy to manage. However, in a scenario with multiple instances and higher security is absolutely essential, there needs to be a mechanism for securely storing TrueCrypt passwords, and automating the mounting of encryption drives. Without a solid, key management device, this can be a challenge.

Townsend Security now offers Key Connection for TrueCrypt for Windows with Alliance Key Manager - an encryption key management hardware security module (HSM) for businesses needing to protect both structured and unstructured data on their devices. Key Connection is a cost-free add-on to Townsend Security’s Alliance Key Manager product for Windows, SQL Server, Oracle, Linux, IBM i, and the cloud. Download our podcast "Managing TrueCrypt Encryption Passwords" to learn more.

4 Ways to Get Password Hashing Right

Over the past couple years we have seen many instances of online companies experiencing major data breaches due to poor or non-existent password hashing techniques. Organizations such as eHarmony, LinkedIn, LivingSocial, Last.fm, have collectively had millions of user passwords stolen. Despite widespread publicity around these breaches, and many reporters  calling out the mistakes these companies have made around their hashing techniques, these types of breaches are only becoming more common.

Fortunately, for companies who want to prevent a data breach of their users’ passwords and and other personal information, and keep their names out of the headlines, it is fairly easy to do hashing right. 

Four things you should do to get password hashing right:

1. Choose a good quality hash algorithm. Do NOT use MD5 or SHA-1. These are known to be weak and you should just never use them. Use one of the SHA-2 family of hashes such as SHA-256 or SHA-512. Yes, I know about the theoretical weaknesses of the SHA-2 family and that we will soon have a replacement for SHA-2. But use the best you can for now.
2. Always use Salt with your hashes. A Salt is some extra data that you add to your password (or any other field that you are hashing) to avoid a rainbow table or brute force attack on the hashed value. Adding Salt can make cracking a hashed value much more difficult.
3. Use a strong Salt value. Using a few characters such as a GUID or short hex string won’t really give you that much additional protection. I would recommend adding a minimum of 128-bits of cryptographically strong Salt to the password you are hashing. We use a 256-bit value in our applications. Using an encryption key might be an excellent choice for your Salt value if it is provably cryptographically strong.
4. Protect your Salt. Leaving the Salt value lying around in a user file or in the clear is a really bad idea. An attacker who has easy access to the Salt value can efficiently attack the hashed value. You must protect the Salt value as you would an encryption key by using an external key management hardware security module (HSM).

If you take these four steps you will have a much more secure and defensible strategy for hashed passwords, will take you a long way down the road to better security of users’ sensitive information.

Patrick

Steps to Take to Reduce Security Risk

Townsend Security recently asked founder and CEO Patrick Townsend to contribute his expertise and thought leadership on data security and executive 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, Patrick Townsend discusses:

• 5 misconceptions business executives have about data security
• 5 steps to take to reduce security risk
• And what tools to invest in to protect your company's future

Read an excerpt from his article below:

"Many business executives are aware that hackers and data breaches pose a risk to their organizations, but they aren’t sure how much risk they really bear, or even how to assess the risk from a business point of View. Let’s look at some of the misconceptions executives have, and what steps they can take to minimize the risk.

5 Misconceptions About Data Security Risk:

1) If we have a breach, we’ll just pay the fine
In many cases there will be fines for a data breach, but it is only a small part of the total cost. The cost of a breach also typically includes a forensics investigation, credit monitoring for customers, lost sales due to brand damage, and litigation costs.

2) We’ve never had a problem, so things are probably OK
This type of thinking is not a form of risk assessment. Since data breaches often take months to discover, you may not know that a breach has already occurred. Wishful thinking won’t help you prevent a breach.

3) My software vendors and consultants say they have everything under control
Today, many software vendors have not moved quickly enough to add encryption to their core products. It is not wise to rely on vague statements about data security from vendors and consultants...

Steps to Take to Reduce Security Risk:

1) Talk About It
Discuss the importance of data security with all members of the organization’s leadership team. Then talk to your IT department. Data security is an ongoing process that involves every member of the organization, and will extend beyond your organization’s boundaries to vendors and service providers. Responsibility for data security belongs to everyone.

2) Assess Your Current Data Security Posture
If you have not had an external audit and assessment of your organization’s data security practices by a qualified security professional, now is the time to start. First, perform a data security assessment with an in-house consultant, security audit firm, or platform vendor to evaluate your current security posture. Find the location of all sensitive data. Lastly, evaluate the security of your backup tapes. The right security assessor will help you identify the most urgent problems, and help you prioritize your efforts. This process can also help you overcome any internal resistance to addressing the problem.
Invest in Encryption and Key Management

3) When you have located sensitive data that is not encrypted, start a project to encrypt it now. Don’t forget to invest in the necessary encryption key management devices to protect the encryption keys. If your risk assessment warrants, provide budgetary exceptions to address the problem. Invest where you need to, as soon as you can. When choosing an encryption and key management solution, you should also ask: Is our encryption industry standard and NIST certified, is our key management FIPS 140-2 compliant, is our key management device an external hardware security module (HSM), and are we using dual control and separation of duties to reduce points of failure...”

Read all the points in the rest of the article in your free copy of the eBook HERE.

Patrick Townsend has more than 25 years of experience in the data security industry and brings both a deep well of knowledge and a unique perspective to the subject. He speaks regularly on data protection and encryption key management topics.  He has produced a series of educational videos available on YouTube, records podcasts on data privacy, and is a regular contributor to the company's blog.

SQL Server Encryption: Three “Key” Things to Remember…

With the emergence of data security standards, encryption and key management have become a necessity for most companies storing or transferring sensitive data such as credit card numbers, patient data, social security numbers, and other personally identifiable information (PII). 

Transparent Data Encryption (TDE) on Microsoft SQL Server 2008, 2008 R2, and 2012, allows automatic encryption on these editions of SQL Server without application changes. With newly available SQL Server encryption capabilities, encryption key management--a critical step to securing your data--is done easily on SQL Server with extensible key management (EKM). EKM allows customers to choose a third-party encryption key management hardware security module (HSM) and integrate that HSM easily into their SQL database.

Without an encryption key management HSM, SQL Server users are essentially leaving the keys to their data underneath their welcome mat!

Three things to remember for following security best practices:

# 3 – SQL Server Encryption isn’t as imposing as it sounds…

• Compliance regulations drive the need for encryption and require that you protect the encryption keys apart from the encrypted data storage.  
• An encryption algorithm is simply a mathematical formula that protects data. The critical element is the way the “Key” to that formula (the encryption key) is managed. 
• HSMs like Alliance Key Manager create, manage, and protect encryption keys through the entire lifecycle and deliver them securely when they are needed.
• Alliance Key Manager is a quick, efficient, and compliant solution that is easy to implement with our “Key Connection for SQL Server” EKM provider software. Based on FIPS (Federal Information Processing Standard) 140-2 certified technology, it is easy to implement, deploy, and configure with “out of the box” integration with SQL Server.
• Townsend Security is Microsoft Silver partner and Alliance Key Manager works with all versions of Microsoft SQL Server including SQL Server 2005. Additionally, Alliance Key Manager allows you to protect sensitive data stored in Microsoft SharePoint and Microsoft Azure.

#2 - You are required to protect data by government and industry created regulations…

• PCI-DSS (Payment Card Industry – Data Security Standard) for merchants
• HIPAA/HITECH  (Health Insurance Portability and Accountability Act)/(Health Information Technology for Economic and Clinical Health) for medical providers
• GLBA/FFIEC (Gramm-Leach-Bliley Act)/(Federal Financial Institutions Examination Council) for the financial industry
• FISMA (Federal Information Security Management Act) for US Government agencies

#1 - Customers expect their data to be protected!

• PCI-DSS is required for anyone who takes credit cards.
• While expectations for data protection in the medical and financial industries are wide-spread, and easily understood, compliance regulations affect business and organizations of all sizes. 
• Beyond the expectations for privacy, and the laws that require it, the consequences of a data breach or data loss can be substantial. 
• Small to mid-sized companies can be an easy target for data thieves, resulting in costly losses to their business and reputation.

We have resources to share with you about SQL Server Encryption and how to best secure your data.  Please click the button below to access these informative downloads! 
 

As always, we welcome your comments and questions!

4 Ways to Encrypt Data in Microsoft SQL Server

Almost every organization has at least one application built on Microsoft’s SQL Server database. Whether you build an application in-house using Microsoft’s development tools or you deploy a software package from a software vendor, chances are that your organizations has one or more SQL Server databases to help you manage information.

Today it is almost impossible to run a business without handling sensitive information and storing storing data such as customer names, credit card numbers, bank account numbers, passwords, email addresses, or other personally identifiable information (PII) or private health information (PHI) in your SQL Server database. If your organization must meet data security regulations such as PCI-DSS, HIPAA/HITECH, or GLBA/FFIEC, you probably already know that this data must be encrypted in order to protect your customers and prevent data loss in the event of a data breach.

What you may not know is that in order to truly protect your data, you must manage your encryption keys in adherence to key management best practices such as dual control and separation of duties using an external hardware security module (HSM). Your company will only be able to avoid data breach notification if you are using these best practices.

The good news is that in its most recent release, SQL Server 2008/2012 comes equipped with transparent data encryption (TDE) and extensible key management (EKM) to make encryption and key management using a third-party key manager easier than ever. Older versions of SQL Server can also be easily encrypted using different tactics, and you can manage those encryption keys just as easily on an HSM as well.

If you’re currently looking into encrypting your SQL Server database or deploying a key management system, you may be concerned about how to protect your data depending on the version, code, and language used to build your database. To help ease your worries, here are 4 ways to encrypt your SQL Server database and protect your encryption keys:

1. Since SQL Server 2008 Microsoft has supported automatic encryption with TDE and cell level encryption for Enterprise Edition users and above. Without any programming you can encrypt the SQL Server database or an individual column, and store the keys on an encryption key management HSM.
2. If you have an older version of SQL Server, or you have SQL Server Standard Edition or Web Edition, you don’t have access to TDE. But you can still automate encryption: Through the strategic use of SQL Views and Triggers, you can automate encryption of sensitive data on your SQL Server without extensive program modifications, and still use a secure key management HSM to protect the encryption keys.
3. Your developers might have written custom application code to implement your SQL Server database. But SQL Server encryption and key management is still within your reach. A good key management vendor should supply you with software libraries that easily add into your applications and implement SQL Server encryption.
4. You might have a SQL Server database, but not be using Microsoft programming languages. Perhaps your applications are written in Java, Perl, or PHP. Again, it is simple to deploy software libraries that encrypt the SQL Server data and which store the encryption keys on a key server HSM.

SQL Server encryption and good key management is not difficult to achieve. Although key management has a reputation for being difficult and costly, today key management for SQL Server is cost-effective, easy, has little to no performance impact, will get your company in compliance, and will keep your organization out of the headlines by helping to prevent a data breach.

To learn more about key management for SQL Server, download the White Paper, “Encryption Key Management for Microsoft SQL Server 2008/2012.”

How LivingSocial Could Have Avoided a Data Breach

Lack of security around passwords, emails, usernames, and other personal information leads to another easily preventable, massive data breach.

Last week we saw another major data breach of personal information due to a hacker who gained access to names, email addresses, dates of birth, and passwords protected using hashes and salt. When this story started to pop up in the news we were pretty surprised by what happened. Didn’t this exact same breach happen to LinkedIn nine months ago?

In June of last year LinkedIn suffered a similarly huge data breach and lost 6.5 million hashed passwords. The passwords were posted online and within a few hours over 60% of the passwords had been exposed. Why were these passwords so easy to crack? Because LinkedIn had been “protecting” user passwords using the hash algorithm SHA-1. SHA-1 is a known weak algorithm that is no longer recommended by the National Institute of Standards and Technology (NIST). Today it is a basic industry standard to use the stronger hash algorithm SHA-256 or SHA-512.

In the end, however, LinkedIn’s breach was really more of a headache than a disaster. A class action lawsuit brought against LinkedIn was thrown out due to lack of clear evidence that any real damage was caused by the breach. Where many consumers and data security experts had probably hoped that their breach had been a wake-up call to the e-commerce community, and anyone still using SHA-1 should have upgraded their data security practices immediately, it seems that many organizations have done nothing.

This is so surprising to us, not only because today using better data security such as strong hashing algorithms is considered to be trivially simple, but because in many states personal information such as first and last names, birthdates, and email addresses are considered to be personally identifiable information (PII) under state data security law. Most of these laws provide safe-harbor from data breach notification if a companies protect this information using industry standard tools.

In the end we hope that other businesses take note from this series of data breaches and update their data security.

How can you prevent a data breach of passwords and emails from happening to you?

1. Use only an up-to-date hash method such as SHA-256 or SHA-512
2. Use a hash based on industry standards - NIST publishes recommendations and standards. Always follow the most up-to-date standards.
3. Use salt for an additional layer of security
4. Protect the salt from loss or disclosure
5. Use two-factor authentication

How can you prevent a data breach that compromises your customers very sensitive data such as credit card information, social security numbers, and private health information (PHI)?

1. Use AES Standard Encryption to protect critical sensitive data such as credit card information and social security numbers.
2. Use a FIPS 140-2 compliant key management system that implements key management best practices such as dual control, split knowledge, and separation of duties.
3. Use a system monitoring tool that will alert you to important changes in your database such as unauthorized access in real time in order to stop suspicious activity before it’s too late.

To learn more about how companies such as LivingSocial and LinkedIn could have avoided a data breach, download the Podcast: How LinkedIn Could Have Avoided a Data Breach.

IBM i Security: FIELDPROC, Encryption Key Management, and Compliance

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.

Merchants Who Passed PCI-DSS Audit Last Year May Fail Next Time

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.

What the CEO Needs to Know About Data Security

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.