Townsend Security Data Privacy Blog

The new California Consumer Privacy Act (CCPA) is a really big deal. Almost no one is ready for it, so you are not alone if you are just getting familiar with the CCPA requirements. Let’s dig into it and try to translate the law (California AB 375 and related statutes) into understandable language. I will also make some recommendations on things you can do right now to get started.

Some history might help

The law itself (AB 375) passed in June of 2018 is a pretty easy read. Interestingly, it directly points to the social and political factors that lead to the creation of the law. The increasing number of data breaches and the Cambridge Analytica scandal are specifically mentioned in the law - but if the law seems a bit rushed and incomplete, that’s because it is!

California is one of those states that make it relatively easy for citizens to gather signatures and put initiatives directly to the people. In early 2018 that is exactly what happened. An initiative related to consumer privacy gathered enough signatures to make it on the California ballot and this proposed new law frightened the technology companies located both in California and outside of the state.

In response to the initiative, the California legislators struck a deal with the initiative proponents. If the legislature could pass a strict new consumer privacy law in short order, the initiative proponents agreed not to put the initiative on the ballot - and that is what happened. Probably breaking speed records for such legislation, the California legislature created the new law in just a few days, and the governor signed it. The initiative was not placed on the ballot.

The speed of the passage of the law had one unfortunate side-effect: There is a lot of ambiguity in the law. You are going to be scratching your head about some of the requirements and definitions in the law. What is missing or undefined is almost as significant as what is in the law. The law goes into effect on January 1, 2020 but the legislature has promised to provide additional guidance in the Fall of 2019, and new clarifying law by June of 2020. More on this below.

The CCPA law, where to find it.

Reading regulations will usually make your eyes roll back in your head. In this case the California law is a pretty easy read. I highly recommend that you do this. I read several summaries of the law in business and technology journals, but learned some important facts when I subsequently read the law directly. Here is the link (there is a PDF version available for download).

Just remember my previous comment about future clarifications of the law. There will be changes and I will try to keep you up to date. You should also check the CCPA website for updates.

Is my Organization required to meet the law? 

If you collect data on people who are in California, and meet the minimum criteria (see below), and are not explicitly excluded, you must meet the requirements of the new law. Notice that I did not say “California citizen”, but people who are in the state at the time of data collection. You are not exempt if your organization resides outside of California. If you collect data on people in California, assume you are covered by the law.

If you meet any of these criteria, you are required to meet the new CCPA law:

• You have $25 Million or more in annual revenue
• You collect information on 50,000 or more people
• You derive 50 percent or more of your revenue selling personal information to third parties 

The law applies to both public and private organizations. I often hear people tell me that they are not covered by regulations because their company is “private.” Don’t make this mistake. Being a private organization does not exempt you from the new California law.

There are some exclusions in the law: If your organization is already covered by equivalent privacy regulations such as HIPAA, GLBA, and others, you may be exempt. Don’t be fooled into a sense of complacency about this. The CCPA has privacy regulations that are not covered under those laws. If you think you are exempt, I would highly recommend that you get legal advice on this point.

When does it take effect?

The law takes effect on January 1, 2020. Here are some important points to consider:

• The law covers data collected for the previous 12 months (from January 1, 2019).
• There will be clarifying guidance in the Fall of 2019.
• The law is likely to be amended for clarification by June of 2020, but it is not likely to be less restrictive.
• The law covers a much broader set of information than any other regulations, including GDPR.

I’ve heard people say that they are not worried because they meet GDPR requirements. That is a big mistake. There is certainly some overlap with GDPR, but some of the CCPA requirements are different and much broader. For example, what is considered “personal information” includes more and different information than GDPR.

What rights are granted to consumers?

Here is a short list of the rights granted to consumers under the new law (please read the law directly):

• The right to opt-in to data sharing BEFORE you collect and share the information, and the right to opt-out of data sharing at any time. The option to opt-out of data sharing must be respected for 12 months, and subsequently there must be an explicit opt-in process before sharing.
• The right to opt-out of data sharing using a web page or phone number (other methods may be added to these).
• The right to a clear privacy statement on your website that specifically addresses the CCPA.
• The right to know the intended uses of the information that is collected.
• The right to know the categories of information you collect.
• The right to know the specific information you collect.
• The right to know the sources of the information that you collect (websites, third parties, etc.).
• The right to know to whom you sell or share information.
• The right to receive a copy of the information you collect in a user friendly format.
• The right to have you delete their information.
• The right to deletion of their information from any third party service providers with whom you shared the data.
• The right to non-discrimination in terms of your services if they opt-out.
• The individual and class action right to sue if sensitive data is lost and is not encrypted, and for other reasons (please read about encryption below).

You have 45 days to respond to a consumer’s request. With proper notice this can be extended another 45 days (90 days in total).

Try to make a sincere effort to understand the nature and intent of these requirements. The law is written to address those who try to be “cute” about meeting the requirements, and the penalties go way up for intentional avoidance of the requirements.

Note that you have the obligation to verify the identity of the consumer who is exercising these rights. Unfortunately, there is not enough guidance on the proper ways to do this. Be aware, however, that you cannot use any information provided by the consumer that is a part of the privacy request for any other purposes! 

What information does it cover?

The personal information covered by the CCPA is quite broad and extends into areas not covered under GDPR and other regulations. The current definition of sensitive consumer data includes:

