designing physical security for complex infrastructure.pdf

Available online at www.sciencedirect.com

www.elsevier.com/locate/ijcip

i n t e r n a t i o n a l j o u r n a l o f c r i t i c a l i n f r a s t r u c t u r e p r o t e c t i o n 7 ( 2 0 1 4 ) 1 7 8 – 1 9 2

http://dx.doi.org/10.1874-5482/Crown Co

nCorresponding aE-mail address: R

Designing physical security forcomplex infrastructures

Rick Nunes-Vazn, Steven Lord

National Security Science and Technology Centre, Defence Science and Technology Organisation, PO Box 1500,Edinburgh 5111, SA, Australia

a r t i c l e i n f o

Article history:

Received 25 June 2013

Received in revised form

10 February 2014

Accepted 27 June 2014

Available online 2 July 2014

Keywords:

Critical infrastructure

Physical security

Security-in-depth

Design

Risk management

1016/j.ijcip.2014.06.003pyright & 2014 Publishe

[email protected]

a b s t r a c t

This paper uses security-in-depth principles to provide practical guidance for the design of

physical security in complex infrastructures. Working from the central tenet of security-in-

depth, that the strength of security comes from the coherence of the entire security system

rather than just the technical excellence of sub-systems, a practical framework is

constructed for assessing the risk reduction of an infrastructure security design proposal.

In this way, alternative proposals may be evaluated for their effects on the overall security

risk to a system, taking into account a broad threat and hazard space. The approach

includes explicit consideration of organizational factors and management structures,

ensuring that the design is consistent with enterprise objectives as well as internal and

external policy and legal constraints.

Crown Copyright & 2014 Published by Elsevier B.V. All rights reserved.

1. Introduction

As the complexity and interconnectedness of physical infra-structures increase, the difficulties associated with designingeffective physical security also rise, perhaps more steeply.Security [23] has always been a compromise between “lockingthe system down” to deny the opportunity of abuse andmaintaining a viable and effective business [24]. However,designing effective, value-for-money security involves anotherset of trade-offs that are less well understood. These are thetrade-offs between alternative security system designs basedon their contributions to risk reduction. Translating strategicsecurity objectives into wise or even agreed choices betweeninvesting in (figuratively) more cameras, more guards, higherwalls or stronger doors is a challenging design problem.

We contrast this contribution from other works (e.g.,[7,8,33]) that use risk to assign rankings of protection priority

d by Elsevier B.V. All righ

nce.gov.au (R. Nunes-Va

to multiple infrastructures in order to minimize the aggregate(expected) risk to all facilities. Our purpose here is to supportthe risk-based design of security for a single infrastructureassuming that, through other processes (e.g., [28]), the deci-sion to enhance physical security against internal or externalmalicious attack has already been made and justified. As aresult of the challenges to security design noted above and, inthe absence of a useful (and simple) security risk evaluationframework, typical practice has tended to rely on threeapproaches that largely avoid tackling the problem directly.Each is acknowledged to be imperfect and, in some cases, hasbeen shown to diminish the effectiveness of security [7,24].

The first approach, which we call “plugging the hole,”involves retrofitting the system to manage vulnerabilitiesexposed by successive security incidents. This could be seenas characterizing the response of aviation security to thehijackings of the 1970s, the events of September 11, 2001, the

ts reserved.

z).

http://dx.doi.org/10.1016/j.ijcip.2014.06.003




http://crossmark.crossref.org/dialog/?doi=10.1016/j.ijcip.2014.06.003&domain=pdf

mailto:[email protected]


i n t e r n a t i o n a l j o u r n a l o f c r i t i c a l i n f r a s t r u c t u r e p r o t e c t i o n 7 ( 2 0 1 4 ) 1 7 8 – 1 9 2 179

shoe-bomber in 2001, the underwear bomber in 2009, etc. Therisk reduction benefit of particular security sub-systems mustbe assessed in relation to a plausible spectrum of potentialsecurity incidents, not just the incidents that have occurred.

The second approach, which might be termed “more isbetter", involves appending another “layer” to the securitymatrix [31]. Quite apart from the confusion in the literatureabout the meaning of the term “layer” (which we addressbelow), security-in-depth analyses [20,23] have shown that itis better to have fewer layers if investment can make thelayers stronger.

The third approach, which we call the “silver bullet” solution,involves investing in high performance technologies withinsub-components of the security system. Security-in-depth prin-ciples [20] indicate that investment should be focused on theweakest function (e.g., detection or response) in a critical layer. Ifthe response is weak, then investment in state-of-the-art scan-ning equipment to further enhance detection is not a wiseinvestment [14].

Why are these workarounds used? Principally, it isbecause of the inherent complexity of the problem. Weconsider the challenges in terms of three types of complexity.The first type of complexity involves the breadth, diversityand adaptivity of the threats and hazards that the systemmay face in the future, and the fact that the effectiveness ofeach control depends on the particular threat and its context.The second type comes from the fact that controls havevarying degrees of interdependence (e.g., CCTV, monitoringstaff, movement sensors and guards are strongly interdepen-dent), which means that assessing the risk reduction orbenefit-cost of possible additional controls can be difficult.The third type of complexity arises from the need for allstakeholders, from the risk owner through the various levelsof management, possibly down to the system operators, to beinvolved and contribute to security design deliberations[9,29]. Broad involvement and ownership is necessarybecause the design process must strike a balance betweenconsiderations of technical performance, usability and stra-tegic security value.

Accepting these challenges to effective security design, thispaper describes a set of structured templates that are intended toguide and facilitate security design discussions. Using theprinciples of security-in-depth, the process is intended to takeinput from and develop ownership within the broad group ofstakeholders, while ensuring that the decisions remain trans-parent and traceable. The aim is to create a practical toolset forsecurity practitioners involved in security system design or re-design. Using this approach, each incremental enhancement ofthe security solution will be justifiable on the basis of (i) itsrelative (value-for-money) contribution to security risk reductionand (ii) its ability to manage the risks that are identified by riskowners and stakeholders as their primary concerns.

The design process is illustrated through the developmentof example solutions to manage a hypothetical terrorismattack on an infrastructure site or facility. The paper showshow security solutions are progressively built by consideringpathways to harmful events and how packages of controls(in “layers” defined below) are developed to change theprobabilities of the events. The paper then develops othercontrol packages to reduce the potential consequences of the

events. Each stage in the design process is supported withgeneric, transferrable templates that are intended to helpdeliver a cost-effective, coherent and complete securitysolution.

