Mazda Logo

A case study from Mazda Motors Europe

Horst Walther SiG Software Integration GmbH, Hamburg
Conference paper in the printout of the & Cyprus Infosec 2004, October 20th, Nicosia / Cyprus

1    Summary

Mazda Motors Europe is the headquarters of the fast growing of the European operations of the Hiroshima based car Manufacturer Mazda Corporation (MC). Its high corporate growth rate results in an increased organisational complexity and subsequently a higher need for mature administrative processes and transparent and auditable repositories of administrative data.

Mazdas Long-term vision is the establishment of company-wide identity management. Therefore, the project "Mazda User Management" (MUM) was set-up. Despite some words of warning Mazda intends to base it’s access to systems on roles according to the definitions of the NIST.

Being aware of the various reported pitfalls of the introduction of a role based access control Mazda Europe focuses on a risk minimising way towards the envisioned aim. The projects starts deployment of RBAC in a business area where visibility is high as is the sensitivity to security breaks, whereas the role complexity is expected to be low and thus a good return on the invested effort is expected. As the project is still in its infancy, it will take about half a year to show the first successful results.

2    Motivation

2.1      Mazda Motors Europe

Mazda Motors Europe is the headquarters of the fast growing of the European operations of the Hiroshima based car Manufacturer Mazda Corporation (MC). While successfully performing the business functions of the back end of a manufacturer value chain like marketing, sales and all those activities subsumed under the term after market activities (e.g. warranty, customer satisfaction, …) resulting in a surprising annual growth rate of ~ 20 %. At the same time Mazda Europe has managed to adhere to it’s original style of doing business in a very effective way in small transparent business units with a limited head count and on a high level of efficiency.

A typical Japanese flavour may be detected when considering the workers attitude. The colleagues start early, work hard and don’t need much organisational overweight to know what are the right things to do and how to do them right. Given this background knowledge you may be surprised that we even consider to make use of a organisational discipline ill famed for being academic and surely not down to earth enough to be applicable for our style of doing business.

The entitlement hierarchy at MazdaFirst let’s give some characterising basic key data: MME (Mazda Motors Europe) is the headquarters, based in Leverkusen / Germany not far from Cologne and Düsseldorf at the banks of the river Rhine. Most of the European logistics and Information processing is done in Mazda Logistics Europe (MLE) in Willebroek / Belgium near Antwerpen.

As sales are local business, it’s the responsibility of national sales companies (NSC) in the major European markets and Distributors in emerging or smaller markets. The NSC’s basically service their connected authorised dealers (AR) and authorised repairers (AR). In the most prominent market, Germany, several central marketing areas (CMA) are defined in order to enable common activities among the local dealers. Gently forced by the European commission through it’s so called ‘group exemption regulation’ we need to support independent motor traders (IMT) and independent distributors (ID) as well.

The dealers and their employees by far outnumber the ~ 500 employees of Mazda in Europe. We assume, that the actual number of dealers is about 2,500 and that each dealer has delegated access to the system to 2 - 3 of his employees, resulting in 5,000 - 7,500 users at present and an estimated number of ~ 10.000 over the next 3 years.

2.2      Mazda User Management

The corporate growth rate results in an increased organisational complexity and subsequently a higher need for mature administrative processes and transparent and auditable repositories of administrative data.

Long-term vision is the establishment of company-wide identity management, capable to provide a secure and efficient foundation to run business transactions through public and private networks among partners of different trust levels and passing domains with non-unified security levels.

Mid-term requirement is to fulfil the necessity of a proper auditablility of the user management with the subsequent introduction of a secure and efficient user provisioning system in a risk minimising way.

In effect, the project is expected to improve control and security through deletion of unwanted and unapproved accounts on the connected systems or adjust actual entitlements according to their business needs.

