Townsend Security Data Privacy Blog

FinTech is transforming the financial services industry. Everyone from banks and credit unions to insurance companies deal with huge amounts of private data on a daily basis - and the best way to secure it is with encryption. Not only are companies deploying encryption to meet compliance (PCI DSS, etc.), but also as a security best practice.

I recently sat down with Patrick Townsend, Founder and CEO, and discussed why encryption is critical to FinTech, meeting the various compliance requirements, as well as how Townsend Security is helping FinTech customers better secure their private data.

The financial world is rapidly changing. Innovations in technology are impacting payments, lending, insurance, and even compliance. Unfortunately, security often does not get as much attention as it should. Do you have any stories that you can share with our listeners about when security really wasn't thought all the way through?

Not only is security a consideration for new solutions coming to market, but it can also be a problem for businesses using legacy technology that was deployed many years ago. Encryption and data protection just were not on the top of anyone’s mind when the applications were built. I recently talked with a large global bank who is running a software package from a well known financial services software vendor and it DOES NOT implement security in the way that we think of it today. Encryption libraries didn’t even exist on some of these platforms when solutions were created, so we are left with applications without encryption, let alone proper key management. This is a ubiquitous problem across the financial services industry as a whole and has become a very big challenge.

Sometimes I wonder how secure our personal data would be if it weren’t for compliance regulations like PCI and GLBA. What are your thoughts on the impact of compliance and data security?

I think compliance follows threats and losses. When individuals suffer from cybercrime, they complain to their legislators and lawyers, and out of that come compliance regulations. For example, we are seeing new compliance regulations like those from the New York State Department Financial Services (NYDFS) requiring organizations to establish and maintain a “risk-based, holistic, and robust security program” that is designed to protect consumers’ private data.” Other compliance regulations like PCI DSS, GLBA, and not just regulations specific to the finance industry, have been created to protect individuals who may be cybercrime targets.

Financials organizations are responding to compliance regulations by further protecting data that they collect. They do it because they have to (to meet compliance requirements), but also because it is important to their brand and the trust that they have established with their customers. Today, no acquirer of FinTech would find it acceptable to have sensitive data not protected to industry standard encryption and security best practices.

The technologies around data protection are pretty straightforward. Encryption and key management are the fundamental compliance related controls required to protect non-public information (NPI) and personally identifiable information (PII) in financial services environments. Encryption can be deployed at the application or database level and allow organizations to provably meet compliance requirements for protecting data – both on premises and in the cloud.

What advice do you have when it comes to selecting and evaluating a FinTech vendor?

Security and compliance have to be top of mind. Businesses need to make sure that their FinTech is secure and that if it handles sensitive data, that it is protected with encryption and key management. Security needs to become an internal governance issue to be sure that solutions that are acquired and deployed or upgraded truly and provably meet compliance and industry standards.

Townsend Security is helping these organizations with Alliance Key Manager, our centralized encryption key management solution. We believe in compliance and standards and our key manager is FIPS 140-2 compliant, in use by over 3,000 customers worldwide, and is available as a hardware security module (HSM) or as a software appliance in VMware or the Cloud (AWS and Azure). Additionally, Alliance Key Manager has been validated to meet PCI DSS in VMware, giving businesses in the financial services industry a “compliance out of the box” solution.

To hear this interview in it’s entirety, download our podcast “Why Encryption is Critical to FinTech” and hear Patrick Townsend, founder and CEO of Townsend Security, further discuss encryption, key management, and meeting compliance requirements specific to financial services.

If you are an IBM i security administrator you know how hard it can be to determine a user’s true level of privilege on your system. IBM has given us a very flexible scheme to grant and restrict privileges to groups of users. And this flexibility can lead to unexpected security exposures. Let’s delve into this a bit deeper with an example (names are made up for this example):

JANICE
Janice is regional manager in the sales team. She’s exceptionally effective at her job and has taken on a number of tasks that help her support her team and the sales goals of her region. Let’s take a look at her user profile:

User Profile . . . . . . . . . . . . . . . . . . . :	JANICE
Special authority . . . . . . . . . . . . . . . :	*SPLCTL
Group profile . . . . . . . . . . . . . . . . . . :	SALES
Supplemental groups . . . . . . . . . . . :	HRUSER PAYROLL REPORTING
	INVENTORY MANAGERS …

 