In addition to the objective of facilitating a more effectivesecurity system design, this paper considers the less tangibleaspects of security [17] that, nevertheless, underpin its effectiveoperation. These aspects, which include system maintenance,staff training, policy development, etc., are termed enablers, andtheir absence or inadequacy can be just as detrimental to thedelivery of effective security as the failure of security controls.

This paper is structured as follows. Section 2 provides a briefreview of security-in-depth principles. Section 3 uses a hypothe-tical infrastructure security problem as a vehicle to generate aseries of templates intended for use in security design orenhancement discussions in any complex context. Section 4discusses security system enablers and where they fit into theoverall framework. Section 5 reviews the strengths and limita-tions of the approach. Section 6 presents the conclusions.

2. Security-in-depth framework

Because the security-in-depth framework lies at the core ofthe approach, it is important to provide a brief overview of itsprimary tenets. Nunes-Vaz et al. [20] have proposed a hier-archy of terms to describe security-in-depth or layeredsecurity. Referring to Fig. 1, a security control, or a physical,procedural technical or other device contributes to the per-formance of one or more security functions, such as detec-tion, response or decontamination. Security functions arecommonly performed by several interconnected controls.A simple threat detection function might involve a guardwatching for people who jump over, and therefore bypass,swipe-authorization entry gates.

Although a function such as detection might be performedperfectly, no risk reduction is achieved unless actions tomanage the detected threats (e.g., entry denial) also occur.Note that risk is assumed to be a function of the conse-quences of a harmful event and the likelihood of the con-sequences eventuating. Risk is reduced by reducing thelikelihood and/or consequence. For this reason the term“security layer” is reserved to represent the integratedarrangement of controls that could either stop a harmfulevent, or preclude its consequences (see Fig. 1). In this way,only security layers explicitly manage security risk.A poorly integrated set of security controls may fail to createlayers and, therefore, fail to manage security risk.

It is argued in [20] that physical security systems should bedescribed in terms of four layers: deter, prevent, protect andcontain. These are shown together in the common “bow-tie”diagram [29] in Fig. 2. The deter and prevent layers serve toreduce the likelihood of a potentially harmful event. Deter islargely passive and relies on the attacker's perception of security,which is primarily influenced by his/her knowledge of, orassumptions about, actual security strength (as well as theseverity of sanctions). Prevent is an active combination ofsecurity functions that usually include detect, alert, respondand impede. In general, each layer acts serially, that is, either anattacker is deterred and prevention plays no part (other than

Fig. 2 – The four layers of a physical security system from [20] in a “bow-tie” diagram linking threats to consequences. Partialbarriers shown inside the layers represent controls and their individual inability to halt the progression of scenarios towardthe right-hand side of the diagram.

Fig. 1 – A hierarchical security construct from [20], where the security controls contribute to the performance of securityfunctions, which are themselves integrated into coherent constructs called security layers. Only security layers reducesecurity risk.


inside the attacker's head) or the attacker is not deterred andprevention comes into play.

When an attack is neither deterred nor prevented, theprotect and contain layers act to reduce the event's conse-quences. Here again, protect is largely passive and relies onthe pre-deployment of controls, for example, landscaping andblast shields to protect a fixed infrastructure from vehiclebombs [4], or the vaccination of populations under threatfrom bio-agents. Contain is an active layer that demandsaction to mitigate harm such as alerting first-responders,isolating hot zones and managing casualties.

The key advance represented in the security-in-depthframework is that it provides a means to understand thenature and strength of layering (in risk reduction terms), and

hence a basis for making wiser investment decisions. In anygiven layer, enhancement should be focused on the weakestfunction. Thus, if the probability of detecting a breach isrelatively high, then investment in the prevent layer shouldbe focused on the alert and response functions.

The independence of layers means that the adversary mustdefeat each layer sequentially (i.e., if not deterred, then ideallyprevented; if not prevented, then assets may be protected; if notprotected, then the harm may be contained). Each layernaturally performs better against some threats than others(deterrence may be a more effective layer with respect to non-violent crime than it is against terrorism), providing a means toinform investment allocated to each layer according to thethreat spectrum that must be managed.


Security enablers such as training, policies, protocols andreporting structures have generated significant confusion inthe literature, principally in terms of how they should beweighed in the mix with the security controls themselves.The framework described here provides a mechanism toidentify, situate and prioritize these additional, crucial com-ponents in security design.

3. Designing a security system

With a foundation of security principles to work with, wenow aim to apply these principles to a notional infrastructuresystem and, in so doing, build a number of generic tools tofacilitate stakeholder discussions during the security designprocess. By stakeholder, we mean those who have a stake inpurchasing, operating and managing the system, plus thosewho are in some way affected by its introduction oroperation.

We start with a hypothetical facility or infrastructure thatis required to reduce the risk associated with a range ofthreats to its physical security. Any such facility can bevisualized as a nested arrangement of zones shown schema-tically in Fig. 3. The entire system may represent a singleconstruction, housing secure rooms with more secure safes,or it might be an extensive infrastructure site (e.g., powergeneration and distribution) with many secure sub-areas andbuildings. In some cases, the outermost perimeter may benotional rather than physical, for example, at airports where(generally) the public has unimpeded access and patrollingguards concern themselves only with suspicious or poten-tially dangerous behaviors.

Using the bow-tie construct of Fig. 2, we illustrate how tocreate effective security layers to manage the pathways fromthreat to consequence. Leaving the deter layer until later, we

Fig. 3 – A conceptual facility with nested security zones. It conscommon area sub-systems. The levels of security indicated areinstead of absolute in national security terms.

focus initially on preventing acts of harm from non-deterredattackers. The implementation of a prevent layer is achievedthrough the use of up to three replicated sub-systems,namely access, perimeter and common area sub-systems(see Fig. 3). Each of the sub-systems may be characterizedin functional terms. For example, a primary access sub-system (Fig. 4) may be characterized by a set of connectedcontainers representing the primary security functionsdetect, alert and neutralize that, together, complete theprevent layer. Initially empty (as shown in Fig. 4(a)), thecontainers are progressively populated with controls duringthe design discussions.

Fig. 4 illustrates the kind of process that should occurwhen developing solutions for a sub-system. In this case, thesolution is a prevent layer to counter a hypothetical terrorismscenario involving a vehicle-based improvised explosivedevice (VBIED), in which the attacker also carries firearms tocoerce entry. On the issue of scenarios, it is important to notethat an effective design process relies critically on appro-priate threat modeling [18], requiring that all potentialthreats, as well as the many different ways that each threatmay manifest itself, are considered ([2]). Fig. 4(a) shows theinitial, unpopulated stage of the design discussions and Fig. 4(b and c) shows the subsequent stages. Note that the sub-system manages the progression of a threat appearing at theleft into one of three possible output states, according to theperformance of its three functions, detect, alert andneutralize.