The project "Mazda User Management" (MUM) was set-up to reduce operational risks and fulfil internal and external legal and audit requirements, enhance transparency by providing correct and in-time information regarding the status of access rights and access rights requests, boost efficiency by introduction of standardised and lean application and administration processes. This opens the chance to keep administrative headcount flat and reduce labour intensive procedural controls, license costs and time wasted in business areas.

As the provider for the supporting software, we have chosen the well-respected Waltham, MA based vendor Netegrity Inc., recently acquired by Computer Associates.

2.3      Why roles?

So why did we come across with role engineering? Well, we simply need some categorisation of our users as the B2B-Portal requires a basis for personalisation and access control, the proposed workflow-systems demands for similar information and the Indentity Management Software from Netegrity can do it’s job more smoothly and transparently by using roles.

Nevertheless, we have been warned. In-house our administrators reported, that they couldn’t recognise any clear privilege pattern for most of the in-house users and predicted as much roles as we do have users - if not more. Additionally the role engineering related literature is full of hidden or even direct hints that those few brave and noble fighters, who would successfully complete a project to introduce role based access control (RBAC) would be guaranteed a seat in the hall of fame.

Well that’s not what we are aiming for. Instead, we are deeply convinced that roles represent a very natural way to describe organisational structures. It is obvious, that in existing organisations entitlements and restrictions are determined by several different dimensions …

Hierarchy.. a superior commonly enjoys a higher level of permissions that his subordinate.
Function If a corporation’s dynamic is viewed at as a superposition of business processes, their atomic activities (functions) need to access business objects.
Location Privileges may differ by location, as they e.g. are devoted to different objects.
Company.. Business units (BU), which form a group structure may introduce further differentiations,
Cost code. Cost or profit centres may not match with the boundaries of organisational units.
User type.. It is common to assign different access rights to employees, contractual staff, temporary personnel, consultants,

This list is far from being complete, but only few of these determining dimensions lead to own roles (e.g. Hierarchy and Function). The others have to be dealt with differently.

3    What is a role?

3.1      Origin

The idea of cross-platform user administration goes back to the late eighties when software companies first saw the need to develop tools, which allowed maintaining users and their privileges on corporate level across all of their production systems in one step. At about the same time researchers in the US worked on methods for access control based on roles (RBAC), an ordering scheme, which originates from the organization theory [01]. When the first tools for cross-platform security administration appeared on the market around the middle of the nineties, it became apparent that the abstraction of the access control concept using role semantics was necessary to exploit the full potential of these administration tools [02]. At the same time, research provided the first formal role models [03], [04].

3.2      Concept

The central idea behind roles is to simplify authorisation management by associating permissions with a role and then assigning this role to a user. Roles are often used in applications to enforce policy.

For example, an application might impose limits on the size of the transaction being processed depending on whether the user making the request is a member of a specified role. A bank teller might have permission to process transactions only less than a specified threshold, supervisors might have a higher limit, and managers might have a higher limit, etc. In other words, roles can be related to various job positions and the permissions associated with them.

A way to look at Roles is the collection of resources and permissions associated with a class of user(s). The class will be granted a consistent set of services based upon their Role. Roles are often equal to job functions in many organisations.

RBAC - Role Based Access Control

Source: Ferraiolo, Sandhu, Gavrila:
A Proposed Standard for Role-Based Access Control, 2000.

Currently, different administrators or application vendors have different definitions of roles. As this situation may serve as a source for confusion, we therefore henceforth will refer to the deserving research of the National Institute of Standards and Technology (NIST).

According to the NIST model (see above) …

3.3      Related concepts

There are three concepts, which are frequently confused: roles, rules and groups. The confusion originated very much from inaccurate use of the terms isolated from their original context and from reluctant abbreviation of their accurate form.

As proposed by the NIST roles can be understood as groupings of cross system privileges on enterprise level.

Although rarely defined explicitly, when "groups" are mentioned, they are used as groupings of users.  Hence, the general term "group" cannot be used for discrimination with sufficient clarity.

To add to this confusion some implementers implement roles through dynamic groups while at the same time maintaining user groups - without being able to clearly state the inherent differences.

