Applying encryption widely in banking: InfoRiskToday interview

• The complexities of ensuring encryption are applied through every step of banking transactions
• Where banks missing the mark when it comes to encryption;
• How to keep a balance between encryption and visibility of data;
• The different areas where banks need to apply encryption. 

Suparna: Hi, this is Suparna Goswami, Principal Correspondent, with Information Security Media Group. I have with me today Jerry Ray, COO at SecureAge, a data security solutions company based out of Singapore. He will be talking about how the financial industry can go about encrypting data and what common mistakes they make. Welcome, Jerry, to the ISM discussion.

Ray: Thank you so much, Suparna.

Complexities of encryption applied in every step of banking transactions

Suparna: We all understand the importance of encryption. I wanted to understand how complicated can it get, the entire process of encryption.

Ray: Oh that is a terrific question! The financial industry, in particular, is one of the best places to study encryption and data security because their task is so challenging, and the number and types of encryption are so varied. To just capture a few of them, if we think about simple transactions, ones that you make at a merchant or an ATM, or simple banking transactions over the counter. Each one of these starts with some type of human interface and some type of sending and receiving of that data said in the motion. There are also data at rest. Other similar terms are data in transit, and data in storage, but they’re all talking about the same things where your data is moving.

Ray: If I’m conducting a transaction at an ATM, you got to look at every piece of that transaction. From the actual PIN number that was generated on that card, creating your pin, making sure that pin is always secret, and covered by some type of encryption for when that pin is at rest and when that pin is being used. This is once more, a piece of the transaction, which is very critical. Then you look at the card number itself; we had to print that number on the card, and we had to ensure that at the printers themselves, these numbers were also secured.

Ray: If you can imagine the challenges just in one small part of the transaction and look at everything from the customer interface to the back-end of the historical data, banks are having to acquire encryption in so many different forms and from so many different vendors because very few would make something that covers from end to end. You’ve got to have a few pieces just to begin, one of them, of course, is ensuring that that card, those pins, that transaction that’s happening are all secure at the time that it’s happening. That’s your data-in-motion piece.

Ray: Most financial institutions are using something called tokenization which will encrypt a portion of the data. They will (1) hide some sensitive portion of a number, (2) hide some columns of the database from internal users, or (3) discard information entirely and make sure that it Is securely wiped. 

Ray: The other type of encryption is when the data is in transit, you want to ensure that the transit connection is encrypted. Then you got the back end, the database itself at the bank's headquarters, and you got to ensure that this database is encrypted. When the data is finally at rest in the back end, you need another tool to ensure that it is encrypted. 

Ray: In each of these pieces of the encryption puzzle, you got to have a key, and these keys need to be as secure as any other component, so then you got the complexity of making sure you’re able to encrypt the keys with another key that is still secure.

How bank does encrypt data in motion, in use and at rest?

Suparna: Typically banks deal with a lot of data, so they hold the data for a long time. Therefore there’s a need to protect data in motion, data in-store, data in use, etc. How is the encryption being acquired or done in each of these cases?

Ray: Banks are notorious for having a very prolific development staff inside - they write a lot of software themselves, but that’s not the encryption case. This takes us back to the point where there are so many different pieces in motion, they all need to come together seamlessly and have to work and work well together. There are some things that certainly the security officers in financial institutions could do better overall.

Ray: Outside the regulations and by this, I mean that there are regulations, there’s compliance and there’s checking off boxes for each of those, and there’s also the spirit of that regulation, the spirit of compliance, what are they getting at. They can demand some type of encryption being placed for your data at rest, but there are so many different variations of that from folders encryption to file-level encryption to file folder encryption and for each of those levels, it is up to those institutions themselves to decide which one is best for their own needs. However, whether they make the regulation, whether they comply with something or not, they have to invest their efforts into making sure that what they have chosen keeps all the data secure at all times, both from outsiders who have malicious intents to insiders who either make mistakes or have somehow being compromised.

How to keep a balance between encryption and visibility of data?

Suparna: But I also understand that it is important that they are also able to maintain certain visibility across the security infrastructure, right? So how can they keep that balance, how can they manage that? 

Ray: Yes, that’s a critical issue. Encryption is not an option for banks or financial institutions; it’s a must. To ensure there’s also visibility, the other side of all those other regulatory compliance is that the regulators want to see evidence that you’re complying and there are also financial regulators who also have to trace transactions, auditors who have to be able to have access to every piece of information. So as much as you also need to encrypt and protect the data, you also need to make sure that it’s visible. 

Ray: The way this is achieved is through key management. Proper key management means that at each point where I have encrypted data, I need to have the appropriate key to decrypt and make it available to regulators, customers, partners, and merchants. Key management is an area that has a lot of different standards and a lot of different options. 

• People will manage keys with software tools that come with a certain package and leave it with that. 

• Others will go one step beyond and buy hardware such as an HSM; now these hardware security modules are things that will allow you to manage and store keys securely and recall those keys when you need them. 

• Then other people take that even further and they will backup keys with redundant hard drives that they will store in separate safes and people who will encrypt those hard drives will each have half of those very long, complex passphrases. 
  

The answer to your question is key management, but key management is a very long and complex answer in itself when you talk about all the different components and all the different methodologies.

What can banks do to begin their encryption process?

Suparna: Okay, so Jerry, also if I’m a bank and as a CIA, how do I decide that I will probably encrypt my data? How will I begin the process?

Ray: If we think of banks, they first have to look at that interface with the customer, and the interface that happens at terminals, for tellers, it happens at ATMs machines. For all of those things, it will begin with vendors that offer products such as PCI compliance products, Tapenic card industry, American Express, Visa, and MasterCard, they created these standards and they have detailed in particular, what banks need to do to comply with these standards and those can be looked at by outside auditors and they will welcome the banks through the types of encryption they’ll need. 

