The security industry is feeling the impact of two major trends: globalization and ongoing technological development. Multinational enterprise, convergence of IT and physical security systems, compliance issues and legislation - all are influencing access control systems. Nedap is responding to and incorporating these trends into its products. Time for a look at today's challenges and how AEOS is being adapted to them.

Much has been written in the past ten years about convergence or unification: the merging of information (IT) security and physical security systems. Just one of the many benefits of convergence would be an improved capacity for dealing with disparate compliance regula- tions and national and international legislation. Although several big players have tried to develop all-encompassing systems that integrate, or bridge the gap between, IT security and physical access control systems (PACS), most large corporations still deploy the two separately. This is partly the legacy of the past. Physical security was traditionally a local, site responsibility. This left today's large multinationals with a wide variety of PACS in different countries. Decentralized decision-making on physical security has in fact hampered attempts at unification.

Call for Ready-made Solutions
In today's uncertain economy, most major enterprises are cutting costs and reorganizing to boost operational efficiency. Facility management divisions are being asked to support processes such as asset management, IT infrastructure and security. This shift is generating a strong demand for unification and policy-based systems: essential tools for gaining global control and servicing primary business processes at a fair cost. There is a great demand for Commercial Off-The-Shelf (COTS) products which can encapsulate legacy systems. A degree of customization is accepted, but developing new tailor- made systems to support secondary business processes is seen as a bad business decision.

Calls for unification and policy-based security governance have grown steadily louder. These appeals are now being heard from global business domains outside IT security and physical access control. Stricter compliance regulations and industry-specific laws in finance, healthcare, manufacturing, pharmaceuticals, travel, transport and energy have spread the need for the integration of multiple systems.

Service Oriented Architecture
In our industry, this shift is clearly observable in today's RFI/RFP documents, all of which call for integration of security systems in a Service Oriented Architecture (SOA) of some kind. Some global enterprises have already introduced an Enterprise Service Bus (ESB), implemented in combination with rule engines, business process modelling engines (BPM), and extensive workflow model- ling. More recently, work has been done on the use of business operation platforms that incorporate a service bus but also take things further, towards ideas like the Internet of Things (IoT), the Semantic Web or Web 3.0. The common denominators in these last three movements are: enabling cross-domain service integration, improving usability, delivering true online business operations and decreasing human interventions by adding intelligence.

The information industry has been dealing with calls for integration for much longer and has learned to use open standards, to hide legacy systems behind service interfaces, and to minimize service dependencies by using Loose Coupling and the principle of Separation of Concerns. The security industry could learn a great deal from this.

Impact on Access Control
Now let us turn our attention to a core aspect of physical security, Access Control, and analyze how these trends - globalization, unification and the use of open standards - impact the architecture of access control systems.

A common domain model in access control systems is that of an abstract subject that wants to gain access to an object. The subject first needs to authenticate itself (based on what it has, what it knows or what it is), after which the access control decision is evaluated based on the identity of the subject and the active policy governing access to the object. The policy typically includes business (security) rules and date/time aspects, and often uses some distinguishing characteristics of the subject, e.g. employee vs. visitor.

Access Control Models
The access control model identifies whether a subject is authorized to access or perform a certain action on an object. In physical access control, the object is usually a physical space, e.g. a room, a parking lot or a locker. (In the system architecture, these objects are referred to as resources.) Here, authentication of the subject (e.g. a person) is usually carried out using an electronic RFID card. In high-security environments, this authentication is supplemented by a PIN or biometric characteristic.

Mainstream PACS usually make use of an Access Control List (ACL) model. This means the access control model is based upon a simple list of authorized subjects for different access points at specified dates/times. The ACL model is well-suited to create fine-grained permission structures, but the downside is its mushrooming complexity as the number of subjects and objects grows.

Reducing Complexity
A slightly more sophisticated approach, aimed at reducing complexity, is the Role Based Access Control (RBAC) model. In this structure, the complexity of assigning permissions to users is overcome by introducing a level of indirection, i.e. a role, which clusters access rights to certain objects. The subject's role in the organization is used to evaluate its access to an object. Although the RBAC approach seems more usable, it is less suitable for fine-grained permission modelling. In many organizations, role engineering appears to be extremely difficult. Attempts to circumvent the built-in coarseness of the permission model tend to result in so-called role explosions. These make the system virtually unusable. It is worth noting, however, that ACL-based access control systems become unwieldy much sooner than RBAC-based systems when the organization grows or the number of factors affecting access rules increases.