For the postulated VBIED threat, the objectives of theprimary access sub-system are to (i) assess entry credentials;(ii) deny entry to unauthorized persons/vehicles; and(iii) detect and assess any breach, and alert security officers,response teams and/or all personnel of the threat posed by abreach. This type of access sub-system constitutes a com-plete prevent layer because the successful performance of all

ists of three replicated subsystems, access, perimeter andintended to be relative to the context of the facility owner

Fig. 4 – Functional representation of a primary access sub-system at the (a) pre-stage, (b) mid-stage and (c) late stage of adesign discussion addressing a single scenario. (a) At the commencement of discussions, the three function containers areinitially unpopulated and the inevitable failure of the (unpopulated) detect function (shown by a dotted arrow below the detectcontainer) leads to the least desirable output state “inside without alarm”. (b) Discussions have identified candidate controlsto perform the detect and alert functions. Successful detection (indicated by a solid arrow from the detect function container)may still lead to the output state “inside without alarm” if there is a failure to raise an alarm (as postulated in the scenario). (c)Additional control options to perform the neutralization function are now proposed (completing the prevent layer). Incombination with protection for the guards, the chances of achieving more desirable output states (neutralized, or inside withalarm and delay) are increased. The discussion focuses on identifying candidate controls to shift the balance of probabilitiestowards preferred outputs.


three functions will prevent the VBIED attack. Note that adecision to detonate the device at the sub-system, becauseprogress to the intended target is impeded, is still a (partial)failure of the prevention layer because the threat was notneutralized; successful risk management would then rely onprotection and containment layers to minimize harmfulconsequences.

The input or entry state associated with the threat isshown in the left-hand side of Fig. 4 as invalid entrycredentials plus arms. Successful performance of all threefunctions (detect, alert and neutralize) is required for the

threat to be neutralized, as shown by the sequence in Fig. 4(a)linked by solid arrows to the desired end-state shown on theright. Failure of a function is represented by a dotted arrow.Progression through the sub-system ends at a specific outputstate, such as inside without alarm if either detection or alertfails, or inside with alarm if the neutralization function fails.Since all the function containers are initially empty, theintegrated set of controls required to achieve successfulfunction performance remains unspecified at this point.

Fig. 4(b) shows an intermediate stage in the designdiscussion. Participants have agreed that one of the detection


effects required is entry authorization and the discussion hasidentified that control options to perform this role includeguards, electronic swipe authorization and biometric sys-tems. The alert function is proposed to be performed by(the same) guards and/or a remote monitoring system. Forour VBIED scenario, if the attackers carry fake or stolen entrycredentials (which we assume they do not), it may lead to afailure of detection. They may instead (as we assume) besuccessfully detected as unauthorized intruders, but theguards may be disabled through the use of firearms, leadingto a failure of the alert function. Either failure leads to the endstate, inside without alarm.

Fig. 4(c) shows the agreed outcome for this sub-system atthe end of design discussions similar to those above. Theneutralization effect, specifically entry denial, is proposed tobe achieved using systems such as an anti-vehicular gate andtire spikes. To protect the guards from coercion, they may besituated inside ballistic protection systems and they maythemselves carry weapons for self-defense.

In the context of this scenario, the effectiveness of alter-native generic control systems is assessed and solutionsproposed, which lead to changed probabilities for eachpotential end-state (indicated in Fig. 4(c)) and, hence, to lessrisk from the scenario. Options that lead to more desirableend-states emerge from scenario role-playing in the designdiscussions, allowing participants to see where and how theprobability change is occurring – an extremely valuablefeature of the qualitative process. For instance, the likelihoodthat guards may be overwhelmed before raising an alarm willbe an important discussion, as is the likelihood of alarmactivation following the implementation of protective mea-sures. These kinds of deliberation provide traceability ofdesign decisions and justification for the final designsolution.

Assuming that the sub-system is populated as shown inFig. 4(c), the probability of neutralizing the attack (which maystill be less than 100%) is much greater. There is also a largerprobability that the alarm will be activated and relevantresponse actions inside the facility (e.g., lock-down, siteevacuation and police response) will be triggered to containthe harm. The introduction of delay associated with the timetaken to defeat implemented controls (shown in Fig. 4(c)below the neutralization function) frequently improves thesuccess of downstream security measures [12].

While there is no firm requirement to do so (see [16]),as a general principle, it is often wise to complete a securitylayer (such as prevent) within the boundaries of a singlesub-system as in Fig. 4. For an IED attack scenario, it makessense to populate all the functions of the prevent layer atthe site boundary rather than relying on neutralizationto occur further inside the facility. In other cases, itmay be reasonable to postpone neutralization (or anotherrelevant response function) to subsequent internal sub-systems.

Beyond any particular scenario, again, in general, we notethat passage through each security sub-system may lead to anumber of alternative output states. The overall aim ofdesign discussions is to populate each sub-system withcontrol options that increase the probabilities of paths lead-ing to more favorable (i.e., reduced likelihood and/or

consequence) output states across the spectrum of antici-pated threats.

At this point, on an individual scenario basis, it would beunwise to attempt to refine control choices to optimize therelative probabilities of possible outcomes. For this reason,the most useful technical expertise to have on hand in thesediscussions is a broad understanding of how much outcomeadjustment is achievable and affordable, rather than exper-tise in the specific technologies that may be required for itsdelivery. Defining the preferred technical solution will even-tually require local security expertise combined with systemtechnical knowledge but, at this stage, it is only necessary toidentify the control effect, such as a ram-proof gate or bombdisruption, with a sense of its success statistics, instead ofthe precise solution to be implemented.

Once constructed, Fig. 4 provides a basis for the partici-pants in the design process to examine another dimension ofsecurity-in-depth called system depth [11,20]. This relates tothe effective integration of systems to ensure system-widerobustness and resilience in the operational context. Forexample, the performance of a critical function must not becompromised by a single point of failure. In such a case, othercontrols should be used to support the function with respectto the same threat pathway so that risk reduction remainsrobust. Fig. 4 can be used to facilitate this discussion byraising “what if questions” in relation to the loss or failure ofparticular controls and sub-systems. Redundancy, reliabilityand resilience should be knowingly designed into the system.

