+1.800.357.1019

+1.800.357.1019

Feel free to call us toll free at +1.800.357.1019.

If you are in the area you can reach us at +1.360.359.4400.

Standard support
6:30am - 4:00pm PST, Monday - Friday, Free

Premium support
If you own Townsend Security 24x7 support and
have a production down issue outside normal
business hours, please call +1.800.349.0711
and the on-call person will be notified.

International customers, please dial +1.757.278.1926.

Townsend Security Data Privacy Blog

Top 3 Areas of Weakness when Undergoing a PCI Audit for the First Time

Posted by Sophia Khan - CyberGuard Compliance on Apr 17, 2018 8:21:00 AM

Guest blog by Sophia Khan of CyberGuard Compliance


CyberGuard-Word-CloudWith 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 http://www.cgcompliance.com.

Topics: Compliance, PCI DSS

What Data Needs to Be Encrypted in MongoDB?

Posted by Luke Probasco on Feb 23, 2018 8:11:00 AM
A Checklist for Meeting Compliance

 

What Information Do I Need to Protect with Strong Encryption?

compliance-webinar.jpgOrganizations starting an encryption project always have this question on their minds. It is a simple question, but can be hard to answer. Generally speaking, you should encrypt any information that alone, or when combined with other information, can identify a unique, individual person. This is called Personally Identifying Information, or PII. This should be your starting point, but you may need to address other information depending on the compliance regulations you must meet.

[For even more information on encrypting data in MongoDB, view our Definitive Guide to MongoDB Encryption & Key Management.]


Quicklinks:

Federal/State Laws and Personally Identifiable Information (PII)

EU General Data Protection Regulation (GDPR)

Educational Information Covered by FERPA

Federal Agencies and FISMA

Medical Information for Covered Entities and HIPAA/HITECH

Payment Card Data Security Standard (PCI DSS)

Financial Data for FFIEC Compliance

 

Federal/State Laws and Personally Identifiable Information (PII)

Federal and State laws vary in terms of what they consider Personally Identifiable Information (PII), but there is a lot of commonality between them. PII is any information which either alone or when combined with other information, which can identify an individual person. Start with this list of data items:

  • Social security number
  • Credit card number
  • Bank account number
  • First name
  • Last name
  • Address
  • Zip code
  • Email address
  • Birth date
  • Password or passphrase
  • Military ID
  • Passport
  • Drivers license number
  • Vehicle license number
  • Phone and Fax numbers

 

EU General Protection Regulation (GDPR)
Under the GDPR youmust protect the personal data of an individual. The definition of “personal data” is quite broad and includes “any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person”. This includes, but is not limited to:
  • Social security number
  • Credit card number
  • Bank account number
  • First name
  • Last name
  • Address
  • Zip code
  • Email address
  • Medical information
  • Birth date
  • Password or passphrase
  • Military ID
  • Passport
  • Drivers license number
  • Vehicle license number
  • Phone and Fax numbers
Personal data is broadly defined so an excess of caution should be applied to protection of individual information.
 
 
Educational Information Covered by FERPA

Educational institutions who fall under the FERPA regulations must protect Personally Identifiable Information (see above) as well as the following information:

  • Student name
  • Student ID number
  • Family member names
  • Place of birth
  • Mother’s maiden name
  • Student educational records
  • Immunization records
  • Health records
  • Individuals with Disabilities (IDEA) records
  • Attendance

 

Federal Agencies and FISMA

Federal agencies must evaluate their systems for the presence of sensitive data and provide mechanisms to insure the confidentiality, integrity and availability of the information. Sensitive information is broadly defined, and includes Personally Identifiable Information (see above), as well as other information classified as sensitive by the Federal agency. Sensitive information might be defined in the following categories:

  • Medical
  • Financial
  • Proprietary
  • Contractor sensitive
  • Security management
  • And other information identified by executive order, specific law, directive, policy or regulation
 
Medical Information for Covered Entities and HIPAA/HITECH
The HIPAA / HITECH Act defines Protected Health Information to include Personally Identifying Information (see above) in addition to the following Protected Health Information (PHI):
  • Patient diagnostic information (past, present, future physical or mental health)
  • Patient treatment information
  • Patient payment information
  • Medical record numbers
  • Name
  • Street Address
  • City
  • Zip code
  • County
  • Health plan beneficiary numbers
  • Fingerprints and other biometric identifiers
  • Full facial photographs and images
  • Device identifiers and serial numbers
  • IP address numbers and web URLs
  • Any other individual identifiable information
 