At first glance it would seem that Janice has a normal user level of special authorities. In fact the only special authority is spool file control (*SPLCTL) which would be reasonable for a manager who needs to run and print reports. It also seems appropriate that Janice has a Group Profile of SALES. You would imagine that this probably gives her the ability to access the company sales management application.

The first hint of concern is the long list of supplemental groups. If you’ve met effective managers like Janice it won’t surprise you that they have access to a number of applications. She probably has responsibility for approving time off for her department’s employees, and has responsibilities for reporting to management. But what privileges are hidden in that Group Profile and in those Supplemental Groups?

Let’s take a look. 

SALES (Group profile)
When we display the SALES user profile we find these special authorities: 

User Profile . . . . . . . . . . . . . . . . . . . :	SALES
Special authority . . . . . . . . . . . . . . . :	*SPLCTL
	*JOBCTL
Group profile . . . . . . . . . . . . . . . . . . :	*NONE
Supplemental groups . . . . . . . . . . . :

 

Janice already had authority to spool files, but notice the job control value of *JOBCTL. This means that Janice has now inherited additional authority to manage jobs. This is not a severe uplift in privileges, but it shows how privilege escalation works.

Now, what about those supplemental groups? Do we have to look at every one?

Yes we do. Let’s look at the HRUSER profile next

HRUSER (Supplemental Group)
When we display the HRUSER user profile we see these authorities: 

User Profile . . . . . . . . . . . . . . . .  :	HRUSER
Special authority . . . . . . . . . . . . :	*SPLCTL
	*JOBCTL
	*SECADM
Group profile . . . . . . . . . . . . . . . :	*NONE
Supplemental groups . . . . . . . . :

 

Wow, the HRUSER has the special authority of security administration (*SECADM). That’s a bit worrying. If we had to guess there is probably third party HR package requirement for this, or this authority was just granted out of convenience. But now Janice has much more authority. 

Let’s continue our exploration of those supplemental group profiles:

PAYROLL (Supplemental Group)
Let’s take a look at the PAYROLL user profile:

User Profile . . . . . . . . . . . . . . . . :	PAYROLL
Special authority . . . . . . . . . . . . :	*SPLCTL
	*JOBCTL
	*ALLOBJ
Group profile . . . . . . . . . . . . . . . . :	*NONE
Supplemental groups . . . . . . . . . :

 

Whoops, the PAYROLL user has All Object authority (*ALLOBJ). Bingo! This is the mother load of privilege. A user with All Object authority basically has the keys to the kingdom. It is pretty much equivalent to being the QSECOFR security officer (“root” for you Linux nerds). Once you have All Object authority you can manage other user profiles, grant yourself additional authority, and basically access any data on the IBM i server. 

If I am an attacker and I can steal Janice’s credentials for the IBM i server I now have all of the authority I need to infiltrate sensitive data.

Did you notice how much work it was to track down Janice’s true privilege level? As an IBM i security administrator you probably know how to fix this problem. You need to analyze the real need for the All Object authority and revoke it. But imagine that you managed a system with hundreds or thousands of users. And imagine if you needed to check this at least monthly in order to detect any changes since the last time you inspected your users? It would truly be impossible to keep up with this task, and as the security administrator you might have other things you need to do, right?

So, is there any hope?

 Sure there is. Our Alliance LogAgent solution will do this work for you. You can run the User Authorization report and Alliance LogAgent will track down these authorities for you. It will tell you the overall inherited authority of any (or all) users, and where they are getting the authority. Here is an example of the output for Janice:

 

Notice that all of Janice’s cumulative authorities are listed right on the top line of the report detail. Then notice that the Group Profile and all Supplemental Group profiles are listed with their authorities. The PAYROLL user is clearly identified as having the All Object authority. Now you can go to work. 

The Alliance LogAgent report can be executed for all users, or for a group of users. And you can filter it so that you first get a list of all users who have inherited All Object authority. Then run it with additional authorities. In a few seconds you can find your privileged users, discover where they get that authority, and create a work plan to fix the problems.

However, Alliance LogAgent goes even further. As it is processing events from the security journal QAUDJRN, it can resolve in real time the true privilege of each user signing on to the IBM i server, tag job start events where the user has elevated privileges, and send them to your SIEM for monitoring. In real time.

