why access control is difficult

Steve Purser

Senior Manager IT Security,Clearstream Services, 5 RueHoehenhof, Senningerberg,L-2963 Luxembourg

Founder Member of "Clubde Sécurité des SystèmesInformatiques auLuxembourg (CLUSSIL)"

Introduction

Together with authentication, and in particularpassword-based authentication, authorizationand access control have traditionally been thecornerstones of the IT security approach.However, despite the undeniable importance ofthese techniques, achieving a satisfactory levelof control in this area is still one of the majorchallenges facing today’s IT security manager.

In this article, the term access control refers tothe process and mechanisms by which access toIT systems, functionality and data is managed.This includes the request for creation,modification and/or suppression of accounts andassociated access rights, the approval of suchrequests, their implementation and verification.The term authorization is used to refer to theworkflow and decision by which changes to theexisting structure of access rights are granted.Authorization is therefore a part of the accesscontrol process.

Whilst access control is one of the easiest ITsecurity concepts to understand, theimplementation of an efficient and scalableapproach to access control, which is capable ofhandling the complexities associated withmodern, highly distributed IT environments, isextremely difficult. In particular, the traditionalapproach to access control, involving thedefinition and management of highly granularaccess rights on a large number of independentplatforms, does not scale well and will notenable most medium to large-sized companies tosatisfy future requirements.

The major problem associated with deploying atraditional approach to access control withinmodern IT infrastructures is that this approachdoes not take account of the distributed natureof such infrastructures. As a result, each

platform is considered as an independentcollection of resources (processes or data) whichcan be protected in isolation of the surroundingenvironment. Access rights are requested,approved and verified on a system by systembasis, using a variety of concepts and notations,which can lead to problems of coherence (suchas access to a resource being denied via oneapplication but permitted by another). Inaddition, a complex workflow combined withthe necessity of using manual procedures oftenresults in backlogs, which increases the pressureon security administrators and can lead tomistakes.

In this article, several problems associated withthe traditional approach to access control areidentified, and the following possible areas ofimprovement are discussed:

• Setting achievable policy goals.

• Achieving a balance between granularityand control.

• Defining and agreeing roles andresponsibilities.

• Using an architectural approach.

• Centralizing access control data

• Implementing an efficient workflow process.

• Defining and implementing an appropriatetechnical infrastructure.

• These issues are analyzed in detail andpossible solutions are presented.

Problems with the traditionalapproach

The traditional approach to access control is tomanage access rights on a system-by-systembasis. The major assumption underlying this

Why access control is difficult

303

approach is that systems are independent ofeach other and any dependencies can bemanaged using well-defined procedures. Thisapproach suffers from a number of importantdeficiencies, which can be classified into threedistinct areas; organizational issues, technicalissues and procedural issues.

Organizational Issues

True security is rarely based on purely technicalsolutions. Whilst technology plays anincreasingly important role in controlling IT-related risk, this is usually only an effectivestrategy insofar as there is a correctly designedorganizational and procedural framework tosupport the technical components. A scalableand efficient approach to access control mustbe capable of resolving the followingorganizational issues:

• Current methods for representing accessrights are difficult to understand forparticipants in the control process who donot have the required technicalbackground. This is particularly true forthose who approve and verify access rights.

• In traditional environments, securityadministrators tend to specialize in aparticular type of technology. This is anatural consequence of managing accessrights on a platform by platform basis. Thisresults in increased costs due to the need toretain a wide range of skill sets within thesecurity administration team.

• Organizations using a data-centric approachto access control may experience problemsin mapping access rights to specific groupsof data. This is particularly true whereapplications are written to access severalsources of data, belonging to different dataowners. Such data is often visible in variouscombinations using database querylanguages, rendering the approval processcomplex and difficult to manage.Equivalently, many applications are

designed to control access to functionality,rather than data. Under these conditions,the approval model may break downcompletely or, at best, be extremely difficultto maintain.

• As a result of the issues presented above,response times to users will increase slowlyif the underlying problems are notaddressed. If the level of staffing remainsconstant, there is a risk that this will impactcore business processes.

Technical Issues

The traditional approach to access control isassociated with a number of technical problems,which are becoming harder to address assystems become increasingly distributed.