• Identifiers such as a real name, alias, postal address, unique personal identifier, online identifier IP address, email address, account name, Social Security number, driver’s license number, passport number, or other similar identifiers.
• Personal and commercial behaviors, and inferences from them.
• Characteristics of protected classifications under California or federal law
• Commercial information including records of personal property, products or services purchased, obtained or considered, or other purchasing or consuming histories or tendencies
• Biometric information
• Internet or other electronic network activity information including, but not limited to, browsing history, search history and information regarding a consumer’s interaction with a website, application or advertisement
• Geolocation data
• Audio, electronic, visual, thermal, olfactory or similar information
• Professional or employment-related information
• Education information, defined as information that is not publicly available personally identifiable information (PII) as defined in the Family Educational Rights and Privacy Act (20 U.S.C. section 1232g, 34 C.F.R. Part 99)
• Inferences drawn from any of the information identified in this subdivision to create a profile about a consumer reflecting the consumer’s preferences, characteristics, psychological trends, preferences, predispositions, behavior, attitudes, intelligence, abilities and aptitudes.

 This is an amazing list of data items that goes far beyond what we see in other regulations. Many companies have done a lot of work using Artificial Intelligence and Machine Learning to make inferences about consumer behavior. I hope you are not missing the fact that this type of inferential and derived data is covered under the CCPA!

What are the penalties?

The potential penalties fall into two categories: Those imposed by the California Attorney General, and those imposed by newly enabled consumer litigation.

First, let’s look at the penalties that can be assessed by the AG. The penalty range starts at $2,500 per violation. Many people think this amount is for each record that is lost or in non-compliance. It is easy to see that this could expensive very quickly. However, if the AG finds that you are “intentionally” in violation of the CCPA the penalty increases to $7,500 per record. One way to trigger this level of penalty is to ignore a formal notice by the AG that you are in violation of the CCPA. Never ignore this type of notification! The higher level of penalty can trigger an existential crisis for many companies.

The second area of penalty relates to newly enabled litigation by individuals. Under the CCPA individuals have a right to bring direct legal action against an organization. This includes the ability to bring a class action against a company. Other than fully meeting the privacy requirements of the CCPA there is no way to limit your exposure to this type of litigation. The CCPA explicitly prohibits the use of arbitration clauses and other means of contractually reducing your exposure. You have to be notified about an impending action, and you have 30 days to correct the action and respond.

These two areas of exposure should motivate you to get a plan in place to fully meet the CCPA privacy requirements, and start executing on the plan. Time is short. 

Am I required to encrypt sensitive data? 

If you want to avoid the risk of direct or class action litigation related to data loss you should encrypt the sensitive data. Individual and class action litigation only applies to unencrypted sensitive data that is disclosed or lost, for whatever reason. The CCPA is clear on the need for encryption. If you lose unencrypted sensitive data this is direct evidence that you violated your duty to provide reasonable security procedures and practices to protect the sensitive information. See section 1798.150(a)(1). 

Most modern relational and Big Data databases provide an easy path to encryption. Find where your sensitive data is stored, prioritize an encryption strategy, and move it forward. This effort may require an upgrade to your database systems to a version that supports encryption. Understand the budget requirements and add the costs for encryption key management.

What should I do now? 

Although there will be additional guidance in late 2019, and there will likely be clarifying legislation in early 2020, you should not wait to get started. There are a lot of things you will need to do to meet the CCPA privacy regulations. Here is a short list that should help you get started. There is more to do, but these will be critical steps:

• Identify and document all of the sensitive information that you collect or derive from interpretations of the data. Document the sources of this data, how you collect it, the individual items, and then classify the data.  Pay special attention to the categories of data outlined above. In addition to your internal IT systems be sure to include your hosted and cloud applications, and your web-based SaaS systems.
• Identify all of the third parties with whom you share information. Be sure to document exactly what information is shared.
• Review your website to ensure you meet the explicit requirements of the CCPA. You will need to update your privacy statement per the CCPA requirements. 
• Institute processes for handling consumer privacy requests. This will probably require new IT reporting applications as well as human processes for responding to requests. Be sure to keep an audit log of all requests from consumers, and your response.
• For all service providers who receive information that you share, review your service agreements. Revise those agreements to bind the service provider to the new CCPA regulations. If service providers resist new contract terms, or are non-responsive, have a plan to replace those service providers. Since many service contracts renew on an annual basis, start this process now.
• Encrypt the data and use good encryption key management. Your only safe-harbor from litigation in the event of a data loss is encryption. The time to get started is right now.

 Disclaimer

 Nothing in this article constitutes legal advice in any way. Consult with a qualified attorney for any legal questions or advice. The new California Consumer Privacy Act will have new guidance before the activation date of January 1, 2020 and is likely to be modified by additional legislation. Please refer to the official California state website for more information. 

Many VMware customers know that they can encrypt their virtual machines that are managed with vSphere and other VMware tools. VMware vSAN encryption can also provide important protections for data-at-rest in vSAN virtual disks. I wanted to share some thoughts I’ve received from our VMware customers and partners on some of the benefits of using vSAN storage with encryption enabled.

A Simple Way to Encrypt

When you have a large database, it can be inefficient to store the data in a directory or folder directly in your virtual machine. vSAN can be much easier to manage from an administrative and recovery point of view and your VMware applications can easily connect to the vSAN volume. vSAN is configured using the VMware tools you already know how to use and managing vSAN storage is easy.

Did you know that you can enable vSAN encryption to protect that database with sensitive data? You can enable vSAN encryption on existing virtual disks or on new virtual disks that you create. The process is simple and does not require any downtime for your application - and vSAN encryption enables the use of a KMIP compatible key manager like our Alliance Key Manager so that you stay lined up with industry standards and security best practices. It is an easy way to improve your overall security posture.

A Simple Way to Meet Compliance