Rules in contrast to these both statically usable grouping constructs only unfold their power when interpreted at runtime. Rules are generally understood as general expressions using symbolic variables and Boolean or even arithmetic operators. They might be nested using brackets as commonly used delimiters.

All three concepts may be used independently but it is recommended to combine them in balanced way in order to achieve optimal modelling results.

While dealing with the semantics of user management terms it should be mentioned, that throughout this conference paper the terms entitlement, privilege, access right and permission are used synonymously.

3.4      Standards

RBAC is now an American National Standard - ANSI INCITS 359-2004 (approved 19 Feb 04). The NIST RBAC Models offer four increasingly powerful yet increasingly demanding variations with respect to implementation. These fine-grained variants allow less sophisticated implementing systems to realise a subset of the full-blown RBAC set rather than failing completely by not complying with the maximum requirements.

4    Policies

RBAC in the NIST flavour is regarded as being policy free. Nevertheless, it can be used to express several policies. Four of the most commonly known and - at certain times and in defined environments - most widely applied policies are discussed here.

4.1      Least Privilege Principle

The principle of least privilege is important for meeting integrity objectives. It requires that a user be given only the privilege necessary to perform a job. Ensuring least privilege requires identifying what the user's function is, determining the minimum set of privileges necessary, and restricting the user to a set of roles with only those privileges. By excluding users from transactions that are unnecessary for the performance of their duties, those transactions cannot be used to circumvent organizational security policy. With RBAC, enforced minimum privilege is easily achieved. [05]

4.2      Separation of Duties

Separation of duties (SoD) is determined from organizational policy. RBAC facilitates splitting administration of the role-user relationship from that of the role-permission relationship[06].

Since many users in an organization typically perform similar functions and have similar access rights, user functions are separated by role.

Separation of duties requires that for particular sets of transactions, no single role be allowed to execute all transactions within the set. As an example, there are separate transactions needed to initiate a payment and to authorize a payment. No single role should be capable of executing both transactions. Separation of duties by role is valuable in deterring fraud since fraud can occur if an opportunity exists for collaboration between various job-related capabilities.

A role can be further qualified with affiliation. A person’s access could be limited to a geographic or departmental boundary. For example, a role of branch manager could be qualified by an affiliation to a particular branch thereby conferring branch manager permission only within that branch.

Both static and dynamic forms of separation exist. Static separation (SSD) means that roles which have been specified as mutually exclusive cannot be included together in a user's set of authorized roles. Dynamic separation (DSD) means that while users may be authorized for roles that are mutually exclusive, those exclusive roles cannot be active at the same time. In other words, static separation of duty enforces the mutual exclusion rule at the time of role definition while dynamic separation of duty enforces the rule at the time roles are selected for execution by a user[07].

4.3      Discretionary Access Control

Discretionary Access Control  (DAC) permits the granting and revoking of access privileges to be left to the discretion of the individual users allowing them to grant or revoke access to any authority under their control without the intercession of a system administrator[08]. It acts as a means of restricting access to resources based on the identity of persons and/or groups to which they belong.

4.4      Mandatory Access Control

The most common Mandatory Access Control (MAC) is widely used to secure military systems. MAC is a means of restricting access to data based on varying degrees of security requirements for information contained in the objects. Information is associated multi-level security (MLS) requirements with labels such as "top secret", "secret", "confidential" and "unclassified"[09].

4.5      Our Choice

DAC may be considered as a very basic policy only suitable for isolated non-critical systems with few users only. Therefore, this policy is not applicable at for a globally acting corporation and is only considered here for historic reasons.

MAC’s primary focus is to keep confidential information secret. This policy relies on the existence of a strict hierarchy where the superior always owns a superset of the permissions of his subordinates. This is not necessarily true for commercial organisations and may even conflict with the principle of least privilege.