• The assumption that systems areindependent of each other is increasinglyless valid as we move from centralizedarchitectures (such as the traditionalmainframe infrastructure) to highlydistributed architectural models (such asJ2EE and CORBA). In addition, modernapproaches to developing distributedsystems tend to hide the location of thedata. This is known as locationtransparency and the objective is to allowthe free movement of executable codebetween systems.

• Not only is it difficult to treat modernsystems as isolated units, securityframeworks for modern architectures areoften designed to span multiple platforms.An example of this approach is provided bythree-tiered architectures using connectionpooling to access the database. Here, it iscommon for an application to access thedatabase using a single user account and tomultiplex requests for access over a fixednumber of database connections. Underthese conditions, access to the database istypically controlled by the application or byits associated middleware component.

304


Steve Purser

• Access rights are generally maintained atdifferent ‘software levels’. The mostfundamental level is the operating systemlevel, but access rights are usually set at thedatabase and application level as well. Thissituation results in considerable complexity(see Figure 1). Whilst it is possible to treataccess rights at different levels as beingindependent of each other, this can lead toinconsistencies. A simple example would bean access control scheme, which tried toprevent the UNIX root account fromaccessing an application on the samemachine (the UNIX root account is all-powerful and can access any object on thesystem without restriction).

• There is no universally accepted model forrepresenting or enforcing access rights.Operating systems, database and applicationsoftware deploy highly specificrepresentations and, in general, theserepresentations are not transportable fromone type of operating system to another.

Procedural Issues

Current procedural issues include:

• There is usually no consolidated view ofaccess rights which covers all platforms.The data relating to any individual isdispersed over several systems.

• Most access control systems technicallypermit the setting of extremely granular

access rights. A common practice is to setsuch access rights at the file level. Thismodel does not scale well and can quicklybecome unmanageable.

• The workflow associated with requesting,approving and implementing access rightsmay be cumbersome due to the number ofdifferent participants in the process.Whereas the workflow for approving accessrights for new staff and deleting accessrights for departures is usually relativelystraight forward, handling internal jobrotations is often quite complex. This is dueto a number of factors, including the re-negotiation of transfer dates and thepossible requirement for the staff member toprovide extended support to the unit he/sheis leaving.

• An inappropriate workflow process canresult in long delays and dissatisfied users. Ifthe origin of an approval bottleneck is notknown to the end-user, he/she will oftenphone the security administrator directly,which results in increased delays for otherusers and a rapid degeneration of the wholeprocess.

• Procedures are used to ensure consistency,but these procedures tend to be slow andmay be circumvented in situations requiringa rapid response.

In analyzing these issues, it is clear that anyapproach to managing access, which is capableof providing real control, must be relativelysimple. In other words, real control can only beattained if all actors are aware of the risksassociated with inappropriate access control andthe way in which these risks are mitigated.Whilst it is not difficult to understand thethreats, it is often extremely difficult toappreciate to what extent the technical andprocedural framework is responding to thesethreats and therefore (in qualitative terms) toappreciate the residual risk which is beingaccepted.


305

Steve Purser

Database Middleware

Operating System

Application

Figure 1: Security layers

Guidelines for a new approach

This paper identifies the following areas asstrong candidates for reducing complexity andconsequently increasing control:

• IT security policy, including roles andresponsibilities.

• Structure of access control data.

• Architectural approach.

• Centralization of access control data.

• The approval process and associatedworkflow.

• Technical infrastructure

These areas are discussed below.

Policy considerations

The security policy should be concise,unambiguous and easy to understand. In thearea of access control, the policy should provideclear guidelines in the following areas:

GranularityAny statements relating to granularity of accessshould be checked to ensure that they arereasonable. Modern IT architectures potentiallydeploy millions of distributed objects. Whilstoperating system and support software aretechnically able to support granular access atthis level, this is only useful if the supportingprocesses are capable of handling such granulardata.

OwnershipThe policy should clearly identify therequirement for ownership of resources. Theowners will then be responsible for authorizingaccess to the resources they own. Most ITsystems allow access to be granted to data (e.g. afile), to functionality (e.g. a program), or toboth (e.g. a transaction). Hence, it is possible todefine a schema of ownership based on data(‘Data Owners’) or on functionality(‘Application Owners’) or potentially both. It is

recommended that the ownership schema bedesigned so as to simplify the authorizationprocess and associated workflow. As anexample, for organizations having applications,which draw on data from several sources, anownership schema based on applications may bemore appropriate in order to avoid lengthychains of authorizations. The extent to whichthis is achievable in practice may be limited byregulatory or legal restrictions, such as arequirement to identify Data Owners, but evenhere it may be possible to use a more practicalschema by using a formal delegation of approvalrights.