Payment Card Data Security Standard (PCI DSS)
The Payment Card Industry Data Security Standards (PCI DSS) require that merchants protect sensitive cardholder information from loss and use good security practices to detect and protect against security breaches.
 
If you accept or process credit card or other payment cards, you must encrypt the following data:
  • Primary Account Number (PAN)
You must also NOT store, even in encrypted format:
  • Track 1 and Track 2 data
  • Security codes (CVV, CVV2, etc.)
 
Financial Data for FFIEC Compliance
Banks, credit unions, and other financial institutions must protect Non-public Personal Information (NPI) which includes personally identifying financial information (see above). In addition to Personally Identifying Information above, you should protect:
  • Income
  • Credit score
  • Collection history
  • Family member PII and NPI

 

Encrypting Data in MongoDB
mdb-enterprise-certified-technology-partner_300x660.pngTownsend Security is helping the MongoDB community encrypt sensitive data and properly manage encryption keys. Developers who need to protect sensitive data know that storing their encryption keys within MongoDB puts their data at risk for a breach. With Alliance Key Manager for MongoDB, administrators are now able to keep their encryption keys secure by storing them remotely and only accessing them when the encryption/decryption happens. 

Alliance Key Manager for MongoDB is an enterprise key management solution that allows you to easily encrypt sensitive data with NIST-validated AES encryption and securely retrieve and manage encryption keys from Townsend Security’s FIPS 140-2 compliant Alliance Key Manager. With an easy to use interface and certifications to meet compliance requirements, you can rest assured knowing your data is secure.
 
Encryption and key management for MongoDB
 

 

LIMIT OF LIABILITY/DISCLAIMER OF WARRANTY:

THE PUBLISHER, THE AUTHOR, AND ANYONE ELSE INVOLVED IN PREPARING THIS WORK MAKE NO REPRESENTATIONS OR WARRANTIES WITH RESPECT
TO THE ACCURACY OR COMPLETENESS OF THE CONTENTS OF THIS WORK AND SPECIFICALLY DISCLAIM ALL WARRANTIES, INCLUDING WITHOUT LIMITATION WARRANTIES OF FITNESS FOR A PARTICULAR PURPOSE. NO WARRANTY MAY BE CREATED OR EXTENDED BY SALES OR PROMOTIONAL MATERIALS. THE ADVICE

AND STRATEGIES CONTAINED HEREIN MAY NOT BE SUITABLE FOR EVERY SITUATION. THIS WORK IS SOLD WITH THE UNDERSTANDING THAT THE PUBLISHER IS NOT ENGAGED IN RENDERING LEGAL, ACCOUNTING,
OR OTHER PROFESSIONAL SERVICES. IF PROFESSIONAL ASSISTANCE IS REQUIRED, THE SERVICES OF A COMPETENT PROFESSIONAL PERSON SHOULD BE SOUGHT. NEITHER THE PUBLISHER NOR THE AUTHOR SHALL BE LIABLE FOR DAMAGES ARISING HEREFROM. THE FACT THAT AN ORGANIZATION OR WEBSITE IS REFERRED TO IN THIS WORK AS A CITATION AND/OR A POTENTIAL SOURCE OF FURTHER INFORMATION DOES NOT MEAN THAT THE AUTHOR OR THE PUBLISHER ENDORSES THE INFORMATION THE ORGANIZATION OR WEBSITE MAY PROVIDE OR RECOMMENDATIONS IT MAY MAKE. FURTHER, READERS SHOULD BE AWARE THAT INTERNET WEBSITES LISTED IN THIS WORK MAY HAVE CHANGED OR DISAPPEARED BETWEEN WHEN THIS WORK WAS WRITTEN AND WHEN IT IS READ.

Topics: Compliance, MongoDB

GDPR, Right of Erasure (Right to be Forgotten), and Encryption Key Management

Posted by Patrick Townsend on Jan 22, 2018 11:11:28 AM

Download the EU Data Privacy White PaperThe 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

EU Data Privacy Protections and Encryption

Topics: Compliance, EU GDPR

Banks & Financial Services: Meeting Data Security Compliance Requirements

Posted by Luke Probasco on May 22, 2017 7:11:00 AM
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.
Compliance Ready Encryption for Financial ServicesI 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.

Compliance

Topics: Compliance, GLBA/FFIEC

New York Department of Financial Services (NYDFS) and Encryption - 8 Things to Do Now

