Applying Encryption Widely in Banking: InfoRiskToday Audio Interview

Thank you, InfoRiskToday, for interviewing Jerald Ray, COO of SecureAge Technology.

In this interview, he discusses:

  • 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.

Below is the transcript of the interview for easy reading:

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 are the common mistakes they make. Welcome, Jerry, to the ISM discussion.

Ray: Thank you so much, Suparna.

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

Ray: Oh that is a terrific question and 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 and 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 in rest. There are other terms that are similar, data in transit, data in storage, but they’re all talking about the same things where your data is moving, so 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, we had to ensure that at the printers itself, these numbers were also secured. If you can imagine the challenges just in one small part of the transaction if you 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 is 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 hide some sensitive portion of a number or they will hide some columns of the database from internal users, or they will discard information entirely and make sure that it Is securely wiped. The other type of encryption is when that 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 banks headquarters, and you gotta ensure that this database is encrypted and certainly when the data is finally at rest in the back-end, you yet need another tool for ensuring that its encrypted for back there. In each of these pieces of 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.

Suparna: Typically banks, they deal with a lot of data, so banks hold data for a long time. So 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 there are so many different pieces that all need to come together seamlessly, and then they all have to actually work, and they gotta work together and there are some things that certainly the security officers in financial institutions could do better overall but better outside the regulations and by this, I mean that there’s 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 really 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 each of those levels, its 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 really have to invest their efforts into making sure that what they’ve 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.

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 really critical issue. Encryption is not an option for banks, 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’s 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 and the way this is achieved is key management, and 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, merchants, and 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, recall those keys when you need them. Then there are other people who 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 passphrase, so the answer to your question is key management, but key management is very long and complex answer in itself when you talk about all the different components and all the different methodologies.

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: Certainly, so 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, so for all of those, things will begin with vendors that offer products such as PCI compliance product, Tapenic card industry itself, American Express, Visa, MasterCard, they created these standards and they’ve 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 and 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 and inside of those machines are the software that will provide tokenization and then you will have the vendors who will take care of the data at rest then you’ll look into 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. And then what I talked about earlier with the transport layer, that data in motion, you gotta encrypt on your connected tunnels so there are vendors for SSL VPN, there are other vendors who can setup on legacy systems, some type of TLS, the transport layer security and the biggest challenge after that is to make sure that all your tools are ones that 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, so it’s far more complex to just say here’s what they should do instead, if things 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.

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

Ray: Sure, that’s something that we’re seeing on the news on a weekly basis, when we see large rows of credit card numbers being posted to the Internet that were breached from some financial institution, and financial institutions take it especially hard because they’re such a rich target and when it comes to the mistakes they’re making, its 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 its the algorithm or the mere existence of encryption but that doesn’t mean that you’ve really secured the data from all the threats coming its way. So recently, there was an incident in the US with Capital One, and Capital One being one of the largest players for 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 own settings so Capital One had to set up its own instances on AWS to do its own banking and in a misconfiguration, its former AWS employee was able to exploit that and steal customer data and then ultimately breach that data, so the problem here was in the statement released by Capital One after the incident where they said, well in this particular incident, the way the person access our data meant that our encryption sent the data out in a decrypted manner, and that statement there is really 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, then your encrypting tool simply just doesn’t work, and there’s many encryption tools that do that, it’s not that the tool is broken, its that’s how the tool was designed, specifically full disk encryption, otherwise known as hard disk encryption. When you encrypt an entire volume of data, when that volume is closed, when the machine is turned off that’s holding up on, 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 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. Once that volume is open, its open. And even though the data that’s 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, 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 so if they can think of these large databases as a single file, and apply some type of file-level encryption to that, then 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 gonna be secure. And they can critically look at all of their transaction interfaces, all of their internal systems where employees are accessing data, is my encryption protecting it from my own 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 authorized, simply shouldn’t allow someone to go out with plain data. That means I authorize people inside my bank to have access to this large database with customer information. However, they are not authorized to take any of that data out.

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 and 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, so the challenge for banks is to critically look at their own 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 it out those questions, talk it out 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 here.