Fig. 3, which represents the entire security context, showsthat there are many other opportunities to create preventlayers. Similar function diagrams to Fig. 4 are then con-structed to represent common area sub-systems, where thedetection of suspicious or dangerous behavior is paramount,and perimeter sub-systems, where entry-denial is the pri-mary goal although detection and notification of a breachmay also be important. The entire system is then connectedas a serial and/or parallel arrangement of sub-systems (seeFig. 5). The output states of earlier sub-systems become theinput states of those that follow, which allows internal sub-systems to behave differently if an alarm has already beenraised, for example. In this way, the system is designed anddiscussions are prompted and recorded for the entire path-way, all the way through to the set of possible consequenceoutcomes.

A similar process is used to assess the value of controlsthat contribute to the consequence management layers,protect and contain. For a contain layer, Fig. 6 shows anexample containment sub-system consisting of three func-tions: detect, alert and respond. Detection, in this case,corresponds to recognition that a harmful event has occurred(which may not be straightforward for events such as a toxicchemical release). Alert involves notifying and triggering allrelevant personnel and agencies, which may involve raisingan evacuation order for all on-site personnel as well asactivating requests for emergency services response.

For each possible output state in Fig. 6, expert knowledgeis required to assess the expected consequences. If localunderstanding is relatively immature, it makes sense tocharacterize the harm qualitatively through terms such ascatastrophic or severe, which have agreed, context-specific

Fig. 6 – The reduction of expected consequence (measured in fatalities) at a hypothetical facility, associated with raising analarm to alert local personnel to enact protective actions followed by a neutralization (e.g., police) response. Despite apotential failure of the respond function (shown by the dotted arrow below the function container), the consequences arereduced through the self-preservation actions of personnel following the alarm. The level of detail of consequences illustratedmay not be required in the early design discussions.

Fig. 5 – Nested arrangement of access, perimeter and common area sub-systems typical of a complex facility or infrastructure.


meanings. On the other hand, if the facility is well under-stood as a result of extensive modeling and simulation, itmay be possible to represent the harm through distributionsof consequence similar to those illustrated in Fig. 6. In thiscase, failure to detect the threat or failure to alert personneland responders leads to a broad distribution of expectedcasualties as shown at the end of the failure paths (below thealert function in Fig. 6). If the alert is successful, but theresponse is partially or totally ineffective, then the conse-quence distribution might be modified to reflect the reducedharm associated with, for instance, partial evacuation. In theevent that all the functions perform well, the expectedcasualty numbers may be markedly reduced, as shown inthe example distribution on the right-hand side of Fig. 6.Thus, as before, the design discussion is intended to identifythe suite of control effects that increase the probabilities ofpaths that lead to more favorable (lower consequence)outcomes.

Consideration of the protect layer is a little simplerbecause the controls that achieve protection are passiveand essentially work alone (i.e., there are no connectedfunctions involved). They are useful only inasmuch as theyare suited to the specific threat and scenario. For example,protection against an armed assassin might require bodyarmor suited to the caliber of the possible weapons.

Protection against explosives might require the enforcementof adequate standoff (e.g., bollards and vehicle-proof barriers,or the design of buildings to withstand defined blast pres-sures). As a general rule, protection controls must be pre-positioned to contribute to consequence management.

We have deliberately delayed the discussion of the deterlayer to this point, because deterrence occurs in the mind ofthe attacker and largely depends on his/her perception of thechances of failure and the severity of penalties if appre-hended. It therefore tends to be an emergent property relatedto the attacker's perception of security effectiveness, which isclosely related to the actual effectiveness of security. Thestrength of the deter layer is, therefore, largely defined by thestrength of other layers. There may, however, be some scopeto manipulate the attacker's perception of security effective-ness, and hence deterrence, independently of real securitystrength. A prominent sign declaring “guard dogs patrol thissite” when no dogs are present is a simple example, but manydeceptions of this kind only survive for as long as they are notprobed.

After the discussions have identified candidate controlsystems in each of the relevant sub-system functions andlayers, it becomes possible to trace through a particularpathway according to its relative probability (whether quali-tative or quantitative), and identify more and less probable


outcomes. Thus, each pathway may be assessed for both itslikelihood and its consequences, and the change of risk ineach scenario can be assessed according to adjustments inthe choice of controls (see [16]). Such discussions lead to oneor more candidate security system proposals tailored to thethreat-scenario pair considered.

Equivalent discussions should then occur based on theother threat-scenario pairs in order to develop the scenariodepth dimension of security-in-depth [20]. Developing auseful and comprehensive set of scenarios to drive theanalysis is simplified by experience. Over-enthusiastic inclu-sion of many similar scenario variants quickly overloads thedesign discussion, although it soon emerges that somevariants are essentially equivalent (and therefore redundant)in the way they stress a particular design. Conversely, somevariants around a theme such as armed attack may need tobe teased out, because forced entry through the primary gate,covert entry over a perimeter fence and insider-assisted entryall stress quite different aspects of the security solution.

4. Assessing risk reduction

After an appropriate threat spectrum has been used to drivediscussions using the methods described above, each analy-sis generates a distinct security proposal, which should thenbe examined alongside all others. This section develops atemplate intended to support the assessment of the value ofeach proposal as a contribution to managing the totalspectrum of risk. We illustrate the method using severalhypothetical terrorism scenarios.

4.1. Defining risk reduction objectives

When assessing pre- and post-proposal implementation risks,we would advocate that stakeholders and experts are asked toidentify ranges of likelihoods (e.g., 25%–50% chance) and con-sequences (e.g., 0%–20% chance of one fatality or 0%–2% chanceof two fatalities) at each stage. This approach supports sensi-tivity modeling and more robust decisions about the relativevalues of alternative proposals. We do acknowledge, however,that it is currently common practice to use fixed, discreteintervals (cells) for the allocation of likelihood and consequenceestimates in the form of a risk matrix akin to that shown inFig. 7 (see [26,27]). In such cases, the intervals should be chosento best support stakeholder/expert discrimination of pre- andpost-proposal implementation likelihoods and consequences.Note that the matrix in Fig. 7 is 5�5, but the matrix should

Fig. 7 – Example risk matrix distinguishing tolerable risk

reflect the categories and breakpoints that appropriately repre-sent security objectives, which could be 3�4, 6�5, etc.

