Top Data Protection Questions I Would Ask Your Vendors in 2014

January 29, 2014
Kevin Lam

I read an article this past week that gave readers a checklist on protecting data. One of the bullet points the author provided read something like this “Ensure your vendors are also secure”.

Not a lot of prescriptive guidance followed. And it left me (and I suspect others reading the same article) feeling unsatisfied. As someone who protects data for a living, here are the top 10 questions I would ask my vendors with respect to data protection to help “ensure that they are also secure”.

Question #1: Do you have an application security process?

Ask to look at your vendor’s “secure application development process”.  This is the set of controls that they overlay onto their development efforts to help ensure that their software (which is handling your data and your reputation) is reducing risk from data breaches and malicious hacker attacks. This is very important especially for vendors who develop their own software. And because most of the attacks today are targeting software applications.

Look for security control implementations at the different stages of software development (like design, development, testing and deployment). If you get a response like “We (just) use SSL and AES encryption” and nothing else that’s a red flag. Encryption alone is not going to be enough for today’s threat landscape.

Question #2: What encryption algorithms do you use?

Encryption is an effective means of protecting data. But choosing the right algorithms is incredibly important.  By today’s standards you want to see algorithms like Advanced Encryption Standard (AES) 128-bit or 256-bit, and Rivest Shamir Adleman (RSA) 2048-bit or higher being used. Ten years from now the industry standard will probably change, so it’s always important to know what algorithms your vendors are currently using.

You also want to ask if they are using “standard encryption libraries.”  A standard library means a library that has been well tested and certified correct by review boards.  This is what you want. What you don’t want is vendors creating their own encryption libraries which is highly prone to error and easily defeated.

Question #3: How do you reduce risk from SQL injection attacks?

SQL (pronounced see-quel or S-Q-L) is the language that modern databases speak. A SQL injection attack is a way by which malicious hackers can compromise databases.  The reason why I bring this type of attack up and not others is because this is the #1 most common attack today. And coincidentally the one most likely to lead to a data breach of your data. It’s also the same attack attributed to many of the high profile data breaches you read about on CNN.

Vendors who develop their own software should be using controls like “parameterized stored procedures and queries” or “input validation”.  If they ask “what’s that?”, I’d be really worried. SQL injection attacks don’t require a lot of skill and they can have a severe impact on your business.

Question #4: How is data protected at rest?

When data is stored on a system it’s very exposed to attack.  Someone could steal the hard-drive and all the data on that drive. Or a hacker could hack into the system and gather the data on that fresh kill. Someone could decommission a computer system, but forget to wipe the disks (just ask Kaiser Health). A lot of bad things can happen that can leave your data exposed. You want some level of assurance that your data is being encrypted. Any other response like “don’t worry your data is safe” or “there’s no need for encryption” should have you worried.

Question #5: Who has access to the encryption keys?

OK, so your vendor has told you that they encrypt your data at rest.  Great, next question: who has access to the encryption keys? When you encrypt data, there’s always a corresponding key to decrypt that data (typically the same key that was used for encryption). If everyone and their mother (all employees, partners and vendors, etc.) have access to the key there’s still a risk of unauthorized access.  Find out how they are preventing unauthorized access to encryption keys.

Question #6: How is my data transferred and how is it protected while in transit?

Protecting data during transmission is vitally important, like protecting data at rest.  The most common methods of protecting data in transit is using Secure Sockets Layer (SSL) or Transport Layer Security (TLS). Go even more geek and ask what “public key size and symmetric algorithm” is being used, which indicate the strength of the SSL or TLS protection. You want to look for 2048-bit or higher (public-key size) and AES-128 or higher (symmetric algorithm). What you don’t want to hear is that they use protocols like email and FTP as these by default do not provide protection for data at rest or in transit.

Question #7: What’s your password security policy?

Passwords always tend to be the weakest link in a system and weak passwords are the number one way they get compromised.  It’s important for you to understand how a vendor handles their passwords.  Do they use strong passwords?  How often are they changed? Are passwords ever shared?

Question #8: When are your systems patched?

Vendors can write the most secure application in the world and do all the right things to protect your data. But if the system that it runs on is full of security holes, it’s wasted effort.  Sooner or later your data will get compromised.  Ask your vendor how often their systems are patched and what their policy is on applying those patches.  Microsoft patches are released every second Tuesday of every month, so a patch cycle that has a regular schedule like that is recommended. We for example apply patches within 24-48 hours of public release, which may seem extreme, but we tend not to mess around when it comes to security.

Question #9: What security training has your team taken?

Technology is important. Process is important. But so are people.  If the three aren’t working well together to protect your data then a data breach will happen. Ask your vendors what additional security training their staff has taken. There are so many ways today to get hacked, and so it’s incredibly important that people be able to be aware of common attacks and how to respond to them.

Question #10: Has anyone conducted a security assessment on your systems?

At IronBox we have more than a decade’s worth of experience writing secure applications and conducting security assessments.  So we review our own systems and source code. We’ve even written a published book on the topic.  But that doesn’t mean that it’s good enough. We also have security expert partners independently review our systems and provide us feedback on how we can improve security.  Ask vendors if they have had a third party service review their systems. Remember that it’s not so much important that issues were found, but rather that they were fixed.

If you take a look around our Web page, you’ll quickly see that we’re vendors too. And yes, we do hold ourselves to the same standard as above and more. Some vendors think that a simple $50 SSL certificate is enough for security. We strongly disagree. And if you take one thing away from this article I hope it’s this: people, process and technology. It’s important, so here it is again: people, process and technology. When these work together, you get really great security. The questions above will help you determine this.

Good luck, and happy Friday,