Many of our VMware customers are struggling to implement encryption on their databases to meet compliance regulations and to protect the organization’s digital assets. Although encryption and key management have become much easier over the years, it can still seem like a daunting task. VMware vSAN encryption to the rescue! It is easy to implement with the tools you already have, and you can deploy an affordable key management solution such as our Alliance Key Manager to fully meet compliance requirements and security best practices. You configure key management directly through the KMS Cluster facility in vSphere, and then activate vSAN encryption. Alliance Key Manager does not impose any limits on the number of virtual disks you protect, nor on the number of nodes that connect to the key manager.

A Simple Way to Save Money

Some databases, such as Oracle and Microsoft SQL Server, require expensive license upgrades to enable encryption capabilities. This cost can be out of reach for many small to medium size organizations. Using vSAN encryption is an affordable way to achieve a better security posture using the tools and the IT professionals you already have.

You might be wondering if VMware supports the deployment of these databases on vSAN volumes. The answer is absolutely YES! You will find substantial documentation from VMware on doing exactly this. The documentation includes reference architectures and analysis of performance impacts. You can confidently move forward with vSAN encryption knowing that VMware has invested time and effort to make sure you are successful.

Lastly, we know that some VMware users have deployed the free version of vSphere. There are some costs associated with upgrading to the paid tier of vSphere in order to get the ability to encrypt VMs and vSAN. If this is where you are today, talk to us about how we can help with the uplift to the next level of vSphere capability.

Resources:
vSAN Documentation
Oracle Database on VMware vSAN Solution Overview
Architecting Microsoft SQL Server on VMware vSphere
Pointers to our AKM for vSphere/vSAN Solution Brief 

Guest blog by Sophia Khan of CyberGuard Compliance

---

With all of the security breaches you hear of in the news and the occurrence of these incidents becoming more widespread, how can you be sure your customer’s credit card information remains secure? This is the purpose of PCI DSS (Payment Card Industry Data Security Standards) as it pertains to all merchants who accept credit cards, irrespective of their annual revenue and credit card transaction volume. Even with this mandatory requirement, a vast majority of organizations are still struggling to maintain PCI compliance, and the process is costing companies a great deal in consulting fees to address the root cause of PCI audit failures. By being proactive in assessing the areas of weakness when undergoing a PCI Audit, especially for the first time, companies can avoid the frustrations of a failed audit and be well on their way to continued PCI compliance.

FIRST TIME PCI AUDIT AREAS OF WEAKNESS:

 

1) Encryption Key Management

Several sections of PCI DSS address cryptography and key management with respect to the protection of cardholder data. When a company is unfamiliar with the ever-evolving encryption standards and requirements, this can provide additional challenges in maintaining PCI compliance. PCI DSS does not specify which cryptographic standards should be utilized, however most companies do implement Advanced Encryption Standard (AES) and Triple Data Encryption Standard (TDES), which are widely accepted for the encryption of sensitive data. These are the standards approved by the National Institute of Standards and Technology (NIST).

The list of requirements includes the protection of cryptographic keys utilized for the use of encryption of cardholder data by limiting access to the fewest number of custodians necessary, and the secure storage of keys in as few locations as possible. Additionally, cryptographic keys generated need to be strong with secure key distribution and storage, with periodic key changes being mandatory. For example, if a vendor hosts your encryption keys, then they along with hackers can most likely access it. Therefore, it is essential for maximum security to exclusively host your own encryption keys.

The solution to the complex issue of encryption key management, is the utilization of encryption and tokenization tools which will protect sensitive information with NIST-validated AES database encryption. There are five fundamentals of encryption key management:

1. Key storage
2. Key policy management
3. Key authentication
4. Key authorization
5. Key transmission

By implementing a strong key management application, secure data can be protected and there will be prevention of third-parties from accessing unencrypted content.  

2) Two-Factor Authentication

Passwords are typically the first and final line of defense in protecting user accounts. They are also the easiest for hackers to crack and on their own can compromise the security of sensitive information. Two-factor authentication, also known as multi-factor authentication, significantly reduces the risk of system intrusion, as you are required to utilize both a password as well as an additional measure such as a security code sent to a mobile device. PCI security standards require at least two of three authentication methods described in the requirement to be utilized.

• Something you know: This utilizes knowledge of something such as a password, PIN, or phrase.
• Something you have: This may involve an RSA token device, smartcard, key fob, or cellular device with mobile authentication.
• Something you are: This involves biometric measures such as a fingerprint or retina scan, facial or voice recognition, or other unique physical identification.

By utilizing two-factor authentication, companies can reduce the security threat of possible intrusion with added authentication mechanism beyond a simple password.

3) System Logging

Section 10 of the PCI DSS indicates organizations must track and monitor all access to network resources and cardholder data. This is one of the most important PCI compliance requirements as it related to network security and access. The requirement has many subsections outlining what needs to be fulfilled in order to maintain compliance in this section.

The following must be logged and maintained:

• There must be a system for logging access to all system components and every individual user.
• Audit trails for each of the following must be established:
  • Individual users with cardholder data;
  • All actions performed by users with administrative privileges;
  • All invalid access attempts;
  • Tracking of audit log clearings;
  • Secure assessment trail logs and access restriction to those with a job-related need.

System logging capabilities and the function to track user activities are imperative in detecting, preventing, and diminishing the potential impact of a data security breach. In the absence of system activity logs, it would be near impossible to detect the cause of a compromise and correct it. By maintaining knowledge of who had access to the system what they used the data for, a company can be proactive in the event cardholder data goes missing or there is suspicion of any foul play.