Ray: Next thing you talk to is vendors who will provide transaction processing machines, little terminals that will be you know, your merchants or ATM itself. Inside those machines is the software that will provide tokenization and you will have the vendors who will take care of the data at rest then you’ll look internally, at your own systems and everywhere, that the data is plain or accessible without a password, you can the righteously consider it should be encrypted. 

Ray: And then what I talked about earlier with the transport layer, that data in motion, you got to encrypt on your connected tunnels so there are vendors for SSL VPN, there are other vendors who can set up on legacy systems, some type of TLS, the transport layer security. 

Ray: The biggest challenge after that is to make sure that all your tools can play nicely together. There are ones that you can still manage those keys, you can still manage that data, and you can ensure that everything is protected from one end to the other. It’s far more complex to just say here’s what they should do instead, if you just look at the flow of information from customer interface to back-end storage, everywhere in between there are a very large number of players in the industry, vendors who will provide that encryption, who will provide the hardware and software, and it’s a monumental task for the banks themselves to then seek through and see which vendors are the ones to provide the things that will be suitable for them.

Common mistakes and challenges banks make in encryption

Suparna: What are some common mistakes that you see banks making as far as encryption is concerned, and what are some challenges in the process?

Ray: We are seeing on the news on a weekly basis of large rows of credit card numbers being posted to the Internet that was breached by some financial institution, and financial institutions take it especially hard because they’re such a rich target. When it comes to the mistakes theta are making, it's statistically in banks, merely looking at the regulations in place without considering the spirit, something that I talked about earlier that you can comply with an encryption standard whether it is the algorithm or the mere existence of encryption but that doesn’t mean that you have secured the data from all the threats coming its way. 

Ray: Recently, there was an incident in the US with Capital One, and it is one of the largest players in credit card insurance and banking, they had a data breach that took place from someone who previously worked for the cloud provider AWS, who no longer work with it. However, that person had some knowledge of how the security was implemented for people who were using AWS, specifically institutions and the bank does its settings so Capital One had to set up its instances on AWS to do its banking. In a misconfiguration, its former AWS employee was able to exploit that and steal customer data and then ultimately breach that data. The problem here was in the statement released by Capital One after the incident where they said, in this particular incident, the way the person access our data meant that our encryption sent the data out in a decrypted manner. That statement there is the key mistake that so many banks make.

Ray: If you have an encryption tool that allows your data to go out plain or in a decrypted state, your encrypting tool simply just doesn’t work, and many encryption tools do that. It’s not that the tool is broken, it's how the tool was designed, specifically full disk encryption, otherwise known as hard disk encryption. When you encrypt an entire volume of data and it is closed (the machine is turned off that’s holding up), it’s perfectly secure. Think of full disk encryption as a physical security layer. If I have it on my laptop and someone steals my laptop, and when it is turned off, I don’t have to worry, that data is perfectly safe. There’s nothing they can do to the laptop or the hard drive if they remove it and try to start it up somewhere else, they have no way of accessing that data, but that’s not suitable for a system that’s turned on.  

Ray: Once that volume is open, it's open. Even though the data is encrypted and you pull the data out, it turns out plain as the design of full disk encryption. You can say you have encryption, but if you’re using full disk encryption, that doesn’t mean anything once that computer is turned on. The only time when full disk encryption is giving you security is when that machine is turned off, and this is just an example of the design of the product was not suitable for the use of that product and this, this is something that banks need to consider every step of that pathway I was speaking of earlier.

Ray: From those transactions upfront to the storage in the back, they need to consider “what the use of that product is?”, “why am I putting this in place?”, “why am I using this form of encryption instead of that form?”, and that they were using some file-level encryption. File level keeps that data secure, at any point when the machine is turned on, when that file is transmitted over some pathway, and when the machine is turned off. At all levels, that file is safe. If they can think of these large databases as a single file, and apply some type of file-level encryption to that, they can ensure that at all points during the lifespan of that data, from the time that it is created to any point in the future when it is stored, it’s going be secured. 

Ray: They can critically look at all of their transaction interfaces and all of their internal systems where employees are accessing data “ is my encryption protecting it from my employees?”, and not because your employees are bad, but because your employees can be so easily manipulated to social engineering and they can be easily attacked by motivated hackers who spoof emails through other mechanisms and your employee, that interface with that data is the weakest link, the easiest to exploit, the most dangerous. So you got to say “is my encryption tool stopping my employees from making potential mistakes?”, and “is it preventing any type of access that, while authorised, simply shouldn’t allow someone to go out with plain data?”. That means I authorise people inside my bank to have access to this large database with customers.

Ray: So getting back to what the question was, that what mistakes they are making - they’re not matching the actual use the interface of people with machines, people with data, with the tool that they’re buying. It’s easy to understand why, the complexity of this, the large number of vendors who are in place, it’s a very complex, complicated dance that has many moving parts and many different players. 

Ray: The challenge for banks is to critically look at their system, more than vendors, and say “where is my data?”, “what’s my data doing?”, “who has access?”, and “what are the limits of that access?”, and if they can talk out those questions, talk about those issues internally, look at their own needs, then they can go and find vendors to meet their needs instead of finding vendors who meet regulatory compliance check-boxes, looking only at the regulation, you can always put yourself in the wrong corner, and buy the wrong tool.

Suparna: Ok, Jerry, Thanks a lot for sharing your thoughts.

You can find the original audio interview from InfoRisk Today.