Posted by Patrick Townsend on Dec 12, 2016 10:27:38 AM

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.

encryption-key-management-simplifiedThere 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:

http://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/

The Encryption Guide eBook

 

Topics: Compliance, Encryption

New York Financial Regulations and the CISO. Oh My.

Posted by Patrick Townsend on Oct 24, 2016 10:43:52 AM

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.

encryption-key-management-simplifiedLarger 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
The Encryption Guide eBook

Topics: Compliance

New York, Financial Institutions, and IBM i Encryption

Posted by Patrick Townsend on Oct 7, 2016 8:49:18 AM

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.

IBM i Encryption with FieldProcFirst, 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

Topics: Compliance, IBM i

Privately Held Companies Think They Don’t Need to Worry About Security and Compliance

Posted by Patrick Townsend on Sep 13, 2016 9:37:33 AM

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
Download Whitepaper on PCI Data SecurityAnyone 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.

download the Whitepaper: Meet the Challenges of PCI Compliance

Topics: Compliance, PCI DSS

MongoDB and Encryption Key Management for Compliance

Posted by Patrick Townsend on May 9, 2016 1:00:00 AM

MongoDB: Encryption Best Practices 

As the importance of encryption increases across the regulatory spectrum, it is heartening to see database vendors implementing encryption and encryption key management that meet security best practices. MongoDB Enterprise is one of the most popular modern databases and has given its customers the ability to quickly and effectively implement encryption and good key management at the level of the database itself. This means that MongoDB Enterprise customers can transparently implement encryption directly in the database without deploying third party file or volume based encryption products to accomplish this task. MongoDB customers enjoy rapid deployment of encryption, a unified management interface to the database, high performance encryption, and integrated encryption key management based on the industry standard Key Management Interoperability Protocol (KMIP).

Securing Data in MongoDB podcastBy basing key management on the OASIS KMIP standard MongoDB is providing real benefits to their customers. These include:

  • Rapid implementation of key management with no need for developer resources.
  • No requirement for server-side software libraries, updates, and patching.
  • Secure encryption key retrieval services based on TLS.
  • Vendor neutrality for encryption key management services.
  • Vendor portability and avoidance of vendor lock-in.
  • Seamless migration from one key management solution to another.

MongoDB Enterprise is a case-study in the benefits of using open standards for encryption and key management. MongoDB’s customers can choose the key management solution that makes the most sense for them, and having choices reduces the cost of encryption key management.

MongoDB: Encryption Key Management Made Easy

Townsend Security's Alliance Key Manager solution works out of the box with MongoDB Enterprise to help customers meet compliance regulations which require encryption of sensitive data. It takes just a few minutes to deploy Alliance Key Manager and to configure MongoDB for key management. On first boot, Alliance Key Manager creates a set of strong encryption keys including a 256-bit AES key that can be used with MongoDB, and it creates a set of PKI certificates used for TLS authentication. The PKI certificates are copied to the MongoDB server to secure the connection to the key manager. A quick command or two from the MongoDB command line console and, Voila! Your MongoDB encryption key is now fully protected by a key encryption key on Alliance Key Manager. You have an encrypted MongoDB database and a highly redundant and recoverable encryption key management infrastructure. From the technical team at MongoDB:

“The encryption occurs transparently in the storage layer; i.e. all data files are fully encrypted from a file system perspective, and data only exists in an unencrypted state in memory and during transmission.”

After installing the key manager certificates on the server hosting the MongoDB database, here is an example of the command to enable encryption:

mongod --enableEncryption --kmipServerName akmmongo --kmipServerCAFile /etc/mongodb-kmip/AKMRootCACertificate.pem --kmipClientCertificateFile /etc/mongodb-kmip/AKMClientCertificate.pem --dbpath /var/lib/mongodb/

It’s that simple.

With Alliance Key Manager you have your choice of network-attached hardware security modules (HSMs), VMware virtual machines, and dedicated cloud instances in Microsoft Azure and Amazon Web Services. The key manager works the same way in all environments so you can even mix and match hardware, VMs, and cloud instances to achieve the level of security that is right for your organization. All instances of Alliance Key Manager are dedicated to you with no access by cloud service providers or third parties. Key custody remains exclusively under your control.

Many MongoDB customers deploy the database in VMware environments. Alliance Key Manager also runs in VMware as a virtual machine. You can deploy the key manager in a VMware security group and protect one or more instances of MongoDB across the entire VMware environment. If you are running on a VMware vCloud platform the same support is provided for key management.