In recent times, many organizations have fallen into the ‘check the box’ category, where PCI compliance is simply a mandatory prerequisite they try and get through for the sake of fulfilling a minimum requirement. By practicing good cybersecurity hygiene on a consistent basis, and being cognizant of the potential areas of weakness, your Company can ensure cyber-risk management is a continued priority as you minimize operational risks. This will also allow your firm to stay ahead of the curve as technology evolves when the standard updates with time.

Visit CyberGuard Compliance’s website to learn more about their services relating to PCI audits.

About CyberGuard Compliance
CyberGuard Compliance is based in the United States, but serves clients around the globe. The firm’s leadership team has over 150 years of combined business management, operations and related information technology (IT) experience. CyberGuard Compliance has performed over 1,000 SOC audits, and unlike most traditional CPA firms which focus on financial statement auditing and tax compliance, CyberGuard Compliance focuses on cybersecurity and compliance related engagements. These engagements include, but are not limited to, SOC 1 Audits, SOC 2 Audits, SOC 3 Audits, SOC Readiness Assessments, ISO 27001 Assessments, PCI Compliance, HIPAA Compliance, HITRUST Compliance, Vulnerability Assessments, and Penetration Testing. For more information, please visit https://www.cgcompliance.com.

A Checklist for Meeting Compliance

 

What Information Do I Need to Protect with Strong Encryption?

The European General Data Protection Regulation (GDPR) is a radical and transforming event in the information technology space. Due to go into full effect on May 25, 2018, it will require major changes to IT systems and they way organizations relate to their customers, employees, and external partners. It is hard to overstate the the impact of the regulation. Organizations of all sizes and types, and cloud service providers small and large, must adjust to the notion that people now fully own information about themselves - and companies outside of the EU zone are impacted, too.

Article 17 of the GDPR focuses on the “Right of erasure”, also known as the “Right to be forgotten”. Here is a link to that section.

Let’s talk about how we can use encryption and key management to help meet the requirements of the legislation. Since deploying encryption will also help meet the privacy requirements of GDPR, the same technology can be used to implement Right of Erasure.

First, let’s look at the technology landscape related to encryption:

Encryption is one of the most well understood mechanisms for data privacy. There are well-established, mature standards for encryption and the related key management technologies. Most companies will use encryption to meet GDPR privacy requirements, and will be deploying encryption key management to protect the keys. There are mature encryption technology solutions available on all major enterprise operating systems and on all major cloud platforms. Protecting encryption keys is also well understood. Many organizations have already deployed encryption in some parts of their organizations, and GDPR will speed this process and extend protections across all parts of the data landscape.

The hardest part of getting encryption right has to do with creating, protecting, and deploying encryption keys. It is probably the hardest part of getting an encryption strategy right - and there are a lot of ways to get key management wrong:

• Storing the unprotected encryption key with the protected data
• Using weak protection methods to secure encryption keys
• Storing the encryption key directly in application code
• Using a weak encryption key - a password is an example of a weak key
• Not using strong, industry standard methods of generating an encryption key
• Not providing separation of duties and dual control around key management

There are lots of ways to get encryption key management wrong - and bad key management practices will result in GDPR compliance failures.

Fortunately, it is fairly easy to deploy good encryption key management that is affordable, easy to install and configure, and easy to integrate with your encryption strategy. A number of professional key management solutions are available to serve every enterprise operating environment. We have one (Alliance Key Manager), and others are available.

Now that we have a good encryption and key management strategy in place, let’s use it to meet the GDPR Right to Erasure.

Under GDPR Article 17 a need to erase personal information can be triggered by a number of events:

• A Data Subject (usually a person) can request erasure of personal information
• The personal information is no longer relevant from a business perspective
• A Data Subject withdraws consent and there is no overriding need or requirement to retain the data
• A Data Subject withdraws consent for processing their information
• Personal data has been unlawfully obtained or processed

That covers a lot of ground! It is not as simple as just responding to a request for erasure, we have to be aware of our actual need for information. And erasure triggers some secondary requirements:

• The Data Controller must attempt to remove data that has been made publicly available
• The Data Controller must inform third party Data Processors of the need to erase data

We have a lot of responsibilities under GDPR Article 17. How can we use encryption and key management to meet this requirement?

A key management approach:

Imagine that you assign a unique encryption key to each Data Subject (employee, customer, and so forth) and that you encrypt that person’s personal data in your databases with that unique and specific key. The time comes when must meet your obligations under Right of Erasure. Rather than go through every database table and storage server to delete the data, you could just delete the encryption key. Assuming you have strong encryption keys and industry standard key deletion processes, the deletion of the key is an effective way to zero the protected data without actually modifying the database. Data that is encrypted is unrecoverable if the key is no longer available.

There is one more added benefit to this approach - it effectively erases all of the data on your backups! Managing compliance with GDPR is especially difficult when it comes to off site backups of sensitive data. The ability to effectively erase data by erasing the encryption key without having to pull those backups out of storage is a huge cost and administrative saving!

The strategy described above is only defensible if you are encrypting the Data Subject’s information, if you are assigning them a unique encryption key, and if you are using an encryption key management solution that provably meets industry standards for key zeroization. Our key management solution does and you can get more information here.

We’ve touched just one aspect of GDPR. We will be talking more about GDPR in the days ahead.

Patrick

Due to the vast amounts of sensitive data that they deal with on a regular basis, it is understandable that the banking and financial services industries are among the most regulated in the world. While GLBA/FFIEC are specific to these industries, compliance regulations such as PCI DSS, SOX, and state privacy laws can also apply. One thing that they all have in common though, is that encryption, along with proper key management, can mean the difference between a public breach notification and having a safe harbor.
I recently sat down with Patrick Townsend, Founder and CEO, of Townsend Security to discuss the Gramm-Leach-Bliley Act (GLBA), the Federal Financial Institutions Examination Council (FFIEC), and what they say about protecting non-public personal information (NPI) and personally identifiable information (PII).