Roles and responsibilitiesThe policy should clarify all roles andresponsibilities relating to the access controlprocess. Whilst this should be relativelystraightforward for the core process, certaintypes of access will probably require specialtreatment involving different actors. Inparticular, any type of privileged access (such asthe ‘root’ account on UNIX systems) shouldpreferably be authorized by someone aware ofthe consequences of providing such access.Whereas the IT security unit is an unlikelychoice for approving access to business data, itmay make sense to delegate the approval to useprivileged accounts to this unit.

Special considerations for test anddevelopment environmentsIf test and development environments arecorrectly segregated from the productionnetwork, it is worth considering implementingless stringent procedures in these environmentsin order to facilitate the development process.

Structure of access control data

The structure of access control data tends to bedictated by the platform and software used toimplement the application. However, there areseveral ways in which this low-levelinformation can be structured into somethingmore meaningful and easier to manipulate.

306


Steve Purser

• Use of naming conventions at the systemlevel.

• Compartmentalisation of data by usingappropriately designed directory structures.

• Use of third party tools and/or meta-directories to define cross-platform accessprofiles.

• Use of IT Security standards to ensure thattechnical implementations on differentplatforms are based on similar technicalguidelines and follow similar namingconventions where possible.

When restructuring access control information,it is useful to bear in mind the following generalprinciples:

• In the long term, it may be possible togreatly simplify the administration processby putting the expertise into developingprofiles rather than with the administrator.This reduces the dependency on the skill ofthe administrator and ultimately reducescost.

• In some cases it may be sensible to reducethe level of granularity of access in order toproduce an access schema, which is easier toadminister. This should result in morecontrol even though access rights will bemore permissive (as they will be controlledmore efficiently). Indeed, this approach maybe necessary in order to reduce thecomplexity of the overall system to anacceptable level.

• In reducing complexity, the access controlprocess will be easier to understand for non-technical decision makers. This increasedtransparency will improve the quality of theapproval process and facilitate regularchecking of access profiles.

Architectural approach

In order to correctly control access rights in adistributed environment, it is necessary to have

a view of access control data, which spans allcomponents. In the traditional approach, it isnecessary to construct such a view by manuallyconsolidating data taken from a variety ofplatforms — a process, which is both error-prone and time-consuming.

One way to deal with this problem is tocentralize access control data and make itavailable through a Unique AdministrationInterface (UAI). This might be achieved usinga dedicated software solution or by creating andmaintaining a meta-directory to hold the data.Depending on the platforms and softwarepackages supported by the selected technicalapproach, this produces a multi-platform viewof the access rights held by any individual. Anarchitectural view of access control data reducesthe risk of error by helping the administrator torecognize and eliminate inconsistenciesbetween access rights on different platforms.

In addition, the ability to manipulate data fromseveral platforms via a single interface results incost efficiencies and quicker turnaround timesfor the end-user. In the long term, it may bepossible to achieve even greater cost efficienciesby re-structuring data from legacy systems intobusiness profiles, which span many systems. Byusing a sensible naming-scheme, this approachprovides a solution to the problems associatedwith data representation. However, this is likelyto be a long and complex activity and isprobably best carried out as a second phase oncedata consolidation has been achieved.

Implementing an efficient workflowprocess

The workflow is often the rate determining stepin the access control process. Possibilities foroptimising workflow include:

• Verifying that the roles and responsibilitiesestablished by the Security Policy arecorrectly implemented. In particular,approvers should be aware of the scope oftheir responsibility and the tools at their


307

Steve Purser

disposal to accomplish it. Approvers shouldpreferably be at the management level, butnot senior management (due to problems ofavailability). If policy dictates that seniormanagers must be responsible for approvingaccess, a formal scheme of delegation mayprovide a practical solution to this problem.All approvers should have named backupsto cover periods of sickness and otherabsence.

• The approval workflow should be welldocumented and available to allparticipants, especially end users. Thisworkflow should be complete in that itshould cover all known scenarios (e.g. jobrotations, maternity leave and authorizationof privileged accounts), whilst stillremaining easy to understand.