I think that’s pretty powerful, don’t you?

Patrick

Updated: 3/13/2020 - to reflect current status of TDE in SQL Server editions.

In 2008, Microsoft introduced Transparent Data Encryption (TDE) to its Enterprise and Datacenter Editions of SQL Server. Billed as a way to seamlessly deploy SQL Server encryption, users now had the choice of full database-level encryption, instead of just the previous choices of cell-level encryption (CLE), Encrypting File System (EFS), or Bitlocker. With its rapid deployment, ease-of-use, and enhanced security TDE has been a staple for every version of SQL Server Enterprise Edition (and Developer Edition) ever since.

Versions of SQL Server Enterprise with TDE:
2008 and up

Versions of SQL Server Standard with TDE:
2019 and up

SQL Server TDE has become a favorite for bulk encryption in meeting regulatory compliance (like PCI DSS) or internal corporate data security initiatives. But while TDE has it’s advantages, it is not a cure-all. Sung Hsueh did a great job explaining the advantages and disadvantages of TDE as compared to CLE. The following is a curated look at that whitepaper. Let’s take a quick look:

What is Transparent Data Encryption?

TDE fundamentally is full database-level encryption. It functions at the Input/Output (I/O) level. Any data written into the database is automatically encrypted. Backups are also automatically encrypted. Data in use is decrypted by TDE as they are read by a user or application and stored, in clear text, in memory. Since the data-in-flight is decrypted; TLS or SSH (or now, “Always Encrypted”) should be enabled to protect the data while in motion.

What is Cell-Level Encryption?

Introduced in 2005, CLE is implemented as a series of built-ins. It is a manual process “that requires a re-architecture of the application to call the encryption and decryption functions.” Hsueh also notes that “the traditional limitations of encryption are inherent in this method as none of the automatic query optimization techniques [of TDE] can be used.” 

CLE vs. TDE

The advantages of CLE:

• Since it is column level encryption, it encrypts only the sensitive information in a table.
• With CLE, the data is still encrypted even when it is loaded into memory.
  CLE allows for “explicit key management” giving you greater control over the keys and who has access to them.
• CLE is highly configurable, giving you a high degree of customization (especially when your applications require it).
• Queries may be faster with CLE if the encrypted column(s) is not referenced in the query. TDE will always decrypt the entire row in the table. CLE will decrypt the column value only IF it is a part of the data that is returned. So in some cases CLE implementations provide much better overall performance.

The disadvantages of CLE:

• One of the main disadvantages of CLE is the high degree of fully manual application changes needed to use it. TDE, on the other hand, can be very simple to deploy with no changes to the database, tables or columns required.
• CLE can also have high performance penalties if search queries cannot be optimized to avoid encrypted data. “As a rough comparison, performance for a very basic query (that selects and decrypts a single encrypted column) when using cell-level encryption tends to be around 20% worse [than TDE].”

The whitepaper goes on to note that with CLE performance impacts “are several magnitudes worse when attempting to encrypt an entire database. One sample application with 10,000 rows was four times worse with one column encrypted, and 20 times worse with nine columns encrypted.” TDE, on the other hand, only had a 3-5% average performance impact compared to a non-encrypted database.

Final Thoughts

A case could be made for using CLE in conjunction with TDE as a defense-in-depth strategy. By selectively encrypting columns with CLE, encrypting the full database with TDE, and then managing the separate keys with a centralized key manager; it would ensure that crucial data was protected, even while loaded into memory.

But, in general, TDE and CLE are used for different purposes. If you are looking to encrypt a small amount of data, if your application “has custom design requirements,” or if performance is not a much of a concern, CLE may have advantages over TDE. But, if performance is a concern or you would like to avoid manually implementing encryption (normally a time-consuming process) then TDE is the way to go.

For more information on both types of encryption and how they relate to Extensible Key Management, visit our Definitive Guide to SQL Server Encryption & Key Management.

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.

One of the most frequent questions I receive about encryption in the AWS cloud is “Who owns the encryption keys in the cloud?” and “Does Amazon have access to my keys?” I understand why this is a confusing question. I also understand why the question is important to many Enterprise customers. Cloud service providers don’t like to talk about this very much, so let’s spend some time running this to ground. We’ll start with the question about Amazon’s access to your encryption keys.

Amazon Web Services provides two encryption key management options:

• AWS Cloud HSM
• AWS Key Management Service (KMS)

The answer to the question of key ownership depends on which service you are using. Let’s deal with the easy one first.

The AWS Cloud HSM is a physical hardware security module (HSM) that is dedicated to you. It is physically located in an AWS regional cloud data center, but only you have administrative access to the key server. Amazon is clear on the topic of encryption key ownership with the Cloud HSM service: Only you have access to the keys. Of course, Amazon has physical access to the HSM in their data center, but I think we can trust Amazon’s claim that only you have access to the actual encryption keys in a Cloud HSM server.

Now let’s turn our attention to the AWS Key Management Service, or KMS. This is a multi-tenant service provided by Amazon which is backed by an Amazon hardware security module. That is, Amazon creates a key that is only used by you, but that key is protected (encrypted) by an Amazon managed HSM. When you create a key in KMS it is called a Customer Master Key, or CMK. The CMK is actually a data structure that contains your symmetric key and meta data about the key. The CMK is protected by an Amazon HSM key. So, the answer to the question about who owns your key is straight-forward: You and Amazon share ownership of the encryption key and that ownership is equal. You both can access the raw encryption key.

Recently Amazon introduced a new “Bring Your Own Key” option for the KMS service. Does this change anything about who has access to the key? No, you are bringing your own encryption key and loading it into the AWS KMS service as a part of a CMK, but it is still protected in the KMS service by an Amazon HSM key. This means that you and Amazon share equal ownership of the key and both of you have access to the key. The only difference with Bring Your Own Key is that you retain the actual value of the encryption key outside of the AWS cloud.

So, to summarize: The AWS Cloud HSM service provides dedicated encryption keys that only you have access to. The AWS Key Management Service provides encryption keys and both you and Amazon have access to the key.

So, why is this important? Here are some comments that Enterprise customers have shared with me:

In almost every country both law enforcement and national security agencies have legal means to compel a cloud service provider to surrender data related to cloud customers. Certainly in the US this is the case, and it is true in most other countries. In the US it is additionally true that law enforcement and national security agencies may access this information and prohibit the cloud service provider from notifying you – the customer – that access has been granted. Cloud service providers like Amazon and others naturally abide by the laws of the countries in which they operate. But this means that your encryption keys in AWS KMS can be surrendered without your knowledge. You may not like this aspect of your country’s legal system, but it is a fact of life.

Why is this of concern to Enterprise customers? It is because significant law enforcement or intelligence service activity concerning your employees or customers may take place without your knowledge. If you are an executive in a large Enterprise you really want to know if there are potential problems in your workforce, or significant problems with a customer or service provider. Questions like these might arise:

• Do I have an employee engaging in illegal activity?
• Do I have multiple employees colluding together to engage in illegal activity?
• Is one of my customers engaging in criminal activity that may compromise my business?
• Are there managers in my organization that are breaking the law?
• Is there some activity that may significantly damage my business reputation?
• How can I deal with a problem if I don’t know about it?

When your IT systems are physically located in your data center law enforcement and intelligence agencies have to contact you to get access to data. That is not the case in the cloud – you will be in the dark in many cases.

In my experience Enterprise customers will cooperate with their legal requirement to provide data to law enforcement. This is not a question of cooperating with legal requirements to surrender data in a criminal investigation. But Enterprise customers really want to know when significant legal events take place that affect their organizations.

The critical concern is visibility of law enforcement and intelligence service activity that affects you. For this reason many Enterprise customers will not use the AWS Key Management Service. And because they do not have physical access to the Amazon Cloud HSM devices, they will not use this dedicated encryption key management service either.

I hope this clarifies some of the issues related to the Amazon key management options. Of course, these issues are not exclusive to Amazon, the same issues are relevant to the Microsoft, IBM and Google cloud platforms. There are good alternative options to cloud encryption key management services and we will cover those in a separate blog.

Patrick

I recently spent the better part of an hour talking to a new IT director for a small financial services company. He was feeling overwhelmed at the scope of the work ahead of him, and was bemoaning the lack of any guidance on how to start. The set of tasks in front of him seemed gargantuan in terms of the number of tasks and the scope of work. I can understand that sense of panic when you realize that you are behind the curve and that your organization is facing real threats. I want to share with you some of the advice I gave this IT director (with a tip of the hat to all of those hard working security professionals who’ve shared with me!).