Hi Patrick. 95% of the top US commercial banks have a network security grade of “C” or below (according to SecurityScorecard’s latest Financial Cybersecurity report). In the past we have talked about the perimeter being weak and this report really supports that - which in turn supports the importance of encrypting data at rest.

Yes, the financial industry is a little bit late to the game in terms of protecting data at rest with encryption. I know this might surprise some people when they hear this. There has been an increased level and sophistication of attack and cybercriminal activity towards financial institutions. We are seeing attacks on banks, insurance companies, and many others. And it makes sense, right? Verizon recently reported that the vast majority of these attacks, around 90%, have a financial motive. Yes, these actors have other interests, but largely, data breaches and attacks have a financial motive, which makes banks a natural target.

Historically, banks have not had much compliance pressure to implement encryption – which is now changing. We are seeing this happening now, for example, in New York with the Department of Financial Services regulations. There is a lot more pressure for financial institutions to encrypt data at rest, along with properly managing encryption keys – and it is only going to continue with more regulations and more requirements.

Let’s talk about compliance regulations. The finance industry arguably falls under more than any other industry. Can you talk about the various regulations?

You are absolutely right. Financial institutions do cross a lot of boundaries – GLBA/FFIEC, PCI DSS for credit cards, SOX if they are publicly traded, privacy regulations, etc. There is just a broad set of compliance regulations coming into play.

Banks who handle credit cards have always fallen under PCI DSS. But PCI DSS focuses specifically on credit card data – credit card number, expiration date, cardholder name, etc. Specific to the banking industry, GLBA and FFIEC are requiring these organizations to protect non-public personal information (NPI). At the end of last year there was an update from the FFIEC covering best practices on strengthening the regulations around encrypting and protecting NPI. The FFIEC has been very active in that area and is fully empowered to ensure the security and confidentiality of customer records and information.

Furthermore, we just saw the state of New York and the Department of Financial Services promote some new regulations in the area of data security. NYDFS covered a lot of ground, all the way from specifying the requirement of a compliance officer right down to encrypting private data. We are seeing an evolving regulatory structure that is moving towards more security and data protection, not less, and there is no question that across the board compliance regulations and banks are having to step up to better protect data with provable technologies. Encrypting data at rest is an evolving area, but has certainly been moving at a rapid pace.

When you talked about PCI you covered what credit card numbers are required to be encrypted. What are some examples of NPI that needs protection under GLBA?

Think of it as any kind of sensitive data that could be used by a cyber criminal. For example:

• Any information an individual gives you to get a financial product or service (for example, name, address, income, Social Security number, or other information on an application)
• Any information you get about an individual from a transaction involving your financial product(s) or service(s) (for example, the fact that an individual is your consumer or customer, account numbers, payment history, loan or deposit balances, and credit or debit card purchases)
• Any information you get about an individual in connection with providing a financial product or service (for example, information from court records or from a consumer report)

Just think about it as sensitive data in the broader sense and not worry so much about the formal definition of NPI – again, information that might compromise someone’s financial or reputational status and you probably have a pretty good idea of what needs to be protected.

Along with encryption also comes key management, which has often been described as the most difficult part of encryption.

Yeah, we often say that encryption is the hardest part of data security and key management is the hardest part of encryption. Why is that? When you encrypt data, you are using a special secret, known as an encryption key (something that can’t be guessed or predicted) to keep the encrypted data safe.

First, businesses should be using standards-based encryption like AES or RSA, and these algorithms require keys to make them work. Key management then becomes the real challenge for financial institutions because they need to create and manage provably strong and protected encryption keys. Regarding strong keys, it is important to note that a password, or even what you think of as a strong password, is not adequate. This is the function of an enterprise key management solution. At Townsend Security we have our Alliance Key Manager, which is validated to industry standards (FIPS 140-2), and that means that encryption keys are strong, stored in a protected fashion, away from the data that they are protecting. All of that becomes a very important part of an encryption strategy because encryption is only as strong as the protection of the keys.

Critical functions of a key manager include:

• Ensure origin and quality of keys
• Manage keys through entire lifecycle, not just store them remotely
• Use accepted and standards-based encryption algorithms
• Implement dual control, separation of duties, split knowledge
• Ensure that keys are securely backed up, at all times
• Implement strong authentication mechanisms
• Protect and restrict access to encryption keys

Thanks Patrick. Any final thoughts you’d like to share?

We really believe in the term “Compliance out of the box.” Townsend Security provides several solutions that can help members of the financial services industry protect NPI/PII and help them meet the vast number of evolving compliance requirements. We provide encryption key management solutions that are validated to meet PCI DSS, as well as a variety of client-side applications and SDKs to make encryption projects easier than ever. Alliance Key Manager is a mature product that is in use by thousands of customers, worldwide.

To hear this interview in it’s entirety, download our podcast “Encryption Requirements for Banks & Financial Services” and hear Patrick Townsend, founder and CEO of Townsend Security, further discuss encryption, key management, and meeting compliance requirements specific to financial services.

The New York Department of Financial Services (NYDFS) surprised the financial services industry by fast tracking new cybersecurity regulations in September of 2016. Due to go into effect in January of 2017 with a one-year transition period, it takes a very prescriptive approach to cybersecurity which includes a mandate to encrypt data at rest. The financial sector is broadly defined as banks, insurance companies, consumer lenders, money transmitters, and others. The law is formally known as 23 NYCRR 500 and you can get it here.

