Effective Physical Security Fourth Edition Chapter 2 Introduction to Vulnerability Assessment Copyright © 2013, Elsevier Inc. All rights reserved. 1 ◼ A systematic evaluation to predict: ◼ ◼ ◼ ◼ Physical protection systems (PPS) component performance Overall system effectiveness Identifies exploitable weaknesses in protection from a defined threat Establishes requirements for upgraded PPS design Copyright © 2013, Elsevier Inc. All rights reserved. 2 Introduction to Vulnerability Assessment Vulnerability Assessment (VA) 2 Vulnerability Assessment ◼ Three phases: ◼ ◼ ◼ ◼ Planning Conducting the VA Reporting and using results Part of larger risk assessment processes Copyright © 2013, Elsevier Inc. All rights reserved. 3 Vulnerability Assessment ◼ Key points: ◼ ◼ ◼ ◼ Risk management/VA Risk management/VA process VA process overview VA and systems engineering Copyright © 2013, Elsevier Inc. All rights reserved. 4 Vulnerability Assessment ◼ Difference between: ◼ Safety: ◼ ◼ Measures to prevent/detect an abnormal condition that can endanger people, property, enterprise Security: ◼ Measures to protect people, property, enterprise from malevolent human threats Copyright © 2013, Elsevier Inc. All rights reserved. 5 Risk Management/VA ◼ Risk management: ◼ Set of actions taken to address identified risks: ◼ ◼ ◼ ◼ ◼ ◼ Avoidance Reduction Spreading Transfer Elimination Acceptance Copyright © 2013, Elsevier Inc. All rights reserved. 6 Risk Management/VA ◼ Avoidance: ◼ ◼ Accomplished by removing risk source Reduction: ◼ Achieved by actions to lower risks to reduce loss severity Copyright © 2013, Elsevier Inc. All rights reserved. 7 Risk Management/VA ◼ Spreading: ◼ Multiple locations ◼ ◼ ◼ Production at more than one facility Distribution of assets across large facility Transfer: ◼ Insurance to cover replacement or other costs Copyright © 2013, Elsevier Inc. All rights reserved. 8 Risk Management/VA ◼ Acceptance: ◼ Recognition there will always be risk ◼ ◼ Need to determine acceptable level Risk management decisions based on: ◼ ◼ ◼ Consequence of loss of assets Defined threat Risk tolerance of the enterprise Copyright © 2013, Elsevier Inc. All rights reserved. 9 Risk Management/VA ◼ Categories of risk: ◼ ◼ ◼ ◼ ◼ ◼ Market Credit Operational Strategic Liquidity Hazard Copyright © 2013, Elsevier Inc. All rights reserved. 10 Risk Management/VA ◼ Three questions to be answered: ◼ ◼ ◼ What can go wrong? Likelihood it would go wrong? What are the consequences Copyright © 2013, Elsevier Inc. All rights reserved. 11 Risk Management/VA ◼ Then ask: ◼ ◼ ◼ What can be done What are the options What are associated trade-offs in: ◼ ◼ ◼ ◼ Costs Benefits Risks Impact of current management decisions on future options? Copyright © 2013, Elsevier Inc. All rights reserved. 12 Risk Management/VA ◼ Risk management process is: ◼ ◼ ◼ ◼ Systematic Statistically based Holistic Security RA—with the benchmarks of: ◼ ◼ ◼ Threat Likelihood of attack Consequences of loss Copyright © 2013, Elsevier Inc. All rights reserved. 13 Risk Management/VA ◼ Risk assessment—evaluation of PPS supported by analysis methodologies: ◼ ◼ ◼ ◼ Threat analysis Consequence analysis Event and fault tree analyses Vulnerability analysis Copyright © 2013, Elsevier Inc. All rights reserved. 14 Risk Management/VA Process ◼ Measured qualitatively or quantitatively through: ◼ R = PA x (1 – PE) x C ◼ ◼ ◼ ◼ R: Risk to facility PA: Probability of adversary attack in period of time PE: Probability of responder interruption x probability of adversary neutralization C: Consequence value (normalizing factor) Copyright © 2013, Elsevier Inc. All rights reserved. 15 VA Process Overview ◼ System performance-based approach to meeting PPS objectives ◼ Primary functions: ◼ ◼ ◼ Detection Delay Response Copyright © 2013, Elsevier Inc. All rights reserved. 16 VA Process Overview ◼ Both quantitative and qualitative methods used to evaluate PPS components ◼ ◼ Quantitative techniques—facilities with highconsequence loss assets Qualitative techniques if: ◼ ◼ No quantitative data available Asset value much lower Copyright © 2013, Elsevier Inc. All rights reserved. 17 VA Process Overview ◼ Purpose of VA—evaluate PPS component to estimate performance as installed ◼ Quantitative approach: ◼ ◼ Start with tested performance value of component Degrade its performance based on how it is: ◼ ◼ ◼ ◼ Installed Maintained Tested Integrated into the overall PPS Copyright © 2013, Elsevier Inc. All rights reserved. 18 VA Process Overview ◼ Purpose of VA (con’t) ◼ Qualitative approach: ◼ ◼ ◼ Performance of each component degraded based on same conditions Performance of device assigned a level of effectiveness Evaluated under all weather conditions and facility states, considering all threats Copyright © 2013, Elsevier Inc. All rights reserved. 19 Reporting and Using the VA ◼ The VA team reports on the facility data analysis with the goal to: ◼ Provide accurate, unbiased info that defines: ◼ ◼ ◼ Current effectiveness Potential solutions to ineffective system areas Use report in successive projects to address vulnerabilities/improve facility PPS Copyright © 2013, Elsevier Inc. All rights reserved. 20 Reporting and Using the VA ◼ ◼ ◼ Reporting can be formal/informal, verbal/written, overview/detailed Content must make report useful Should not be shared indiscriminately ◼ One organization should have final control Copyright © 2013, Elsevier Inc. All rights reserved. 21 Reporting and Using the VA ◼ Steps after report is completed: ◼ ◼ ◼ Pursue improving PPS Consider recommendations—cost effective or no? Design team to create upgrades meeting performance predicted in upgrade analysis phase of VA. Copyright © 2013, Elsevier Inc. All rights reserved. 22 Reporting and Using the VA ◼ Three stages of design activity: ◼ ◼ ◼ ◼ Conceptual Preliminary Final design For new facility: ◼ VA analysts and designers work together to model proposed PPS Copyright © 2013, Elsevier Inc. All rights reserved. 23 System Engineering and VA ◼ Definitions: ◼ System—integrated collection of components or elements designed to achieve an objective ◼ ◼ Small or large, but composed of subsystems System of systems/family of systems—a collection of many systems into a functional whole Copyright © 2013, Elsevier Inc. All rights reserved. 24 System Engineering and VA ◼ Systems engineering— “interdisciplinary approach and means to enable the realization of successful systems” ◼ Integrates into business goals and environment requirements that are: ◼ ◼ ◼ Functional Technical Operative Copyright © 2013, Elsevier Inc. All rights reserved. 25 System Engineering and VA ◼ Integration of: ◼ ◼ ◼ ◼ ◼ Physical or electrical Customer needs Technical performance Safety Reliability ◼ ◼ ◼ ◼ ◼ ◼ Procedures Personnel Maintenance Training Testing Life cycle costs Copyright © 2013, Elsevier Inc. All rights reserved. 26 System Engineering and VA ◼ Process to begin at requirements stage ◼ ◼ ◼ ◼ ◼ VA fits here, then guides the other stages VA results determine upgraded system design When installed, test system and maintain Requirements may change Address replacement of system/components Copyright © 2013, Elsevier Inc. All rights reserved. 27 System Engineering and VA ◼ Alogical and structured process: ◼ ◼ ◼ Define problem to be solved Consider multiple potential solutions Analyze solutions to support section and implementation of most balanced that meet requirements/goals. Copyright © 2013, Elsevier Inc. All rights reserved. 28 System Engineering and VA ◼ Implementation includes: ◼ ◼ ◼ ◼ Proper installation Maintenance Testing Personnel training Copyright © 2013, Elsevier Inc. All rights reserved. 29 System Engineering and VA ◼ A systems development model considers both systems and component engineering ◼ Both areas science based: ◼ ◼ ◼ Science—what is Component engineering—what can be Systems engineering—what should be Copyright © 2013, Elsevier Inc. All rights reserved. 30 System Engineering and VA ◼ Systems engineering domain includes: ◼ ◼ User requirements— define the problem System requirements— boundaries/constraints ◼ Domain includes: ◼ ◼ ◼ ◼ ◼ Component selection Design Analysis Integration Testing Copyright © 2013, Elsevier Inc. All rights reserved. 31 System Engineering and VA ◼ Project leader may be system engineer ◼ ◼ Ensures final product meets customer needs Large projects may have separate systems engineer ◼ Component engineer —subject matter and technical experts on: ◼ ◼ ◼ Adversary and response tactics Explosives Analysis Copyright © 2013, Elsevier Inc. All rights reserved. 32 System Engineering and VA ◼ VA process described is performance based, using: ◼ ◼ ◼ Science Systems Component engineering Copyright © 2013, Elsevier Inc. All rights reserved. 33 System Engineering and VA ◼ Example of distinction between: ◼ ◼ Compliance based—radar to provide exterior intrusion detection Performance based—ensures all system requirements identified and then select device that best meets requirements Copyright © 2013, Elsevier Inc. All rights reserved. 34 System Engineering and VA ◼ Exterior intrusion detection requirements: ◼ ◼ ◼ ◼ ◼ ◼ Probability of detection Nuisance alarm rate Vulnerability to defect by defined threat Integration with other PPS components Expansion capability Life cycle cost of implementation/operation Copyright © 2013, Elsevier Inc. All rights reserved. 35 System Requirements ◼ Requirement—characteristic that identifies levels needed to achieve specific objectives under given set of conditions ◼ ◼ Threshold—something that must be achieved Goals—desirable but not mandatory Copyright © 2013, Elsevier Inc. All rights reserved. 36 System Requirements ◼ In early stages of evaluation, must determine mandatory requirements from customer wants/needs ◼ Step should be done before system evaluation to ensure process gives client satisfaction. Copyright © 2013, Elsevier Inc. All rights reserved. 37 System Requirements ◼ Types of system requirements: ◼ Functional—describes product and level of detail ◼ ◼ Address integration of people, procedures and equipment that provide end product Address needs, expectations of stakeholders, customers, and users Copyright © 2013, Elsevier Inc. All rights reserved. 38 System Requirements ◼ Types of requirements: ◼ Constraint—any external/internal compliance condition/stipulation ◼ ◼ ◼ ◼ ◼ Laws and regulations Legal liabilities Standards Enterprise policies and procedures In VA, function of site and other conditions Copyright © 2013, Elsevier Inc. All rights reserved. 39 System Requirements ◼ Type of requirements: ◼ Performance—how well a capability must operate and under what conditions ◼ ◼ ◼ ◼ Earned value Monthly financial status Milestones met Security performance measures Copyright © 2013, Elsevier Inc. All rights reserved. 40 System Requirements ◼ Need to know underlying reason and goals for VA ◼ ◼ ◼ Enterprise policy or regulatory agency Facility may have recently been attacked Response to attacks on other facilities (9/11) Copyright © 2013, Elsevier Inc. All rights reserved. 41 System Requirements ◼ Functional requirements = defining protection objectives: ◼ ◼ ◼ What is to be protected From whom Characterize enterprise in terms of: ◼ ◼ Mission External and enterprise operating environment Copyright © 2013, Elsevier Inc. All rights reserved. 42 System Requirements ◼ Performance requirements of security system related to capability of threat ◼ ◼ PPS protecting assets from vandals—lower performance needed Protecting assets from motivated and wellequipped activists—high performance needed Copyright © 2013, Elsevier Inc. All rights reserved. 43 System Requirements ◼ Threshold—used to specify minimum acceptable performance needed ◼ If cannot be met by improved PPS within contraints: ◼ ◼ System not implemented or requirements reduced ROI zero—extra money for no corresponding increase Copyright © 2013, Elsevier Inc. All rights reserved. 44 System Design and Analysis ◼ System evaluated by component engineers considering: ◼ ◼ ◼ Defined threat Identified assets All constraints Copyright © 2013, Elsevier Inc. All rights reserved. 45 System Design and Analysis ◼ VA on PPS considers: ◼ ◼ ◼ Functions of detection, delay, and response How well people, procedures, and equipment meet requirements Implicit that threat must physically enter ◼ Standoff attacks from off-site or cyber attacks not part of VA of a PPS Copyright © 2013, Elsevier Inc. All rights reserved. 46 System Design and Analysis ◼ If baseline analysis shows system does not meet requirements: ◼ ◼ Potential upgrades analyzed on a functional level VA establishes new set of system requirements, passes on to designers Copyright © 2013, Elsevier Inc. All rights reserved. 47 System Design and Analysis ◼ Analysis supported by evaluation tests ◼ Documents PPS component performance ◼ ◼ Deficiencies that lead to system weaknesses May be historical test data Copyright © 2013, Elsevier Inc. All rights reserved. 48 System Design and Analysis ◼ Consider performance expected for various combinations of elements ◼ Robust design will go beyond threshold ◼ Example: shows effectiveness against the defined threat AND how well the system will work against higher threats Copyright © 2013, Elsevier Inc. All rights reserved. 49 System Design and Analysis ◼ VA will show if current PPS is/is not effective. ◼ ◼ ◼ ◼ If not,VA team proposes upgrades VA is complete. Final report written Client decides whether to implement changes Copyright © 2013, Elsevier Inc. All rights reserved. 50 System Design and Analysis ◼ Design change: ◼ ◼ ◼ ◼ Begins with conceptual design Preliminary design Deploys final system design Multidisciplinary team reviews potential designs Copyright © 2013, Elsevier Inc. All rights reserved. 51 System Design and Analysis ◼ Multidisciplinary team reviews potential designs, using ◼ ◼ ◼ ◼ Design reviews Modeling and simulation tools Test data Discussions with customer Copyright © 2013, Elsevier Inc. All rights reserved. 52 System Design and Analysis ◼ Before implementation: ◼ System components analyzed to validate and verify system ◼ ◼ Validation—process of checking stakeholder satisfaction Verification—checks that design meets specified technical requirements Copyright © 2013, Elsevier Inc. All rights reserved. 53 System Design and Analysis ◼ Requirements traceability— ◼ ◼ Nor requirements missed and no extraneous requirements Shows that system is what customer wants ◼ Example: Choosing a camera ◼ Does camera meet functional, constraint, and performance requirements of the system as the customer wants? Copyright © 2013, Elsevier Inc. All rights reserved. 54 System Installation and Test ◼ New design is implemented ◼ ◼ Deviations from specs should be approved by experts Some changes may affect system performance: ◼ Changing distance between or height of light fixtures change available light to an area Copyright © 2013, Elsevier Inc. All rights reserved. 55 System Installation and Test ◼ ◼ ◼ Operational tests to confirm device works: Functional tests to show device is working and performing as expected Final acceptance tests recommended before client accepts delivered system Copyright © 2013, Elsevier Inc. All rights reserved. 56 System Installation and Test ◼ PPS expected to perform after installation ◼ ◼ ◼ Proper maintenance and periodic testing to maintain optimal function Make recommendations on maintenance, testing, and training procedures Complete system documentation Copyright © 2013, Elsevier Inc. All rights reserved. 57 System Replacement ◼ Good practice to: ◼ ◼ Include planning for system retirement and replacement after expected lifetime is reached Allow for system expansion/growth ◼ ◼ 50% expansion above current capability typical Example: installation of fiber optic cable bundles with more conductors than currently needed Copyright © 2013, Elsevier Inc. All rights reserved. 58 System Replacement ◼ Expected that: ◼ ◼ ◼ ◼ Technology will advance Threats will change Facilities will grow or shrink Equipment will fail Copyright © 2013, Elsevier Inc. All rights reserved. 59
Purchase answer to see full attachment