ABAC Model
In information security, the drawbacks of ACL and RBAC have not gone unnoticed. This has led to the introduction of an Attribute Based Access Control (ABAC) model. In this model, a subject's access rights depend on the attributes describing this subject, e.g. age, possession of a valid driver's license, security clearance, etc. Such dependency is expressed in rules, which may be combined into policies, which, in turn, may be clustered in policy sets.
A simple example of a rule would be "to enter this amusement park the subject has to be at least x cm. tall". To express such rules, an XML-based language was developed. OASIS recently published the XACML 3.0 language standard, aimed at standardizing access control models using ABAC. ABAC offers great flexibility and fine-grainedness, but these benefits come at a price: in ABAC it is easy to lose sight of the maximum permission set for a given subject. That is, it is impossible to answer a question like "Is subject A allowed to enter a chemical lab?" until subject A actually tries to enter such an object.

Dilemma
ABAC is well-suited for open systems, such as libraries, car-rental offices, video stores and open Wi-Fi networks, where neither the identity of a subject, nor the state of an object or the environmental circumstances are known beforehand. However, openness is not the norm in the physical security industry. And yet some pioneers, like the Open Group, have broken with tradition. By publishing its Open Enterprise Service Architecture (O-ESA), the Open Group is trying to encourage the use of industry best practices in defining organizations' global security models. The physical security industry clearly faces a dilemma.
Should we follow in the footsteps of IT security, open up the controllers, implement open standards like XACML and become (web)service providers in the Identity and Access Governance (IAG) domain? Or should we stubbornly resist the unification of information security and physical security?

Best of Both Worlds
At Nedap, we have decided to do both, and more. AEOS's technology roadmap is aimed at improving usability and scalability in combination with policy-based security governance. The AEOS platform will be adapted to enable cross-domain integration in global enterprise (SOA) environments. At the same time, it will provide the best policy-based access control models, a modern service lifecycle model and state-of-the-art IPv6-based security devices. The security architecture will be based on the latest encryption technology using Secure Application Model (SAM) devices and network-based key revocation methods. The access control model proposed by Nedap is a hybrid model combining the strengths of RBAC with the flexibility of ABAC. One simple example can illustrate the power of this approach compared to a purely ACL, RBAC or ABAC-based model.

Consider a multisite company with employees who regularly travel between company sites. Every site has its own PACS, but both identity and access rights are enforced automatically by global regulations. In an ACL-based system, each individual object would have to be assigned a list of authorized employees. Besides the obvious fact that this approach will fail in any large-scale company, there are other problems, such as a high risk of malicious assignments, made possible by the Segregation of Duties. For example, a dishonest security officer could add himself to the list at any resource.
So it might seem better to use the RBAC model, based on the employee's work role in the organization. RBAC addresses the Segregation of Duties problem by only allowing assignation of either subjects to roles or permissions to roles. However the risk of role explosion becomes apparent as soon as highly fluid factors are included in the role definitions. Using the ABAC model would prevent role explosion, as ABAC makes it possible to combine any number of fluid factors by introducing appropriate policies at resources. However, the ABAC drawback mentioned earlier still stands: the model effectively hides a subject's actual permissions.

Hybrid
AEOS uses both RBAC and ABAC, benefiting from the advantages of both models. RBAC provides the necessary level of coherence and transparency for overall security policies, while ABAC adds flexibility and minimizes the risk of role explosion. In this hybrid model, an employee's role describes optional permissions necessary for them to fulfil their duties, while rules and attributes identify for each individual whether a permission becomes unconditional or must be withdrawn. A simple example would be the pair: Role-Manager and Attribute-Location.

The intelligence in this approach lies in the fact that the location list can be used to evaluate the PACS to which identity information needs to be distributed. This improves performance and scalability. At the same time, knowledge about the PACS configuration is hidden from the users, so data entry interfaces can be based on business process language (role, location). This improves usability. And finally, these meta-access rights can be mapped automatically to any PACS that has some form of import module. This supports the encapsulation of legacy PACS into the policy- driven security architecture. In short, Nedap is ready to deal with the challenges posed by globalization, unification and the trend towards open systems. With our hybrid model and the technological developments planned for AEOS, we can ensure that we will continue to deliver a future-proof product to our customers.