There isn’t much wiggle room on the requirement for encrypting sensitive data. You can use compensating controls if you can show that encryption is “infeasible”. But I am not sure how you would show that. All modern database systems used by financial applications support encryption. It would be hard to imagine a financial database where encryption would not be feasible. Don’t plan on that being an excuse to delay encrypting data at rest!

The time frame is short for implementing the encryption mandate. One year seems like a long time, but it is extremely aggressive given the development backlog I see in most banks.

Here are some things you should start doing right now:

1) Inventory All of Your Financial Systems

This seems like a no-brainer, but you might be surprised how many organizations have no formal inventory of their IT systems that contain financial data. This is a top-of-the list item on any cybersecurity list of recommendations, so making or updating this list will have a lot of benefits.

2) Document Storage of All Sensitive Information (Non-Public Information, or NPI)

For each system in your inventory (see above) document every database and storage mechanism that stores NPI. For database systems identify all tables and columns that contain NPI. You will need this documentation to meet the NYDFS requirements, and it is a roadmap to meeting the encryption requirements.

3) Prioritize Your Encryption Projects

You won’t be able to do everything at once. Following all modern cybersecurity recommendations, prioritize the systems and applications that should be addressed using a risk model. Here are a few factors that can help you prioritize:

• Sensitivity of data
• Amount of data at risk
• Exposure risk of the systems and data
• Compliance risk
• Operational impact of loss

It is OK to be practical about how you prioritize the systems, but avoid assigning a high priority to a system because it might be easiest. It is better to tackle the biggest risks first.

4) Establish Encryption Standards

Be careful which encryption algorithms you use to protect sensitive data. In the event of a loss you won’t want to be using home-grown or non-standard encryption. Protect data at rest with NIST compliant, 256-bit AES encryption. This will give you the most defensible encryption strategy and is readily available in all major operating systems such as Windows, Linux, and IBM enterprise systems.

5) Establish Key Management Standards

Protecting encryption keys is the most important part of your encryption strategy and the one area where many organizations fail. Encryption keys should be stored away from the encrypted financial data in a security device specifically designed for this task. There are a number of commercial key management systems to choose from. Be sure your system is FIPS 140-2 compliant and implements the industry standard Key Management Interoperability Protocol (KMIP).

Hint: Don’t fall into the project-killing trap of trying to find a key management system that can meet every key management need you have in the organization. The industry just isn’t there yet. Pick a small number of key management vendors with best-of-breed solutions.

With encryption standards well defined and an encryption key management strategy in hand you are ready to get started with your encryption projects.

6) Analyze Performance and Operational Impacts

Encryption will naturally involve some performance and operational impacts. Encryption is a CPU intensive task, so plan on doing some performance analysis of your application in real-world scenarios. If you don’t have test environments that support this analysis, get started now to create them. They will be invaluable as you move forward. Modern encryption is highly optimized, and you can implement encryption without degrading the user experience. Just be prepared to do this analysis before you go live.

There are also operational impacts when you start encrypting data. Your backups may take a bit more storage and take longer to execute. So be sure to analyze this as a part of your proof-of-concept. Encrypted data does not compress as well as unencrypted data and this is the main cause of operational slow-downs. For most organizations this will not be a major impact, but be sure to test this before you deploy encryption.

8) Get Started

Oddly (to me at least) many organizations just fail to start their encryption projects even when they have done the initial planning. A lack of commitment by senior management, lack of IT resources, competing business objectives, and other barriers can delay a project. Don’t let your organization fall into this trap. Do your first project, get it into production, and analyze the project to determine how to do it better as you move forward.

Fortunately we have a lot of resources available to us today that were not available 10 years ago. Good encryption solutions are available and affordable for traditional on-premise environments, for VMware infrastructure, and for cloud applications.

You can meet the NYDFS requirements and timelines if you start now. But don’t put this one off.

Patrick

 

Resources:

New York Department of Financial Services:

https://www.dfs.ny.gov/legal/regulations/proposed/propdfs.htm

 

Harvard Law School analysis of NYDFS:

https://corpgov.law.harvard.edu/2016/09/24/nydfs-proposed-cybersecurity-regulation-for-financial-services-companies/

 

I’ve been spending some time digesting the proposed State of New York financial regulations that are due to go into effect in the new year. The new regulations are fairly prescriptive which has its good and bad points. But it is very clear that the regulators have had it with “opt out” security controls for banks. One of the areas of focus is on the role of the Chief Information Security Officer, or CISO. Let’s take a closer look at what the new regulation says about the CISO and what it means to your financial organization.

First, you have to have one of these.

Larger national and global institutions already have someone filling the CISO role. This won’t be anything new for them. The CISO is responsible for the overall security policy and practices of their organization. I think this will be a larger challenge for smaller regional banks and credit unions. Much of their IT infrastructure is probably outsourced and they depend on a network of vendors and service providers to fill their security needs. So these folks are going to have to on-board someone to fill the CISO role. And the experienced CISO is in hot demand. Hiring a qualified individual will be a challenge.

See below for a suggestion on how you can tackle this problem with a virtual CISO.

Second, the CISO now has to report to the board of directors or the equivalent level in your organization at least twice a year. And the report has to include a fair amount of detail on the security posture of the organization! This is going to be a major shift in almost every financial institution, and is probably a big shock for many! Currently the CISO typically reports to the CEO or similar level of executive management. It is going to be an uncomfortable change for the CEO to let go of this direct report and have unfiltered information going straight to the board of directors.