It’s a Process, Not a Destination

The first error I see many IT managers make is that they look at security as a set of tasks to accomplish rather than a set of new IT processes. We technical folks really like to make a task list and check them off. We have a sense of accomplishment when we get to the end of the list. It’s done! Hallelujah!

Sorry, security is never done. It is important to realize that a security program means that many people throughout your organization are going to be doing things differently, and will be adjusting to new threats over time. For example, we used to think that the use of strong passwords was adequate to protect our access to corporate web services. But it isn’t enough now. Now we have to use multi-factor authentication in addition to strong passwords. Why? The attacks on password protected assets has become more sophisticated. We have to step up our game. And this is true across a number of security practice areas.

If you are successful you will be changing how your organization OPERATES over time. Not just completing a set of tasks.

Know Where Your Sensitive Data Is

It is very common that businesses do not actually know where their sensitive data resides in the organization, and where it goes outside of the organization. Business are always undergoing change to meet new objectives, counter emerging competitive threats, accommodate new technologies, and comply with new compliance regulations. Managing a business is like fighting a war on many fronts – it is barely organized chaos!

It is understandable then that an IT organization may not have a clear map of its critical data. But you will need that map before you can start really protecting those assets. For example, you might have data extracts uploaded to your web site for customers but not know that the upload process was put in place 5 years ago and the development has moved on. That sensitive data just gets uploaded every night and might not be properly protected.

It’s time to do some archeology.

Be sure you have an inventory of all of your critical applications along with the data the process. This is going to seem like a tedious job, but it will be critical to everything you do. Make the map and then hold a celebration and invite your executive team.

In the process don’t forget the data feeds. Document every place that data enters your organization from the outside, and where you send data to outside services.

Find a Dynamic Security Framework

Now you need a plan! Fortunately you won’t have to figure out a plan on your own. There are several good sources of dynamic security planning guides that you can use as a starting point. A good plan will cover the essential security tasks, and will prioritize them by importance. A complete plan with prioritized tasks will help you focus your attention in the right areas!

Here are some sources for security plans that you can access and use right away:

• CIS Critical Security Controls
• NIST Cybersecurity Framework
• SANS

The great thing about these security plans and frameworks is that you can get started with them very quickly. For example, the CIS Critical Security Controls is available as an Excel spreadsheet. You can make a copy and start working through the sections from top to bottom.

Do the Important Things First

We are sometimes tempted to do some of the easy things first in order to convey a level of accomplishment to our management team. I recommend that you try to resist this tendency as much as possible. Start with the most important items in your priority list and tackle those first. They often give you a lot of security benefit and many do not require a lot of investment or work. It is important to do the most effective and critical tasks first.

Get Your Management Buy-in

Security takes commitment, human resources, financial resources, and much more. You will need to get your management buy-in as quickly as possible. Start by sharing some stories from other companies in the financial services segment. We don’t necessarily want to scare our managers, but they need to have a realistic idea of the threat.

Educating your management team means explaining your need for budget resources. Some things can be done on the cheap, and you won’t want to overlook inexpensive steps to take that improve security. But some things are going to take some budget dollars to deploy. For example, continuous monitoring of system logs with a SIEM solution is one of the most effective security strategies you can deploy. But this will almost certainly mean the deployment of a commercial SIEM solution and this will require fiscal expenditures.

Any steps you take to educate your management team will be worth the effort.

Don’t Forget About Employee Education

Remember that you live in the security world, but the employees in your organization don’t. They are not likely to be up to date on the latest threats. Educating employees on how to identify spam email messages has a lot of benefits. Find ways to work in a few minutes each week into employee schedules a simple security awareness exercise.

You’ve probably heard of Bug Bounties – how about providing some small rewards to employees that discover and report spam emails with potentially harmful content? It is amazing how effective programs like this are.

Rinse and Repeat

Let’s go back to that first point. A security program is something that changes how you and your colleagues live your professional lives – it is not a set of checkboxes. Create an annual calendar of security tasks and review points. Make sure that this includes periodic reviews with the upper management team. If you are doing this right you will be making periodic adjustments to the security program and things that are important today may be eclipsed by new threats tomorrow. That’s not a particularly happy thought, but if you keep adjusting you will be in a safer position.