The matrix is used to assign discrete risk levels tolikelihood-consequence combinations against which stake-holders can represent their risk appetite in the form of risktolerance levels. Once endorsed, a risk tolerance table sets thetarget for risk reduction objectives as long as untreated risks(i.e., no security or no additional security) and treated risks(implemented security proposal) can be estimated. In theabsence of absolute estimates of attack scenario likelihoods,it may still be useful to conduct a vulnerability analysis,assuming that each attack variant is certain to occur (i.e., verylikely in the terms of Fig. 7), as we illustrate below.

4.2. Assessing contributions to risk reduction

Fig. 8 shows a template intended to support the holistic assess-ment of all security design discussions and their outcomes.In Section 3, we outlined the collaborative development of asecurity design proposal relevant to a single threat-scenario. Inthis section, we combine it with the outputs of (six) equivalentdiscussions relating to all the remaining scenarios of interest.

The three security layers in consideration (prevent, protectand contain) are shown in the far left-hand side of Fig. 8.Immediately to the right of each layer title are the securityfunctions and control effects that contribute to its perfor-mance. The full list of controls is the inclusive set from allindividual proposals and it also includes any extant controls.Thus, each individual scenario-related design proposal (eachcolumn) is identified by noting the ticks that indicate thecontrols that are considered to be important solution com-ponents. Where controls (e.g., guards) contribute to morethan one function/layer, they should appear more than oncein the template.

The deter layer was deliberately omitted from this exampleanalysis because deterrence is difficult to measure [19,30] and itis also primarily a by-product of perceived strength in otherlayers, as discussed above. Unless it is proposed to manipulatethe adversary's perceptions of security strength independently ofother layers or there is a need to highlight the controls that arebelieved to change those perceptions, explicit consideration ofthe deter layer may be bypassed.

The prevent layer in the security-in-depth frameworkmanages the likelihood of a harmful event. An outcome ofeach design discussion should be an assessment of thelikelihood reduction in relation to the specific scenario, whichthe implementation of the prevent controls in the design isexpected to deliver. Fig. 8 shows the assessments in the form

(light shading) from intolerable risk (dark shading).

Fig. 8 – Results from a hypothetical discussion about the contributions of existing and proposed system level controls inmanaging the scenarios identified in the column headers, and their contributions to likelihood, consequence and riskreduction. Each column represents a single scenario for which proposed controls are indicated by ticks. This diagramsupports a holistic discussion about the role of controls in managing all relevant scenarios and the risk reduction achieved ineach case. An extra cost column may be added where the value of candidate controls also requires cost to be considered.


of a difference between untreated likelihood (before proposalimplementation, shown in the row above the prevent layer)and treated likelihood (after proposal implementation, shownin the row immediately below the prevent layer). In two ofthe hypothetical scenarios (Scenarios 5 and 6), no likelihoodreduction was achieved (no controls were proposed).

In the security-in-depth framework, the protect and containlayers combine to reduce the consequences of an incident.Again, stakeholders and experts present in the design discus-sion are asked to assess the untreated consequences of eachscenario prior to implementing the control proposal. Thesescenario-dependent untreated consequences are collected inFig. 8 in the row above the protect layer. Assessments of theconsequence reduction that each design proposal is expected toachieve are collected in the row below the contain layer.Consequence reduction achieved under each scenario is, there-fore, represented in Fig. 8 as a (qualitative) difference betweenthe untreated and treated consequences shown in each sce-nario column. The expected changes of consequence are thejustifications for the set of control choices collected in Fig. 8.

The assessments of risk and the risk reductions associatedwith each scenario are shown in the last three rows of Fig. 8.

Untreated risk is obtained from the combination of untreated(pre-implementation) likelihood and untreated consequence.Treated (conditional) risks are obtained from the combinationsof treated likelihood and treated consequence under eachscenario. We use conditional risks in this example because eachuntreated likelihood is assumed to be certain (actually, thehighest likelihood category corresponds to very likely), that is,the attack would occur [6]. If we had included the probability ofoccurrence of a scenario, then the treated risk row should beused instead. Risks are shaded in Fig. 8 to match the risk levelsshown in Fig. 7. The risk cells that also show ticks indicate thatstakeholders consider the treated risk as either tolerable oracceptable.

Collecting each of the scenarios together in the mannershown in Fig. 8 makes it apparent that the controls are notuniversally useful, that is, a specific control may be critical tothe management of one scenario, but may be relatively insig-nificant in another (e.g., some prevention controls in Scenarios 1and 4). It is also apparent that the proposed implementationachieves significant (conditional) risk reduction in some scenar-ios (i.e., Scenarios 1, 2 and 3), but very little in others (notablyScenario 6). Since this implementation proposal incorporates no


controls to prevent perimeter breaches, risk reduction in Sce-narios 5 and 6 relies on contain systems alone. The purpose of atemplate-driven process such as this is to focus discussion onthe holistic value of control combinations and their contribu-tions to risk reduction across the spectrum of anticipatedthreats. The apparent failure to manage Scenario 6 is intendedto stimulate discussion on whether additional controls arerequired to produce a more acceptable outcome.

The value of the analysis shown in Fig. 8 is in triggeringmany trade-off discussions to examine the benefit-costs [28] ofcontrol combinations, leading to a solution that (if possible)acceptably manages risks from all scenarios within cost con-straints. In this example, a few controls were assessed asimportant to managing many (if not all) of the scenarios andfor these, it may be wise to ensure that they receive priority inthe proposal that goes forward. Conversely, bollards andbarriers together with building protections were judged relevantonly to Scenario 2. Depending on the likelihood of and themagnitude of stakeholder concerns about Scenario 2, themitigation impact of losing these controls should be discussed.Perhaps their loss could be compensated elsewhere in thedesign. Decisions such as these can be made by takingfractional costs into account (all that is required is to add acost column to the template of Fig. 8).

It is important to note, however, that the removal of onecontrol from a design may undermine an entire layer becauseof interdependency between controls, making many othercontrols potentially redundant. Value should be assessed atthe layer, rather than at the control level, that is, if a controlis removed from a proposed solution, the assessments shownin Fig. 8 must be re-done for the scenarios that are affected.

The merit of this approach lies in its ability to lift thediscussion above the level of technical performance and themerits of a single security component in isolation to a broaddiscussion focused on trading risk reduction outcomes acrossdifferent parts of the overall security design. The process isone of balancing the stakeholders' risk tolerance againstcosts, in fact cost can be used as a primary constraint inthe design process.

At the conclusion of the process, a system level (S-level)design proposal is generated. All such proposals raise manyrequirements on the organization with regard to enablingsystems and arrangements [29], as we discuss next.

4.3. Enablers required by the security solution

