Practical IT: how to assess a third-party provider’s security (part 1)

Chances are you’ve already got at least one key application hosted externally.

Did you consider the security implications? It’s very easy to assume that when outsourcing an application, you’re paying someone else to worry about data loss, along with the other issues of data centers, servers, licensing, administration and whatnot.

This is a dangerous assumption. It is still your data, and you are responsible for its integrity. Customers, regulators and shareholders will not care that your infrastructure wasn’t technically compromised. They trusted you, and you let them down.

So what can you do make sure that the right security measures are in place in a third-party’s applications & infrastructure? I’ll grant you that it’s not easy – there’s a certain amount of trust involved. But ask the right questions, and you’ll start to get a feel for their security posture:

Concerns broadly fall into two categories:

• Application integrity – the hard security. Is the application and the infrastructure behind it robust? Is it securely developed & well maintained?
• Security functionality – what features are available within the solution to help you configure it in a secure manner? This is often the more-neglected area, particularly when you start looking at identity, authentication & authorisation.

There’s a lot to cover, so I’ll concentrate on application integrity in this article and dive into functionality (particularly identity) in part 2.

Warning:You need to expect that no one is going to provide you with perfect answers. It’s important to weigh up the responses against the impact of a compromise. If an application is of minor importance to your organisation and doesn’t hold any sensitive data, then ask the questions but don’t worry too much if they can’t provide a weekly breakdown of their endpoint patch levels.

Application Integrity

The trick here is to get a feel for the organisation’s approach, while avoiding becoming an auditor. How far you go to check their claims depends upon the importance of the application and the data it handles. Or, to put it bluntly, how much bullsh1t you smell. If you’re concerned, it’s worthwhile to source a direct line to whomever handles security: it’s only natural that your sales contact is going to embellish things a little!

So, here are a few areas to start the grilling:

Certification & compliance: If someone else has already done the work, you’ve immediately got less to worry about. Be careful to make sure you understand what the certification covers and, more importantly, doesn’t cover. ISO27001 offers some good assurance; SAS70 is also a popular tick in the box, but neither have much to say about web application vulnerabilities (XSS, SQL injection, etc). If it’s a custom application, you probably want evidence that they adhere to a formal secure development lifecycle (SDL). I also like to ask vendors if their SLA includes a commitment to fixing critical vulnerabilities promptly.

Penetration testing: Do they perform regular pen-testing? Will they share the results with you? Can you perform your own pen-test on the code? These questions are great to gauge the vendor’s confidence. Understandably, they’re unlikely to share all their results, but a confident and open organisation might provide the executive overview from their latest tests. Purchasing your own test is an expensive measure, so you will probably only want to consider that for critical services but a flat refusal suggests they’re hiding some problems.

Controls: It is always worth seeing what they’ve deployed. Rather than listing every security technology you’ve heard of, I’d suggest asking the question to find out what they can offer (you might even learn of something interesting!). To make sure they end up on the right person’s desk I tend to split them up:

1. What network layer controls does the hosting infrastructure employ? Obviously firewalls are pretty key, network IDS, SIEM (security information event management) systems & DLP show that someone’s thought about it. You’ll probably also get useful info on their approach towards transport encryption: VPNs are good, but end-to-end cryptography is even better.
2. Host layer controls: AV is the obvious must-have, but you probably also want them to have deployed client firewalls, DLP, host based IDS, disk encryption, patch control et al where appropriate. Evidence of configuration hardening procedures or use of mandatory access control systems like SELinux shows they take things seriously.
3. Application layer controls: at the very least, passwords should be stored in an encrypted format. A web application firewall (WAF) provides some good defence in depth. Database firewalls are also on the horizon: if a vendor already has these deployed, then they’re pretty cutting edge!
4. Finally “Do you take any other measures to mitigate against the risk of host compromise or data leakage?” is a good catch-all to finish off with incase anything doesn’t fit into the above boxes.

Audit: Does the vendor proactively keep an eye on the key metrics? User account activity, patch levels and AV updates should certainly be tracked. You might also hear SIEM mentioned here, which is a good thing.

These tips should help you gain a valuable insight into a vendors security practices but don’t forget to assess the answers in context with the application you are assessing.

Want more?

In part 2 of this article, I will touch upon security functionality. We’ll look at what features should be available within the solution to help you configure it in a secure manner.