Finally, we make progress one step at a time. Once you start down this road it will get easier as you progress. Good luck with your new security programs!

Patrick

By protecting data with encryption and key management solutions from Townsend Security, businesses can easily meet compliance requirements.

Townsend Security, a leading provider of encryption and key management solutions, today announced that Alliance Key Manager can help businesses in the finance industry meet new encryption requirements, including those found in the New York Department of Financial Services (NYDFS) cybersecurity regulation and the European Union General Data Privacy Regulation (GDPR), in addition to existing Gramm-Leach-Bliley Act (GLBA) and PCI Data Security Standard (PCI DSS).

By protecting nonpublic personal information (NPI) and personally identifiable information (PII) with NIST-compliant AES encryption and FIPS 140-2 key management found in Townsend Security’s Alliance Key Manager, businesses can protect private information including: customer financial records, social security number, income, and account numbers. Organizations that experience a data breach where un-encrypted data is lost can suffer fines reaching into the millions of dollars, as well as face indirect costs like brand damage and customer loss.

Fortunately, encryption and key management has gotten tremendously easier to deploy and is within reach of the most modest budgets. Customers worldwide have turned to Alliance Key Manager because it enables them to easily meet the most stringent requirements found in GLBA, PCI DSS, and HIPAA. The solution has been validated to meet PCI DSS in VMware, and is also available as a hardware security module (HSM) and in the cloud (AWS, Azure, vCloud).

“The finance industry is increasingly being held accountable for the security, confidentiality and integrity of non-public customer information,” said Patrick Townsend, founder and CEO, of Townsend Security. “Encryption, along with key management, is the best way to ensure that private information remains private – even in the event of a breach.”

 

It should come as no surprise that the financial industry is among the most regulated in the world.  There are strong data security requirements for banking and financial industries due to the sensitive and private data that they deal with.  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.

What Data Needs Encryption?

Aside from the obvious personally identifiable information (PII) such as names, addresses, and social security numbers, the financial industry also regularly handles data that includes income, credit score, collection history, and family member PII and Non-public Personal Information (NPI).

The Gramm-Leach-Bliley Act (GLBA) specifically requires that institutions doing business in the US establish appropriate standards for protecting the security and confidentiality of customers’ NPI. The objectives are to:

• Ensure the security and confidentiality of customer records and information
• Protect against any anticipated threats or hazards to the security or integrity of such records
• Protect against unauthorized access to information which could result in substantial harm or inconvenience to any customer

Additionally, the Federal Financial Institutions Examination Council (FFIEC), which is “empowered to prescribe uniform principles, standards, and report forms to promote uniformity in the supervision of financial institutions,” adds:

“Financial institutions should employ encryption to mitigate the risk of disclosure or alteration of sensitive information in storage and transit.”

Between FFIEC and GLBA, banks and financial institutions should encrypt:

• Any sensitive information an individual gives you to get a financial product or service (such as 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 products or services (for example, the fact that an individual is your 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)

Encrypting Private Data

Encryption is often considered the hardest part of securing private data.  The first step that banks and financial services can take is to deploy encryption based on industry-tested and accepted algorithms, along with strong key lengths.  Examples of industry-tested and accepted standards and algorithms for encryption include AES (128 bits and higher), TDES (minimum double-length keys), RSA (2048 bits and higher), ECC (160 bits and higher), and ElGamal (1024 bits and higher). See NIST Special Publication 800-57 for more information.

There are many levels within an organization’s stack that encryption can be deployed, ranging from the operating system to the application and database level.  Choosing where to implement encryption has security implications.  Let’s focus on the two that are the most secure.

Encryption at the Database Level

Almost all commercial databases now support some time of encryption in the database itself.  Encryption at the database layer provides some distinct advantages:

• Encryption is optimized for database performance
• Encryption services are better integrated with other database access control services resulting in fewer security gaps
• Encryption key management may be better integrated into the encryption implementation

Encryption at the Application Level

Application encryption involves the use of an encryption library and a key retrieval service.  Encryption at the application layer fundamentally means that you are encrypting data before inserting it into a database or other storage mechanism, and decrypting it after you retrieve the data.  It provides a very granular level of control of sensitive data and allows for the application of user access controls, program access controls, data masking, and other security controls.  Many feel that application layer encryption is the most secure way to protect data.

Encryption Key Management

Encryption is only as secure as your encryption keys.  The essential functions of a key management solution include storing the encryption keys separate from the data that they protect, as well as managing the encryption keys through the entire lifecycle including:

• Generating keys for different cryptographic systems and different applications
• Generating and obtaining public keys
• Distributing keys to intended users, including how keys should be activated when received
• Storing keys, including how authorized users obtain access to keys
• Changing or updating keys, including rules on when and how keys should be changed
• Addressing compromised keys
• Archiving, revoking, and specifying how keys should be withdrawn or deactivated
• Recovering keys that are lost or corrupted as part of business continuity management
• Logging the auditing of key management-related activities
• Instituting defined activation and deactivation dates, and limiting the usage period of keys

Just as with encryption, it is paramount that your key management solution meets industry standards.  Again, look to NIST and vendors who have a solution that is FIPS 140-2 compliant.  By adequately encrypting data to industry standards, the loss of encrypted data is not generally considered a breach, and is exempt from notification requirements.

FFIEC Guidance

The FFIEC provides guidance and oversight of GLBA for banks and financial organizations.  They publish the IT Examination Handbook, which provides guidance for the IT security controls that can or should be used to protect NPI under GLBA.  According to the Handbook, financial institutions should employ encryption to mitigate the risk of disclosure or alteration of sensitive information in storage and transit. Encryption implementations should include:

• Encryption strength sufficient to protect the information from disclosure until such time as disclosure poses no material risk
• Effective key management practices
• Robust reliability

Fortunately, encryption and key management has gotten tremendously easier to deploy and is within reach of even the most modest budgets.  By protecting data with strong, standards-based encryption, organizations can meet the requirements of GLBA/FFIEC and protect their customer's’ private data – even in the event of a breach.

We have a lot of Enterprise customers deploying our Alliance LogAgent solution for the IBM i server to send security events to Splunk. On occasion a customer will deploy Alliance LogAgent and send data in the Log Event Extended Format (LEEF) to Splunk. The LEEF format is the preferred log data format for the IBM Security QRadar SIEM, so I’ve always found this a bit puzzling.

The light finally came on for me this week.

Security event information in syslog format (see RFC 3164) is largely unstructured data. And unstructured data is hard for SIEM solutions to understand. Here is an example from an Apache web server log:

[Wed Oct 11 14:32:52 2000] [error] [client 127.0.0.1] client denied by server configuration: /export/home/live/ap/htdocs/test

An SIEM administrator would have to do a fair amount of work configuring the SIEM to properly understand the importance of this message and take the proper action. If only the data was in some type of normalized format!

It turns out that the IBM Security QRadar LEEF format normalizes the system log information. A message like the above might look something like this in LEEF format:

date=20001011 time=143252 ipAddress=127.0.0.1 violation=client denied severity=5 path=/export/home/live/ap/htdocs/test

With field definitions like “date” and “time” the Splunk SIEM can easily digest the message and the Splunk query tools work great. It is easy to create reports and dashboards with this type of normalized data. The LEEF format is really good about this and Alliance LogAgent supports the LEEF definition.

What most Splunk administrators do not realize is that our Alliance LogAgent solution normalizes all IBM i security events in this type of normalized fashion. That is, this format is the default data format for security events. This is already what Alliance LogAgent does for IBM i security events!

When we started the development of Alliance LogAgent more than 10 years ago we understood at the outset that system log data would be hard for a SIEM to parse. So from the first release of our solution we provided data in this normalized format. Whether you are using Splunk, LogRhythm, Alert Logic, or any other SIEM we make it really easy for the SIEM to digest and act on the information. And forensic, query, and dashboards are easy to create.

So, Splunk users - listen up! The default system log format in Alliance LogAgent is exactly what you need to make Splunk work really well. You can use the LEEF format if you really want to, but you have all of the benefits of normalized data with the default format.

Here at Townsend Security we are vendor neutral when it comes to SIEM solutions. Our customers deploy a wide range of solutions including Splunk, IBM QRadar, LogRhythm, Alert Logic, SolarWinds, McAfee, and lots more. And they can move from one SIEM to another without changing their Alliance LogAgent configurations. We believe that actively monitoring system logs in real time is one of the most important security steps you can take. Early detection of a problem is so much better than trying to remediate a breach after the fact.

Patrick