Why did the State of New York demand this change? I am just guessing here, but way too often I’ve seen the recommendations of a CISO stifled at the CEO level. Business line managers have a hard time understanding the relative importance of investing in security when there are so many demands for resources. Line of business needs often pre-empt security needs. For this reason many large companies are failing to invest in the way they should. I think the State of New York decided that the CISO needs to provide information directly to the board to improve governance, risk management, and compliance. Yeah, that GRC thing.

Lastly, too many financial institutions treat security as a checkbox item, rather than as an ongoing adaptive process. Without a level of seriousness about cyber security in the organization the right things are not prioritized and security investments aren’t made. Making sure that a qualified security professional is in the driver’s seat should help financial institutions become more secure, and thus the data of their customers better protected. A CISO can push this agenda forward.

Smaller institutions will certainly have some difficulty in acquiring the talent needed to meet the CISO role. I suggest that you consider a Virtual CISO (yes, that is a thing) to fill this need for the short or long term. The timelines for the new regulation are very short and you will have to meet some requirements within six months and all of them within one year. That is a very short timeframe for any financial institution.

Here are just a few suggestions:

If you are an IBM i (AS/400, iSeries) shop, look to an expert on this platform to help you. One that I work with on a regular basis is Botz and Associates. I’ve worked with Patrick Botz for many years and he is a long-time advocate for approaching security as a business process, just as this regulation mandates. He was the head of security for the IBM i platform for many years and can help you with his new Virtual CISO service.

Another security firm that I’ve worked with is Coalfire. I’ve always been impressed with their ability to really understand our needs and become that trusted advisor that you need. They also have a Virtual CISO service to help you meet the new regulations, and you get a good security friend in the process.

Here is where you can find the proposed State of New York regulations, it is a pretty easy read.

Financial institutions and their service providers have a big challenge ahead and very tight deadlines. Time to get cracking!

Patrick

New York State has finally had enough. Most people think that their bank has strong encryption in place to protect them from cyber criminals and nation-state actors. But that is too often just not the case. After a number of high profile data breaches at larger financial institutions, and a worrying increase in attacks on banks, the State of New York is about to require that banks implement some stringent security controls to protect Non-Public Information (NPI). The  new regulations are not a difficult read and you can find the proposed new regulations here.

Let’s take a look at some of the new requirements.

First, banks are required to develop a cyber security program. This means that there must be formal security processes in place, and appropriate management oversight. Banks are required to have systems and processes to identify threats, respond to them, and recover from an attack. The regulation also requires appropriate reporting of security events, something that is not always honored in today’s environment.

Next, banks are required to have a Cybersecurity Policy that addresses a number of areas related to information security, incident response, access controls, data privacy and other areas. If you are familiar with the Center for Internet Security Critical Security Controls or the NIST Cybersecurity Framework, these points will be familiar to you. As you might expect, a premium is placed on ongoing adaptive responses to new threats, so these frameworks are not a check-box response to the problem. Banks are being asked to step up to a new level of seriousness around IT security.

You also need a Chief Information Security Officer (CISO) position designated in your organization. And, interestingly, the CISO is required to report to the board of directors of the bank. I find this requirement interesting as it means that boards of directors cannot remain ignorant about the state of the bank’s IT security. And this means that it will have to become a part of the governance process of the board.

The new regulations now get down into the weeds about what you should be doing. Here are some of the areas:

• Vulnerability and Penetration testing
• Collect and archive system logs
• Implement restricted access controls
• Conduct risk assessments at least annually
• Hire cybersecurity professionals and make sure they stay current on new threats
• Require third parties to adhere to the same security rules as the bank
• Use multi-factor authentication for internal and external access to NPI
• Train and monitor all personnel with access to NPI (SIEM, anyone?)
• Encrypt NPI
• Develop and incident response plan

The requirement to deploy encryption is surprisingly strong. It is a mandate unless deploying encryption is unfeasible. Given the wide availability of encryption in all major operating systems and databases, I believe it will be difficult for a CISO to argue against the use of encryption. Clearly the regulators want banks to encrypt sensitive NPI data.

Who does the new rule affect?

The new rule affects any financial institution that is regulated by the New York Department of Financial Services. This will affect all national and global banking organizations as New York is one of the leading centers of global finance. It may also affect regional banks through the extension of the rules to affiliates. Regional and local banks should review their relationships with larger banks to try to understand their requirements under these new laws.

When does the new rules take effect?

The new rules take effect on January 1, 2017. In terms of time, that is very soon! And there is only a 180 day transition period. CISOs can request an extension, but these controls must be in place by January of 2018. That is a very aggressive timeframe!

How is the IBM i (AS/400, iSeries) affected?

Almost all large banks and financial institutions use the IBM i server somewhere in their organizations. The IBM i server is perfect for the back office applications that banks run and which need a very high level of availability. Many of the largest third party banking applications are deployed on IBM i servers.

But banks are going to face a big challenge with IBM i DB2 database encryption. The Non-Public Information that must be protected is often used for indexes in the DB2 database. While IBM DB2 supports column level encryption, it won’t work well RPG programs that use encrypted indexes. Here at Townsend Security we have a fix for this problem! By implementing an OAR-based SQL interface for RPG files we are removing the impediment that banks face with encryption on the IBM i server. You can read more here.

And you can get a quick look at how this helps in this short video: 

Patrick

In my role at Townsend Security I engage with companies both large and small and have many conversations about data breaches and security. One pattern that I see a great deal is the belief by privately held companies that they are not subject to compliance regulations, are not a target by cybercriminals, and don’t have much to worry about. The feeling seems to be “Gee, we are not publicly traded so we don’t have to do all that security stuff. It’s hard and expensive and it doesn’t really apply to us. Besides, we are too small for hackers to bother with.” I’m sure I’ve heard exactly these comments a number of times.