In the security design proposal developed so far, we havefocused on building appropriate packages of controls ordevices rather than considering aspects such as training,organizational arrangements and security policies. In muchof the literature, these aspects of security implementation,which we call enablers, are often incorporated in illogicalways. It is clear that they are needed, but their contributionschange the risks indirectly. This means that their inclusion inthe design discussions to this point focused, as they are, onassessing risk reduction, is more likely to confuse than clarifythe way forward. There is another problem associated withenablers that relates to completeness; while training is rarelyforgotten as a crucial enabler, others may be omitted becausethere is no clear guidance on the enablers that should be

considered in a given security problem. This is the subject ofthe remainder of this paper.

There is substantial literature related to organizational orenterprise risk that is aimed at pre-identifying the ways inwhich an organization's primary systems may fail to operateas intended, and the importance of precursor signals inforeshadowing such failure (see, e.g., [3,17,21,22,25]). Thesemethods have grown in response to safety failures in thenuclear power industry (e.g., Chernobyl and Three MileIsland), chemical industry (e.g., Bhopal) and in other complexengineered systems (e.g., Space Shuttle Challenger and theDeepwater Horizon platform). Such failures often have theirroots in “human systems” relating to the decisions made bykey personnel who are ill-placed or ill-equipped to makethem, or management failures that set the standards andcreate the corporate psyche for inadequate response [15,32].

These broader issues are relevant because the effectiveoperation of security relies on much more than the effectiveperformance of its systems and devices. For example, wherea guard is expected to conduct vehicle and personnelsearches, the organization must provide training and proto-cols (e.g., random searches versus profiled searches), allocateresponsibility and authority, and ensure that the actions areconsistent with policy and law. Effective security depends oncoherence within and across many parts of the enterprise.Therefore, the design process (and templates) must beextended to include the development of consistent, coherentaction, decision-making and enterprise arrangements. Theabsence or inadequacy of these crucial enablers can compro-mise security just as severely as the failure of security controlsystems.

Building on the concepts in [17], we use three conceptuallevels of enabler, termed the action (A), management (M) andpolicy (P) levels. Each is primarily a checklist [13], developedby and with stakeholders in connection with the develop-ment of the security design itself. Together, the action,management and policy level assessments are intended toensure that all the enablers are explicitly and unambiguouslyidentified prior to implementation. The assessments can alsoeasily include costings. Note that enablers conceptually sitabove the system or S-level proposal (see [20]) that wasdeveloped in Sections 2 and 3.

The action level (Fig. 9) is intended to represent all aspectsof the enterprise required to ensure that its people andtechnical systems are equipped to operate the security solu-tion effectively. This demands the development of opera-tional protocols to guide local decision-making, training ofrelevant personnel (which may include all personnel in, forexample, evacuation procedures), the conduct of appropriatesimulation and rehearsal exercises, and the testing andmaintenance of all technical elements (e.g., alarms andcommunications systems). This list is illustrative rather thandefinitive. It is appropriate that stakeholders add furthercategories to satisfy their objectives and needs.

Fig. 9 shows a hypothetical action level assessmentmatched to the design proposal of Fig. 8. Its constructionalso matches that of Fig. 8, except that the column headersnow represent the information, activities and decision pro-cesses required to ensure that all actors and systems performappropriately. For example, detecting the arrival of a threat

Fig. 9 – A hypothetical action level analysis showing the implications of a security proposal (defined by the three leftmostcolumns) for human and technical enablers required to make the system effective. This template generates a checklist toensure that the implications of implementing each control are acknowledged explicitly in the design specification.


using remote (e.g., CCTV) monitoring (row 3 in Fig. 9) relies onthe development of protocols that support threat recognition,as well as the need for technical system testing and main-tenance. Fig. 9 provides a checklist to ensure that these threerequirements are not overlooked.

There is nothing sophisticated in this type of analysis, exceptthat it provides a systematic framework to ensure that theimplications of security implementation at the S-level arethoroughly considered. For every tick in a matrix (assigned bystakeholders and experts), responsibilities must be assigned andan underlying work program developed. The medical and avia-tion safety professions have notably demonstrated the criticalvalue of checklists in ensuring that nothing important is over-looked inadvertently [13].

A corresponding (hypothetical) management level assess-ment is shown in Fig. 10. Again, the security system proposalin the three left-most columns matches previous figures. Keyenablers associated with organizational arrangements andmanagement functions are identified in the remaining col-umns under six headings: personnel, planning and control,organization, training, infrastructure and support. As before,these headings should not be considered definitive andothers may be equally relevant in other contexts. This set isa modified version of the Australian Army's fundamentalinputs to capability [1] and its U.S. equivalent [5], which areintended to represent the principal elements involved indelivering a capability. The management level checklistshould ensure that the enterprise (roles, responsibilities,etc.) and its arrangements (e.g., use of employees versuscontractors, lines of reporting and decision-making, and

training program design and delivery) are appropriatelyaligned with the security design proposal. Again, the purposehere is to leave no ambiguity in understanding the organiza-tional implications of the security design proposal.

For completeness, Fig. 11 shows a hypothetical policy levelassessment matched to Figs. 8 through 10, identifying theelements of the design proposal that may need to takeaccount of, or may require amendments to, legal or localpolicy obligations. This assessment is shaded in relation tothree legislative/policy frameworks, which might include anOccupational, Health and Safety Act, a National (or Home-land) Security Act, etc. As before, the purpose of such anassessment is to ensure consistency between law, policy,decisions and actions in the context of security.

Where existing laws place constraints on aspects of theproposal, the issues must be traced down, potentiallythrough to the system level assessment, to discern whetheran alternative solution might circumvent the constraint.Alternatively, it may be appropriate to trace upwards toassess the policy implications of proposed system levelcontrols. This occurred recently in Australia's Defence Legis-lation Amendment (Security of Defence Premises) Bill of 2011,which amended the Commonwealth Defence Act of 1903 toauthorize members of the Australian Defence Force to use“reasonable and necessary force” to manage an attack onDefence premises. Such a requirement could have beenidentified by tracing up to the policy level from the preferredsystem level threat neutralization response.

Overall, Figs. 9 through 11 can be seen as a qualitativeview of the action, management and policy enablers required

Fig. 10 – A hypothetical management level analysis showing the implications of a security proposal (defined by the threeleftmost columns) for management and organizational enablers required to make the security system internally consistentand effective.


