Context-enhanced authorization: usefulness and feasibility for the banking sector
We did a very interesting project for a large Dutch bank (Rabobank) and IBM to determine the usefulness and feasibility of Context-enhanced Authorization in the banking sector. We focussed here on employees, and taking their context (location, used device etc) into account for authorization decisions. This would allow the authorization to become more dynamic, and address new trends such as nomadic working (Dutch: Het Nieuwe Werken) and Bring Your Own Device. An important technology in this project was XACML, for which we used IBM’s tooling (Tivoli Security Policy Manager). In short the outcome was yes it is useful and yes it is feasible.
Today I presented the project at a XACML seminar, organized by PIMN, CSA, PvIB and SURFnet. I repeat the key take-aways here:
- Centralization – take authorization out of the application (cf authentication)
- Use attributes (ABAC), XACML is the standard to do this multi-vendor and across domains
- Our pilot: use dynamic attributes (i.e., context)
- Yes it is useful, yes it is feasible
- But w.r.t. context: authenticity, quality & privacy
- But w.r.t. dynamic attributes / XACML: complexity of policies & scalability/performance
More information can be found in my presentation. We also described (most of) the project in a public whitepaper, and even made small video (2:39’, credits go to my colleague Ruud Kosman). I also copied the management summary of the whitepaper below for convenience.
Context-enhanced authorization is about knowing when and where users are, what they are doing, which device they are using etcetera, and using this information as a parameter in authorization decisions. A sector which could benefit from this is the banking sector. There is an increasing need for banks to be deal with security in a more flexible way, for instance in order to enable nomadic working and the usage of less secure devices (tablets, smart phones, bring-your-own-device). Banking employees need to be able to perform transactions with a high security risk from different locations (home, office, at a customer etc.), at different times of the day, and from different devices. This brings with it new risks that may be mitigated by context-enhanced authorization. The promise of context-enhanced authorization is that by making this context explicit in authorization rules the flexibility increases without reducing security. Implementing context-enhanced authorization is also facilitated by the wide-spread introduction of mobile devices, which makes more context information available, and the adoption of (logically) centralized authorization systems.
This whitepaper provides the outcome of a feasibility study of implementing context-enhanced authorization for bank employees. An important part of this study was a demonstrator based on the XACML policy language, which enables centralized authorization policies. The whitepaper also provides a context model, criteria for usefulness of context for authorization and use cases for context-enhanced authorization for bank employees.
The main conclusion of the feasibility study is that context has indeed the potential to make authorization more flexible, and that it is possible to use XACML tooling to implement this. Relevant and practical context types, for now, are location, time, and information that can be derived from context. There are however non-trivial issues that have to be dealt with, especially:
- Authenticity of context – Depending on the context source, context can easily be falsified, e.g., when the context owner is the potential attacker. Context should be from trusted context sources if possible. In all cases, when designing context-enhanced policies, the authenticity of the context has to be carefully taken into account. For example, location information from an employer-owned WiFi network is typically more useful than location information originating from a smartphone.
- Quality of context – Context is known with a certain amount of “vagueness”, this is called Quality of Context, due to technical limitation of context sensors. For example, an employee is never a 100% certain at home, but may be 95% certain within a 50 meter radius at his or her home. This vagueness further adds to the complexity of context-enhanced policies.
- Privacy – Context information is often privacy sensitive information, e.g., location. The privacy risks have to outweigh the benefits of context-enhanced authorization. An issue for, among others, using context-enhanced authorization for banking employees is that they benefits may be more with the employer, and the privacy risks with the employee. There is also no generic answer if the benefits outweigh the privacy risks, this basically depends on the used context (how privacy sensitive is it), and what the actual benefits are in a specific case. The privacy implications were not explored in any detail within the scope of this study, but should be in potential follow-ups, This should include both legal aspects (e.g., role of works council, can informed consent play a role), technical (e.g. privacy-by-design) and user acceptance (e.g., do employees see benefits, what context information is sensitive).
- Complexity of context-aware policies – Adding context parameters to policies makes them more complex. The use cases and demonstrator show that fine-grained policies are possible, but this finer level of granularity also means that it may become harder to ensure that the produced policies are complete, safe, and conflict-free.
- Scalability and performance – Context information is different from the usual static information on which today’s access policies are based (the identity of the user, the role of the user within the organization): context information is only relevant when processed in (near) real-time, and there is much more context information (in terms of amounts of data). This requires careful design of the collection of context, and puts much more stress on policy evaluation engines.