For the sake of these small businesses who represent the real backbone of our economy, we need to dispel these myths. Let’s look at a few of them:

We Don’t Need to Meet PCI Compliance
Anyone who takes credit or debit cards in their business must comply with the PCI Data Security Standard (PCI-DSS). When you signed your merchant agreement you agreed to be bound by the data security standards for payment cards. This is not a government regulation - this is an agreement between you and your payment provider and they all require this compliance. It doesn’t matter if you are small or large, privately held or publicly traded on the NYSE. You have to meet PCI compliance for security. Failure to comply with PCI-DSS standards can put you a jeopardy for loss of the ability to accept credit card payments. This can be devastating for any company.

I Only Store a Small Number of Credit Cards, PCI Doesn’t Apply to Me
This is an incorrect understanding of the PCI Data Security Standard. Processing a small number of payment transactions, or a low dollar amount, may put in you a lower category for PCI compliance, but the PCI-DSS still applies to you. In the event of a data breach you may find that you have new on-site PCI audit requirements, additional liabilities, and you may have to pay a higher rate to authorize payment transactions. These effects can really hurt your business. Rest assured that if you take credit card payments the PCI-DSS requirements apply to you.

We Don’t Need to Meet HIPAA Compliance and Reporting
If you are a medical organization defined as a Covered Entity under HIPAA regulations you need to meet HIPAA data security requirements. This includes both privately held as well as publicly traded organizations. There is no exclusion for privately held organizations whether you are a country doctor with a small practice or a large HMO or hospital chain. A quick review of the compliance actions by OCR shows that privately held organizations are just as likely to be fined as larger organizations. And penalties often do not stop at monetary fines, there are often requirements for years of on-site security audits and assessments that are very costly.

We are Not Big Enough to be a Target
Many executives and members of the IT organization at privately held companies believe that they are not a target of hackers and cybercriminals simply because they are privately held and small. This falls into the category of wishful thinking. In fact, as the FBI reports, smaller private companies are increasingly the focus of cybercriminals and are experiencing significant financial losses. Here is what John Iannarelli, and FBI consultant, says:

"Time and again I have heard small business owners say they have nothing to worry about because they are too small to interest cybercriminals. Instead, small businesses are exactly who the criminals are targeting for two primary reasons. In the criminal's mind, why go after large companies directly, when easier access can be attained through small business vendor relationships. Secondly, since small businesses have less financial and IT resources, criminals know they are less 'compromise ready' and tend to be less resilient."

We Don’t have to Report a Data Breach
Many smaller privately held companies are under the mistaken impression that compliance laws do not require them to report a data breach. This is incorrect - state and federal laws that require data breach notification require small businesses and privately held companies to report data breaches. Being small or privately held does not exclude you from data breach notification.

Compliance Regulations Don’t Apply to Us
It is true that if you are a private company the Sarbanes-Oxley compliance regulations certainly do not apply to you, those regulations only apply to publicly traded companies. And the Federal Information Security Management Act (FISMA) does not apply to you because it only applies to US government federal agencies. You are, however, covered by state privacy law, PCI Data Security Standards (if you accept credit or debit cards), HIPAA if you are a Covered Entity in the medical segment or if you process patient data for a Covered Entity, and the Federal Trade Commission (FTC).

We are Not Under FTC Rules About Data Privacy
The Federal Trade Commission has a broad charter to protect consumers and this includes enforcement for consumer privacy. From large companies like Google, Facebook and Twitter to small companies like an auto dealership, the FTC has taken enforcement actions that include private companies. The enforcement actions can include fines, mandatory audits that last for many years, and other penalties. Private companies do fall under FTC jurisdiction. You can read more about the FTC and data privacy here.

In summary, smaller privately held companies are the target of cybercriminals, are less prepared to deal with an attack, and have fewer resources to recover from an attack. No competent executive in a privately held company would forgo general liability insurance for their business, but are much more likely to suffer a loss from a cyber attack. It is not good business sense to ignore real threats.

Some last thoughts from the FBI:

The criminal then either creates another account or directly initiates a funds transfer masquerading as the legitimate user. The stolen funds are often then transferred overseas. Victims of this type of scheme have included small and medium-sized business, local governments, school districts, and health care service providers.

The potential economic consequences are severe. The sting of a cyber crime is not felt equally across the board. A small company may not be able to survive even one significant cyber attack.

From a Washington Post interview with the FBI:

Federal agents notified more than 3,000 U.S. companies last year that their computer systems had been hacked, White House officials have told industry executives, marking the first time the government has revealed how often it tipped off the private sector to cyberintrusions.

The alerts went to firms large and small, from local banks to major defense contractors to national retailers such as Target, which suffered a breach last fall that led to the theft of tens of millions of Americans’ credit card and personal data, according to government and industry officials.

“Three thousand companies is astounding,” said James A. Lewis, a senior fellow and cyberpolicy expert at the Center for Strategic and International Studies. “The problem is as big or bigger than we thought.”

Others notified by the Secret Service last year included a major U.S. media organization, a large U.S. bank, a major software provider, and numerous small and medium-size retailers, restaurants and hotels, officials said.

“Within hours of us coming up with information that we can provide, we would go to a victim,’’ said Edward Lowery, Secret Service special agent in charge of the criminal investigative division. “The reaction would be just like when you’re told you’re the victim of any crime. There’s disbelief, there’s anger, all those stages, because there’s a lot at stake here.”

Yes, Indeed. There is a lot at stake.