The application of SoD in either of it’s defined variations (SSD or DSD) at Mazda Europe is surely justified or even required in several back office processes at MME, MLE or even within the larger NSC’s.  For reasons of simplicity and because we are unsure of an appropriate support of DSD by the executing systems, we will stick with the static variant only.

Whereas the principle of least privilege will be our leading principle whenever applicable. However, we are aware of the danger of over-engineering. Excessively following this rule may lead to an inflation of narrowly defined roles and thus to a loss of transparency and manageability. On the other hand the granting of surplus privileges, e.g. those which are not necessarily needed in this particular case can lead to security threads and clearly violates the principle of least privilege. Thus, a role engineer has to carefully balance these contradicting requirements in order to lead to a well-crafted set of access roles.

RBAC is a form of mandatory access control, but not based on multilevel security requirements. Rather, access control decisions are determined by the roles individual users take on as part of an organization.

RBAC tends to be modelled after the natural structure of an organization where functions are grouped into roles and users are permitted to one or more of these roles. The security policy of the organization determines role membership and the allocation of each role’s capabilities. Unlike DAC, RBAC’s premise is that the organisation, not the user, owns the objects being secured. In most implementations, users cannot sub-delegate access permissions on to other users at their discretion[10].

5    Role Engineering

5.1      Life Cycle Management

Due to the complex nature of role-engineering projects, where a multitude of interfaces (both organizational and technical) must be managed, it is advisable to follow a formal and structured process, e.g. that one  proposed by Schimpf[11].

The Role Engineering Process
Source : Schimpf, Life cycle Management for roles

Schimpf defines six activities to performed within four phases:

5.1.1     Analysis

During the analysis phase, the following activities are performed

5.1.2     Design

During the design phase, the following activities are performed by role engineering

5.1.3     Build

During the build phase, the following activities are performed

5.1.4     Maintain

During the role maintenance phase, the following activities are performed.

Establish enterprise wide processes including triggers to cope with changes and their impact to roles, leading to …

Triggers for role maintenance may be …

5.2      How to find roles

6   Pitfalls of RBAC

Roles are static constructs relying on a minimum stability of the defining business environment. For some cases they turn out to be too static, i.e. too difficult to keep current. This objection is specifically true for dynamic business functions and dynamic industries.

For cases like this augmentation of roles by executable business rules may help. Rules can modify or restrict role-based entitlements e.g. only modify sales data in your territory. They can create additional entitlements not based on roles e.g. anyone in "corporate" gets HQ building access. Thus, they can be used to complement roles.

Obviously the effects of role based entitlement assignment can be misunderstood and simply done wrong. From early lessons learned the advice can be given: Don’t try to represent all user entitlement requirements in Roles. Role proliferation is a serious management problem anyway and a security issue too, as security is truly a direct function of transparency and simplicity.

Easily situations can be constructed, where role inflation occurs, resulting in more roles than users. Not surprisingly inappropriate design may adversely affect transparency and, even worse, let the situation deteriorate, it was intended to improve.

If on the other hand a radically dynamic approach is followed, data requirements for rules may be difficult to meet, especially with respect to availability and reliability.

where to look for roles bestBest practise experience leads to the insight, that implementing an access control solution that is a combination of Roles and Rules best balances the desired goals with the existing capabilities of the underlying systems.

As pointed out already not all businessareas are equally well suited for successful role engineering. Frequently occurring business functions with low or medium complexity obviously promise best result to effort ratios. Those functions are most commonly found at the lower end of the traditional enterprise pyramid, where operational functions are located. Here is clearly a good starting point for role engineering. The nearer the role engineer comes to the headquarters and the more he moves up the corporate hierarchy the more difficult his task becomes. The adjacent portfolio diagram may serve as a guideline while looking for a good starting point for role engineering.

Another serious issue is related to any centralised business function: Role engineering processes, even in the above-mentioned way, are by no means real time processes. If the potential necessity of fast track changes is not properly foreseen and reflected within the administrative regulations, role engineering can easily lead to a fatal bottleneck - impeding role change means interfering with the business.