• In order to prevent long delays, the numberof approvers required to completely approvean access should be minimized, but aminimum of two is recommended toprevent the accumulation of rights (e.g. theline manager of the requestor and theapplication owner).

• It might make sense to define a defaultprofile to which everyone has access and toprovide this access automatically to all staff.This could provide access to essential tools(such as office automation facilities) untilmore specific access is granted.

• The establishment of a Service LevelAgreement defining standard turnaroundtimes and how to proceed in the event ofreduced service will decrease the pressure onadministrators. It may be helpful to define a‘degraded mode’ of operation to coveremergencies. If this is done, it is importantto define how a move to degraded mode willbe signalled to users.

• Deployment of a workflow tool can bringbenefits, especially if the tool allows theuser to visualize the state of his/her request.

This ensures that any questions areaddressed to the correct person, rather thanhaving all users converge on the IT securityadministrators.

Technical infrastructure

The technical infrastructure supporting theaccess control process is of critical importanceas this infrastructure determines to what extentaccess data can be centralized and workflow canbe automated. Most current approaches tocentralizing access control data can be groupedinto two classes:

• Centralization of data using a meta-directory.

• Use of a dedicated product for administeringaccess control data.

The meta-directory approach has the advantageof enabling further consolidation with dataunrelated to access control. However, theadvantages of consolidating security data withother administrative data need to be weighedagainst the disadvantages. For instance,combining data may make it more difficult toapply an appropriate level of security to theaccess control data itself. Similarly, such anapproach may render the overall data schemaextremely complex, whereas complexity is oneof the factors we are aiming to reduce. Themajor disadvantage of the meta-directoryapproach is that it is not tailored to solve theproblems associated with the management ofaccess rights. Hence, it may be necessary todevelop a lot of functionality in-house usingscripting languages. This in turn leads to a non-standard product and raises maintenance issues.

There are several solutions in the marketplacedesigned to permit centralized management ofaccess control over multiple platforms. Themore sophisticated products support mostcommon operating systems and some offersupport for ERP systems and databases. Theseproducts are also starting to support integratedworkflow functionality and provide a good

308


Steve Purser

approximation to the concept of a UniqueAdministration Interface. It is important tonote however that the number of platformssupported is limited (and therefore that certainplatforms cannot easily be integrated into sucha scheme). Similarly, whilst several of thesepackages provide APIs for enablingapplications, this is likely to be a complex andexpensive undertaking.

The approach taken depends largely on thegoals and the security stance of theorganization. The important point is that bothapproaches provide a technical basis fortransforming the access control process from asystem-centric approach to an architecturalapproach.

Conclusions

Whereas many organizations have implementedstate-of-the-art IT architectures to support theirbusiness processes, methods for managing accessrights in distributed systems have remainedlargely unchanged over the last few years. Thisis problematic due to several reasons:

• Modern IT architectures are extremelycomplex and it is becoming increasinglydifficult to administer access control in suchenvironments using a system-by-systemapproach.

• This difficulty manifests itself in a variety oforganizational, technical and proceduralissues, which are difficult to resolve using atraditional approach.

• By focussing on individual systems it is hardto appreciate the level of security associatedwith the architecture as a whole. This maylead to a global access schema, which isincoherent, and possibly undetected securityincidents.

A more appropriate approach for distributedarchitectures is based on the followingprinciples:

• Genuine control is more important thangranularity.

• Access control data should be centralized soas to provide a complete image of accessrights across the enterprise. This will helpeliminate incoherent access rights andprovide a global view.

• The approval process and workflow need tobe optimized. This involves not onlydefining and agreeing clear responsibilitiesbut also providing access control data insuch a way that it is easily understood andmanipulated. The approval of privilegedaccounts should be carried out bytechnically aware individuals.

• Special attention should be given tocomplex procedures, such as job rotationsand extended leave of absence.

• User expectations can be controlled bydefining and agreeing a Service LevelAgreement.

• The technical infrastructure should becapable of supporting the architectural viewby providing the facilities to view andmanipulate cross-platform access controldata.

Finally, the technical infrastructure shouldenable the administrator to ‘drill down’ on thelevel of detail provided for any particularsystem, which then provides the traditional‘system view’ of access.

References

[1] See for example the evolution of CERT statistics onvulnerabilities reported for the period 1995 until 2001(http://www.cert.org/stats/cert_stats.html#vulnerabilities)


309

Steve Purser

why access control is difficult

Documents