For compliance, Alliance Key Manager is validated for PCI-DSS compliance in the VMware platform. This will help you achieve PCI-DSS compliance for your MongoDB database and applications. The PCI-DSS statement of compliance is here.

MongoDB is rapidly becoming the high performance, scalable, NoSQL database of choice for organizations large and small. As such it becomes a part of the critical infrastructure for business applications. Alliance Key Manager also implements high availability features such as automatic, real-time encryption key mirroring, and backup. For customers deploying the hardware version of Alliance Key Manager, there is redundancy at the hardware level with dual hot-swappable RAID disks, redundant power supplies, and redundant network interfaces. All of these features mean that your key management infrastructure will be resilient and reliable.

Alliance Key Manager will help you will meet common compliance regulations such as PCI-DSS, HIPAA, FFIEC, FISMA, the EU General Data Protection Regulation (GDPR), and other compliance schemes. Alliance Key Manager regardless of platform is based on the same FIPS 140-2 compliant software found in our enterprise level HSM. With no restrictions or license costs for client-side connections, you can protect as many MongoDB databases as you like with one Alliance Key Manager.

The product team at MongoDB did a great job of implementing encryption and key management for their customers. They deserve to be applauded for basing their solution on industry standards like KMIP. This will lower the bar for getting encryption right in the database. With Alliance Key Manager, getting encryption right means rapid deployment, conservation of developer resources, lower administration costs, and provable compliance.

A match made in techno-heaven.

Patrick

Securing Data in MongoDB

Topics: Alliance Key Manager, Compliance, MongoDB Encryption, MongoDB Encryption Key Management, MongoDB

EU Data Privacy, Safe Harbour and Encryption

Posted by Patrick Townsend on Oct 7, 2015 12:19:00 PM

In a ruling that shocked Internet service providers and businesses in the US and abroad, the European Court of Justice ruled this week that current data Safe Harbour rules may not be adequate to protect the privacy of EU citizens and that individual countries may make their own rules about data privacy. Anyone who has lived in Europe and knows the historical context of governmental tracking and abuse of individual rights will certainly not be surprised by this ruling.

But why is this such a big deal?

Download the EU Data Privacy White PaperHave you noticed how good Google, Facebook, Microsoft, Amazon, Yahoo and others are at showing you advertising that reflects your interests? They are really good at this because they are the ultimate data aggregators. They use their vast network of global systems to bring data about you together and then perform sophisticated analytics. This means that most Internet service providers are moving data across country boundaries into the United States or areas controlled by the US where that data is subject to government inspection.

Beyond the obvious advertising aspects of Internet services, many backup and archival systems are built on Internet-based storage services. This means sensitive backup data moves over the Internet and may move to servers or networks outside of the host country. Internet service providers have been working hard to make their systems resilient and this often means integrating across borders.

In fairness, it is not just the US government that snoops on individual activity - many governments around the world do the same thing. And that is the concern of the European courts.

If data can’t leave a country, that will have a major impact on Internet service providers. And, of course, that will have a major impact on the small and large businesses that use these services. It’s potentially a very large problem!

In a Computer Weekly interview with Andy Hardy, Managing Director of Code42, he noted the importance of encryption and key management in meeting the new requirements. Andy said:

“It need not be the end of business as we know it in terms of data handling. What businesses need to do now is safeguard data,” he said.

According to Hardy, businesses must ensure they can keep company and customer data private, even when backed up into a public cloud.

“The right technology will ensure data it is encrypted before it leaves the endpoint device, so that it cannot be decrypted in the cloud and hence remains private. The best technologies will ensure that encryption keys are kept by our customers on-premise, so only they can decrypt the data and that no one else can access it unless with prior direct request. This is the only way to ensure privacy in the public cloud post-Safe Harbour,” he said.

I think Andy has this exactly right. When encryption is done right it makes the data unintelligible to anyone without the encryption keys. Using a key management solution that is resident in the EU, which is dedicated to the data holder, and which does not allow third party administrative access will be crucial to meeting the new EU privacy laws.

That’s exactly what we do with our encryption solutions that integrate with Alliance Key Manager and we are already helping EU customers protect their data with strong encryption. EU customers can locate Alliance Key Manager within their own data center, or in a country-specific hosting center, or even in a cloud service provider platform where there are adequate guarantees around in-country hosting.

EU Data Privacy Protections and Encryption

Topics: Compliance, EU Data Privacy Protection

 

 

Subscribe to Email Updates

Recent Posts

Posts by Topic

see all