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

A month or so ago, I wrote the first part of this article, which focuses on how to assess a third-party provider’s security. Here’s the second part, looking at security functionality.

This is the hard part. Responsibilities get blurry.

Your vendor might have a rock-solid application that is virtually impenetrable to web application server exploits or SQL injection attacks. So what? What if authorisation is so primitive that everyone’s an administrator? Or maybe the application sends password reminders in a plain text email.
If these are the case, then good luck keeping it secure.

The functionality you’re likely interested in from a security perspective centres on authentication and authorisation.

If you’re not sure of the difference between these two, here is an analogy: being a 17-year old university student presented me with problems getting into nightclubs (the legal drinking age in the UK is 18). When challenged by the doorman, I would flash my student card in the hope this would be sufficient.

It rarely worked. By showing my student card, the doorman could check the photo and authenticate my identity but he would also, unfortunately, check my date of birth and confirm I wasn’t authorised to get in.

Authentication

If you’re deploying an app to more than a couple of dozen users, there’s really only one option: federated identity.

Federated identity is about delegating authentication to another system – in the enterprise, this is usually Active Directory – allowing your users to login with the same credentials they use internally.

Unfortunately, this is a complex area where standards haven’t really kept pace with requirements, but it’s one well worth understanding.

Federated identity support is great when doing security reviews as you can immediately cross a whole bunch of questions off the list. Concerns about enforcing password policy, handling forgotten passwords, promptly terminating accounts and auditing are hopefully addressed by your existing infrastructure.

It’s also a rare example of a security technology that your users will actually find beneficial, not just tolerable. Particularly if deployed in a single-sign-on configuration, your users will appreciate seamless access to applications without the complexity of yet another password.

There are a few technologies to consider for federated identity. First is “Security Assertion Markup Language” (SAML).

SAML is an industry standard with good support among the larger SaaS providers and by Active Directory. It has a reputation for complexity and can initially seem quite daunting but it’s mature enough that, for the simple cases at least, most of the complexity should remain firmly under-the-bonnet.

The major competing technologies are OpenID and OAuth. They tend to dominate consumer-focused sites but are also making inroads in the enterprise.

Authorisation

First, can the app provide the necessary granularity?

Make sure you start with clear specifications for the key roles. It will then be necessary to work closely with the business to understand the high risk areas where really sensitive functionality and data resides.

This is really important – only someone who fully understands a business process can spot how it can be abused.

Once you have specs and an understanding of the risks, it’s pretty simple to see if the application can segregate functionality and data appropriately by having a play (or, ideally, getting the vendor to demonstrate some defined use-cases for you).

If you are planning on penetration testing the application, the specs also come in very useful – an application may appear to do a good job but often security is bolted on at the user-interface layer. A pen-tester will need to know who should be able to access what to really check when there is a robust data access model in place.

Make sure they don’t focus solely only on the vertical privilege controls. Of course, a normal user shouldn’t be able to gain administrative rights, but horizontal controls are often neglected and can also be very serious. In an HR app, for example, the ability for one employee to access another’s record is likely a show-stopping bug.

The second consideration for an authorisation system is qualitative. An application may technically be able to satisfy the requirements but scalability and manageability dictate how secure it will prove in a real-world implementation. Obviously some form of group or role management is essential – something will be missed if you have to manage every user’s access individually.

Beyond the basics, make sure you understand the access inheritance model (if there is one). Possibilities exist for synchronising group membership with existing staff directories and reporting capabilities to spot potential access misconfigurations. It’s good to get the service desk engaged for this; they are the experts at user account management and can help you spot unmanageable functionality.

It’s really worth investing the time in both these areas but it does get complicated, so you may also wish to take a look at the bigger picture: there are various products and services, collectively referred to as ‘identity management’ which can help you navigate the maze.

Unfortunately, vendor support in this area can be seriously lacking, especially for smaller niche applications. If your queries about SAML support or identity management draw a blank (yet there is still significant value in the offering), it will be necessary to focus on the application’s user management system. If the intended user base is small, maintaining separate accounts for every user is probably an acceptable overhead.

You’ll want to test the user provisioning process and password management system – remember that email is a dangerous system to rely on for security. Passwords and login URLs containing user access tokens sent via email should be single use only. The ability to enforce a password policy is a must-have and, of course, the application should use https throughout.

Education plays a key role too. Users should not share passwords between websites and the service desk will need to be aware of the application so they can manually revoke access if a member of staff leaves. To ensure this is reliably performed you’ll need a ‘leaver’ process with a comprehensive checklist of all access revocations required, prioritising systems which are accessible directly over the internet.

If you want a way to help you educate your users, check out Sophos’s free toolkit. You’ll get a download that includes a presentation, videos, posters – everything you’ll need.

_{Doorman, protected data, security and authorised sign images, courtesy of Shutterstock}