to support the system level security implementation (Fig. 8).Its purpose is to ensure consistency and alignment between allenterprise components required to deliver effective security.The action, management and policy level analyses actuallyprovide the means to identify, understand and address allaspects of enterprise risk that can compromise or disablesecurity just as effectively as a system failure. It is worthnoting also that the action, management and policy levelsmight also be a focus of deliberate sabotage by insiders, whomay change a protocol, subvert or seek to gain a key respon-sibility, or generate system test fatigue and indifference toalarms in order to disable or compromise crucial systemcomponents. Developing complete and robust methods formanaging enterprise risk is central to effective security.

5. Discussion

This paper provides a systematic approach to managing anumber of the complexities of physical security design. Afterusing the process, stakeholders should have an agreed designproposal to guide implementation that is both documentedand defensible in terms of the discussion of risk pathwaysand how proposed controls reduce risk.

The approach is governed by several guiding principles:

�
The value of new or modified security arrangements shouldbe assessed on the basis of risk reduction with respect to arepresentative spectrum of plausible threats and scenarios.
�
Security controls, because they demonstrate complexinter-dependencies, should be considered collectively asmembers of security layers. Security controls, only inas-much as they form complete security layers, managesecurity risk. Controls (in general) are not independentinstruments of risk reduction.
�
It is important to take a broad and inclusive approach tothe involvement of stakeholders in the design process.
�
When considering a single threat scenario, design discus-sions should focus on managing the probabilities andconsequences of alternative pathways through the systemin order to shift the balance to more acceptable or morefavorable end states.
�
Instead of optimizing security arrangements to manage asub-component of the problem, it is more important tosupport a holistic appraisal of performance across thewhole threat scenario space, and enable stakeholders totrade risk reduction value across all parts of the system(mindful of costs).

Fig. 11 – A hypothetical policy level analysis showing the implications of a security proposal (defined by the three leftmostcolumns) in relation to three policies that impact, or are impacted by, the implementation of the proposed security system.


�
The effective performance of security layers and controlsrelies intimately on the effectiveness of a complex web ofenablers related to policies, organizational structures,operational arrangements and system support tasks. It isimportant to expose these requirements explicitly andunambiguously to ensure that all aspects of security arecoherent and consistent.
Using the security-in-depth framework [20] to assess con-tributions to security risk reduction addresses a deficit in theliterature that cannot be covered by control-centric approaches(e.g., [10,19,29]). The method specifically aids security designersin resolving the issue, noted in [8], that “the large number ofpotential attack scenarios and security options makes it difficultto assess and include portfolio effects of mitigation measures”.

The approach has certain limitations, of course. Whenreviewing the full proposal illustrated in Fig. 8, any decisionsto adjust the solution require a re-evaluation of all the earlierstages affected by the adjustment. This is because a correctconsideration of risk reduction contributions can only beperformed by assessing packages of controls that representlayers, rather than individual controls (other methods incor-rectly assign measures of effectiveness at the control level).This imposes an overhead in relation to re-iterating processesleading to Fig. 8. To some extent, the overhead can belessened by incorporating exploratory discussion of alterna-tives in the sub-system solution development illustrated inFig. 4, but this will necessarily be a compromise imposed bythe appetites of stakeholders.

The extent to which qualitative assessments are compro-mised by the inability to assess all the re-adjustments indesign is unclear, but the process is nevertheless a stepforward from control-centric methods. One potential way tomanage this difficulty is to use quantitative methods. In [16],the iteration of all possible combinations of control packageswas achieved through models of control contributions, butthis again requires considerable investment from stake-holders to generate appropriate representations.

A further issue relates to the criticality of enablers in theaction, management and policy dimensions, because we havenot traced these down (beyond noting their inclusion) toassess their relative importance in managing risk. Under-standing and then designing systems of enablers usingmeasures of risk reduction, as we have done with templatesfor the system level, remains an unsolved problem. Extendingquantitative analysis to include the action, management andpolicy level enablers greatly raises the complexity. The orderof the inter-dependencies between system components andenablers, and between enablers and enablers, can renderquantitative assessments of enabler performance intractable.Further research is needed in this area.

A related question, in terms of informing investmentpriorities, is whether it is feasible to optimize the investmentinto different layers to “best” manage the entire threatscenario spectrum. In other words, given the likelihood ofeach scenario and the expected consequences in each sce-nario after treatment, the question is: can the total expectedconsequences be minimized by adjusting the relative invest-ments in each layer? The template shown as Fig. 8 is


intended to support qualitative discussion leading to betterdecisions, but its binary level of detail is inadequate forassessing whether or not overall security is improved bystrengthening one layer at the expense of another.

Addressing this type of question takes us beyond the quali-tative assessment of layer performance, although the layerconstruct lends itself to a relatively straightforward extensionto an expert-informed quantitative approach. In the course ofour work with clients, we have enhanced Fig. 8 using quantita-tive techniques (although not to the extent of using a quantita-tive model as in [16]) in order to answer layer prioritizationquestions without losing the qualitative appeal of Fig. 8. As wewill report in a forthcoming paper, given a specific scenario, it isreasonable to ask stakeholders to define a range of effectiveness,e.g., equal chance in the range 20%–50% of preventing the attackwith control package A, whereas package B would increaseprevention effectiveness into the (uniform) range 50%–75%.These opinions may then be incorporated into a simple layeredmodel of security that supports Monte Carlo sampling to developstatistics around the expected outcomes of improved perfor-mance (i.e., investment) in one layer versus another.

6. Conclusions

The primary goal of this paper is to provide a set of templates(Figs. 4 and 8 through 11) to guide and facilitate risk owner,stakeholder and technical expert interactions in the design ofeffective security solutions for complex infrastructures. Basedon the concept of security layering, the paper offers apragmatic, yet rigorous, approach to physical security design.The methods and templates described in the paper areintended to harmonize the strategic views and objectives ofowners and stakeholders with those of system managers andoperators, so that each has an effective voice in the designprocess. Bringing all the parties together in an iterative andcollaborative process maximizes the chance of deliveringtechnically effective security solutions that balance risktolerance with risk reduction within cost constraints, whilealso providing traceability of collective decisions.

Acknowledgments

We are very grateful to the reviewers who took the time toprovide constructive suggestions for enhancing the manu-script. The Commonwealth of Australia funded this researchand the preparation of this paper, and has granted permis-sion to publish the paper.

r e f e r e n c e s

[1] Australian Army, LWD 1: The Fundamentals of Land Warfare,Sydney, Australia, 2008.