Regardless which instruments we choose, we have to face the brutal truth, that business modelling is not an easy task anyway and may offer various pitfalls on its envisioned pathway to success. But leaving these critical essential administrative processes on the currently lower maturity level is no solution.

7   Outlook

As Mazda is a cost sensitive Company, any investment has to deliver appropriate return.

By making RABC happen, we will save money. We will streamline our administrative processes. However, we don’t intend to solve all our organisational issues through the introduction of roles, rules, groups and direct assigned privileges.

We will start the introduction at the most promising organisational units - the Mazda dealerships. The dealers qualify for enjoying this advanced organisational feature first by their expected large number in combination with their expected structural simplicity while being highly exposed to public visibility - and to public and internal auditors as well.

We are strongly committed to our obligation to keep the organisational structures flexible - hence simple. This intention will guide us during role modelling and prevent us form ‘academic’ experiments.

We maintain our big vision of a highly responsive well-organised organisation based on mature controllable processes. However, in order to mitigate the inherent implementation risks we will approach it in small and controllable steps.

The project "Mazda user Management" has just started. It is still too early to summarize any successes. Please, ask us next year again - and we surely will tell you a success story.

8    Appendix

8.1     Horst Walther - Short Bio

Dr. Horst A. Walther is founder and president of the SiG Software Integration GmbH in Hamburg, Germany. He works in the field of computer science since about two decades.

Starting with the implementation of the techniques of software engineering in large software projects in insurance companies and banking institutes, he later shifted his focus on IT-Audits and IT-Strategy development.

He recently had a special focus on smooth integration of role based access control and directory services as a core element for identity management environments.

He is an acknowledged expert in processes and systems for the identity management. For this specialization became the principal advisor of the German savings banks organization, which holds the largest market share in the German financial sector. He contributed his expertise to several security related projects in the automotive sector and in German banks and published several articles.

8.2      Glossary

In this chapter, those Abbreviations or Acronyms are listed, which appear at several occurrences after they have been defined and explained once - unless they are self-explaining or expected as commonly known.

Table 1: Acronyms

Acronym
Expanded Term
ACL
Access Control List
AD
Authorised Dealer
AR
Authorised Repairer
B2B
Business to Business
B2C
Business to Consumer
BER
Basic Encoding Rules
CCITT
Comité Consultatif International Téléphonique et Télégraphique
CMA
Central Marketing Area
COM
Component Object Model
CRM
Customer Relationship Management
DAC
Discretional Access Control
DBMS
Database Management System
DSD
Dynamic Separation of Duties
ID
Independent Distributor
IMT
Independent Motor Trader
ISO
International Standards Organization
LoB
Line of Business
NIST
National Institute of Standards and Technology
MAC
Mandatory AccessControl
MC
Mazda Corporation
MLE
Mazda Logistics Europe
MLS
Multi Level Security
MME
Mazda Motors Europe
MRE
Mazda Research Europe
NSC
National Sales Company
OASIS
Organization for the Advancement of Structured Information Standards
OS
Operating System
OSI
Open Systems Interconnection
PKI
Public Key Infrastructure
POP
Post Office Protocol
RBAC
Role Based Access Control
RDBMS
Relational Database Management System
SAML
Security Assertions Mark-up Language
SoD
Separation of Duties
SSD
Static Separation of Duties
W3C
World-Wide Web Consortium
XACML
eXtensible Access Control Mark-up Language
XML
Extensible Mark-up Language

8.3  References


Literature

Contact

Dr. Horst Walther
SiG Software Integration GmbH
Chilehaus A * Fischertwiete 2
D-20095 Hamburg
Fon: +49 40 32005 439
Fax & Voice-Mail: +49 40 8708306 8
Mobil & Voice Box: +49 171 2145502
VoIP (SIP): +49 40 414314453
VoIP (Skype): HoWa01
E-Mail: Horst.Walther@Si-G.com
www.Si-G.com

Horst Walther, Hamburg