[2] H. Bergmans, J. van der Horst, L. Janssen, E. Pruyt,V. Veldheer, D. Wijnmalen, M. Bokkerink, P. van Erve, J. vande Leur, Working With Scenarios, Risk Assessment andCapabilities in the National Safety and Security Strategy ofthe Netherlands, Landelijk Operationeel CoordinatieCentrum, The Hague, Netherlands, 2009.

[3] V. Bier (Ed.), Proceedings of the Workshop on Accident

Sequence Precursors and Probabilistic Risk Analysis, Center

for Reliability Engineering, University of Maryland, College

Park, Maryland, 1998.[4] Centre for the Protection of the National Infrastructure,

Integrated Security: A Public Realm Design Guide for

Hostile Vehicle Mitigation, Centre for the Protection of

National Infrastructure, London, United Kingdom, 2011.[5] Chairman of the Joint Chiefs of Staff, Operation of the Joint

Capabilities Integration and Development System, CJCSM

3170.01C, United States Armed Forces, Washington, DC, 2007.[6] L. Cox Jr., Some limitations of risk¼threat�vulnerability�

consequence for risk analysis of terrorist attacks, Risk Anal.

28 (6) (2008) 1749–1761.[7] L. Cox Jr., Improving risk-based decision making for

terrorism applications, Risk Anal. 29 (3) (2009) 336–341.[8] R. Dillon, R. Liebe, T. Bestafka, Risk-based decision making

for terrorism applications, Risk Anal. 29 (3) (2009) 321–335.[9] M. Dunn-Cavelty, M. Suter, Public-private partnerships are

no silver bullet: an expanded governance model for critical

infrastructure protection, Int. J. Crit. Infrastruct. Prot. 2 (4)

(2009) 179–187.[10] Federal Emergency Management Agency, Risk Assessment:

A How-To Guide to Mitigate Potential Terrorist Attacks

Against Buildings, Washington, DC, 2005.[11] K. Fleming, F. Silady, A risk-informed defense-in-depth

framework for existing and advanced reactors, Reliab. Eng.

Syst. Saf. 78 (3) (2002) 205–225.[12] M. Garcia, The Design and Evaluation of Physical Protection

Systems, Elsevier Butterworth-Heinemann, Boston,

Massachusetts, 2008.[13] A. Gawande, The Checklist Manifesto: How to Get Things

Right, Metropolitan Books, New York, 2010.[14] A. Gerstenfeld, P. Berger, A decision-analysis approach for

optimal airport security, Int. J. Crit. Infrastruct. Prot. 4 (1)

(2011) 14–21.[15] S. Johnson, Success, failure and NASA culture, ASK Mag. (32) .

⟨appel.nasa.gov/2008/09/01/success-failure-and-nasa-culture⟩.[16] S. Lord, R. Nunes-Vaz, Designing and evaluating layered

security, Int. J. Risk Assess. Manag. 17 (1) (2013) 19–45.[17] D. Murphy, M. Pate-Cornell, The SAM framework: modeling

the effects of management factors on human behavior in

risk analysis, Risk Anal. 16 (4) (1996) 501–515.[18] S. Myagmar, A. Lee and W. Yurcik, Threat modeling as a basis

for security requirement, in: Proceedings of the Symposium

presented on Requirements Engineering for Information

Security, 2005.[19] T. Norman, Risk Analysis and Security Countermeasure

Selection, CRC Press, Boca Raton, Florida, 2010.[20] R. Nunes-Vaz, S. Lord, J. Ciuk, A more rigorous framework for

security-in-depth, J. Appl. Secur. Res. 6 (3) (2011) 372–393.[21] M. Pate-Cornell, The engineering risk analysis method and

some applications, in: W. Edwards, R. Miles Jr., D. von

Winterfeldt (Eds.), Advances in Decision Analysis: From

Foundations to Applications, Cambridge University Press,

Cambridge, United Kingdom, 2007, pp. 302–324.[22] M. Pate-Cornell, Accident precursors and warning systems

management: a Bayesian approach to mathematical models,

in: J. Cochran (Ed.), Wiley Encyclopedia of Operations

Research and Management Science, 45, Wiley-Blackwell,

Oxford, United Kingdom, 2011, pp. 1–14.[23] L. Pietre-Cambacedes, C. Chaudet, The SEMA referential

framework: avoiding ambiguities between security and

safety, Int. J. Crit. Infrastruct. Prot. 3 (2) (2010) 55–66.[24] B. Schneier, Beyond Fear: Thinking Sensibly About Security

in an Uncertain World, Copernicus Books, New York, 2003.

http://refhub.elsevier.com/S1874-5482(14)00042-0/sbref1








































appel.nasa.gov/2008/09/01/success-failure-and-nasa-culture


























[25] P. Sonnemans, P. Korvers, Accidents in the chemicalindustry: are they foreseeable?, J. Loss Prev. Process Ind. 19(1) (2006) 1–12.

[26] Standards Australia and Standards New Zealand, AS/NZSHB436:2004, Risk Management Guidelines: Companion toAS/NZS 4360:2004, Sydney, Australia and Wellington,New Zealand, 2005.

[27] Standards Australia and Standards New Zealand, AS/NZSISO31000:2009 Risk Management – Principles and Guidelines,Sydney, Australia and Wellington, New Zealand, 2009.

[28] M. Stewart, Risk-informed decision support for assessing thecosts and benefits of counter-terrorism protective measuresfor infrastructure, Int. J. Crit. Infrastruct. Prot. 3 (1) (2010)29–40.

[29] J. Talbot, M. Jakeman, Security Risk Management Body ofKnowledge, Wiley, Hoboken, New Jersey, 2009.

[30] M. Taylor, C. Kiekintveld, C. Western, M Tambe, A frameworkfor evaluating deployed security systems: is there a chink inyour ARMOR?, Informatica 34 (2) (2010) 129–139.

[31] Transportation Security Administration, Layers of security,Arlington, Virginia. ⟨www.tsa.gov/es/node/1034⟩, 2013.

[32] D. Vaughan, The Challenger Launch Decision: RiskyTechnology, Culture and Deviance at NASA, University ofChicago Press, Chicago, Ilinois, 1996.

[33] H. Willis, T. LaTourrette, T. Kelly, S. Hickey, S. Neill, TerrorismRisk Modeling for Intelligence Analysis and InfrastructureProtection, TR-386-DHS, RAND Corporation, Santa Monica,California, 2007.













www.tsa.gov/es/node/1034








designing physical security for complex infrastructure.pdf

Documents

security objectives

money security

hasf security

strength of security

response of aviation

successive security

central tenet of security

security design nothe