TRANSPORTATION INFRASTRUCTURE SECURITY UTILIZING INTELLIGENT TRANSPORTATION SYSTEMS

ALI ALSHAHIBI

Natural disasters increasingly threaten the safety of the mankind. Not only that, in past decades there has been an obvious increase in the number of natural disasters, but it is also present an increase in their destructiveness. This results in a higher loss of life, material and non-material damage. In addition, compromising critical infrastructure prevents or limits the implementation of vital state functions (governance, health, education, energy, economic, social, and general security functions), which is further reflected in the safety of states and citizens. Despite the technological development of mankind, societies are increasingly threatened. It is clear that the disasters and their impact on people and critical infrastructure cannot be prevented, but mechanisms for prediction and early warning of disasters can be improved that the resilience and capacity for faster and more efficient revitalization of endangered values and goods can be increased. Besides the degree of destruction, the response strategy in an emergency situation will depend on the type of disaster, but also on the kind of critical infrastructure and specific goods and values that are threatened. In this regard, the paper gives an overview of the scope and the content of (still undetermined) concept of critical infrastructure, the term and the phenomenology of natural disasters, the consequences of geophysical, hydrological and meteorological disasters on critical infrastructure and critical infrastructure protection capabilities against natural disasters.

Disasters are very common. Worldwide, earthquakes, floods, cyclones, landslides, technological accidents, and urban fires occur daily. They tend to occur suddenly, without much warning, and cause massive destruction, sometimes killing or injuring large numbers of people within a short time. In 1999 alone, natural disasters killed over 60,000 people in Turkey, 10,000 people in India, and 25,000 people in Venezuela

TRANSPORTATION INFRASTRUCTURE SECURITY UTILIZING INTELLIGENT TRANSPORTATION SYSTEMS Transportation Infrastructure Security Utilizing Intelligent Transportation Systems R. Fries, M. Chowdhury and J. Brummond Copyright © 2009 John Wiley & Sons, Inc. TRANSPORTATION INFRASTRUCTURE SECURITY UTILIZING INTELLIGENT TRANSPORTATION SYSTEMS RYAN FRIES MASHRUR CHOWDHURY JEFFREY BRUMMOND JOHN WILEY & SONS, INC. 1 This book is printed on acid-free paper. Copyright # 2009 by John Wiley & Sons, Inc. All rights reserved Published by John Wiley & Sons, Inc., Hoboken, New Jersey Published simultaneously in Canada No part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, scanning, or otherwise, except as permitted under Section 107 or 108 of the 1976 United States Copyright Act, without either the prior written permission of the Publisher, or authorization through payment of the appropriate per-copy fee to the Copyright Clearance Center, 222 Rosewood Drive, Danvers, MA 01923, (978) 750-8400, fax (978) 646-8600, or on the web at www.copyright.com. Requests to the Publisher for permission should be addressed to the Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030, (201) 748-6011, fax (201) 748-6008, or online at www.wiley.com/go/permissions. Limit of Liability/Disclaimer of Warranty: While the publisher and the author have used their best efforts in preparing this book, they make no representations or warranties with respect to the accuracy or completeness of the contents of this book and specifically disclaim any implied warranties of merchantability or fitness for a particular purpose. No warranty may be created or extended by sales representatives or written sales materials. The advice and strategies contained herein may not be suitable for your situation. You should consult with a professional where appropriate. Neither the publisher nor the author shall be liable for any loss of profit or any other commercial damages, including but not limited to special, incidental, consequential, or other damages. For general information about our other products and services, please contact our Customer Care Department within the United States at (800) 762-2974, outside the United States at (317) 572-3993 or fax (317) 572-4002. Wiley also publishes its books in a variety of electronic formats. Some content that appears in print may not be available in electronic books. For more information about Wiley products, visit our web site at www.wiley.com. Library of Congress Cataloging-in-Publication Data: Fries, Ryan. Transportation infrastructure security utilizing intelligent transportation systems / Ryan Fries, Mashrur Chowdhury, Jeffrey Brummond. p. cm. Includes index. ISBN 978-0-470-28629-6 (cloth) 1. Intelligent Vehicle Highway Systems–Security measures. 2. Information technology– Security measures. 3. Highway communications–Security measures. I. Brummond, Jeff. II. Title. TE228.3.F74 2008 338.3012–dc22 2008022805 Printed in the United States of America 10 9 8 7 6 5 4 3 2 1 To Sydney, Celeste, Jane, Nick, and Danielle Fries To Manzur, Setara, Farzana, Aniqa, and Adeeba Chowdhury, and A.S.M. Ilias To Melissa, Jacob, and Jenna Brummond CONTENTS Preface xiii Acknowledgments xvii 1 INTRODUCTION 1 1.1 1.2 1.3 1.4 1.5 Concept of Security / 1 Transportation and Security / 4 Security in the ITS Context / 6 Scope and Audience of the Book / 10 Content and Organization / 11 References / 12 Review Questions / 13 2 NEED FOR SURFACE TRANSPORTATION INFRASTRUCTURE SECURITY 2.1 2.2 2.3 14 Vulnerabilities / 14 Common Characteristics of Surface Transportation Systems / 16 Common Threats to Surface Transportation Systems / 17 2.3.1 Earthquakes / 17 2.3.2 Fires / 18 2.3.3 Terrorist Attacks / 18 2.3.4 HAZMAT / 19 2.3.5 Blackouts / 20 vii viii CONTENTS Hurricanes / 20 Floods / 21 Biological and Chemical Attacks / 22 Derailment / 23 Cyber Attacks / 23 Defending against Threats Both External and Internal / 24 Why Transportation Infrastructure Security Is Important / 26 Focus Areas / 27 Summary / 28 References / 28 Review Questions / 30 2.3.6 2.3.7 2.3.8 2.3.9 2.3.10 2.4 2.5 2.6 2.7 3 LEVERAGING ITS TO REDUCE RISK AND EXPOSURE USING ITS SECURITY AREAS 3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 Introduction / 31 Disaster Response and Evacuation / 35 Freight and Commercial Vehicle Security / 40 HAZMAT Security / 44 ITS Wide Area Alert / 47 Rail Security / 49 Transit Security / 50 Transportation Infrastructure Security / 54 Traveler Security / 57 Conclusions / 58 References / 59 Review Questions / 59 4 RISK ASSESSMENT FRAMEWORK 4.1 4.2 4.3 31 Risk Assessment Framework / 61 4.1.1 Critical Assets / 64 4.1.2 Risks Assessment Methods / 64 4.1.3 Mitigation and Countermeasures / 70 4.1.4 Selection of Options / 71 Opportunities and Challenges / 72 Application of the Framework / 72 References / 72 Review Questions / 73 60 CONTENTS 5 APPLICATION OF RISK ASSESSMENT AND MANAGEMENT TOOLS 5.1 ix 74 Application of Risk Assessment Methods / 74 Blue Ribbon Panel Method / 74 Fault-Tree Analysis / 84 Weibull Hazards Model Example / 93 Application of Evacuation Models and Traffic Models for Response Planning / 94 Application of Other Methods / 99 References / 99 Review Questions / 100 5.1.1 5.1.2 5.1.3 5.2 5.3 6 FUNDAMENTALS OF COMPUTER NETWORK SECURITY FOR ITS 6.1 6.2 6.3 6.4 6.5 6.6 6.7 Introduction / 102 Elements of Computer Network Security / 103 Importance of Computer Network Security / 104 Approach to Computer Network Security / 104 6.4.1 Policy / 105 6.4.2 Current State / 106 6.4.3 Security Requirements / 106 6.4.4 Recommended Controls / 106 6.4.5 Accountability / 107 6.4.6 Timetable / 107 6.4.7 Continuing Attention / 108 Computer Network Security in ITS / 108 Network Security Objectives / 108 6.6.1 Confidentiality / 109 6.6.2 Authentication / 112 6.6.3 Message Integrity and Nonrepudiation / 113 6.6.4 Availability / 114 6.6.5 Access Control / 116 Future of Network Security and Its Impacts on Securing ITS Network / 117 References / 117 Review Questions / 118 102 x CONTENTS 7 SECURING ITS 7.1 7.2 7.3 7.4 7.5 7.6 7.7 7.8 Introduction / 120 Security Objectives / 123 7.2.1 Confidentiality / 123 7.2.2 Integrity / 123 7.2.3 Availability / 123 Security Threats / 124 7.3.1 Deception / 124 7.3.2 Disruption / 124 7.3.3 Usurpation / 124 7.3.4 (Unauthorized) Disclosure / 124 Security Services / 125 7.4.1 Information Security / 125 7.4.2 ITS Personnel Security / 125 7.4.3 Operational Security / 126 7.4.4 Security Management / 126 Securing ITS Subsystems / 127 Securing Communications between Subsystems / 128 Security and ITS Standards / 133 7.7.1 National Transportation Communications for ITS Protocol / 133 7.7.2 Traffic Management Data Dictionary and Message Sets / 137 7.7.3 Commercial Vehicle Information Systems and Networks / 137 7.7.4 Archived Data / 139 7.7.5 Dedicated Short Range Communications / 139 7.7.6 Incident Management / 140 7.7.7 Transit Communications Interface Profiles / 140 7.7.8 Advanced Traveler Information Systems / 142 Conclusions / 143 References / 143 Review Questions / 144 8 ITS SECURITY AREAS AND MULTIMODAL TRANSPORTATION SECURITY 8.1 120 Protecting People / 146 8.1.1 Airports / 146 8.1.2 Public Transit / 149 146 xi CONTENTS Perception of Security / 153 Protecting Vehicles and Infrastructure / 154 8.2.1 Airports / 154 8.2.2 Public Transit / 156 8.2.3 Rail Vehicles and Infrastructure / 159 8.2.4 Ships and Ports / 160 Protecting Freight / 162 8.3.1 Containers / 162 8.3.2 HAZMAT / 164 8.3.3 Liquids / 165 8.3.4 Military Freight / 165 The Future / 166 References / 167 Review Questions / 169 8.1.3 8.2 8.3 8.4 9 PROCESS FOR DEVELOPING A REGIONAL TRANSPORTATION SECURITY PLAN 9.1 9.2 9.3 9.4 Introduction / 171 Developing a Regional Transportation Security Architecture / 173 9.2.1 Security in a Regional ITS Architecture Development Process / 174 9.2.2 Developing a Regional Transportation Security Architecture / 181 Developing a Project Security Plan / 183 Conclusion / 186 References / 186 Review Questions / 187 10 ISSUES AND OPPORTUNITIES FOR TRANSPORTATION INFRASTRUCTURE SECURITY 10.1 10.2 10.3 10.4 10.5 171 ITS Security versus Privacy / 188 Public and Private Roles / 189 Stakeholder Cooperation and Coordination Requirements / 192 10.3.1 Information Sharing / 193 10.3.2 Resource Sharing Agreements / 194 Funding Sources and Constraints / 195 Human Resources / 195 188 xii CONTENTS 10.6 Future Directions and Opportunities / 196 References / 197 Review Questions / 198 APPENDIX A NATIONAL ITS ARCHITECTURE SUBSYSTEM SECURITY DESCRIPTIONS 199 APPENDIX B SECURING ARCHITECTURE FLOWS 211 APPENDIX C USDOT FHWA FINAL RULE 237 APPENDIX D USDOT FTA POLICY ON TRANSIT PROJECTS 261 APPENDIX E WEIBULL DISTRIBUTION SUPPORT 274 Index 277 PREFACE ‘‘Security’’ has suddenly become an important parameter in determining international, national, regional, and even local policy. It is even a substantial consideration in the planning, design, and operations of new and existing infrastructures. To detect and thwart deliberate attacks against infrastructure that cause harm to both life and property, determining the appropriate response to such attacks has become a public policy issue of great importance. It has been necessary to create manuals and perform drills on how to respond to such attacks and thus minimize their impact. The lives of millions of citizens are disrupted and threatened when the various infrastructures supporting the nation’s transportation system are deliberately attacked. Ensuring infrastructure security and enhancing the public’s perception of security are not only important for protecting life and property; they also are intimately tied to the social and economic well-being of the United States. Recent terrorist attacks such as the London Underground and bus bombings of 2005, the Madrid commuter rail bombings of 2004, and the events of September 11, 2001 in the United States have changed the environment in which transportation systems are operated worldwide. Although mobility and safety are the primary objectives for any good transportation system, security has become an equally important parameter in their design and operation. As security measures become ever more vulnerable, attacks against smaller targets using less conventional weapons have become much more effective. Further, natural disasters, such as the Indian Ocean tidal wave in 2004 and Hurricane Katrina in 2005 have further emphasized the vulnerabilities of our transportation systems. Transportation practitioners and researchers must recognize the role of these systems as emergency management tools while simultaneously considering their use as either targets and/or weapons. xiii xiv PREFACE Besides the ever-changing security environment, increasing traffic congestion, the reduced ability to procure highway and rail rights-of-way, increasing fuel costs, and improving technological abilities are also shaping the transportation industry worldwide. Reacting to these issues, transportation practitioners have increasingly turned to technological solutions for traffic, transit, and maritime challenges. Because computing abilities continue to improve, there is every indication that technologies will continue to play a major role in the development and operations of new and existing transportation industry infrastructures. Intelligent transportation systems (ITS), which integrate different computing, control, and communication technologies, were first deployed to combat traffic congestion and improve transportation efficiency; their dual use for security represents a valuable opportunity to address two issues with a single scheme. While closed circuit traffic cameras and variable message signs are now commonplace, experience shows that they may not always remain so. Instead, new tools with new capabilities will have to interact with older systems. ITS Architectures support system interoperability and interchangeability; which are also the underlying themes of using ITS architectures for security purposes. Adoption of security areas in the development of regional architectures has recently become easier within the United States due to the addition of security-related emphasis areas in the National ITS Architecture. The National ITS Architecture developed in the United States provides a general framework for defining and planning ITS services and functions, as well as integrating intelligent transportation systems components. However, ITS also represents an inherent security risk since individuals with malevolent intentions could attempt to use these systems against the public. The ever-increasing amount of control that system managers wield over the deployed environment—specifically through reversible lanes, automated evacuation gates, signal system control, and variable message signs—has the potential to cause devastating harm if commandeered for nefarious purposes. The future is unpredictable. New technologies will provide new mechanisms for managing security risks to transportation infrastructure, and technological advances may initiate new threats. A strategic security planning process must be developed in which security objectives and tools adjust to exploit new opportunities while averting continuous threats. It is our expectation that this book will help educate both students and transportation professionals. This book is intended for upper-level undergraduate and graduate courses as well as the self-taught professional. The text is also meant to highlight the need to contemplate, consider, and develop strategies for enhancing the security dimension of ITS. Within the field of transportation engineering, this book fills a gap in the practical application of security by leveraging ITS for use in that role. It also offers valuable insight into the new security challenges encountered with the use of computerized transportation systems. PREFACE xv One of the challenges for today’s transportation engineer is the breadth of knowledge needed beyond that of a typical civil engineering degree. It is now necessary to understand not only civil engineering principles but also those of computer science, systems engineering, communications engineering, and the security-related ramifications of those domains. Because of this multidisciplinary perspective, this book covers such diverse topics as computer systems, risk analysis, and multimodal transportation systems, which are necessary for securing ITS as well as providing security to our transportation systems through ITS. ACKNOWLEDGMENTS Many individuals contributed to the preparation of this manuscript through both review efforts and encouragement. We would like to acknowledge the contributions of Dr. Anne Dunning, member of the faculty in Transportation Planning at Clemson University, for providing valuable input on multimodal transportation security; Dr. Richard Brooks and Dr. Samuel Sander, both faculty members of the Electrical and Computer Engineering department at Clemson University, for providing feedback on computer systems security; Steve Ernst, a senior engineer at the Office of Bridge Technology at the Federal Highway Administration, for his feedback on bridge and tunnel security as presented by the Blue Ribbon Panel; Lieutenant Colonel Theodore D. Mauro, PhD (SCSG-CA), for his feedback on military transport security; and to our U.S. National ITS Architecture Team colleagues. Our sincere thanks go to Godfrey Kimball of Clemson University for his help with the review of several chapters of the book. We would also like to thank Yan Zhou and Dr. Yongchang Ma for their support in the preparation of the manuscript. xvii CHAPTER 1 INTRODUCTION S ecurity is an expectation of surface transportation users. Tools like intelligent transportation systems (ITS), which provide services such as surveillance, control, communication, and information collection and dissemination in real time, can support safeguards against threats. This chapter introduces the concepts of security within the context of ITS, then concludes with a description of the anticipated audience and scope of this book. 1.1 CONCEPT OF SECURITY The world is full of natural and man-made risks, often characterized in terms of their likelihood of occurrence and their subsequent impacts to both life and property. Natural events, such as floods, hurricanes, tornados, and earthquakes, as well as involuntary events, such as machine or system malfunctions, can be quantified in terms of probability of occurrence and severity of their impacts. Similarly, human-induced events, such as deliberate attacks or errors, can cause similarly devastating affects. These deliberate or unintentional acts also can be expressed in terms of risks of their occurring and possible impacts of these events once they occur. Table 1.1. shows similarities and dissimilarities between deliberate threats, such as terrorist attacks and natural disasters such as hurricanes. The perception of security has far-reaching effects. A secure environment provides an atmosphere where innovations and economic growth flourishes. Even the perception of security can benefit society and improve social and economical fabrics of life through new investments. Transportation Infrastructure Security Utilizing Intelligent Transportation Systems R. Fries, M. Chowdhury and J. Brummond Copyright © 2009 John Wiley & Sons, Inc. 1 2 INTRODUCTION TABLE 1.1 Possible Similarities and Dissimilarities of Terrorist Attacks with Natural Disasters Similarities Mass casualties Damage to infrastructure Occur with or without warning Evacuation or displacement of citizens Dissimilarities Caused by people on purpose May target specific security vulnerabilities Affected areas will be treated as crime scenes May not be immediately recognizable as terrorist events May not be single events Place responders at higher risk May result in widespread contamination of critical equipment and facilities May expand geometrically in scope May cause strong public reaction Source: Parsons Brinckerhoff and Science Applications International Corporation, 2002. Several factors contribute to the perception of security. One such factor is a possible in-place system that can identify threats before they occur. This forward-thinking concept is most desirable, but often it is the most difficult to accomplish. Therefore, having an appropriate response plan for any deliberate attack is also important for an overall security plan. This plan may include coordination between first responders, resource sharing, providing immediate care to those most affected, and evacuating those most at risk. Thus, security planning against deliberate threats encompasses different facets of tasks between multiple agencies involved in different activities, whose coordination is a must for identifying and managing any security threats. Conversely, a security breach, resulting in either man-made or natural catastrophes, both impedes innovation and stifles economic creativity and the vitality of areas affected by such events. Within a very short time—in a matter of days, in fact—the sense of security shared in the public’s collective perception, which has evolved over a long period, is shattered. In addition to public loss of confidence in security measures, the loss of human life, injuries, and, the economic costs of a terrorist attack on any region are overwhelming. A study conducted by the RAND Corporation reported that the initial costs of a terrorist attack involving a nuclear event near the port of Long Beach, California, could exceed $1 trillion. (Meade and Molander 2006). These staggering costs, which would cause untold harm to the U.S. and global economies, would be driven by demands for a massive medical response to such a disaster, subsequent insurance claims, compensation for lost jobs, and economic devastation to the greater Los Angeles area, not to mention the overwhelming cost of evacuation and reconstruction, including radioactive cleanup. Table 1.2 shows the wide range of terrorist threats and their possible impacts on infrastructure and other targets. 1.1 CONCEPT OF SECURITY 3 TABLE 1.2 Terrorist Threats and Effects on Infrastructure and Other Targets Weapons of Mass Destruction Conventional explosives (detonation of military-type or commercial bombs, such as fuel oil–fertilizer, etc.) Possible Distinguishing Signs Explosions Casualties Various types of localized blast damage up to structural collapse Exposure to dust and hazardous building materials (e.g., asbestos) May be used to spread harmful radiological or chemical materials Chemical (dispersion of pesticides, mustard gas, chlorine gas, cyanide, tear gas, etc.) Biological (dispersion of viruses, bacteria, toxins, fungi, etc.) Radiological (dispersion of radioactive material by nonnuclear explosion or pressurized gas) Nuclear (nuclear detonation with radioactive fallout) Novel concepts (unusual delivery systems—aircraft, boats; combinations of weapons and attack modes; unexpected targets with secondary consequences) Initial unexplained deaths and illnesses Effects mostly localized to release site but may be distributed farther by wind and contamination Area may be marked by unusual clouds, haze, mist, odors, tastes, droplets, etc. May be persistent in environment Initial unexplained deaths and illnesses, possibly beginning a day or more after an incident Immediate effects mostly localized to release area, but distribution may be expanded through human transmittal Possible persistence in environment Possible geographic contamination Unexplained deaths and illnesses Effects mostly localized to release but may be some distribution via wind and other means beyond release site Persistence in environment Geographic contamination Conventional explosives used for dispersal may cause additional effects and explosions Large-scale infrastructure destruction Extensive radioactive fallout Long-term persistence in environment Geographic contamination Radioactive poisoning of foodstuffs, water sources, and long-term illnesses Unknown Source: Parsons Brinckerhoff and Science Applications International Corporation, 2002. 4 INTRODUCTION TABLE 1.3 Security Issues Key Topics in Infrastructure Security 1. Foundations for Policy 2. Planning, Design, and Engineering 3. Management and Operational Practices 4. Information Security 5. Mobilization (‘‘Notice’’) and Response (‘‘Trans-event’’) 6. Recovery (Post-event) Specific Issues Criteria establishing investment priorities Institutional continuity Design review for secure structures Research and development (R&D) needed to support ‘‘design for security’’ Design criteria Design specifications Best practices Practice review Institutional relationships Preparedness Personal and vehicle security Communication/outreach Procurement practices Information security Threat warning Early response Initial response Damage assessment Functional continuity Source: Blue Ribbon Panel, 2003. Table 1.3 outlines the major topics concerning infrastructure security and related issues. Although this table was developed for bridge and tunnel security by the Blue Ribbon Panel on Bridge and Tunnel Security, it can apply to other transportation infrastructure. The table provides important considerations for infrastructure security in six different phases: policy, planning, design and engineering, operations and management, information security, response, and recovery. 1.2 TRANSPORTATION AND SECURITY Transportation has always been strongly tied to economic development and sustainability; and regional, national or international economies have come to depend increasingly on efficient and secure transportation systems. Transportation systems connect vital regional economic components (e.g., businesses and employee housing) to ensure that employees can use these systems to get to work while also ensuring that businesses can use them to provide and receive various supporting services and/or supplies. Nationally, the U.S. system of interstate roadways plays an indispensable role in economic vitality, connecting the goods of one region with the demands of another. Interstate travel also plays 1.2 TRANSPORTATION AND SECURITY 5 a significant role in national defense; indeed, our system of interstate highways was built with just this purpose in mind. The overriding objective of the Eisenhower Interstate Highway System in the United States, begun in the 1950s, was the strategic, efficient, and quick movement of troops, weapons, and supplies in time of war. While successful in scope, it is interesting to note that the major benefit of the Interstate Highway System has been one of commerce rather than for the military, becoming the great enabler of moving goods and people efficiently via surface transportation. Transport services are provided through air (including space), water, and surface vehicles. Airplanes and ships mainly accommodate air and water travel, respectively, whereas railroads, private automobiles, commercial trucks, and public transit comprise the surface transportation system. Many times these different transportation modes serve independent travels, and these modes often complement each other in serving overlapping travel requirements. For example, delivering cargo from Paris, France to Santa Fe, New Mexico, United States, necessitates that goods be freighted through a complex web of surface, water, and in some cases air travel to reach their destination. These transportation choices are not simply relegated to the movement and reception of cargo. Residents around Seattle, Washington, may use private automobiles, public transit, or ferry transportation to commute to work. Similar complementary services exist within modes; travelers in the Boston area may use either private automobile or the Massachusetts Bay Transit Authority light rail to reach their destinations. There have been numerous terrorist attacks on such large-scale transportation systems. The September 11, 2001, terrorist attacks by means of the U.S. airline industry revealed the risks of the transportation system being used as a weapon. We realized that not just aircraft but surface transportation systems (trucks, containers, transit cars, barges) and the bridges and tunnels that facilitate their use could be weaponized (Kulash 2002). Critical transportation infrastructures, such as bridges, tunnels, and intermodal faculties, were seen to be particularly vulnerable to terrorist attacks. Other bombings—coordinated bombings in 2004 against the commuter train system of Madrid, Spain, which killed 191 people and wounded 2,050, and the July 7, 2005, bombings against London’s public transport system, in which 52 commuters were killed and 700 were injured—illustrate these vulnerabilities (U.S. Department of State 2004). Since 2000, terrorist attacks on transportation systems worldwide have more than doubled as compared to the previous decade, with attacks being conducted against smaller targets and in smaller cities. (U.S. Department of State 2004). Security incidents can have an impact on the transportation system. For example, the September 11 terrorist attacks in the United States affected all modes of transportation for the entire region and the I-95 corridor and necessitated significant road repair. Threats near a transportation facility can result in closures or travel restrictions (Federal Highway Administration 2004). In the United States, the Federal Highway Administration (FHWA) is 6 INTRODUCTION supporting the development of new technologies and training programs to assist regional and state transportation agencies in upgrading operational tools and processes for providing enhanced security (Federal Highway Administration 2008). The focus of this effort related to ITS includes: Model emergency scenarios Integrate ITS with State Emergency Operations Centers, Implement voice and data interoperability between transportation and public safety agencies Train transportation agency personnel in Incident Command/Unified Command (ICS/UC). ICS/UC is a tool, jointly developed by stakeholder agencies called the National Response Team (NRT) to protect the public against threats from land, air and water by efficiently responding and managing emergency events. NRT includes stakeholder agencies such as U.S. Department of Commerce, U.S. Department of Defense, and U.S. Department of Transportation (NRT 2008). Apply ITS to support and improve homeland security efforts. These efforts, along with state and local planning, are improving the future security landscape of the United States. Both developing and developed nations have initiated their own transportation security strategies. In the United States, transportation security is an integral part of homeland security. In fact, transportation is listed as one of the 17 critical infrastructure sectors in the strategies for homeland security (Office of Homeland Security 2005). Because most of the European initiatives parallel efforts in the United States, many opportunities exist for international collaboration through communications and information sharing. This sharing is expected to result in efficient management of international security efforts to minimize security threats worldwide, which is an increasingly important task. 1.3 SECURITY IN THE ITS CONTEXT This book focuses on the ability of intelligent transportation systems to improve security. ITS systems combine traffic engineering, computer technologies, and communications systems that complement and integrate these services provided by various agencies to improve traffic flow and safety in the surface transportation system (Chowdhury and Sadek 2003). The surface transportation system includes roads, bike paths and pedestrian corridors, mass transit systems, and railroads. Surface transportation infrastructure includes the fixed assets of the surface transportation system, such as highways and streets, train stations, public transit terminals, and bridges (U.S. General Accounting Office 2004). Although the concept of intelligent vehicle highway systems, which was later renamed ITS, was introduced in the 1980s, it has recently received much 1.3 SECURITY IN THE ITS CONTEXT 7 attention and has proceeded through several evolutionary milestones. Today ITS is a recognized field of research in the transportation community that provides a viable means to help meet future transportation demands. The systems are also increasingly viewed as alternatives to additional road infrastructure construction to meet future travel demands. ITS applications primarily focus on the surface transportation infrastructure, but they also are applicable to air and water transportation systems (e.g., airports and seaports) that have the potential to be interdependent. Through government-sponsored field evaluations in which ITS was shown to minimize crashes while reducing travel times, the collective transportation community has come to see the inherent value of such systems. Studies conducted by the U.S. Department of Transportation (DOT) determined that the deployment of ITS in major U.S. metropolitan areas resulted in considerable savings in travel time, an increase in safety, improvement in air quality, higher customer satisfaction, and lower fuel consumption (U.S. DOT 2005). These applications, encompassing various areas, are briefly described next along with some primary security risks. Arterial management systems. Arterial management systems include computer and sensor systems to control traffic flow on arterial roadways based on demand. Because operating agencies often control such systems from remote locations, they are vulnerable to unauthorized usage. For example, depending on the signal preemption security settings, individuals have been able to acquire devices that cause unintended signal preemption. Freeway management systems. A freeway management system includes such functions as surveillance, control, guidance, warning, and information dissemination (FHWA, Freeway Management Handbook, 2003). These functions, provided in limited-access highways to improve traffic flow, are also vulnerable to security disruptions, which can be potentially catastrophic during mass evacuations. Incident management systems. Incident management systems are used to reduce the impact of unusual or abnormal occurrences, such as crashes, stalled vehicles, work zone lane closures, or special events. Such systems potentially can minimize the duration of an incident, minimize the risks of secondary crashes, and support re-routing traffic. Any disruption to the incident management system can accentuate the response to incidents. Transit management systems. Transit management systems are designed to improve the efficiency, security, and safety of public transit, including subways, light rail and buses. The public expects that these systems provide a safe and secure environment. Location identification technologies, operations software, real-time information, and electronic fare payment are some of the primary tools used to improve the efficiency, safety, and security of the transit systems. Knowing the real-time location 8 INTRODUCTION of the transit system elements and having transit drivers communicate with the dispatch and operations center ensures that the transit system is alerted of potential incidents on routes, so that drivers can take alternate routes. By implementing video and sensor surveillance in the transit terminals and area outside the vehicles, security of the system can be enhanced. Electronic toll collection (ETC). ETC systems permit automatic toll payment, where motorists need not stop to pay tolls. Vehicle-mounted units record payments from individual motorists, lessening toll plaza backups of vehicles and permitting more efficient and safer travel. Similar to ETC technology, security-related detection and surveillance devices in automated toll booths and at critical locations are also under development for monitoring suspicious activities. Regional multimodal traveler information systems. Multimodal traveler information systems provide travel-related information for use in highway, transit, ferry, and airway systems. The fusion of historical and current data makes it possible to create real-time information that can be passed on to travelers to rerout and avoid an incident scene, thus increasing safety and efficiency. Providing similar information on evacuation routes, routes to avoid, emergency transit services, and the transportation situation during emergencies can be valuable during and after an emergency event. Field evaluations have been mostly positive regarding the effectiveness of these applications. This positive experience has been the major motivating factor for widespread deployment of ITS. Previous studies and field evaluations found positive gains in safety by implementing various ITS services. It is expected that the deployment of ITS will increase nationwide, expanding new opportunities to improve the transportation infrastructure and its associated regional and national security concerns. Because using ITS to improve security can simultaneously attain other mobility and safety objectives, ITS can prove to be an efficient endeavor for both public and private agencies. Integrating ITS with other non-transportation infrastructure, such as surveillance cameras for businesses, can further mitigate safety and security risks. Large trucks carrying unauthorized hazardous materials are of major concern. The technology that can be applied to scan and check the carrier credentials and truck contents from a roadway checkpoint while the truck is in transit is a potentially beneficial way to improve security. In addition, ITS can minimize the impact after a security breach has occurred through the use of preestablished routes for evacuating people during emergencies. In both cases, providing motorists with real-time traffic assignment based on the traffic demands on designated routes and alternate evacuation routes can minimize the impact of any security breach within the infrastructure of the U.S. surface transportation system. 1.3 SECURITY IN THE ITS CONTEXT 9 The primary benefits of ITS, including efficiency, safety, and security, are illustrated in Figure 1.1. Also shown are the security-related services provided by ITS, which potentially can prevent the tampering of both highway and transit infrastructures, including surveillance of traffic conducted through sensors, videos, and freeway service patrols. In addition, the use of ITS to regularly monitor commercial vehicles can support constant surveillance to prevent their use as terrorist weapons. Moreover, because ITS can minimize the impacts of highway incidents through traffic control and management at and near the incident-impacted area, the same concepts and technologies, such as use of dynamic message signs to inform motorists, the use of lane access control signs, and gates, can be used adjacent to the site of a terrorist attack to reroute traffic and track the location of vehicles carrying hazardous material close to the crisis area. Additionally, ITS can help first responders and subsequent public safety assets dispatched by various law enforcement or rescue agencies increase their effectiveness by maintaining secure communications links. ITS can also support evacuation by providing information and control regarding lane reversal. Through ITS deployment in one or more of these areas—detection, surveillance, control, information, and coordination—some of the surface transportation safety and security risks can be minimized. Efficiency Intelligent Transportation Surveillance Safety Detection Systems Security Scene Management Response Coordination Evacuation Figure 1.1 ITS Functions and Security. 10 INTRODUCTION The security-related services presented in Figure 1.1 may also provide ‘‘safety’’ and ‘‘efficiency’’ benefits; which means that investment of ITS and any other transportation infrastructure to strengthen security is likely to provide benefits in other areas as well. For example, ITS-related security features for bridges over navigable waterways, such as surveillance systems, will also support traffic management during a crash or evacuations due to natural or man-made emergencies, thus supporting safer and efficient traffic operations. Other security measures on bridges, such as lighting and pier strengthening, will contribute to its overall safety. Similarly, having an integrated and interoperable communication system between different stakeholder agencies for accelerated security response will benefit non-security related emergency events, such as supporting hurricane or flood related evacuations of at-risk population from an affected region (Parsons Brinckerhoff and Science Applications International Corporation, 2002). The multiple non-security related benefits that may be derived from a transportation security investment will make it more cost-effective and thus more justifiable. 1.4 SCOPE AND AUDIENCE OF THE BOOK The focus of this book is on the infrastructure-based transportation technology that will contribute to the regional and national security against deliberate attacks on the transportation system. Although the book concentrates on technology related to the surface transportation infrastructure, modes of transport, such as personal transportation, public transit, and freight, are presented in terms of their relationship with the surface transportation infrastructure as identified in the National ITS Architecture (RITA, National ITS Architecture 6.0) including the Security Document (RITA, National ITS Architecture Security Document). This book discusses different objective measures to identify and quantify risks and develop mitigating measures using ITS while concentrating on different vulnerable links in transportation where ITS can contribute to security. This book is intended to serve as a reference for transportation engineers, planners, and service providers in the public and private sectors involved in transportation or infrastructure security and will be useful to personnel involved in homeland security. It is also designed to serve as a college textbook for a graduate-level course or as a supplement to an undergraduate course. This book covers theories behind many risk analysis tools and provides real-world examples of transportation security plans and implementation guidelines of these plans. It concentrates on infrastructure planning and the system architecture that binds it with various surface transportation modes: personal vehicle, public transit (paratransit, buses, ferries, and rail), and commercial vehicle operations. The surface transportation system faces the challenges of meeting the demand of increasing congestion with increased risks in safety and security 1.5 CONTENT AND ORGANIZATION 11 breach. We need to educate and train our future transportation professionals to meet these challenges. As ITS is expected to be a dominant element of future transportation systems, transportation professionals should know how to minimize the greatest risks to surface transportation systems through an understanding of security. By presenting academic background as well as projectoriented examples, this book provides fundamental knowledge to prepare professionals and students to improve the safety and security of transportation systems. Review questions are available at the end of each chapter in addition to exercises to help the reader apply the material. 1.5 CONTENT AND ORGANIZATION The initial chapters of this book discuss how ITS can contribute to security, followed by approaches on using ITS for security and concluding with issues and opportunities to providing security through ITS and concepts of security. This book is organized into ten chapters: Chapter 1 introduced the concept of security and its contributions to positive social and economic growth. This chapter also discussed transportation security and how ITS can contribute to it. Additionally, the scope of this book and intended audience are also identified. Chapter 2 presents the case for having a comprehensive security framework for surface transportation infrastructure to minimize the risk of occurrence of a deliberate attack and to minimize impact after such an event has occurred. The chapter presents several case studies from around the world on transportation security programs. Chapter 3 introduces how the systems engineering approach of the National ITS Architecture can facilitate effective and systematic deployment of transportation technologies. This chapter focuses on the security aspects of the National ITS Architecture and presents examples of how these tools have been applied. Chapter 4 presents the process for identifying infrastructure security risks and associated factors with example problems and solutions. This will be the foundation for identifying the qualitative and quantitative relationship between risk and associated factors using state-of-the-art tools as presented in Chapter 5. Chapter 5 illustrates different concepts of risk modeling, including the data requirements and assumptions. In addition to detailing processes for evaluating the threats, this chapter discusses potential measures for mitigating these threats. Chapter 6 explains the fundamentals of computer network security as it pertains to ITS. It provides a background on the elements of computer network security followed by a general approach to securing these 12 INTRODUCTION networks. The objective of this chapter is to prepare the reader for Chapter 7 which is entitled Securing ITS. Chapter 7 discusses how ITS itself can be protected from deliberate attacks. The chapter presents different areas of ITS that need security considerations: information security, personnel security, and operational security. The chapter also discusses how security programs could be built on safety initiatives. Chapter 8 discusses the relationship between ITS security areas and other modes of transportation. It presents a framework of how ITS security areas can contribute to the security of air, maritime, rail, and military transportation. Chapter 9 presents the process for developing an integrated program in surface transportation security using ITS. This chapter also discusses how security can be integrated into the transportation planning and asset management processes. Chapter 10 discusses the issues and challenges for implementing security programs in the surface transportation system and discusses practical ways to meet these challenges. REFERENCES Blue Ribbon Panel on Bridge and Tunnel Security. 2003. ‘‘Recommendations for Bridge and Tunnel Security.’’ Prepared for the American Association of State Highway and Transportation Officials Transportation Security Task Force. September. Chowdhury, Mashrur, and Adel Sadek. 2003. Fundamentals of ITS Planning. Artech House. Federal Highway Administration (FHWA.) 2003, Freeway Management and Operations Handbook, FHWA Report No.: FHWA-OP-04–003, Washington, D.C. Federal Highway Administration (2004), http://ops.fhwa.dot.gov/aboutus/one_pagers/ emerg_response.htm (accessed in June 6, 2008). Federal Highway Administration (2008), http://ops.fhwa.dot.gov/opssecurity/docs/pub_safety_ sec_bro.pdf, 2008). Meade, Charles, and Roger C. Molander. 2006. ‘‘Considering the Effects of a Catastrophic Terrorist Attack.’’ RAND Center for Terrorism Risk Management Policy. National Response Team (NRT), Unified Command Technical Assistance Document, 2007. www.nrt.org. Parsons Brinckerhoff and Science Applications International Corporation. 2002. ‘‘National Needs Assessment for Ensuring Transportation Infrastructure Security.’’ Prepared for the American Association of State Highway and Transportation Officials Transportation Security Task Force. October. Research and Innovative Technology Administration (RITA). May 2007. National ITS Architecture, Version 6.0. www.its.dot.gov/arch/index.htm. Research and Innovative Technology Administration (RITA), National ITS Architecture Security Document. May 2007. www.its.dot.gov/arch/index.htm. REVIEW QUESTIONS 13 U.S. Department of Homeland Security. 2005. State and Urban Area Homeland Security Strategy. ‘‘Guidance on Aligning Strategies with the National Preparedness Goal.’’ July. U.S. Department of State. (2004). Significant Terrorist Incidents, 1961–2003: A Brief Chronology. Office of the Historian, Bureau of Public Affairs, U.S. Department of State. Available at: http://www.state.gov/r/pa/ho/pubs/fs/5902.htm (assessed June 2007). U.S. Department of Transportation (U.S. DOT), Federal Highway Administration (FHWA.) 2005, Intelligent Transportation Systems Benefits, Costs and Lessons Learned: 2005 Update, Report Number FHWA-OP-05-002, Washington, D.C. U.S. General Accounting Office. 2004. Report to the Ranking Minority Member, Committee on Commerce, Science, and Transportation, U.S. Senate. ‘‘Many Factors Affect Transportation Investment Decisions.’’ June. REVIEW QUESTIONS 1. Differentiate between natural hazards and terrorist threats in terms of protection and impacts. 2. Why is the perception of security so important for a society? 3. Provide a summary of attacks on transportation infrastructure around the world and their impacts. 4. Provide two scenarios where transportation security concerns will impact a highway engineer. 5. What is ITS? How can risks to our transportation system be minimized with ITS infrastructure? 6. Identify the stakeholders who are responsible for providing transportation security in your region and their roles in this capacity. CHAPTER 2 NEED FOR SURFACE TRANSPORTATION INFRASTRUCTURE SECURITY T his chapter presents the vulnerabilities of the surface transportation system and provides examples of situations when these vulnerabilities have been exploited by natural or man-made disasters. Through these examples and the lessons learned from them, we explain why surface transportation infrastructure security is necessary. 2.1 VULNERABILITIES Vulnerabilities will always exist in surface transportation systems because of their characteristically open nature. Controlling access to freeways, transit systems, and other surface transportation facilities can significantly impact the way we travel, our quality of life, our economies, and our prosperity. Therefore, it is more tangible to mitigate these vulnerabilities while keeping our access to surface transportation systems open. A level of interdependence frequently exists within our transportation system that can either reduce or spread the impact of regionally significant incidents. The prevalence of alternate routes adjacent to freeways can lessen the impact of incidents on such roads, allowing travelers to reroute in the event of such an incident. Further, the multiple routes that often serve most major metropolitan areas also provide redundancy against security incidents. Interconnected traffic management centers (TMCs), however, Transportation Infrastructure Security Utilizing Intelligent Transportation Systems R. Fries, M. Chowdhury and J. Brummond Copyright © 2009 John Wiley & Sons, Inc. 14 2.1 VULNERABILITIES 15 could allow one computer virus to partially or completely disable the functionality of the TMC and the traffic controls at multiple intersections. This vulnerability is of particular concern for agencies connected to other agency’s systems. Similar systems exist to control transit systems, freight operations, and ports. Although identifying vulnerabilities is an important part of managing security needs, a one-time assessment is not enough. Because security threats constantly evolve to circumvent prevention initiatives and because new technologies keep changing the face of transportation infrastructure, vulnerabilities must be reassessed in an ongoing process. Many tools exist to help practitioners and researchers identify and rank these vulnerabilities, including planning and analysis guidance, such as the National Infrastructure Protection Plan of the U.S. Department of Homeland Security (DHS) (U.S. DHS 2006) and the Guide to Highway Vulnerability Assessment for Critical Asset Identification and Protection by the American Association of State Highway Transportation Officials (AASHTO 2002). Other more infrastructure-or location-specific works, although not as universally adopted, can provide insight to those seeking to identify and address specific vulnerabilities. Recent works have offered methods for vulnerability assessments, highway risk assessments, funding allocation, and traffic management center risk assessment. Hood et al. present a methodology for transportation vulnerability assessment that weighs the vulnerability of an infrastructure element against the criticality of that element, considering vehicle, user, infrastructure, social setting, and environment as elements. This approach requires a large amount of data but uses workshops that stakeholders can use to identify these elements and their associated vulnerabilities (Hood et al. 2003). Xia et al. also present a methodology for risk assessment of highway networks. This model dynamically assesses vulnerability based on three indices: static vulnerability, dynamic vulnerability, and attack potential. Although this model can dynamically identify when key segments of highway are at their highest risk—for example, during rush hour—it requires a large amount of qualitative data (Xia et al. 2005). King et al. developed a method to optimally allocate funding and other resources to address vulnerabilities in transportation facilities. This work identified the similarities and differences between vulnerability assessments conducted for earthquakes and that conducted to prevent or manage terrorist attacks. Overall, impacts to key infrastructure are the same for man-made and natural disasters because they share the same need for an objective vulnerability assessment (King et al. 2003). Roshan et al. applied risk assessment and vulnerability identification to traffic management centers (TMCs). Initially this methodology was applied to three different centers as a field test. Findings from these 16 NEED FOR SURFACE TRANSPORTATION INFRASTRUCTURE SECURITY implementations can help identify vulnerabilities at other TMCs (Roshan et al. 2005). 2.2 COMMON CHARACTERISTICS OF SURFACE TRANSPORTATION SYSTEMS Current travel networks are at or nearing capacity across the country; therefore, incidents on one facility can affect several other nearby facilities and modes. Similarly, as transportation technologies become increasingly interdependent, problems in one system, such as a computer virus, have the potential to impact several other systems. To address these issues, the National Infrastructure Protection Plan (NIPP) seeks to protect the nation’s critical infrastructure and key resources. Although not focusing solely on transportation systems, this plan emphasizes the need for infrastructure security and seeks to manage risks by deterring threats, mitigating vulnerabilities, and minimizing consequences (U.S. DHS 2006). More important, the NIPP provides a common framework for agencies across the United States to identify and rank transportation infrastructure vulnerabilities in a consistent manner. Because today’s freight and traveler transportation systems are highly interconnected, security boundaries need to be defined. Although freight can change modes multiple times before reaching its final destination, security inspections are not, and should not be, conducted on each change. Consistent security coordination between agencies and between modes reduces the need for security inspections when freight changes modes or vehicles. Similarly, providing surveillance at one transit station and not others merely shifts the vulnerability rather than addressing it. After the 2001 terrorist attacks, airline travelers were subjected to the regular security checkpoint and then a further security screening at the gate. Today the security area has been expanded so that security checks at the gate are no longer necessary. Funding is commonly the constraint to securing all locations, but it does not obviate the need for consistent security coordination. Security scenarios appear in many forms, including natural and man-made disasters. These scenarios could affect populated areas of any size, transportation systems for any mode, and take many forms. The possibilities may be endless, but the responses are usually similar. To rehearse these responses, agencies across the United States and abroad conduct full-scale drills to simulate disaster response and to identify problems. Common scenarios that agencies have simulated include bombings on buses and in subway stations, hurricane evacuations, and most recently dirty bombs. These drills have helped agencies identify their weaknesses. For example, a drill testing the security of a transit system in Miami-Dade County, Florida, illustrated how easily uniformed personnel, even without name badges, could access their facility and prompted several security changes (Tarr et al. 2005). 2.3 COMMON THREATS TO SURFACE TRANSPORTATION SYSTEMS 17 2.3 COMMON THREATS TO SURFACE TRANSPORTATION SYSTEMS Common threats to surface transportation systems take many forms and impact various pieces of transportation as we know it. These threats include earthquakes, fires, terrorist attacks, hazardous material (HAZMAT) spills, blackouts, hurricanes and tornadoes, floods, and train derailments. Some of these disasters, such as hurricanes, are not preventable, and authorities must focus on management; for other disasters, such as train derailments, the focus can be shared between prevention and management. After September 11, 2001, AASHTO created the transportation security task force, which determined that security planning was needed in three areas, including protecting critical mobility assets, improving state Department of Transportation emergency response capabilities, and enhancing traffic management capabilities. This task force also identified explosive attacks on key links as the most significant threat to highway infrastructure (Field 2004) and initially identified approximately 50 tunnels and 450 bridges as critical assets (AASHTO 2002). To protect these assets, AASHTO recommended four key countermeasures: 1. Maximize the distance between possible explosive placements and important structures and mechanical systems using barriers. 2. Use locks, caging, and fencing to prevent access to locations where explosives would significantly impact structural integrity. 3. Limit time of intruders by using detection and surveillance systems for secured areas. 4. Use blast shielding and other methods to enforce key members of infrastructure. 2.3.1 Earthquakes Earthquakes can damage highways, bridges, tunnels, and traffic signals. The Loma Prieta 1989 earthquake in California caused unprecedented transportation chaos. In particular, the top level of the two-level raised Cypress freeway in Oakland, California, collapsed. Other earthquake impacts can include buckling, cracking, and sinking of pavement due to liquefaction and movement of the underlying soils. Pavement discontinuities can shut down freeways, airports, and parking facilities. Since many surface transportation technologies require electricity and because earthquakes commonly disrupt power supplies, traffic sensors, aside from possibly being damaged from the earthquake itself, may not be able to provide traffic managers with needed information about the status of transportation facilities. When transportation infrastructure is damaged during earthquakes, the impact is twofold. Not only are motorists and injured victims stranded, but emergency responders are unable to use that road to access emergency 18 NEED FOR SURFACE TRANSPORTATION INFRASTRUCTURE SECURITY locations. This fact could make the postearthquake recovery period more devastating than the initial impacts. 2.3.2 Fires Fires impacting surface transportation systems are most significant in tunnels. A tunnel fire could relate to freeway, freight rail, or passenger rail. While tunnel fires damage the infrastructure and disrupt transportation flows, their more important effect is that they cause injuries and fatalities to travelers. Ventilation and egress remain the two key concerns from such disasters. Much work has been done to mitigate these issues, such as the Memorial Tunnel Fire Ventilation Test Program conducted by the Federal Highway Administration (Luchian 1997) and others (Carvel 2005; Jojo and Chow 2003). Security systems to detect and manage such disasters are important, particularly as many cities with limited surface-level space have relocated freeways to underground. For example, the Boston, Massachusetts, Big Dig Project replaced a 6-lane elevated freeway through its downtown with an 8- to 10-lane expressway directly underneath its previous location. Although this project opened up green space, created room for modest development in downtown, and reconnected parts of the city separated for over half a century, there were significant challenges, including security. Surface roads also can be closed due to fires and their smoke. Fires on surface transportation systems have traditionally been nonmalevolent, caused by fuel spills after vehicular crashes and by forest fires. Fuel spills have the potential not only to damage the pavement but to cause fires to start beside and under the road as drainage systems carry fuels downhill. Smoke closes roads due to visibility problems like those experienced during wildfires in California. 2.3.3 Terrorist Attacks In today’s age of information technology, terrorists can not only attack our surface transportation system with bombs and hijackings, they can attack from within by hacking our transportation control computer systems. Both attack types can carry significant risks if not prevented. Bombs on surface transportation systems have usually focused on public transit, including trains, buses, and ferries, because of the density of travelers and the open access that is necessary for such systems to maintain ridership. The Paris Metro bombings and the Tokyo subway sarin gas attacks in 1995, the events of September 11, the Moscow Metro and the Madrid commuter rail bombings in 2004, and the London Underground bombings in 2005 have ignited worldwide focus on these systems and their undisputed vulnerabilities. While less publicized, hijackings of trains, buses, and trucks are also significant. Perhaps the most noteworthy train hijackings were those in Holland in 1975 and again in 1977. Although few train hijackings since have generated such worldwide attention, vulnerabilities still exist on rail systems. 2.3 COMMON THREATS TO SURFACE TRANSPORTATION SYSTEMS 19 Because of their ability to change routes easily, buses and trucks are more frequent hijacking targets than trains. Of these two, buses are particularly at risk because of their open access to the public and the value of their riders. For example, school buses have been hijacked many times in the United States, including 1976 in Chowchilla, California, 1995 in Miami, Florida, and 2000 in Las Vegas, Nevada. The increasing size of vehicles in the United States also fuels security risks for vehicles used as weapons. Although trucks and buses cannot increase their future size significantly due to the geometry of existing road infrastructure, the average size of personal vehicles can change. The popularity of certain vehicle types, such as sport utility vehicles, and the uncertainty of future fuel types and prices will continue to play a significant role in defining the vulnerability that vehicles pose to infrastructure if used malevolently. 2.3.4 HAZMAT The Hazardous Materials Transportation Uniform Safety Act (1990) was the foundation of today’s safety procedures concerning HAZMATs. This legislation required that HAZMAT carriers obtain permits prior to transporting hazardous materials and provide specific information about that material. Regulations since, particularly after the events of September 11, have become increasingly intensive. Table 2.1 displays a list of materials considered as potential HAZMAT weapons; on the table, ‘‘bulk’’ indicates quantities more than 119 gallons (450 liters). Regulations have greatly improved the safety of the public and environment from HAZMAT, but because over 800,000 HAZMAT shipments depart each TABLE 2.1 Potential HAZMAT Weapons Material Explosives Flammable liquids (e.g., gasoline) Flammable gases (e.g., propane) Flammable solids Hazardous wastes and substances Infectious substances (e.g., anthrax) Nonflammable gases (e.g., anhydrous ammonia) Organic peroxides Oxidizers (e.g., oxygen generators) Pesticides Poisonous gases (e.g., chlorine) Poisonous liquids Radioactive materials Source: USDOT/FMCSA, 2002. Quantity Any quantity Bulk Bulk Bulk Bulk Any quantity Bulk Bulk Any quantity Bulk Any quantity Any quantity Any quantity 20 NEED FOR SURFACE TRANSPORTATION INFRASTRUCTURE SECURITY day in the United States (Stock et al. 2004), risks still exist. Comprehensive and collaborative safety and security systems still are necessary to ensure that each shipment arrives safely at its destination. 2.3.5 Blackouts Due to an increasing reliance on technology in transportation, power outages have the potential to disrupt or even stop transportation networks. Major blackouts have occurred in the United States in 1965, 1977, 1996, and 2003, illustrating how the increasing use of powered technology deepens the impact of a power outage. The blackout in 2003 affected New Jersey, New York, Pennsylvania, Michigan, Ohio, Connecticut, Vermont, and Massachusetts. In New York City alone, 11,600 traffic signals were darkened and 413 subway trains were stopped (DeBlasio 2004). Even if traffic management centers operated on backup power, they were mostly without data to monitor the transportation network because most video cameras and sensors required a working power source. 2.3.6 Hurricanes Hurricanes, because of their high wind speeds and tidal surges, cause the evacuation of large numbers of people. These evacuations almost exclusively use roadway networks, placing a high demand on freeway capacity. To use the existing capacity effectively, authorities in multiple jurisdictions and at multiple levels of government must coordinate to, for example, issue evacuation instructions, reverse freeway lanes, and transport those without personal vehicles. Intelligent transportation systems (ITS) are commonly used to manage evacuations and lane reversals. Permanent infrastructure, such as traffic cameras and dynamic message signs (DMS), are preferred, but they are not always economical due to the rarity of evacuations. Therefore, agencies such as the South Carolina Department of Transportation operate mobile units that include traffic cameras and DMS which can be deployed during such emergencies (Ballard 2007). Further, agencies must establish a backup source of power for their permanent and portable ITS infrastructure during hurricane evacuations. After hurricanes, significant efforts must be made to coordinate recovery. Hurricane Katrina caused an estimated $3 billion in highway damages alone (Burton and Hicks 2005), destroyed almost half of the transit streetcars that operated in New Orleans (Luczak 2007), and damaged or destroyed six key railroad bridges along the Gulf Coast Main Trunk of CSXT (SimmonsBoardman 2005). These impacts, shown in part in Figure 2.1, affect all modes of transportation. Extensive financial efforts and leadership are required to rebuild not only the infrastructure but the communities. 2.3 COMMON THREATS TO SURFACE TRANSPORTATION SYSTEMS 21 Figure 2.1 U.S. Route 90 after Hurricane Katrina (2005). 2.3.7 Floods Closely related to hurricanes, floods can merit evacuations and sever transportation links simultaneously. While interstate freeways are built to remain functional in the event of a 100-year flood, state and local roads are usually built with more focus on budget. Floods can occur with little-to-no warning and break transportation links, requiring emergency and transportation management to reduce the threat to lives, infrastructure, and reduce delay. Flooding can also block waterways with debris. Figure 2.2 shows the results of flooding in Gulfport, Mississippi after Hurricane Katrina in 2005. To manage the impacts of flooding, departments of transportation often use environmental monitoring systems. Combined with traffic cameras for verification, these monitoring systems can provide an effective way of identifying water on roadways. Based on the severity of flooding, traffic management officials can select a response by activating flashing lights on signs stating, ‘‘Watch for Water on Road,’’ as used by the Houston, Transtar traffic management system, by activating dynamic message signs, or by closing bridges or roads. The United States Geological Survey and the National Weather Service’s flash flood monitoring and prediction initiative as well as transportation researchers are striving to warn travelers of possible floods with increasing speed and accuracy. 22 NEED FOR SURFACE TRANSPORTATION INFRASTRUCTURE SECURITY Figure 2.2 Flooding in Gulfport, Mississippi (2005). 2.3.8 Biological and Chemical Attacks Although biological and chemical attacks seemingly carry similar threats, they are significantly different. A biological attack disperses living organisms, including bacteria and viruses, which can incubate for days or weeks. After this incubation period, those exposed have the potential to infect others, thus making it difficult for medical and public health personnel to isolate victims and stop the spread. It is also difficult to identify the time and location of such an attack. A chemical attack, however, can disperse toxic synthetic- or biologically based chemicals that have more immediate effects than biological agents. Victims need not be isolated, but they must be decontaminated. Therefore, the spread of chemical attacks is more easily prevented than that of a biological attack (Henderson 1999). One of the better-known chemical attacks was the 1995 sarin gas attacks on the Tokyo subway. Sarin, a nerve agent similar to some insecticides, was released on several lines of the Tokyo subway during a morning rush hour by domestic terrorists. This attack killed 12, severely injured 50, and caused shortterm vision problems for approximately 1,000 others. Review of this incident suggested that agencies coordinate their efforts through disaster drills, that poison control centers play an increased role and stressed the need for real-time communication availability and redundancy (Okumura et al. 1998). 2.3 COMMON THREATS TO SURFACE TRANSPORTATION SYSTEMS 23 2.3.9 Derailment Because railroads represent a vast network of tracks, bridges, and crossing gates, they are as difficult to secure as a nation’s highways. Train derailments represent a significant risk because of their likelihood and their significant impact. In January 2005, a train derailment in Graniteville, South Carolina, sent a plume of chlorine gas into the air as a 90-ton tank car was ruptured. The spilled gas killed 9 residents and injured 550 (National Transportation Safety Board 2005). Figure 2.3 shows 90-ton tank cars on a comparable South Carolina railway. Similarly, a train collision in Bexar County, Texas, in June 2004 spilled chlorine gas and anhydrous ammonia, killing 3 people and injuring 41 (Mitchell et al. 2005). High-speed passenger rail is at greater risk for damage from derailment than freight because the train cars are lighter and faster (Zaworski and HunterZaworksi 2004). To limit derailment risks for both freight and passenger lines, agencies can use many monitoring systems to help identify obstacles on tracks, particularly at rail-grade crossings. Advances in optical sensors have shown promise for monitoring these locations. 2.3.10 Cyber Attacks Because many traffic management centers are linked to the Internet to provide travelers with real-time information, the risk of cyber attacks is higher than ever before. Firewalls prevent many attacks from gaining control of ITS systems, but programmers with inside knowledge of such systems still pose a threat. The end result of such a threat can range from a full computer system crash, to opening dual access, to contra-flow systems (NMAB et al. 1999). Most recent cyber risks have come in the form of stolen computers, particularly laptops. After two Figure 2.3 90-ton Chlorine Rail Cars. 24 NEED FOR SURFACE TRANSPORTATION INFRASTRUCTURE SECURITY laptops containing the personal information of over 3,000 HAZMAT truckers were lost/stolen from the U.S. Transportation Security Administration (TSA) in 2007, data encryption became mandatory on all computers used by the TSA and its contractors. 2.4 DEFENDING AGAINST THREATS BOTH EXTERNAL AND INTERNAL To defend against threats, transportation agencies, both public and private, use various tools. These tools can be categorized by their use in prevention, management, or recovery. Prevention tools include surveillance systems, data encryption, and even padlocks. Management also can include surveillance systems and data encryption, plus additional tools, such as fire and water containment systems and information dissemination systems. The recovery category uses information dissemination to inform motorists of available routes, surveillance to help inspect facilities for debris, and various other tools, depending on the type of incident. This section focuses on defending against threats and reviews tools aimed at prevention. One of the most popular tools used in surveillance is closed circuit television (CCTV), as shown in Figure 2.4. Many public transportation agencies have installed CCTV for use as traffic cameras to detect and verify traffic incidents on freeways, such as crashes. As security emphasis increases, these devices can serve a dual purpose, which further increases their value to the public. Data encryption, while commonplace in the computing world, has just begun to be applied to transportation management. Public agencies generally overlook the need for data encryption for communication between traffic signals, to and from traffic cameras, and to and from remote access gates. Vulnerability assessments, as discussed in later chapters, can help identify which of these communications links are at risk and which can cause the most significant impact if disabled, disrupted, or commandeered. Lock-and-key is arguably the oldest forms of security and still is used to security vital parts of our surface transportation infrastructure. Traffic signal equipment cabinets, rail crossing gate controls, and traffic camera control cabinets are all frequently secured using locks. This security method is adequate to mitigate the risks for many of these devices, but facilities such as traffic or transit management centers, require more failsafe security measures. To identify potential weaknesses and communication problems, agencies across the United States and abroad conduct security drills. During these drills, a full-scale event, such as a bus bombing, is simulated, and emergency agencies (fire, police, medical responders, and transportation management agencies) respond accordingly. Drills normally measure evacuation efficiency, time required and transportation methods use to transport victims to local hospitals, and communication latency between public safety responders. Findings from drills and other security-related research suggest that redundancy is one of the best existing defenses against most transportation security 2.4 DEFENDING AGAINST THREATS BOTH EXTERNAL AND INTERNAL 25 Figure 2.4 Traffic Camera for Security and Traffic Management. incidents. Due to the massive size of transportation infrastructure systems in and around most cities, there exist many routes and more than one way to complete most journeys. EXERCISE Form a group of three to five members and answer these questions about your local area. 1. What security-related tools exist in the area (even if they are not currently being used for that purpose)? 26 NEED FOR SURFACE TRANSPORTATION INFRASTRUCTURE SECURITY 2. Could these tools be used for prevention, management, or recovery of security incidents? (More than one may apply.) 3. Based on the size of your community and the amount of infrastructure to protect, name two security-related projects you would recommend in the next five years. Be sure to state why it is important and which agency should lead the initiative. 2.5 WHY TRANSPORTATION INFRASTRUCTURE SECURITY IS IMPORTANT Effective transportation infrastructure security can mean the difference between repeating the mistakes of the past and preventing or properly managing disasters in the future (Fries et al. 2008). Loss of life is a relatively immediate potential impact of a security incident, but long-term impacts can propagate like shockwaves to affect individuals, travelers, and businesses far and wide, further underscoring the need for such security. Globalization and just-in-time shipping can cause an incident in one region or country to propagate and impact several others. For example, the loss of a key highway bridge will delay both travelers and freight and may cause them to reroute or change travel modes to reach their final destination, or postpone the trip entirely. The loss of the highway bridge represents a large cost, but the delay to travelers and goods while the link is cut is more significant. Depending on the size of the incident, this delay has the potential to cross political boundaries and impact neighboring states, countries, and regions. Developed countries have larger amounts of transportation infrastructure to protect than developing nations. In 2006 Europe accounted for 38.7 percent of the global transportation infrastructure industry, followed by the Asia-Pacific regions with 32.8 percent, and the United States with 20 percent. The rest of the world accounted for only 8.4 percent of the global transportation infrastructure industry. These industry distributions are a direct result of higher level of government spending on transportation infrastructure in developed countries (Data Monitor 2007). Despite the disparity in infrastructure quantity in different countries, it is important to maintain consistent security while trading worldwide. Because of political differences, level of development, and unique regional threats, security between countries will never be exactly the same. It is important, however, to recognize the different levels of security required by each country to maintain the flow of goods. To aid with the flow of goods between countries, carriers that have been certified by the U.S. Customs and Border Protection unit as secure are able to conduct prescreening of goods prior to leaving the country of origin. This helps inspections of goods at their destinations, but carriers must protect the goods from tampering during shipment. Tamper monitors, similar to those used for intranational shipping, can provide this verification. 2.6 FOCUS AREAS 27 2.6 FOCUS AREAS Although recent focus in the United States has overwhelmingly been on air transportation security, attention has now shifted to surface transportation modes (USGAO 2007). In Europe and Japan, the focus traditionally has been on transit systems, due to the history of attacks on such targets. Unfortunately, due to the size of the transit systems and space and time constraints of agencies, most security initiatives are reactive, changing focus after an attack or attempted attack (Jenkins and Gersten 2001). Table 2.2 shows focus areas of the U.S. Transportation Security Administration on the surface transportation system and the general progress as of 2007. The often-limited budgets of transportation agencies often guide the security focus. For example, although the Tokyo sarin gas attack in 1995 undoubtedly changed the security in and around subway systems worldwide, detection systems for such chemical agents are not broadly used, except by the military, due to their cost (Jenkins and Gersten 2001). Focus also is guided by the need for public transportation systems to remain open, which reduces the ability of security authorities to limit access. Facilities such as freeways must remain open to serve the public, and in the case of public transit, a myriad of access points must remain open to maintain ridership, preserving this source of income. Due to these constraints, many current security investments focus on the management of threats rather than prevention. Because terrorists and natural hazards can strike any part of the transportation system at almost any time and because it is unreasonable to protect every part of the system all the time, agencies must identify and focus on the parts most vital to operation, the economy, and human life. TABLE 2.2 Performance Expectations and Progress Made in Surface Transportation Security Performance Expectation Develop and adopt a strategic approach for implementing surface transportation security functions Conduct threat, criticality, and vulnerability assessments of surface transportation assets Issue standards for securing surface transportation modes Conduct compliance inspections for surface transportation systems Administer grant programs for surface transportation security Total Source: USGAO 2007. Generally achieved Generally not achieved H H H H H 3 2 28 NEED FOR SURFACE TRANSPORTATION INFRASTRUCTURE SECURITY Using existing transportation management tools offers a cost-effective way to prevent and manage security threats. Many tools applicable to both transportation management and infrastructure security can be categorized as ITS. ITS deployments are required to meet the FHWA Rule 940.11 entitled ‘‘Intelligent Transportation System (ITS) Architecture and Standards’’ and the FTA Policy entitled ‘‘National ITS Architecture Policy on Transit Projects’’ to ensure their interoperability with future systems, see Appendix C and D, respectively. These rules refer to tailoring regional ITS architectures based on the U.S. National ITS Architecture. The transportation infrastructure security areas as defined in the National ITS Architecture are discussed in Chapter 3. Chapter 7 discusses securing ITS as defined by the national architecture. Other tools practitioners can use for transportation security are under development by the Transportation Security Administration. Within the U.S. Department of Homeland Security, TSA is the primary agency responsible for the transportation area. Although TSA shares security responsibilities with federal, state, and local governments as well as with private transportation agencies, it is solely responsible for national policy making and security standards development (USGAO 2007). The National ITS Architecture specifies a framework and corresponding mappings to standards that are specific to ITS. Additional communications standards are under development by the TSA and other standards development organizations. It is hoped that the TSA standards and the ITS standards will interoperate with each other. 2.7 SUMMARY A plethora of natural and man-made events threaten our surface transportation infrastructure every day. Because it is unreasonable to protect every part of our infrastructure from every threat at every moment, practitioners must identify and focus on critical elements with respect to functionality, economic and cultural value and human life. Further, due to the difficulties in preventing a security incident, initiatives also must focus on response and recovery from events. Many tools in the intelligent transportation systems domain exist to help protect our infrastructure and manage responses; surveillance is one of the more commonly used. The transportation industry continues to learn from past attacks, but it needs to become less reactive and more active in security planning. Effective transportation infrastructure security needs to be an ongoing process, with focus being revised continually and techniques being refined. REFERENCES American Association of State Highway and Transportation Officials (AASHTO). 2002. A Guide to Highway Vulnerability Assessment for Critical Asset Identification and Protection. Contractor’s Final Report. REFERENCES 29 American Association of State Highway and Transportation Officials. 2002. ‘‘National Needs Assessment for Ensuring Transportation Infrastructure Security, Contractor’s Final Report.’’ Ballard, A. J. 2007. ‘‘Traffic Operations for Hurricane Evacuation.’’ Proceedings of the Transportation Research Board Annual Meeting, National Research Council. Burton, M. L., and M. J. Hicks, 2005. ‘‘Hurricane Katrina: Preliminary Estimates of Commercial and Public Sector Damages.’’ Center for Business and Economic Research, Marshall University. Carvel, R. O., et al. 2005. ‘‘Fire Size and Fire Spread in Tunnels with Longitudinal Ventilation Systems,’’ Journal of Fire Sciences 23, No. 6: 485–518. Data Monitor. 2007. ‘‘Global Transportation Infrastructure: Industry Profile. Transportation Infrastructure Industry Profile: Global,’’ March: 1. DeBlasio, A. J., Regan, T. J., Zirker, M. E., Fichter, K. S., Lovejoy, K. 2004. ‘‘Effects of Catastrophic Events on Transportation System Management and Operations: August 2003 Northeast Blackout New York City. DOT-VNTSC-FHWA-04-04#. Field, M. A. 2004. ‘‘Highway Security and Terrorism Review of Policy Research,’’ 21, No. 3: 317–328. Fries, R., M. Chowdhury, and A. Dunning. 2008. ‘‘Transportation Security Framework for a Medium-Sized City.’’ European Journal of Transportation and Infrastructure Research. In press. Henderson DA. The Looming Threat of Bioterrorism. Science. Feb 26, 1999; 283(5406): 1279-82. Hood, J. N., Olivas, T., Slocter, C. B., Howard, B., and Albright, D. P. 2003. Vulnerability Assessment Through Integrated Transportation Analysis. Transportation Research Record, No. 1922. Journal of the Transportation Research Board. Pp 18–23. Jenkins, B. M., and L. N. Gersten, 2001. ‘‘Protecting Public Surface Transportation Against Terrorism and Serious Crime: An Executive Overview.’’ Mineta Transportation Institute. FHWA/CA/OR-2001–29. Jojo, S. M. L., and W. K. Chow. 2003. ‘‘Numerical Studies on Performance Evaluation of Tunnel Ventilation Safety Systems,’’ Tunneling and Underground Space Technology Vol. 18, No. 5 (November): 435–452. King, S.A., Adib, H.R., Drobny, J. and Buchanan, J. (2003). Earthquake and Terrorism Risk Assessment: Similarities and Differences. Presented at the 6th U.S. Conference and Workshop on Lifeline Earthquake Engineering. August 2003, Long Beach, California, USA. Luchian, S. F. 1997. ‘‘Memorial Tunnel Fire Test Program,’’ TR News No. 190: 48–49. Luczak, M. 2007. ‘‘Road to Recovery: Nearly Two Years After Hurricane Katrina, New Orleans RTA is Slowly Building Back Infrastructure, Ridership, and the ‘Big Easy,’’’ Railway Age 208, No. 7: 34–38. Mitchell, J. T., A. S. Edmonds, S. L. Cutter, M. Schmidtlein, R. McCarn, M. E., Hodgson, and S. Duhé. 2005. ‘‘Evacuation Behavior in Response to the Graniteville, South Carolina, Chlorine Spill,’’ Quick Response Research Report 178. Hazards Research Lab, University of South Carolina. National Materials Advisory Board (NMAB), Computer Science and Telecommunications Board (CSTB), and the Transportation Research Board (TRB). 1999. Improving Surface Transportation Security: A Research and Development Strategy. National Academy Press, Washington, D.C. National Transportation Safety Board. 2005. ‘‘Collision of Norfolk Southern Freight Train 192 with Standing Norfolk Southern Local Train P22 with Subsequent Hazardous Materials 30 NEED FOR SURFACE TRANSPORTATION INFRASTRUCTURE SECURITY Release at Graniteville, South Carolina January 6, 2005.’’ Railroad Accident Report, NTSB/RAR-05/04. Okumura, T., K. Suzuki, A. Fukuda, A. Kohama, N. Takasu, A. Ishimatsu, and S. Hinohara 1998. ‘‘The Tokyo Subway Sarin Attack: Disaster Management, Part 1: Community Emergency Response,’’ Academic Emergency Medicine 5: 613–617. Rowshan, S., Sauntry, W.C., Wood, T.M., Churchill, B., and Levine, S.R. (2005). Reducing Security Risk for Transportation Management Centers. Paper presented at the 84th Annual Meeting of the Transportation Research Board, National Research Council, January 2005, Washington, DC. Simmons-Boardman Publishing Corporation. 2005. ‘‘Bridging to Recovery: A Massive Effort to Rebuild Six Major Bridges Following Hurricane Katrina’s Devastation in Now Under Way on CSXTs Gulf Coast Main Trunk,’’ Railway Age 206, No. 11: 46–47. Stock, D., M. Jensen, M. Carter, E. Wik, C. Louisell, and C. Mitchell. 2004. ‘‘Hazardous Materials Safety and Security Technology Field Operational Test Evaluation Final Report.’’ Report for the FMCSA, FHWA-OP-03-XXX. Tarr, R. W., V. McGurk, and C. Jones 2005. ‘‘Intermodal Transportation Safety and Security Issues: Training against Terrorism,’’ Journal of Public Transportation 8, No. 4. 87–102. U.S. Department of Homeland Security. 2006. National Infrastructure Protection Plan. U.S. Government Accountability Office. 2007. ‘‘Transportation Security: Efforts to Strengthen Aviation and Surface Transportation Security are Under Way, but Challenges Remain,’’ Testimony before the Committee on Commerce, Science, and Transportation, U.S. Senate, GAO-08–140T. Xia, J., Chen M., and Liu, R. (2005). A Framework for Risk Assessment of Highway Network. Paper presented at the 84th Annual Meeting of the Transportation Research Board, National Research Council, January, 2005. Washington, DC. Zaworski, J. R., and K. M. Hunter-Zaworksi, 2004. ‘‘Laboratory Detection Technologies for High-Speed Rail Grade Crossings,’’ Transportation Research Record No. 1862: 119–126. REVIEW QUESTIONS 1. Name three tools that can aid in disaster response. 2. Name ten different threats to surface transportation infrastructure. 3. What events have most recently threatened the surface transportation infrastructure in your region? 4. As of 2008, what expectations were still to be met within the US transportation security administration? Have these expectations been met today and how? 5. Select a local route (arterial or highway) and find the HAZMAT restrictions for using it at the Federal Motor Carrier Safety Administration’s (FMCA) website http://hazmat.fmcsa.dot.gov/nhmrr/index.asp?page= route 6. In the nearest major metropolitan area, find out if any transportation agency has recently conducted a security drill and discuss two of their key findings. CHAPTER 3 LEVERAGING ITS TO REDUCE RISK AND EXPOSURE USING ITS SECURITY AREAS S ystems engineering is about partitioning complex systems into manageable and understandable parts with a precise definition of how those parts interact. Because transportation security is a complex undertaking, a systems engineering approach to implementation can facilitate effective and systematic deployment. In developing intelligent transportation systems (ITS) security areas, the U.S. National ITS Architecture Team analyzed the core areas of ITS using a systems engineering process similar to that applied to homeland security. This chapter presents each of the eight security areas and discusses their scope, National ITS Architecture representation, and real-world applicability. 3.1 INTRODUCTION From a systems architecture viewpoint, intelligent transportation systems as a whole can be roughly divided into eight distinct security areas. These security areas are defined in version 6.0 of the National ITS Architecture. This chapter refers to the next definitions of National ITS Architecture elements throughout. Chowdhury and Sadek (2003) provide a detailed description of the National ITS Architecture and its elements, such as physical architecture and market packages. Transportation Infrastructure Security Utilizing Intelligent Transportation Systems R. Fries, M. Chowdhury and J. Brummond Copyright © 2009 John Wiley & Sons, Inc. 31 32 LEVERAGING ITS TO REDUCE RISK AND EXPOSURE USING ITS SECURITY AREAS Logical architecture Defines the processes required to provide the desired functions. Within the National ITS Architecture, these functions are defined as user services and are divided into 33 distinct categories. Physical architecture Developed from the logical architecture by assigning the functional processes and information flows to parts of systems and to communication links. National ITS Architecture developers define these parts of systems as subsystems and these communication links as architecture flows. The functional processes assigned to each subsystem are implemented through a combination of hardware and software to perform similar functions. Terminator An entity that forms the boundary of ITS architecture. ITS must interact with terminators in terms of information exchange, but cannot require logical architecture or functionality from these entities. Common terminators include the media, vehicles, and personnel, since these are elements whose actions are difficult to regulate. Equipment package A collection of similar functions within a particular subsystem that can be grouped together and implemented by a common combination of software and hardware capabilities. Market package A deployment-oriented ITS service. Each market package is defined by at least two subsystems, often one or more terminators, and architecture flows representing the flow of information both between subsystems and between subsystems and terminators. Market packages represent a user-friendly way for practitioners to use ITS architecture in their designs. As an example of how these systems relate, Figure 3.1 shows the Network Surveillance market package, which includes: Subsystems Traffic management Roadway Information service provider (secondary) Equipment Packages Collect traffic surveillance Traffic maintenance Roadway basic surveillance Roadway equipment coordination Terminators Traffic operations personnel Map update provider Other roadway Traffic 3.1 INTRODUCTION 33 ATMS01 – Network Surveillance Information Service Provider road network conditions Traffic Management Other Roadway roadway equipment coordination traffic operator inputs Traffic Operations Personnel Map Update Provider traffic operator data map update requests Collect Traffic Surveillance map updates Traffic Maintenance traffic flow + traffic images Roadway traffic sensor control + video surveillance control Roadway Basic Surveillance Roadway Equipment Coordination traffic characteristics Traffic Figure 3.1 Network Surveillance Market Package and Architecture. [RITA (Research and Innovative Technology Administration), National ITS Architecture 6.0, 2007.] Architecture Flows Map updates Roadway equipment coordination Traffic flow Traffic images Traffic characteristics Road network conditions Map update request Traffic sensor control Video surveillance control Traffic operator data Traffic operator inputs The market package figures only show a subset of the architecture entities and flows. For a complete list of all entities and flows in a market package please consult the National ITS Architecture’s market package section. Although many market packages touch on security, some are inherently securityoriented. Some examples of market packages that are based on security principles include Transit Security (APTS05) and Disaster Response and Recovery (EM08). Each market package has a short market package ID, which identifies its family (i.e., APTS stands for advanced public transit system; EM is Emergency Management) along with a number identifier. Next we discuss market packages as they relate to particular security areas. 34 LEVERAGING ITS TO REDUCE RISK AND EXPOSURE USING ITS SECURITY AREAS Due to the rich diversity of ITS functionality, the National ITS Architecture defines eight security areas: 1. 2. 3. 4. 5. 6. 7. 8. Disaster Response and Evacuation. Freight and Commercial Vehicle Security. HAZMAT Security. ITS Wide Area Alert. Rail Security. Transit Security. Transportation Infrastructure Security. Traveler Security. These eight security areas, displayed in Figure 3.2, are tied into the functional pieces of the National ITS Architecture and contain information flows both internal and external to the given area. Security elements were added to and enhanced in the National ITS Architecture as Version 4.0 changed into Version 5.0, recognizing security as a significant focus. In Version 4.0 of the architecture, the Traveler Security area was the focus of all security. The most recent version of the National ITS Architecture, Version 6.0 (RITA 2007), has been only slightly enhanced from Version 5.0 with respect to security. Version 6.0’s focus was modeling the major U.S. Department of Transportation initiatives, including Vehicle Infrastructure Integration (VII), Clarus (a nationwide weather observation and forecasting clearinghouse), and Emergency Management Operations (EMO). This chapter defines and discusses the eight security areas. Subsequent chapters will explore the relationship between Figure 3.2 Security Areas from the National ITS Architecture. (Source: RITA, National ITS Architecture 6.0, May 2007.) 3.2 DISASTER RESPONSE AND EVACUATION 35 these areas and other modes of transportation (e.g., air). This chapter explores each security area by providing the overall definition from the National ITS Architecture as well as the key entities and interfaces. It is also important to note that the ITS itself must be secure in order for each security area to be effective. Chapter 7 discusses the threats, objectives and security services necessary for securing ITS. 3.2 DISASTER RESPONSE AND EVACUATION In the wake of multiple natural disasters hitting the state of Florida as well as Hurricane Katrina hitting New Orleans, the Disaster Response and Evacuation Security Area provides insight and a model on how ITS can improve disaster response and evacuation as well as recovery. The Disaster Response and Evacuation (DRE) Security Area uses intelligent transportation systems to enhance the ability of the surface transportation system to respond to and recover from natural disasters, terrorist acts, and other catastrophic events. DRE improves access to the scene for response personnel and resources, provides better information about the transportation system in the vicinity of the disaster, supports resource coordination and sharing of current situation information, and provides more efficient, safer evacuation for the general public if needed. All types of disasters are considered including natural disasters (hurricanes, earthquakes, floods, winter storms, tsunamis, etc.) and technological and manmade disasters (hazardous materials incidents, nuclear power plant accidents, and national security emergencies such as terrorism, nuclear, chemical, biological, and radiological weapons attacks.) Broad inter-agency coordination is critical in all disaster scenarios, with transportation professionals performing well-defined roles in the larger context of the multi-agency response to the disaster. DRE defines how ITS can be used to coordinate and integrate the disaster response and evacuation activities within diverse organizations. This aims to improve the safety of the responders and the public at large, and improve the performance and effectiveness of the transportation system as a part of the overall disaster response (RITA, National ITS Architecture 6.0, May 2007). DRE is central to the Emergency Management subsystem of the physical architecture view of the National ITS Architecture. It represents both the Emergency Operations Centers (EOCs) and the Incident Command Systems (ICSs) that are established before or when a disaster strikes and last through reentry into the affected area and recovery. DRE is comprised of the disaster response and evacuation interfaces to all levels of public safety, emergency management, and other allied response agencies. This security area focuses primarily on these interfaces, or the information flowing between the Emergency Management subsystem and other entities, both subsystems and terminators, that represent maintenance and construction management, traffic management, 36 LEVERAGING ITS TO REDUCE RISK AND EXPOSURE USING ITS SECURITY AREAS transit management, information service providers of traveler information, rail operations, and so on. As previously discussed, the EM subsystem is one critical piece of the DRE security area. With other subsystems and terminators, it is found in four National ITS Architecture market packages: 1. 2. 3. 4. Early Warning System (EM07). Disaster Response and Recovery (EM08). Evacuation and Reentry Management (EM09). Disaster Traveler Information (EM10). The Early Warning System market package, displayed in Figure 3.3, contains the capability to monitor and detect potential and actual disasters including natural disasters, such as tornadoes, hurricanes, earthquakes, and winter storms, as well as technological and man-made disasters, such as hazardous material incidents, nuclear, biological, and chemical attacks or events. It receives alerts and advisories from such systems as the National Weather Service, National Hurricane Center, National Warning System, Information Sharing and Analysis EM07 - Early Warning System transportation weather information request Surface Transportation Weather Service transportation weather information Alerting and Advisory Systems Field Secure Area Sensor Monitoring secure area surveillance control + secure area sensor control secure area surveillance data + secure area sensor data incident report + threat information coordination Other Emergency Management incident report + threat information coordination Traffic Management TMC Incident Detection alerts and advisories incident information secure area surveillance control + secure area sensor control Security Monitoring threat information incident information secure area surveillance data + secure area sensor data Remote Traveler Support Field Secure Area Surveillance Emergency Management Transit Management transit emergency data threat information incident information Emergency Environmental Monitoring threat information Emergency Early Warning System Transit Center Security Maintenance and Construction Management MCM Incident Management Center Secure Area Sensor Management weather information Center Secure Area Surveillance Weather Service Figure 3.3 Early Warning System Market Package. (Source: RITA, National ITS Architecture 6.0, May 2007.) 3.2 DISASTER RESPONSE AND EVACUATION 37 Centers, the National Infrastructure Protection Center, and the Homeland Security Advisory System. It can be connected to field sensors and surveillance through the Security Monitoring subsystem. This market package contains the capability to determine which agencies should be notified of potential or actual threats with specific interfaces to other emergency management, traffic management, transit management and maintenance, and construction management agencies. The Disaster Response and Recovery market package illustrated in Figure 3.4, was created in part from other source material, including the 2001 Hampton Roads Hurricane Traffic Control Plan, needs from the ‘‘A Guide to Updating Highway Emergency Response Plans for Terrorist Incidents,’’ and a study of the hurricane evacuation performed by Florida DOT for Hurricane Floyd in 1999. The user needs identified in these documents were expanded and refined to cover all transportation agencies and all types of disasters. As expected, this market package is complex and deals with management of disasters through the phases of planning and preparation, detection, verification, initial response, resource management, system monitoring and management and critical service restoration. The Emergency Management subsystem is in the center of the market package and is responsible for incident command as well as emergency EM08 - Disaster Response and Recovery emergency transit service request Transit Management Transit Center Security emergency plan coordination Emergency Management resource coordination incident response coordination incident response status + emergency plan coordination transportation system status transportation system status emergency transit service response incident command information coordination transit system status assessment + rail system status assessment emergency transit schedule information emergency transit schedule information emergency plan coordination incident response status + transportation system status Other Emergency Management Rail Operations resource request Traffic Management transportation information for operations resource deployment status emergency plan coordination Information Service Provider emergency traffic control information road network status assessment road network conditions incident response status + transportation system status TMC Incident Dispatch Coordination/ Communication Incident Command maint and constr resource response + road network status assessment Emergency Response Management Maintenance and Construction Management emergency plan coordination transportation system status + emergency traffic control request incident response status + maint and constr resource request maintenance and construction resource request maintenance and construction resource response road network status assessment MCM Incident Management MCM Roadway Maintenance and Construction maintenance and construction resource coordination traffic information coordination + traffic control coordination Other Traffic Management Other MCM Figure 3.4 Disaster Response and Recovery Market Package. (Source: RITA, National ITS Architecture, May 2007, www.its.dot.gov/arch/index.htm.) 38 LEVERAGING ITS TO REDUCE RISK AND EXPOSURE USING ITS SECURITY AREAS response management. It works in concert with the Traffic Management, Transit Management, Information Service Provider, and Maintenance and Construction Management subsystems as well as the Rail Operations and public health system terminators. The Evacuation and Reentry Management market package, shown in Figure 3.5, deals with the movement of people out of and back into the area affected by the disaster. Again, the Emergency Management subsystem is in the center of the market package and is responsible for emergency evacuation support. It works in concert with the Traffic Management, Transit Management, Toll Administration, Information Service Provider, and Maintenance and Construction Management subsystems as well as the Rail Operations, Shelter Providers, and Public Health System terminators. One of the outcomes from the aftermath of Hurricane Katrina hitting the Gulf Coast in 2005 was recognition of the need for a robust recovery plan beyond the short time period after the disaster and including these critical issues (Willhite 2007): Traffic management plan Command and control EM09 - Evacuation and Reentry Management evacuation information Rail Operations Toll Administration Transit Management emergency plan coordination Emergency Management toll service change request Shelter Providers Other EM Maintenance and Construction evacuation information Management maint and constr resource request toll service change response maint and constr resource response MCM Incident Management evacuation information emergency transit service request public health request public health response emergency plan coordination Transit Evacuation Support emergency plan coordination emergency transit schedule information + emergency transit service response emergency traffic control request evacuation information shelter information emergency traffic control information evacuation information emergency plan coordination evacuation coordination Public Health System Traffic Management TMC Evacuation Support emergency plan coordination Emergency Evacuation Support traffic information coordination traffic control coordination Other TM Figure 3.5 Evacuation and Reentry Management Market Package. (Source: RITA, National ITS Architecture 6.0, May 2007.) 3.2 DISASTER RESPONSE AND EVACUATION 39 Figure 3.6 Hampton Roads Hurricane Gate. (Source: U.S. Coast Guard, www.virginiadot. org/travel/resources/hurricaneEvacuation1.pdf.) Evacuating people with special needs Moving fuel Both the Disaster Response and Recovery and the Evacuation and Reentry Management market packages contain the capabilities to help with these critical needs. For example, these market packages have been used to coordinate the traffic management plan for hurricane evacuation of the Hampton Roads area in Virginia. In the Hampton Roads Hurricane Traffic Control Plan, the primary evacuation route uses all lanes on Interstate 64, reversing the eastbound lanes to support the evacuating westbound demand. All lanes on I-64 will carry traffic westbound for about 75 miles from just before the Hampton Roads Bridge Tunnel to I-295 in Richmond, Virginia. To prevent motorists from driving the wrong way during a lane reversal, the Virginia Department of Transportation (2001) is installing hurricane gates along I-64 eastbound, as shown in Figure 3.6. The Disaster Traveler Information market package, shown in Figure 3.7, deals with information dissemination to the traveling public. The central subsystem is the Information Service Provider (ISP), an agency collecting data from the Emergency Management subsystem and to a lesser extent from the Traffic Management and Transit Management subsystems. In addition, information from the Care Facility, Shelter Providers, Yellow Pages Service Providers, Surface Transportation Weather Service, and the Weather Service terminators is integrated into disaster-related traveler information by the ISP. This traveler information is disseminated through the Personal Information Access, Remote Traveler Support, and Vehicle subsystems as well as the Telecommunications System for Traveler Information (511), and back to the shelter providers. At the same time, the Emergency Management subsystem is providing incident information to the Emergency Telecommunications System for the public and to the Media terminators. This market package provides information about the disaster area, including damage to the transportation system, detours and closures in effect, special traffic restrictions and allowances, special transit schedules, and real-time information on traffic conditions and transit system performance in and around the disaster. It also provides emergency information to assist the public with evacuations, including information on mandatory and voluntary evacuation zones, evacuation times, and instructions. 40 LEVERAGING ITS TO REDUCE RISK AND EXPOSURE USING ITS SECURITY AREAS EM10 – Disaster Traveler Information Information Service Provider Emergency Telecommunications System incident information for public Emergency Management incident information for media Personal Information Access* emergency traveler information request emergency traveler information Personal Basic Information Reception Personal Interactive Information Reception Media evacuation information Emergency Evacuation Support Emergency Response Management Transit Management Care Facility transportation system status incident information Telecommunications System for Traveler Information Yellow Pages travel service information Service Providers transit information request transportation weather information care facility status emergency traveler information voice based traveler request voice based traveler information Traffic Management travel service information request transit and fare schedules shelter information Shelter Providers road network conditions ISP Traveler Data Collection Traveler Telephone Information ISP Emergency Traveler Information transportation weather information request weather information Surface Transportation Weather Service Weather Service * Identical interface for Remote Traveler Support and VS Figure 3.7 Disaster Traveler Information Market Package. (Source: RITA, National ITS Architecture 6.0, May 2006.) 3.3 FREIGHT AND COMMERCIAL VEHICLE SECURITY Fleet and freight management companies and agencies are increasingly monitoring their fleets and freight for security and economic reasons. As energy prices soar, commercial vehicle routing and assignments become increasingly important in a just-in-time economic environment. It is important to know exactly what is being tracked, including the driver, commercial vehicle, and freight equipment as defined in the next paragraph. It is also important to know if the commercial vehicle or freight equipment has had a breach or tamper attempt. The area of freight and commercial vehicle security considers the awareness aspect of security through the surveillance of either commercial vehicles or freight equipment. Freight equipment includes containers (with or without chassis), the chassis, or trailers. In addition, the interface with intermodal facilities is another aspect of this area. There are four major functions included as part of this security area. —RITA, National ITS Architecture 6.0, May 2007 3.3 FREIGHT AND COMMERCIAL VEHICLE SECURITY 41 The four major aspects of this security area include: 1. Tracking commercial vehicles and freight equipment location with a determination of a route deviation. 2. Monitoring the driver, commercial vehicle, and freight equipment identities. 3. Monitoring a freight equipment for a breach or tamper event. 4. Monitoring the commercial vehicle for a breach or tamper event. Version 6.0 of the National ITS Architecture allows for tracking of containers on a chassis but not the containers themselves. The capability to have particular container tracking may be added to the National ITS Architecture in a future version. There has also been a consensus effort to align the National ITS Architecture and Federal Motor Carrier Safety Administration’s (FMCSA) Commercial Vehicle Information Systems and Networks (CVISN) Architecture. The CVISN program is coordinating the nationwide deployment of specific new capabilities in three areas: 1. Safety Information Exchange. 2. Credentials Administration. 3. Electronic Screening. The carrier’s operation center (called, in terms of the National ITS Architecture, the Fleet and Freight Management Subsystem [FMS]) is responsible for tracking its fleet vehicles or freight equipment and monitoring their routes and location. Based on the location information obtained through tracking, the FMS makes a determination if an asset has deviated from its planned route or location. Another option is for the commercial vehicle’s onboard system to correlate its current location to the planned route and notify the operation center of a route deviation. If a route or location deviation exceeds the previously established boundaries, commonly called a geofence, the operation center would be responsible for formulating a response plan, which would most likely include notifying appropriate public safety agencies. By monitoring the identity of the driver, commercial vehicle, and freight equipment, the carrier’s operation center (i.e., the FMS) determines if an unauthorized change has occurred from the designated assignment. The FMS is responsible for implementing a response plan, which could include notifying appropriate public safety agencies. This security area also supports exchange of assignment information with intermodal facilities and shippers. The last two aspects of the Fleet and Commercial Vehicle Security involve the monitoring of freight equipment and commercial vehicles for a breach or tamper event. Information about a breach or tamper event includes the nature of event, time, location, identities (commercial vehicle, driver, and freight equipment), 42 LEVERAGING ITS TO REDUCE RISK AND EXPOSURE USING ITS SECURITY AREAS and monitoring device status; for freight equipment, it also includes environmental threat sensor readings (nuclear, biological, chemical, etc.). The Freight and Commercial Vehicle Security area is, for the most part, comprised of four market packages in the Commercial Vehicle Operations (CVO) area: 1. 2. 3. 4. Fleet Administration (CVO01). Freight Administration (CVO02). On-board CVO and Freight Safety and Security (CVO08). Freight Assignment Tracking (CVO13). The Fleet Administration market package, displayed in Figure 3.8, includes the capability for the Fleet and Freight Management subsystem (i.e., the carrier’s operations center) to track the commercial vehicle routes and determine route deviations. The FMS also has the capability to have a contingency response plan, which could include notifying appropriate public safety agencies. The Freight Administration market package, illustrated in Figure 3.9, includes the capability for the Fleet and Freight Management subsystem to CVO01 - Fleet Administration Information Service Provider road network conditions Fleet and Freight Management on-board vehicle request on-board vehicle data route deviation alert route request Commercial Vehicle Subsystem driver alert response route plan trip log request trip log fleet manager inquiry + alert response Fleet-Freight fleet status + Manager fleet and freight alerts Fleet Administration driver to fleet request fleet to driver update CVO driver initialization + alert response route restrictions + Commercial credentials status information + Vehicle cvdriver record Administration trip log information + alerts cvdriver record request map update request map updates alarm Commercial Vehicle Driver Emergency Management alerts and advisories Map Update Provider On-board Trip Monitoring vehicle location Vehicle Vehicle Location Determination fleet and freight threat information Alerting and Advisory Systems Figure 3.8 Fleet Administration Market Package. (Source: RITA, National ITS Architecture 6.0, May 2007.) 3.3 FREIGHT AND COMMERCIAL VEHICLE SECURITY 43 CVO02 - Freight Administration Intermodal Freight Shipper intermod CVO coord + breach response intermod CVO coord + freight breach freight monitoring parameters Freight Equipment freight breach + freight equipment information Alerting and Advisory Systems fleet and freight threat information alerts and advisories Emergency Management Fleet and Freight Management alarm Commercial Vehicle and Freight Security Freight Administration and Management Fleet Administration map updates Map Update Provider map update request fleet and freight alerts on-board vehicle request on-board vehicle data freight equipment information freight breach + freight equipment information Commercial Vehicle Subsystem On-board CV Safety and Security CVO driver initialization + alert response Commercial Vehicle alerts Driver On-board Trip Monitoring driver alert response + commercial vehicle On-board Cargo breach Monitoring alert intermod response CVO commercial commercial coord vehicle vehicle Intermodal Freight data data request Depot Vehicle Fleet-Freight Manager Figure 3.9 Freight Administration Market Package. (Source: RITA, National ITS Architecture 6.0, May 2007.) track freight equipment location and determine location deviations as well as breach and tamper events. The FMS monitors the freight equipment by obtaining location information directly from the freight equipment or via the commercial vehicle. In addition, the FMS monitors shipments to make sure that no tampering or breach of security occurs to the freight equipment. In the event of a security-related incident, the Fleet and Freight Management subsystem also has the capability to have a contingency response plan, for example, notifying appropriate public safety agencies. The On-board CVO and Freight Safety and Security market package, as shown in Figure 3.10, includes the capability for the FMS to monitor the security of the commercial vehicle along with the cargo, containers, trailers, and other equipment that are being hauled. It provides the capability to detect and respond to a commercial vehicle or freight equipment breach and tamper events which can be made available to the Commercial Vehicle Check subsystem. Figure 3.11 shows the Freight Assignment Tracking market package, which provides for the planning and tracking of commercial vehicle shipments where the commercial vehicle, the freight equipment, and the commercial vehicle driver are all monitored for consistency with the planned assignment. The FMS determines any unauthorized changes and also has the capability to have a 44 LEVERAGING ITS TO REDUCE RISK AND EXPOSURE USING ITS SECURITY AREAS CVO08 - On-board CVO and Freight Safety and Security Commercial Vehicle Check CVO inspector information CVC override mode CVO Inspector freight breach + freight equipment information Freight Equipment Driver cv driver credential Identification Card Fleet-Freight Manager on-board safety request + safety inspection request + driver log request + pass/pull-in Commercial Vehicle Fleet and Freight Management on-board safety request driver alert response on-board safety data commercial vehicle breach safety inspection record Citation and Accident Electronic Recording Roadside Safety and Security Inspection CVO pass/pull-in message Commercial Vehicle Driver commercial vehicle breach + freight equipment information + on-board safety data+ driver log + expected driver identity characteristics + tag data + commercial vehicle disable status CVO pass/pull-in message + alerts alert response alert response + fleet manager inquiry fleet status + fleet and freight alerts freight freight breach equipment information commercial vehicle measures Commercial Vehicle and Freight Security Fleet Maintenance Management Basic Commercial Vehicle alarm Emergency Management On-board Cargo Monitoring On-board CV Safety and Security fleet and freight threat information alerts and advisories Alerting and Advisory Systems Figure 3.10 On-board CVO and Freight Safety and Security Market Package. (Source: RITA, National ITS Architecture 6.0, May 2007.) contingency response plan, which could include notifying appropriate public safety agencies. 3.4 HAZMAT SECURITY The HAZMAT Security area’s purpose is to reduce the likelihood of a successful hijacking of security sensitive HAZMAT cargo and its subsequent use as a weapon. —RITA, National ITS Architecture 6.0, May 2007 This security area is an extension of the previous Freight and Commercial Vehicle security area but with an emphasis on Hazardous Material. This security area includes the tracking of security-sensitive HAZMAT cargo-carrying commercial vehicles. If there is an unexpected and significant deviation from the assigned route or traversal on restricted roadways, the FMS can notify the appropriate public safety agency. The commercial carrier’s operations center (FMS) has autonomy to protect confidential operational information of their businesses, determining the significance of the route deviation and deciding whether to notify appropriate public safety agencies. 3.4 HAZMAT SECURITY 45 CVO13 – Freight Assignment Tracking Intermodal Freight Shipper freight transport booking Intermodal Freight Depot booking status Freight Equipment booking status freight equipment information Fleet and Freight Management Emergency Management Commercial Vehicle Subsystem alarm Commercial Vehicle and Freight Security Freight Administration and Management On-board Driver Authentication identities Fleet Administration fleet and freight alerts On-board Cargo Monitoring driver identity characteristics On-board Trip Monitoring alert response commercial vehicle measures Fleet-Freight Manager fleet and freight threat information Commercial Vehicle Driver alerts and advisories Alerting and Advisory Systems Basic Commercial Vehicle cv driver credential Driver Identification Card Figure 3.11 Freight Assignment Tracking Market Package. (Source: RITA, National ITS Architecture 6.0, May 2007.) As part of the extension from the Freight and Commercial Vehicle security area, this security area includes the detection of security-sensitive HAZMAT cargo on commercial vehicles by remote sensing and imaging from the roadside. In conjunction with reading electronic tag information (carrier ID, vehicle ID and driver ID) from a commercial vehicle (CV), any detected security-sensitive HAZMAT can be correlated with existing credentials to determine if the cargo being carried is a permitted operation. If not, the vehicle can be asked to pull in, and appropriate public safety agencies may be notified. Another aspect of this security area is the authentication of drivers and subsequent notification of appropriate public safety agencies if an unauthorized driver attempts to operate a vehicle carrying security-sensitive HAZMAT. Similar to the tracking of HAZMAT cargo, the carrier’s operations center acts to validate and verify any discrepancies prior to public safety agency notification. The HAZMAT Security area is primarily represented by four market packages in the National ITS Architecture: 1. Fleet Administration (CVO01). 2. CV Administrative Processes (CVO04). 46 LEVERAGING ITS TO REDUCE RISK AND EXPOSURE USING ITS SECURITY AREAS 3. Roadside HAZMAT Security Detection and Mitigation (CVO11). 4. CV Driver Security Authentication (CVO12). The previously discussed Fleet Administration market package, illustrated in Figure 3.8, includes the capability to track commercial vehicles, especially those carrying HAZMAT, by a carrier’s operations center. If the carrier’s operations center notices a significant discrepancy, it may notify appropriate public safety agencies. The CV Administrative Processes market package, shown in Figure 3.12, includes the distribution by the Commercial Vehicle Administration subsystem of possible local and national HAZMAT routes with associated administrative restrictions by date and time and for specific classes of HAZMAT cargoes. The Roadside HAZMAT Security Detection and Mitigation market package, as shown in Figure 3.13, is used to detect HAZMAT cargo using roadside sensors and correlate the detection with existing credentials to determine if a detected HAZMAT cargo is a permitted activity. If a nonpermitted activity is detected, the Commercial Vehicle Check station could signal the vehicle to pull off the road. The CV Driver Security Authentication market package authenticates a commercial vehicle driver based on information downloaded to the vehicle from the carrier’s operation center, as displayed CVO04 - CV Administrative Processes route restrictions + Maintenance and current asset restrictions Construction Management Financial Institution Enforcement Agency Commercial credentials information + Vehicle credentials status information + Administration compliance review report + safety status information + cv driver record credential application + audit data + tax filing payment request Fleet and Freight Management Fleet Administration Fleet Credentials and Taxes Management and Reporting transaction status route restrictions information on violators route restrictions safety status information + credentials information + credential fee coordination + Other CVAS credentials status information + route restrictions + citation + accident report + cv driver record Credentials and Taxes Administration CV Information Exchange Information Service Provider Map Update Provider credentials information + safety status information + credentials status information + cv driver record CVO Information Requestor cv driver record request Figure 3.12 CV Administrative Processes Market Package. (Source: RITA, National ITS Architecture 6.0, May 2007.) 3.5 ITS WIDE AREA ALERT 47 CVO11 – Roadside HAZMAT Security Detection and Mitigation Freight Equipment Basic Commercial Vehicle CVO weight and presence + identification information hazmat environmental factors Commercial Vehicle Administration Commercial Vehicle Check credentials information Roadside HAZMAT detection CVO pass/pull-in message alarm Emergency Management Emergency Commercial Vehicle Response pass/pull-in Commercial Vehicle Subsystem Commercial Vehicle Driver Figure 3.13 Roadside HAZMAT Security Detection and Mitigation Market Package. (Source: RITA, National ITS Architecture 6.0, May 2007.) in Figure 3.14. If an unauthenticated driver is detected, a vehicle may be safely disabled by the carrier’s operation center. 3.5 ITS WIDE AREA ALERT The ITS Wide Area Alert security area notifies the traveling public in emergency situations such as child abductions, severe weather watches and warnings, natural and human-caused disasters, military operations, and civil emergencies where lives and/or property are at stake. It utilizes ITS driver and traveler information technologies to immediately provide information and instructions to the traveling public, improving public safety and enlisting the public’s help in some scenarios. The ITS technologies supplement and support other emergency and homeland security alert systems such as the Emergency Alert System (EAS). —RITA, National ITS Architecture 6.0, May 2007 Typically, when an emergency situation is reported and verified and the conditions for alert dissemination are satisfied, a designated agency broadcasts emergency information to traffic management and transit management 48 LEVERAGING ITS TO REDUCE RISK AND EXPOSURE USING ITS SECURITY AREAS CVO12 – CV Driver Security Authentication Commercial Vehicle Driver Emergency Management driver identity characteristics Emergency Commercial Vehicle Response Commercial Vehicle Subsystem disable commercial vehicle expected driver identity characteristics alarm Fleet and Freight Management identities commercial vehicle disable cv driver credential On-board Driver Authentication Driver cv driver credential Identification Card Manage CV Driver Identification Figure 3.14 CV Driver Security Authentication Market Package. (Source: RITA, National ITS Architecture 6.0, May 2007.) agencies, information service providers (traveler information), the media, and other ITS systems that involve driver or traveler information capabilities. These agencies, in turn, provide the alert information to the traveling public using ITS technologies such as variable message signs, highway advisory radios, in-vehicle displays, 511 call-in traveler information systems, and traveler information Web sites. The Emergency Management subsystem represents the agency/system that broadcasts the emergency information to the other ITS systems. As defined in the National ITS Architecture, the EM subsystem provides the alert information to the Traffic Management subsystem, Transit Management subsystem, Information Service Provider, Maintenance and Construction Management subsystem, and Toll Administration subsystem, which in turn provide the alert broadcast information to system operators and the traveling public. The ITS Wide Area Alert security area is characterized in the National ITS Architecture by the Wide Area Alert market package, as seen in Figure 3.15. The alert can include instructions for transportation system operators and 3.6 RAIL SECURITY 49 EM06 – Wide-Area Alert Information Telecommunications voice-based alert notification System for Service Provider voice-based traveler request Traveler Information Personal Information Access ISP Traveler Data Collection ISP Emergency Traveler Information Maintenance and Construction Management MCM Incident Management Traveler Telephone Information Other Emergency Management alert notification TMC Traffic Information Dissemination alert status emergency traveler information Remote Basic Information Reception Vehicle Basic Vehicle Reception alert status TMC Incident Dispatch Coordination/ Communication alerts and Alerting and Advisory Systems advisories roadway information system status Roadway Roadway Traffic Information Dissemination Remote Traveler Support Remote Transit Information Services alert notification Emergency Management alert notification coordination Traffic Management roadway information system data alert status alert notification alert status Personal Basic Information Reception Emergency Early Warning System alert notification Toll Administration Toll Operator Alert alert notification alert status Transit Management Transit Center Information Services Transit Center Security transit traveler information transit traveler information + transit vehicle operator information Transit Vehicle Figure 3.15 Wide Area Alert Market Package. (Source: RITA, National ITS Architecture 6.0, May 2007.) information for the traveling public, thus improving public safety and possibly enlisting the public’s help, such as during amber alerts. The ITS technologies also supplement and support other emergency and homeland security alert systems, such as the Emergency Alert System. 3.6 RAIL SECURITY The general area of Rail Security includes ITS functionality to monitor and secure trains, rail cars, fixed assets (track, wayside equipment and highway-rail intersections) and personnel. Rail Security focuses on freight rail. The security aspects of passenger rail are covered under transit security. The current version of the National ITS Architecture addresses a subset of the overall area of rail security, specifically interfaces between rail entities and highway entities. These are the interfaces relating to highway rail intersections (HRI) and the interfaces from rail operations to traffic and emergency management functions of the architecture. —RITA, National ITS Architecture 6.0, May 2007 50 LEVERAGING ITS TO REDUCE RISK AND EXPOSURE USING ITS SECURITY AREAS ATMS14 – Advanced Railroad Grade Crossing Driver driver information Roadway intersection blockage notification hri operational status track status Traffic Traffic Management traffic characteristics Wayside Equipment arriving train information intersection blockage notification hri status crossing permission crossing call Pedestrians hri request HRI Traffic Management hri control data Advanced Rail Crossing hri advisories Rail Operations Figure 3.16 Advanced Railroad Grade Crossing Market Package. (Source: RITA, National ITS Architecture 6.0, May 2007.) The focus of this security area is the surveillance of the HRIs, which is performed in the architecture by the Roadway subsystem. The market package that provides this function is the Advanced Railroad Grade Crossing as displayed in Figure 3.16. The interface between rail operations and the traffic management capabilities is expressed in the architecture as the HRI advisories architecture flow between the Rail Operations terminator and the Traffic Management subsystem and contains incident and advisory information. It is included in market packages Advanced Railroad Grade Crossing, Standard Railroad Grade Crossing, and Railroad Operations Coordination shown in Figures 3.16, 3.17, and 3.18, respectively. The communication interface between rail operations and the emergency management capabilities is expressed in the architecture as the ‘‘incident information’’ and ‘‘rail incident response status’’ architecture flows between the Rail Operations terminator and the Emergency Management subsystem. The market packages that address this interface are Traffic Incident Management System, shown in Figure 3.19, for normal incidents; Disaster Response and Recovery, shown earlier in Figure 3.4, for disaster response; and Evacuation and Reentry Management, also shown earlier in Figure 3.5, for coordination during evacuations and reentry. 3.7 TRANSIT SECURITY The area of transit security addresses passenger, facility, and asset security for passenger rail and bus transit systems. The area addresses surveillance and sensor 3.7 TRANSIT SECURITY 51 ATMS13 – Standard Railroad Grade Crossing Driver driver information Roadway hri operational status track status Traffic traffic characteristics Wayside Equipment hri status Traffic Management crossing permission hri request crossing call HRI Traffic Management hri control data Pedestrians Standard Rail Crossing hri advisories Rail Operations Figure 3.17 Standard Railroad Grade Crossing Market. (Source: RITA, National ITS Architecture 6.0, May 2007.) ATMS15 – Railroad Operations Coordination Rail Operations railroad advisories hri advisories railroad schedules Traffic Management Rail Operations Coordination hri status hri request Roadway hri control data road network conditions Information Service Provider Figure 3.18 Railroad Operations Coordination Market Package. (Source: RITA, National ITS Architecture 6.0, May 2007.) 52 LEVERAGING ITS TO REDUCE RISK AND EXPOSURE USING ITS SECURITY AREAS ATMS08 – Traffic Incident Management System Emergency Vehicle On-board EV Incident Management Communication Other Traffic Management traffic information coordination decision support information road network conditions + incident information +incident response status Emergency + resource deployment status + traffic images incident status Management video surveillance control + traffic sensor control Emergency Personnel intermodal freight traffic confirmation Rail transportation logged incident information information for Information vehicle route + maint and constr TMC Incident operations Service road network Dispatch Coordination/ resource response incident Communication Provider conditions information Event Promoter event plans Roadway Incident Detection Intermodal Freight Depot incident information + maint and constr resource request Maintenance incident information + rail Operations incident response status event plans Roadway Roadway Equipment Coordination + remote surveillance control incident information + incident response status roadway equipment coordination traffic flow + traffic images incident information + resource deployment status incident command information presentation incident command inputs Other Roadway Traffic Management and Construction Management TMC Incident Detection incident information + maint and constr resource request + incident response status incident information + maint and constr resource response Incident Command Emergency Response Management incident response coordination + incident command information coordination incident response status +incident information Other Emergency Management Transit Management MCM Incident Management maint and constr resource coordination Other MCM Figure 3.19 Traffic Incident Management System Market Package. (Source: RITA, National ITS Architecture 6.0, May 2007.) monitoring of transit stations, stops, facilities, infrastructure, and vehicles. The surveillance includes both video and audio surveillance. The sensor monitoring includes threat sensors (e.g. chemical agent, toxic industrial chemical, biological, explosives, thermal, acoustic and radiological sensors), object detection sensors, motion or intrusion detection sensors, and infrastructure integrity sensors. —RITA, National ITS Architecture 6.0, May 2007 The Transit Security area includes buses and passenger rail. Sensors or surveillance data are examined by the Transit Management subsystem for potential threats or overall security of transit properties. Based on this analysis, notification can be made to the appropriate transit or public safety personnel. This security area has the capability for travelers or transit operators to send a mayday alarm that can be forwarded to central dispatch or the appropriate public safety agencies. In addition, this area also provides access control to transit vehicles, requiring positive operator identification before transit vehicles can be operated. Under the threat of a transit vehicle hijack, this security area allows the transit agency to take response measures, such as remote transit vehicle disabling. This security area can also provide 3.7 TRANSIT SECURITY 53 APTS05 - Transit Security Remote Traveler Support Information Service Provider Traveler Secure Area Surveillance Traveler Secure Area Sensor Monitoring Remote Traveler Security transit incident information Media Transit Management transit incidents for media alarm acknowledge + remote vehicle disable threat support data Emergency Alerting and Advisory Systems threat data for analysis + threat Management information Rail threat information Operations alarm notification + secure area surveillance data + secure area sensor data alarm acknowledge + secure area sensor control + secure area surveillance control Security Monitoring Subsystem Field Secure Area Surveillance Field Secure Area Sensor Monitoring Transit Vehicle transit vehicle operator authentication information Transit Center Security secure area surveillance control + secure area sensor control + infrastructure monitoring sensor control transit vehicle location data alarm notification + secure area surveillance data + secure area sensor data alarm notification + transit vehicle location data + transit vehicle conditions transit vehicle operator authentication update secure area surveillance data + secure area sensor data + infrastructure monitoring sensor data On-board Transit Security alarm acknowledge + secure area surveillance control + secure area sensor control transit emergency data incident response status Emergency Response Management Center Secure Area Surveillance Center Secure Area Sensor Management Center Secure Area Alarm Support Figure 3.20 Transit Security Market Package. (Source: RITA, National ITS Architecture 6.0, May 2007.) emergency information to travelers using the transit system equipment, either by visual signs or audio messages onboard the transit vehicle, at transit stops, or in transit facilities. The transit agency can also share pertinent information with appropriate security agencies to assist in analysis of threats and to report threats. The Transit Security area’s primary market package is aptly named Transit Security and is shown in Figure 3.20. This market package includes key interfaces between these architecture entities: Transit Vehicle and Transit Management subsystems: for vehicle operator or traveler–initiated alarms, vehicle operator authentication, and vehicle disabling Transit Management and Emergency Management subsystems: for coordinating incident response and sharing emergency information Transit Vehicle and Emergency Management subsystems (representing either the public safety entities of a transit agency, such as transit police, or a public safety agency): for vehicle operator or traveler-initiated alarms, sensor monitoring, and surveillance 54 LEVERAGING ITS TO REDUCE RISK AND EXPOSURE USING ITS SECURITY AREAS Remote Traveler Support (representing devices aiding travelers within public transit areas such as rail or bus stations) and Emergency Management subsystems: for surveillance, traveler-initiated alarms, and sensor monitoring Security Monitoring (including devices in nonpublic areas of a transit system, such as rail or bus yards) and Emergency Management subsystems: for sensor monitoring and surveillance Emergency Management subsystem (transit public safety entities or another local public safety agency) and the Alert and Advisory Systems terminator: for sharing of threat data or threat information for analysis (RITA, National ITS Architecture 6.0, May 2007) 3.8 TRANSPORTATION INFRASTRUCTURE SECURITY Transportation infrastructure can be monitored and protected by a broad array of ITS technologies. Transportation infrastructure security includes the monitoring of transportation infrastructure (e.g., bridges, tunnels and management centers) for potential threats using sensors and surveillance equipment. Threats to infrastructure can result from acts of nature (e.g., hurricanes, earthquakes), terrorist attacks or other incidents causing damage to the infrastructure (e.g., stray barge hitting a bridge support). Barrier and safeguard systems are used to preclude an incident, control access during and after an incident or mitigate impact of an incident. —RITA, National ITS Architecture, May 2007 As ITS capabilities become more important to the security of our transportation network, they can themselves be a target. As an example, an excerpt from September 11, 2001 involving the Virginia Department of Transportation (VDOT) traffic management center near the Pentagon is presented. Following, in chronological order, is a bulleted summary of events and actions that took place at the Smart Traffic Center (STC) on September 11, 2001, plus suggestions to make future responses more effective (VDOT 2002). Initially Notification of incident at NY Towers. (Through news media) Plane flies directly over smart traffic center (STC) and hits Pentagon. (Eyewitness & emergency scanner) Secured the STC facility (closed gates to keep citizens and news media out of facility so VDOT could mobilize its forces and act on planning strategies) Began monitoring traffic movements in and around the immediate DC area (Cameras, Computer Systems) and news (Radio, TV) Maintenance Groups and SSP (Safety Service Patrol) personnel were instructed to return to area headquarters. (Planning and Instructions) 3.8 TRANSPORTATION INFRASTRUCTURE SECURITY Immediate VDOT Response Notification through emergency scanners and news media that DC and Federal agencies had enacted a state of emergency and the Pentagon was being evacuated. (STC began intense monitoring of traffic flow out of DC and surrounding areas for implementation of incident plans) Coordinated HOV (High Occupancy Vehicle) gates openings with State Police. (Maximum traffic flow out of city) Programmed VMS (Variable Message Signs). (Traveler information to public) SSP incident supervisors organized and mobilized crews and proceeded to accident scene. STSS (Smart Traffic Signal System) contacted Arlington County signal department and City of Fairfax signal department to coordinate placement of signals into the p.m. plans (outgoing traffic) and execute special incident management plans to facilitate vehicle traffic movement down major corridors. Because of news reports that other threatening planes were still in the air and heading towards DC, STSS moved control of signal systems computers and communications to back up system to VDOT’s Camp 30 facility in Fairfax. (security reasons) Mobilization Unified Command Vehicle Mobilized—Initially set up at ramp 8B directly across and in front of the Pentagon, then relocated vehicle next to STC facility due to smoke and emergency vehicle traffic. (VDOT has permanent operational seat in vehicle) Operational contacts for coordination made with Unified Command Vehicle, STC facility, State Police, Fairfax County Police, Arlington County, Fairfax City, TEOC (Transportation Emergency Operations Center) (Richmond, VA), and Maryland DOT. Maintenance and SSP sections mobilized crash cushions, light towers, traffic cones, manpower, and other related equipment and coordinated with STC and Unified Command Vehicle for placement. Other districts (Culpeper & Fredericksburg, VA) were contacted for available equipment and responded. Monitoring, Informational Process and Continued Mobilization Communication process established for information updates to and from TEOC (Richmond) NOVA district, Fairfax County police, Virginia State Police and NOVA maintenance areas. VDOT coordinated with and assisted United States Military from Naval Annex (Navy, Army) in setting up information command center in secured VDOT Columbia Pike (STC) facility. Secured for them access to phones, e-mail, news broadcasts, CCTV cameras, writing material, white boards, conference rooms and offices. Columbia Pikes Maintenance area headquarters facility was used as day care center for children of military personnel. Work shifts were established for around the clock operations. Conference call established between area agencies including the Council of Governments (COG) discussing and planning openings and closings of roads, public and private facilities and other relevant business decisions. 55 56 LEVERAGING ITS TO REDUCE RISK AND EXPOSURE USING ITS SECURITY AREAS Situational Improvements/Lessons Learned Within a minute of the plane hitting the Pentagon all Cellular phones, and some two-way radio communications, and pagers were periodically interrupted for approximately 3 hours. (Caused by circuit overloads, and military blackout). On that basis, for external communications VDOT will need to rely on the use of more specialized leased two-way and satellite type communication devices. District’s teleconferencing equipment was brought to the STC; this proved to be an essential and useful tool. We need to have appropriate teleconferencing equipment exclusively dedicated for this sensitive traffic operation center. STC evacuation procedure and active personnel verification guidelines and policy need to be established. (i.e., what if STC had been damaged, where should personnel go for instructions, relocation and who should personnel notify to establish list of the non-injured). TEOC guidelines and procedures. This event’s activities demonstrated the need to review, tighten and make developmental improvements on procedures for communications between TEOC (Richmond), and all districts. Within the framework of managing incidents and emergencies of this magnitude and nature, we need interoperability guidelines for contact and interaction with the military. The existing STC facility is old, does not have adequate space, and is not adaptable for the existing and future traffic volume, congestion and high customer expectations. To realistically meet these demands a new facility is needed, and the necessary funding for design and construction should be allocated. A centralized unified district emergency command facility (information and command center) would encompass all VDOT sections (districtwide involved in incident management), police, fire and rescue, COG and others. Aerial visual (helicopter type) link. Ability to see large area of district for traffic flow analysis. During emergencies visual verification of traffic flow and patterns to confirm proper incident management signal plans are adequate for the emergency. Also send STC video feed to command centers across state using communications lines. This would give these facilities instant visual informational feeds. This communications could also be used to feed local news broadcasts to these facilities about District specific emergencies. Establish protocol for providing and obtaining additional resources (equipment, signs, light towers, or manpower) from within the District and from neighboring Districts. The protocol should include guidelines for maintaining communication with crews on route and after they arrive to the incident scene. The role of the Emergency Management subsystem includes monitoring the transportation infrastructure. Information on threats is shared primarily with the Traffic Management, and the Maintenance and Construction Management subsystems but can also be shared with other subsystems. The traffic management center, as we saw in the 9/11 VDOT scenario, controls the barrier and 3.9 TRAVELER SECURITY 57 EM05 - Transportation Infrastructure Protection Alerting and Advisory Systems alerts and advisories + threat support data threat information + threat data for analysis Rail Operations Emergency Management Barrier System Management Safeguard System Management Field Secure Area Sensor Monitoring security equipment maintenance status incident report Other Emergency threat information Management coordination threat information + transportation system status secure area surveillance control + secure area sensor control transportation system status+ emergency traffic control request + Center Secure Area threat information Surveillance TMC Incident Dispatch Coordination /Communication Field Secure Area Surveillance secure area characteristics Management Traffic Management Security Monitoring secure area surveillance data + secure area sensor data + infrastructure monitoring sensor data threat information threat information + transportation system status + Maintenance and security field Construction equipment status Transit Management secure area sensor control + secure area surveillance control + infrastructure monitoring sensor control emergency traffic control information Center Secure Area Sensor Management barrier system status + safeguard system status barrier system control + safeguard system control secure area surveillance data + secure area sensor data Secure Area Environment secure area characteristics Remote Traveler Traveler Secure Area Sensor Monitoring Traveler Secure Area Surveillance Roadway Field Barrier System Control Field Safeguard System Control barrier system control barrier system status Emergency Vehicle On-Board EV Barrier System Control Figure 3.21 Transportation Infrastructure Protection Market Package. (Source: RITA, National ITS Architecture 6.0, May 2007.) safeguard equipment, although Emergency Management can request deployment. The security of transportation infrastructure is covered primarily in the Transportation Infrastructure Protection market package, illustrated by Figure 3.21. The Security Monitoring subsystem was added in Version 5.0 of the National ITS Architecture to handle surveillance equipment allocated solely for security purposes. 3.9 TRAVELER SECURITY The Traveler Security area is responsible for increasing the safety and security of travelers in public areas including public transit facilities, bridges, tunnels, parking facilities, (major) intersections, and other roadway features. —RITA, National ITS Architecture 6.0, May 2007 Four key market packages represent the Traveler Security area: 1. Transit Security (APTS05). 2. Transportation Infrastructure Protection (EM05). 58 LEVERAGING ITS TO REDUCE RISK AND EXPOSURE USING ITS SECURITY AREAS 3. Wide Area Alert (EM06). 4. Disaster Traveler Information (EM10). We have seen each of these market packages in the previous security areas. Their theme in this application is to provide security-related information to travelers with the goal of improving their safety. 3.10 CONCLUSIONS This chapter discussed the various transportation-related security areas that can be addressed by ITS. By providing surveillance and detection capabilities, along with real-time agency-to-agency, agency-to-vehicle, and agency-to-field communications infrastructure, ITS can significantly minimize the security risks to our transportation infrastructure. Transportation security is a new undertaking for many public agencies. The U.S. National ITS Architecture provides excellent resources for these agencies to develop a comprehensive and systematic transportation security plan that will contribute to the homeland security efforts. ITS planning and execution of the national homeland security efforts will also improve if agencies across the country adopt a regional surface transportation security architecture that minimizes risks to surface transportation infrastructure. Agencies or regions may choose the areas for which they wish to develop a security plan. The application of disaster response, evacuation, and ITS widearea-alert security procedures could occur during other emergency events, such as a hurricane evacuation or highway incident. Comprehensive planning in these areas will allow public agencies to minimize risks in multiple scenarios, thereby increasing their return on investment. Commercial vehicle operators and public law enforcement agencies need to work together to safeguard commercial vehicle traffic, freight traffic, and hazardous materials freight traffic. A security breach in any of these areas could be a potentially severe risk to public safety. Interagency cooperation to detect and respond to any security breach in these areas is of paramount importance. ITS can definitely provide an opportunity to effectively perform these functions. ITS also has an effective methodology for providing rail security for passengers, freight, and personnel and for improving security and safety at highway–rail grade crossings. Surveillance, and sensor monitoring of transit stations and vehicles, can minimize the security vulnerabilities inherent in any transit system. Critical transportation infrastructures, such as bridges, tunnels, and management centers, can be potential terrorist targets or vulnerable to natural disasters. Continuous real-time monitoring of these infrastructures will identify any potential threats and initiate a prompt response with early identification of an event. These eight security areas namely, Disaster Response and Evacuation, Freight and Commercial Vehicle Security, HAZMAT Security, ITS Wide REVIEW QUESTIONS 59 Area Alert, Rail Security, Transit Security, Transportation Infrastructure Security and Traveler Security provide a comprehensive view of how ITS can contribute to transportation security. The initial steps in developing such a plan would be to understand what functionalities the National ITS Architecture provides and then determine how they could be implemented. REFERENCES Chowdhury, Mashrur, and Adel Sadek. 2003. Fundamentals of Intelligent Transportation Systems Planning. Artech House. Farradyne, P.B. 2002. ‘‘A Guide to Updating Emergency Response Plans for Terrorist Incidents,’’ AASHTO, May. Post, Buckley, Schuh & Jernigan (PBS&J). 1999. ‘‘I-4 ITS Corridor Framework Phase II Working Paper #1: Evacuation Coordination User Service Development,’’ FDOT, December. Research and Innovative Technology Administration (RITA). May 2007. National ITS Architecture, Version 6.0, www.its.dot.gov/arch/index.htm. Virginia Department of Transportation (VDOT). 2001. Hampton Roads Hurricane Traffic Control Plan, July. Virginia Department of Transportation (VDOT). 2002. NOVA Centric ITS Architecture Outreach Report. Developed by Arinc, Inc., PB Farradyne, Inc., and Iteris, Inc., for the Virginia Department of Transportation, May. Whillhite, Christy D. 2007. ‘‘Hurricane Evacuation and Incorporating Safety and Security into Metropolitan Transportation Plans.’’ AMPO 2007 National Conference, October 4. REVIEW QUESTIONS 1. Why are the ITS security areas dependent on securing ITS? 2. Name all eight ITS security areas. 3. Which ITS security area was best described prior to Version 5.0 of the National ITS Architecture? 4. What National ITS Architecture subsystem handles most of the security area functionality? 5. What functionality is necessary after an evacuation? 6. What new subsystem was added to Version 5.0 of the National ITS Architecture? 7. How many key interfaces are parts of the Transit Security area? 8. What were some of the lessons learned by VDOT in the aftermath of the September 11th terrorist attacks? CHAPTER 4 RISK ASSESSMENT FRAMEWORK I dentifying factors that contribute to the risk of deliberate attacks and the overall probability of the occurrence of such events are the primary tasks in quantifying risks. Quantifying a risk is important for several reasons, including prioritizing security-related projects competing under budget constraints, identifying the threat level for taking precautionary measures such as informing at-risk populations, and designing a secure system. This chapter discusses a framework for assessing the risks of critical transportation infrastructure with the purpose of selecting the appropriate mitigating measures. It details the process for selecting mitigating options for any risks of deliberate attack and includes risk assessment tools for both qualitative and quantitative evaluations. Risk assessment is not unique to the transportation infrastructure. Most public transportation agencies responsible for building, operating, and maintaining infrastructure already have a risk management process in place to protect assets and minimize the potential for loss in the event of an incident. For example, many highway agencies have standard risk management policies to protect themselves from potential lawsuits. Agencies can build on prior risk management experience when focusing on infrastructure security. Before continuing into the background of risk management and assessment, it is important to review the definitions of a few key terms used in this book. Deliberate attack Caused by a person or persons for intentional damage to life and property in order to create terror among the public (Walker 2000). Transportation Infrastructure Security Utilizing Intelligent Transportation Systems R. Fries, M. Chowdhury and J. Brummond Copyright © 2009 John Wiley & Sons, Inc. 60 4.1 RISK ASSESSMENT FRAMEWORK 61 Risk The likelihood of a disruptive event occurring during the life of a key piece of infrastructure or the damage that can occur subsequent to a certain event. The first part of this definition is easily transferable to risk assessment; the second part applies to risk management. Both parts of the definition significantly influence the decision-making process for transportation infrastructure security while using intelligent transportation systems (ITS) (Bekiaris and Nakanishi 2004). Risk factors for highway elements can include structural stability, strategic importance, traffic conditions, and resources to mitigate risks and manage recovery efforts (Xia and Chen 2004). Risk assessment The process of identifying and gathering information about possible risks to a transportation system for use in ranking security and safety improvements. Risk management Refers to the overall effort of managing risks, including risk assessment, the selection of security projects, and the frequent updating of risks (Walker 2000). Uncertainty Arises from the need to make decisions about future events whose predictors could contain errors; thus it involves decision making without full knowledge (Walker 2000). 4.1 RISK ASSESSMENT FRAMEWORK An analytical framework is necessary to formalize the risk assessment process under uncertainties, including the threat of deliberate attack, and to provide objectivity for enhancing public and political support, both of which are necessary for securing funds for implementation. This section presents a framework for managing risks against deliberate attacks to transportation infrastructure. Because the risk assessment process includes several tasks, it is important to develop a framework where different tasks are performed sequentially in an organized fashion to provide maximum benefits. The targets for deliberate attacks and hence the subjects for risk assessment are the critical assets, which, if attacked, will receive the highest attention from both the media and public. One important parameter in the risk assessment process is the use of appropriate risk assessment tools to quantify the vulnerability and implement appropriate countermeasures to minimize the risks. Data are important in the risk assessment process, and proper procedures must be in place for the timely collection of these data to support the process. Examples of static data can include: Regional or strategic importance* Stability of the structure* *From Xia and Chen, 2004. 62 RISK ASSESSMENT FRAMEWORK Functional Resilience* Route redundancy Response resources Reversible lanes Evacuation signage Traffic management center redundancy Recovery ability Dynamic data can include: Traffic volumes* Weather conditions* Road conditions (lane availability due to construction and maintenance)* Personnel availability Traffic control (reversible lane operations) Other special lane operations Signal timings plans in use Surveillance information Many state agencies have developed a process for risk assessment and mitigation for coping with deliberate attacks, in addition to their ongoing efforts to protect their assets and mitigate potential losses. One such process, primarily based on the participation of the stakeholders in identification of possible scenarios and countermeasures, has been developed by the New Mexico state government. This process can be applied to address combined threats from highway incidents, environmental hazards, and deliberate threats from terrorists (Hood et al. 2003). The process defines five elements of the transportation system in terms of the potential for a terrorist attack: 1. User. The known or suspected terrorist or an individual committing an action that can lead to a terrorist act (e.g., someone highjacking a commercial vehicle carrying HAZMAT). 2. Vehicle. Any moving device used to transport travelers or cargo as either a weapon itself or a potential target of terrorists. 3. Infrastructure. Any permanent structure that may serve as a target or a means of attack or weapon. 4. Social setting. The way in which a society organizes its policy, system of justice, values, religious institutions, and investment strategies. The social setting establishes the policies and procedures that guide the society’s critical systems. 5. Environment. Any aspect of the physical environment that influences the start of the incident or affects the consequences of the incident. 4.1 RISK ASSESSMENT FRAMEWORK Red/Blue Team Scenario Response Planning Critical Infrastructure Identification Critical Infrastructure Hardening 63 Major Consequence Definition Figure 4.1 Vulnerability Assessment Flow Diagram. (Source: Hood et al., 2003.) This process recognizes that each of these elements can be a potential target, weapon, or consequence. Although it is more likely for the user and vehicles to be utilized as a weapon and the infrastructure, social setting, and environment to be the target, the other possibilities should not be ignored. Figure 4.1 shows the flow diagram for the vulnerability assessment process. The process goes through an iterative exercise of identifying the critical infrastructure and major consequences. Out of two teams, the Red Team develops potential scenarios for deliberate attacks and the Blue Team, develops operational plans to respond to the Red Team scenarios. The Blue Team’s response planning contributes in the adding security features/countermeasures, or ‘‘hardening,’’ of the critical infrastructure. This process assists response personnel and decision makers to create an operational plan in the event of a deliberate attack. Figure 4.2 shows the framework for assessing risks to transportation infrastructure either to minimize risks before they occur or to minimize the consequences when an undesirable event has taken place. The framework includes four sequential tasks: 1. 2. 3. 4. Identification of critical assets. Assessment of risks. Identification of countermeasures/mitigating options. Selection of mitigating option(s). As shown in the figure, some tasks are supported through additional work. For example, assessing risks involves the collection of several data and information types, such as access to and evacuation from the site and existing security conditions. 64 RISK ASSESSMENT FRAMEWORK Gather Data/Information Identify Critical Assets Assess Risks Identify Countermeasures and Mitigating Options Select Mitigating Option(s) Identify Costs and Benefits of Each Option Figure 4.2 Framework for Risk Assessment. 4.1.1 Critical Assets Qualitative identification of the long-term risks involved with transportation infrastructure comes primarily from governmental sources, such as national intelligence agencies, national security–related departments, and law enforcement agencies. These agencies use information from sources worldwide to identify any risks of deliberate attacks on the public and infrastructure. In the United States, the Department of Homeland Security coordinates the tasks of different agencies to identify these potential threats. This agency was formed after the terrorist attacks on September 11, 2001, to coordinate governmental agencies and to compile and analyze the information from each of these agencies. In coordination with national efforts on threat identification, regional and local authorities may identify potential targets in their jurisdiction and possible ways to protect life and property against deliberate attacks. Like the national efforts on coordinating different agencies to identify threats, the regional and local efforts also must be coordinated with stakeholder agencies. Otherwise, gaps in emphasis and/ or communication between agencies and government levels can allow potential threats to be missed and therefore not included in the risk assessment process. The public may detect immediate threats through observation of unusual or suspicious activities. Educating the public on the importance of alerting authorities and possible ways to detect activities related to terrorist threats is important. The media can be used effectively to educate the public on how to be more vigilant and how to report activities that may pose a deliberate threat. 4.1.2 Risk Assessment Methods One of the most important tasks in the risk assessment framework is to evaluate risks to critical transportation infrastructure, qualitatively and/or 4.1 RISK ASSESSMENT FRAMEWORK 65 quantitatively. Although the various available methods may have different data needs, they can be classified generally as either dynamic or static data, as presented in Section 4.1. Several methods are available for qualitative and quantitative risk assessment of infrastructure. This section presents four methods. The first method has been developed specifically for bridges and tunnels and is used for estimating quantitative risks. The second, fault-tree analysis, is used for analyzing risks, both qualitatively and quantitatively (Chowdhury et al. 2000). It has been applied in many other areas, such as traffic safety, nuclear power plants, and water resource engineering, The last two methods are mathematical tools for determining the impact of changing influences quantitatively. 4.1.2.1 Blue Ribbon Panel Method. One of the methods proposed specifi- cally for risk assessment of highway infrastructure, such as bridges and tunnels, provides for the consideration of interactions of different risk factors. The general expression of risk (Blue Ribbon Panel 2003) is: R¼OV I ð4:1Þ Where R ¼ risk of an infrastructure element. O ¼ occurrence, characterized by the likelihood of deliberate attacks on infrastructure. V ¼ vulnerability, which characterizes severity of a deliberate attack in terms of loss of life, injury, and property damage. It is a measure of expected casualties, injuries, fatalities, and damage to the infrastructure. I ¼ importance, which characterizes the importance of the infrastructure at the regional and national level. This importance can be estimated by analyzing the impacts on the region and country if the infrastructure is unavailable. The likelihood of the occurrence of such attacks will depend on several factors, including: Attractiveness of the target, in terms of visibility and publicity if attacked Prior threats Access to the sites Level of security in place Table 4.1 shows the possible sources of data for O, V, and I. 4.1.2.2 Fault-Tree Analysis. A way to assess the risk, both qualitatively and quantitatively, is through modeling a system in terms of its failure. This assessment can be done through a method called fault-tree analysis, a risk 66 RISK ASSESSMENT FRAMEWORK TABLE 4.1 Sources of Data for Equation 4.1 Factors Examples of Required Data Possible Sources of Data Occurrence (O) Target attractiveness, level of security, access to site, publicity if attacked, number of prior threats Vulnerability (V ) Likely damage from various terrorist threats, including expected damage, outcome of event, expected casualties, and loss of use Effects on region or nation if facility is no longer available due to deliberate attack Law enforcement and intelligence communities familiar with threat and operational security measures Engineering analysis and expertise Importance (I ) Owners, operators, users, and beneficiaries of the facilities, governmental sources Source: Blue Ribbon Panel 2003. modeling and assessment tool, which can be used in qualitative and quantitative analysis of any risks of the infrastructure failure and the events leading to the failure due to a deliberate attack. Fault-tree analysis already has been applied in increasing the security of hardened structures such as nuclear power plants, in highway safety, and in water resource engineering (Chowdhury et al. 2000). Fault-tree analysis models a system by analyzing the failure (for our purposes a deliberate attack) and possible events leading to that catastrophic failure. An advantage of fault-tree analysis is that it may be applied even if all the data are not yet available, a fact that makes it particularly suitable to analyzing infrastructure vulnerability. The analytical technique of fault-tree modeling graphically represents the ways a system can fail (NRC 1981). The graphic includes gates and events in which parallel and sequential combinations of faults lead to the prespecified undesired state of events. Gates serve as decision points, indicating that if a failure can occur if either all or one of the previous events occurs, denoted by AND gates and OR gates, respectively. Fault-tree analysis also represents a graphical Boolean relationship between fault events causing the undesired state (e.g., failure due to a deliberate attack). Using Boolean algebra, a fault tree can be evaluated both qualitatively and quantitatively. Figure 4.3 shows a graphical representation of the relationship among the fault-tree symbols, particularly the events and gates. One of the Boolean expressions can be given for an Event Q, which occurs because either fault event A or B, or both A and B occur. This equation would be written as: PðQÞ ¼ Pð AÞ þ PðBÞ Pð A \ BÞ 4.1 RISK ASSESSMENT FRAMEWORK Figure 4.3 Fault-Tree Symbols. (Source: NRC 1981.) 67 68 RISK ASSESSMENT FRAMEWORK OUTPUT Q + INPUT A INPUT B Figure 4.4 OR Gate. An event Q occurs (say a failure of a bridge due to a deliberate attack) because of the occurrence of either fault A or B. Consequently, it can be represented by an OR gate. Figure 4.4 shows an example of a top-level event, which may represent the failure of a bridge due to deliberate attacks, that is due to an occurrence of one or more of the input events. In other words, Q occurs if A (failure of the foundation) occurs, or B (failure of the bridge deck) occurs, or both A and B occur. Event Q can also occur because both fault events C and D occur. This equation would be written as: PðQÞ ¼ PðC ÞPðC/ DÞ ¼ PðDÞPðD/ C Þ Figure 4.5 shows an example of the top-level event Q occurs (say the failure of a traffic management center communication system due to deliberate attacks) is due to the both of the input events C and D occur, and so can be represented by an AND gate. In other words, Q occurs only if both C (failure of the primary communication system) and D (failure of a redundant communication system) occur. 4.1.2.3 Simulation Analysis. Unfortunately, complete elimination of risk is not realistic even though all possible measures are taken. In addition to having a OUTPUT Q INPUT C INPUT D Figure 4.5 AND Gate. 4.1 RISK ASSESSMENT FRAMEWORK 69 plan to minimize the risk of an attack, a plan to respond quickly and effectively after an attack to minimize the impacts must be in place. Real world drills for response operations are good; however, most of these exercises are resource intensive. Computer simulations to evaluate different response plans are a costeffective alternative and also provide an opportunity to use an animation of the simulation to train first responders. Agencies that are responsible for responding to an emergency created by a deliberate attack must maintain communications (Chowdhury et al. 2003). These agencies must ensure that the emergency communications infrastructure and systems are fully operable under any catastrophic situations so that response is not impacted during critical periods. Communication reliability analysis through laboratory and field experiments as well as computer simulation can provide insight into the amount of delay and communication failure a given system can expect to experience under an anticipated emergency scenario. Different communication network simulators, such as Network Simulator 2 (ns-2) (The network simulator 2001) and Opnet (Opnet Technologies), could be used for simulation of the communication network. Traffic management, including rerouting and evacuation, is an important part of transportation security response plans. Numerous traffic models, including computer simulations, are available for planning for traffic management during a catastrophic event. Models that have been developed for evacuating at-risk populations prior to hurricanes and other natural disasters also can be applied for response planning after a deliberate attack. Chapter 5 presents an example of application of an evacuating model and simulation tool in evacuation planning. Different commercially available microscopic traffic simulation models can be utilized for this purpose. 4.1.2.4 Monte Carlo Analysis. Monte Carlo analysis is a valuable tool when it is difficult to determine a numerical solution because of the influence of several changing factors. This technique uses random numbers to create a statistical distribution based on the influences of multiple factors. Each of these factors, such as the structural integrity of a bridge over time, needs to be described by a mathematical function. The Monte Carlo analysis technique uses random numbers to iteratively identify a probability distribution of the multiple factors occurring simultaneously. Equation 4.2 provides the general form for a Monte Carlo analysis where three factors (x, y, and z) influence the overall outcome. Each of these factors stands for the mathematical equation associating risk. For example, x can stand for an equation relating a bridge’s foundation structural integrity over time, y can stand for a similar equation for the bridge’s deck, and z can relate the change of traffic volumes over time. y ¼ f ðx; y; zÞ ð4:2Þ A simple application of this method is the estimation of pi. If a square is the sample space and a circle is drawn within the square, random Monte Carlo 70 RISK ASSESSMENT FRAMEWORK sampling can provide an estimation of the area of the circle and therefore an estimation of pi. Imagine that each random number selected by the Monte Carlo method represents a grain of sand dropped randomly within the square. Selecting multiple random numbers from the sample, dropping multiple grains of sand within the square, and counting how many fall within and outside the circle will provide an estimate of the area and therefore of pi. The more random numbers or grains used, the better the estimate will be. Monte Carlo analysis helps estimate risk when significant uncertainty exists with the contributing factors (x, y, and z). Because this approach often requires a large amount of input data, it is better suited for research applications. Computer tools generally are used to analyze the large number of calculations involved. 4.1.2.5 Weibull Hazard Models. Based on the Weibull distribution; a statistical distribution influenced by shape, scale, and location variables; Weibull hazard models often are applied for estimating the changing hazards of a system over time. Equation 4.3 presents a Weibull hazard model: f ðx; k; lÞ ¼ k x k1 ðxlÞk e l l ð4:3Þ Where x ¼ time k ¼ shape of the function l ¼ scale parameter (all are nonzero) This model is suited for applications that estimate the life span of systems where the failure rates are well documented. Although this approach does not individually account for the multiple factors that affect the life span of infrastructure, it is a valuable tool when historical failure rate information is available. A plethora of other tools exist to predict risk, including compartmental flow models, stochastic transition models, and discrete event simulation models, but their applications to the transportation field have been rather limited due to the amount of input data required and the complexity of calculations. Chapter 5 discusses these risk assessment methods in more depth. 4.1.3 Mitigation and Countermeasures This step identifies potential mitigating options to different vulnerabilities identified in the risk assessment process discussed in the last section. Reducing the number and level of vulnerabilities will contribute to the reduction of risks to critical transportation infrastructure. For each of the vulnerabilities, several mitigating options may be identified. For example, a specific vulnerability to a critical bridge may be personnel access to the bridge piers. Unnoticed access to 4.1 RISK ASSESSMENT FRAMEWORK 71 these locations, via either water or land, poses a significant threat if trespassers have ill intentions. Mitigating options to this scenario may include video surveillance of the bridge piers and key access locations, restricting access to the piers through the river, and periodic manual surveillance by law enforcement agencies. One or more of these options may be selected to minimize risks to the bridge based on the cost benefit analysis discussed in the next section. Resiliency is a key property that infrastructure systems must possess in order to withstand the multiple events that often follow an incident. For example, while a hurricane may weaken transportation infrastructure from wind and water damage, key infrastructure must be resilient enough to withstand the evacuation loadings. In addition to incorporating resiliency in the planning and design of the infrastructure, appropriate countermeasures must be provided to reduce those factors identified through the risk assessment process that contribute to the failure of a system. 4.1.4 Selection of Options Data generated from the risk assessment process may provide relative benefits and costs of identified countermeasures or mitigating options. One of the most common techniques used in quantitative comparison is benefit-cost analysis. Transportation systems, as public assets, require justification for large expenditures, particularly those relating to security. Benefit-cost analysis provides a rating that allows simple comparison between diverse countermeasures, but it must be applied properly and account for the often-complex impacts that surround security countermeasures. Using a decision matrix can also aid in ranking security countermeasures, particularly when values are difficult to assign to some or all of the impacts. Traditionally these tables have been used to select the best alignment for a new section of roadway, but they readily apply to the selection of transportation security countermeasures. Table 4.2 presents an example of a decision matrix where countermeasures are rated on a qualitative scale based on several criteria. The criteria and scale should be carefully selected by a panel intimately involved with the identification of countermeasures. After rating the options according to TABLE 4.2 Security Countermeasure Decision Matrix Impact Rating (1–5, where 5 is the worst) Countermeasure Option 1 Option 2 Option 3 Option 4 Option 5 Passenger Environmental Travel Nonsecurity Security Friendliness Delay related Financial Appeal Impact value Total 3 2 5 1 4 4 5 2 3 5 1 1 1 2 2 4 5 4 3 3 2 3 4 3 3 14 16 16 12 17 72 RISK ASSESSMENT FRAMEWORK each criterion, a quantitative decision can be made based on multiple qualitative factors. In this example, option 4 should be chosen because it rated the lowest, indicating a more positive impact on travelers. 4.2 OPPORTUNITIES AND CHALLENGES Several risk assessment methods exist to analyze risks against critical infrastructure. The framework described in this chapter is in general consensus with many other models, including that recommended by the Federal Transit Administration (Community Transportation Association of America 2001). Any application of appropriate assessment tools depends on the type of risks, available data, and the level of details needed. These tools provide opportunities to conduct an objective evaluation of risks to infrastructure from any deliberate attacks. Challenges exist in the availability of the required data, quality of data, and resources necessary to conduct these analyses. The availability of infrastructure management systems and traffic-monitoring intelligent transportation systems in large and medium-size cities can serve as a valuable opportunity for collecting much of the information needed in risk assessment. Requiring a security analysis as part of project planning and operations could provide the proper emphasis on risks analysis, incorporating it with operations and maintenance plans. 4.3 APPLICATION OF THE FRAMEWORK This chapter describes a conceptual design that can be followed for managing risks to transportation infrastructure. Although this presentation focused on transportation elements, the general process can be emulated for risk assessment of many other types of infrastructure. Chapter 5 discusses the application of this risk assessment and management tools with example problems. REFERENCES Bekiaris, E., and Y. J. Nakanishi. 2004. Economic Impacts of Intelligent Transportation Systems: Innovations and Cast Studies. Elsevier. Blue Ribbon Panel on Bridge and Transit Security. 2003. Recommendation for Bridge and Tunnel Security, FHWA/AASHTO, September. Chowdhury, Mashrur, and Adel Sadek. 2003. Fundamentals of ITS Planning. Artech House. Chowdhury, M., N. Garber, and D. Li. 2000. ‘‘An Interactive Multiobjective Resource Allocation Methodology for Highway Safety Improvements,’’ ASCE Journal of Infrastructure Systems 6, No. 4: 138–144. REVIEW QUESTIONS 73 Community Transportation Association of America. 2001. ‘‘Risk Management for Rural Transit Systems.’’ Developed for the Rural Transit Assistance Program of the Federal Transit Administration. Hood, J., T. Olivas, C. B. Slocter, B. Howard, and D. P. Albright. 2003. ‘‘Vulnerability Assessment Through Integrated Transportation Analysis,’’ Transportation Research Record Journal of the Transportation Research Board No 1822: 18–23. The Network Simulator ns-2, http://www.isi.edu/nsnam/ns/, 2001 Nuclear Regulatory Commission (NRC). 1981. ‘‘Fault Tree Handbook.’’ Systems and Reliability Research Office. Available online at www.nrc.gov/reading-rm/doc-collections/ nuregs/staff/sr0492/sr0492.pdf. OPNET Technologies, Inc., OPNET network simulation software, www.opnet.com. Walker, W. E. 2000. ‘‘Policy Analysis: A Systematic Approach to Supporting Policymaking in the Public Sector,’’ Journal of Multicriteria Decision Analysis 9, No. 1–3: 11–27. Xia, J., and M. Chen. 2004. ‘‘Using ITS Data in Risk Assessment of Highway Network.’’ Report prepared for Southeastern Transportation Center. REVIEW QUESTIONS 1. What are the difference between risk and uncertainty? Give examples. 2. Identify critical transportation assets in your area. Provide a detailed explanation including the criteria you used in selecting these assets. 3. What type of data will you need to carry out the risk assessment to bridges and tunnels? (Refer to Equation 4.1.) 4. What is the general concept behind a fault tree? What is a top-level event for analyzing risks to a transportation bridge? 5. How will you select the mitigating options? What types of data will you need on the available options? 6. Using Boolean algebra, what is the probability of failure of a communication network hosted by a traffic management center, if failure can only occur if both the primary communication system fails (probability 0.1) and the secondary communication systems fails (probability 0.15)? 7. Also applying Boolean algebra, find the probability of failure of a bridge if either a bridge deck (probability 0.001) or a foundation failure occurs (probability of 0.0005) due to a deliberate attack. CHAPTER 5 APPLICATION OF RISK ASSESSMENT AND MANAGEMENT TOOLS C hapter 4 discussed the framework for risk assessment of critical transportation infrastructure and the theoretical concepts behind these tools. The application of different quantitative and qualitative risk assessment tools is a primary component of that framework. Therefore, this chapter demonstrates the application of some risk analysis methods. Those approaching risk assessment for the first time will find Chapter 4 provides useful background to this chapter. Practitioners and researchers will find this chapter a useful resource of example applications and problems. Examples include fault-tree analysis and the Blue Ribbon Panel method. 5.1 APPLICATION OF RISK ASSESSMENT METHODS The next sections present examples of the application of risk assessment methods. Examples have been created from both hypothetical and real-world data to provide a better insight into these methods and their application. To review the theoretical concepts behind these methods, refer to Chapter 4. 5.1.1 Blue Ribbon Panel Method The method proposed by the Blue Ribbon Panel on Bridge and Tunnel Security makes use of a number of sources.1 The general expression of risk is shown in 1 AASHTO 2002; Audigier et al. 2000; Babaei and Hawkins 1993; Basoz and Kiremidjian 1995; Hart Consultants Group et al. 1994; Kim 1993; King and Kiremidjian 1994; Maroney 1990; Saaty 1980; Sheng and Gilbert 1991; U.S. Department of Justice 2000. Transportation Infrastructure Security Utilizing Intelligent Transportation Systems R. Fries, M. Chowdhury and J. Brummond Copyright © 2009 John Wiley & Sons, Inc. 74 5.1 APPLICATION OF RISK ASSESSMENT METHODS 75 Equation 5.1, also presented in Chapter 4. To review, R represents the risk of an infrastructure element and will be output as a risk score (RS). Risk score represents the relative risk between the infrastructures being considered for ranking. After finding the risk scores for the selected critical bridges and tunnels, ranking them can provide direction for security improvements. The next variable, I, represents importance, which characterizes the importance of the infrastructure at the regional and national level. This variable is represented as the weighted average of attributes related to the Facility Its historic and symbolic importance Replacement value Importance as an emergency evacuation route Importance to the regional economy R¼IOV ð5:1Þ O represents occurrence, characterized by the likelihood of deliberate attacks on infrastructure. It is determined with a weighted combination of these attributes: Level of access Level of security Visibility or attractiveness of the facility Level of publicity History, including the number of times that the facility has been threatened in the past V represents vulnerability, which characterizes severity of a deliberate attack in terms of loss of life, injury, and property damage. This vulnerability factor is computed as the weighted average of: Expected damage to the asset Expected time of closure of the facility Expected number of casualties Figure 5.1 shows the three factors associated with the risk score and their associated attributes. Equation 5.2, showing the risk score (RS) for a particular facility, can be estimated using the general equation 5.1 and summing all of the threats to the facility; therefore, the only differences between the general equation (equation 5.1) and equation 5.2 is that the occurrence and vulnerability factors (OF and VF, respectively) of each threat are multiplied and summed before multiplying by the impact factor (IF) for the facility. RS represents 76 APPLICATION OF RISK ASSESSMENT AND MANAGEMENT TOOLS Figure 5.1 Components of RS and Their Associated Attributes. (Source: Blue Ribbon Panel 2003.) relative risks between facilities under consideration. Because not all facilities have multiple threats, the general equation does not show this summation. RS ¼ I X ½Oi Vi ð5:2Þ To find the risk score using this multiattribute utility method, first we must define the variables IF, OF, and VF. Equations 5.3 through 5.5 show how to determine these variables. IF ¼ X ½Wj VjðXjÞ ð5:3Þ OF ¼ X ½Wj VjðXjÞ ð5:4Þ VF ¼ X ½Wj VjðXjÞ ð5:5Þ Xj represents the value of attribute j. For example, ‘‘Replacement Value’’ is an attribute of IF, where the actual value could be represented by a number or some relative measures, such as high and low. In equations 5.3, 5.4, and 5.5, Vj(Xj) represents the function or table that maps Xj to a utility value between 0 and 1, where 1 corresponds to a very high importance, occurrence, or vulnerability. There are many ways to set up utility functions. In general, consistency in application is the key to success. For more details on utility theory related to multiattribute analysis, see Goicoechea et al. (1982). Last, Wj is the weighting factor on attribute j. 5.1 APPLICATION OF RISK ASSESSMENT METHODS 77 Figure 5.2 Relative Weights for Attributes to Compute Importance. (Source: Blue Ribbon Panel 2003.) Now stakeholders and decision makers need to meet to discuss and assign the importance and value of these key infrastructure elements. The Blue Ribbon Team proposes an Analytic Hierarchy Process that uses a pair-wise comparison process for developing the relative weighting of IF, VF, and OF. To illustrate this process, an example case study is presented. Decision makers assign a relative value to each component or attribute reflecting the relative influence of one component over the others. After averaging these suggestions, the average weighing factors are presented to the group for discussion, revision, and final approval. Figures 5.2 through 5.4 show examples of relative Figure 5.3 Relative Weights for Attributes to Compute Occurrence. (Source: Blue Ribbon Panel 2003.) 78 APPLICATION OF RISK ASSESSMENT AND MANAGEMENT TOOLS Figure 5.4 Relative Weights for Attributes to Compute Vulnerability. (Source: Blue Ribbon Panel 2003.) weights of the attributes associated with IF, OF, and VF for bridge and tunnel security, respectively. Setting all of the weights on a scale that sums to 1 or using a percentage weight are both acceptable when assigning actual values to the weight of each element. The important thing to keep in mind is that each factor is weighted according to the results provided at the stakeholder meeting. Using either a percentage or a fraction of one, both present simple ways of maintaining this ratio. Figure 5.5 Ranking of a Transportation System by Importance. (Source: Blue Ribbon Panel 2003.) 5.1 APPLICATION OF RISK ASSESSMENT METHODS 79 Figure 5.6 Vulnerable Components and Mode of Access to Bridge 1. (Source: Blue Ribbon Panel 2003.) After determining the values for the various weighting factors, the importance factor, IF, should be computed for each facility using equation 5.3, the relative weights found in the previous step as presented in Figure 5.2, and the utility of the attributes associated with Vj(Xj). Figure 5.5 shows the relative ranking results of the eight facilities considered in this case study, based on IF. Bridge 1 and tunnels 1 and 2 are the three most important infrastructure elements in this example. Next the vulnerable components and modes of access to each facility should be identified. Figures 5.6 through 5.11 show the vulnerable components and mode of access to the components of the bridge and tunnel facilities considered in the case study. Identification of vulnerable components and mode of access contributes to the selection of possible mitigation projects to reduce the RS. These identifications lead to the selection of possible 80 APPLICATION OF RISK ASSESSMENT AND MANAGEMENT TOOLS Figure 5.7 Vulnerable Components and Mode of Access to Tunnel 1. (Source: Blue Ribbon Panel 2003.) mitigation projects to reduce the RS. In these figures, elements that have been identified as threat targets are shaded and those considered vulnerable but not a target are not shaded, for example the land vent in the ceiling of the tunnel 1 (Figure 5.7). As shown in Figures 5.7 and 5.8, the two tunnels have identical infrastructures because they were constructed at the same time and used similar designs. 5.1 APPLICATION OF RISK ASSESSMENT METHODS 81 Figure 5.8 Vulnerable Components and Mode of Access to Tunnel 2. (Source: Blue Ribbon Panel 2003.) Figure 5.9 Vulnerable Components and Mode of Access to Bridge 2. (Source: Blue Ribbon Panel 2003.) 82 APPLICATION OF RISK ASSESSMENT AND MANAGEMENT TOOLS Figure 5.10 Vulnerable Components and Mode of Access to Bridge 3. (Source: Blue Ribbon Panel 2003.) After identifying the vulnerable components of each facility, the occurrence needs to be computed. Figure 5.3 illustrates the weight of each attribute for the facility, such as high visibility. Again, the higher the utility value is, the greater the predicted occurrence is. These data and equation 5.4 can be used to find an occurrence value for each facility. Next, the vulnerability factor is computed with equation 5.5 using the relative weights previously developed, shown in Figure 5.4, and the associated expected utility of the attributes in terms of consequence. These vulnerability factors are the last piece of data needed to apply equation 5.2 to find a risk score for each facility. Risk scores can also be used to determine which security improvements will best lower the risk to the region’s transportation infrastructure. Table 5.1 shows ranks of mitigating projects for all eight facilities in the case study in terms of their benefits and costs. Benefits are represented by ‘‘Reduction in Risk Score.’’ Once the mitigating projects related to different threats are identified, the OF, VF, and corresponding RS values need to be recomputed with the assumption that mitigating projects are in place. The differences between the RS under existing conditions and after the mitigating projects provide the reduction in RS. The benefit and cost values in this table will help decision makers to prioritize projects. If the required budget is more than the funding available to implement the mitigating projects, this information could be used to prioritize which mitigating projects to fund. The final result of this analysis was presentation of the projects in terms of the costs of implementation and benefits due to the reduction in risk score as shown in Table 5.1. Figure 5.12 shows the project ranking for benefits and costs of the mitigating projects. As shown in Figure 5.12, the benefit-cost information Figure 5.11 Vulnerable Components and Mode of Access to Bridge 4. (Source: Blue Ribbon Panel 2003.) 5.1 APPLICATION OF RISK ASSESSMENT METHODS 83 TABLE 5.1 Ranking of Mitigation Projects Rank Facility Location 1 2 3 Bridge 1 Other Facility 1 Tunnel 1 4 5 6 7 8 9 10 11 Other Facility 1 Bridge 1 Bridge 1 Other Facility 1 Tunnel 1 Bridge 1 Bridge 4 Tunnel 1 12 13 Tunnel 1 Tunnel 2 14 Tunnel 2 15 16 17 18 Bridge 1 Bridge 2 Other Facility 1 Tunnel 1 19 20 21 22 Bridge 1 Bridge 1 Other Facility 2 Bridge 4 23 24 25 26 27 28 29 Bridge 3 Other Facility 1 Other Facility 2 Tunnel 1 Tunnel 2 Other Facility 1 Bridge 4 30 31 32 33 Bridge 2 Bridge 3 Tunnel 1 Tunnel 2 Main Pier Base B Element A Vent Buildings Buildings Element B Anchor Element B Anchor Element A Element C Approach Viaduct Main Pier Base A Tension Hangers Vent Buildings Tunnel Ceilings Approach Plaza Vent Buildings Buildings Vent Buildings Tunnel Ceilings Deck Level Main Piers Element D Administration Building Tension Hangers Approach Highway Element A Main-Span Abutment Main Piers Element E Element B Tunnel Structure Tunnel Structure Element F Compression Members Main Span Main Span Portals Portals Source: Blue Ribbon Panel 2003. Reduction in Risk Score Project Cost ($1,000) 0.16 0.30 0.48 753 1,872 7,857 0.34 0.11 0.10 0.23 0.12 0.32 0.05 0.16 8,243 2,840 2,840 6,982 3,891 13,937 2,944 12,619 0.03 0.10 2,787 9,142 0.13 12,523 0.30 0.10 0.05 0.01 30,869 12,048 7,432 434 0.07 0.15 0.01 0.02 12,363 32,686 1,950 5,891 0.09 0.10 0.02 0.51 0.35 0.03 0.01 24,649 31,754 6,896 222,723 186,735 20,516 8,687 0.08 0.07 0.01 0.01 64,996 108,718 16,040 14,287 84 APPLICATION OF RISK ASSESSMENT AND MANAGEMENT TOOLS Figure 5.12 Benefit-cost Comparison for Security Projects. presented for the mitigating projects help identify most desirable projects with higher benefits and lower costs to lowest desirable projects with higher costs and lower benefits. 5.1.2 Fault-Tree Analysis As discussed in Chapter 4, fault-tree analysis can be used as a part of adopting and implementing a security framework. For a security framework, fault tree can be used to assess risks of failure of the transportation system or a component of the system caused by a deliberate attack. The top-level events can be the failure of a transportation system or a system component. The fault tree graphically describes various combinations of faults, parallel and sequential, that lead to the top-level event (Nuclear Regulatory Commission 1981). The events and logic gates that are used to construct a fault tree are described in Chapter 4. The primary events, which include basic, undeveloped, conditioning and external events, are not broken down further in fault trees because: They require no further development. For example, basic events can not be described in any more detail. They do not have sufficient consequence or information that requires further development. In particular, undeveloped events have very little information available and an insignificant impact. They represent any conditions or restrictions to any logic gates, primarily INHIBIT and PRIORITY AND gates, and are referred as the conditioning event. 5.1 APPLICATION OF RISK ASSESSMENT METHODS 85 They are expected to occur, which is a not a fault by itself, but which can contribute to a fault when combined with other external events; this is referred to as the external event. 5.1.2.1 Quantitative Evaluation of a Fault Tree. When data are available, quantitative evaluation methods provide valuable tools that enable an analyst to identify the impacts of the mitigating measures to various events that lead to the top-level event. It is necessary to provide probabilities to primary events in a fault tree to compute the probability of the top event, hence data availability is an issue. Once the probabilities of the primary events are provided, Boolean algebra, which relates each successive event to its parent event through logic gates, is used to compute the probability of the top event. Knowledge of probabilistic and statistical analyses is necessary to estimate probabilities for different basic events. The concepts of probability and statistics used for computing the probability of the basic events is outside the scope of this book; however, general knowledge about probability and statistics, such as random samples, different probability distributions, and Bayesian analyses should be sufficient for fault-tree application. Figure 5.13 shows an example of a fault tree, where the top event is ‘‘Power Supply to Computer Fails’’ (known as Event A). The top event occurs if the power supply is disconnected, the operating system fails, or the computer hardware fails. These events are shown as basic events because the assumption here is that these events need no further development. An investigation reveals that the probabilities shown in Table 5.2 are related to these basic events. By applying Boolean algebra, the probability of the top event is calculated in this way, assuming that the A, B, and C, are mutually exclusive events: PðComputer Fails to StartÞ ¼ PðAÞ þ PðBÞ þ PðCÞ ¼ 0:02 þ 0:05 þ 0:01 ¼ 0:08 OUTPUT Q + INPUT A INPUT B INPUT C Figure 5.13 Application of an OR Gate. 86 APPLICATION OF RISK ASSESSMENT AND MANAGEMENT TOOLS TABLE 5.2 Probabilities for Basic Events Basic Events Probabilities Power supply is disconnected (Event A) Operating system fails (Event B) Computer hardware fails (Event C) 0.02 0.05 0.01 Therefore, based on the probabilities of the basic events in this example, there is an 8 percent chance that the computer will fail to start. Figure 5.14 shows an example of a fault tree, with the top event being ‘‘Power Supply to TMC Fails.’’ As shown in the figure, this top event occurs only if both of these two events occur: primary power supply fails and alternate power supply fails. These events are shown as basic events; the assumption in this example is that these events need no further development. An investigation revealed the probabilities shown in Table 5.3 related to these basic events. By applying Boolean algebra, the probability of the top event is calculated in this way, with the assumption that A and B are independent events: PðPower Supply to TMC FailsÞ ¼ PðAÞPðBÞ ¼ 0:05 0:02 ¼ 0:001 When conducting fault-tree evaluation, events must be examined for mutual exclusiveness and independence. When constructing fault trees with OR gates, mutual exclusiveness is the key property to examine between the events. Events that are mutually exclusive cannot occur at the same time. If events under an OR Power Supply to TMC Fails 0.001 Primary Power Supply Fails Alternative Power Supply Fails 0.05 0.02 Figure 5.14 Application of an AND Gate. TABLE 5.3 Probabilities for Basic Events Basic Events Primary power supply fails (Event A) Alternative power supply fails (Event B) Probabilities 0.05 0.02 5.1 APPLICATION OF RISK ASSESSMENT METHODS 87 gate are not mutually exclusive but are independent of each other, then the probability of the top event, for example, Figure 5.13, would be governed by the statement: PðQÞ ¼ PðAÞ þ PðBÞ þ PðCÞ PðAÞPðBÞ PðBÞPðCÞ PðCÞPðAÞ þ PðAÞPðBÞPðCÞ The justification for the additional terms of this statement compared to the previous OR gate example is best illustrated using a Venn diagram. Figure 5.15 shows the probability space of each failure type. If these events were all mutually exclusive, one could image that none of the circles would overlap. Because they are not exclusive and do overlap, Boolean algebra needs to account for this overlap correctly, ensuring that no area is counted twice or even three times; therefore, the areas of overlap between A and B, between A and C, and between B and C need to be subtracted. However, when subtracting these areas, the space covered by A, B, and, C is subtracted three times when it only needs to be removed once, thus the addition of two times this probability at the end of the expression. Other complications arise during fault-tree construction if events are dependent on each other. For example, referring to Figure 5.14, if the two events were dependent whereas the probability of the alternative power supply failing was higher when the primary power supply failed, then the previous equation could greatly underestimate the failure probability. If the two events in Figure 5.14 were dependent as discussed, the probability would be found by PðQÞ ¼ PðBÞPðAjBÞ. Figure 5.16 shows a more realistic and more complicated example of a faulttree construction related to transportation security, where the top event is the failure of a traffic management center (TMC). TMCs are centralized control centers for monitoring and controlling traffic connected with field devices and other centers related to transportation and emergency management through Operating System Fails Q=0.05 B Power Supply Disconnected Q=0.02 Computer Hardware Fails Q=0.01 A C Figure 5.15 Venn Diagram of Independent but Not Mutually Exclusive Events. 88 Figure 5.16 Example of Fault-Tree Application to Transportation Security. 5.1 APPLICATION OF RISK ASSESSMENT METHODS 89 wired and/or wireless communications for online traffic management, especially during emergency situations. The fault tree is constructed to show the events leading to the failure of the TMC. As shown in the figure, probabilities were assigned to basic events. These probabilities are used to calculate the likelihood of the top-level event, using Boolean algebra. EXERCISE Individually or in a group, write out the Boolean algebra equations to solve the fault tree in Figure 5.16. Work from the bottom up to solve each branch. When the four top branches are solved, check that the probability is 0.6097. What assumptions must you make to find the same answer? 5.1.2.2 Minimal Cut Sets. The Fault-Tree Handbook (NRC 1981) defines minimal cut sets as a smallest combination of component failures which, if they occur, will cause the top event to occur . . . a minimal cut set is thus a combination (intersection) of primary events sufficient for the top event. The combination is a ‘smallest’ combination in that all the failures are needed for the top event to occur; if one of the failures in the cut set does not occur, then the top event will not occur (by this combination). A fault tree consists of a number of minimal cut sets. Because a fault tree is merely a graphical represented of Boolean equations, it can be used to determine the minimal cut sets. Basic rules of Boolean expressions are shown in Table 5.4. Figure 5.17 shows a fault tree. Figure 5.18 shows its equivalent fault tree identified through minimal cut sets determination. The following text boxes show an example of the mathematical solution process for determining the minimal cut sets through the rules of Boolean algebra for the fault tree in Figure 5.17. Although this example shows a top-down substitution process, either a top-down or bottom-up approach can be used as long as the rules of Boolean algebra are properly adhered to. The first equation in the text box shows that the event T is equal to the multiplication of the probabilities of events E1 and E2 because of the presence of an AND gate. Further defining this fault tree, the probability of event E1 is the sum of the probabilities of basic event A and event E3 because there is an OR gate. Solving the rest of this branch, the probability of event E3 is the sum of the probabilities of the basic events B and C. Similarly, the probability of event E2 is equal to the sum of the probability of the basic event C and event E4. Finishing this disaggregation, the probability of event E4 is equal to the multiplication of the probabilities of basic events A and B. TABLE 5.4 Rules of Boolean Algebra 90 Mathematical Symbolism (1a) X \ Y ¼ Y \ X (1b) X [ Y ¼ Y [ X (2a) X \ ðY \ ZÞ ¼ ðX \ YÞ \ Z (2b) X [ ðY [ ZÞ þ ðX [ YÞ [ Z (3a) X \ ðY [ ZÞ ¼ ðX \ YÞ [ ðX \ ZÞ (3b) X [ ðY \ ZÞ ¼ ðX [ YÞ \ ðX [ ZÞ (4a) X \ X ¼ X (4b) X [ X ¼ X (5a) X \ ðX [ YÞ ¼ X (5b) X [ ðX \ YÞ ¼ X (6a) X \ X 0 ¼ f (6b) X [ X 0 ¼ V ¼ I * (6c) ðX 0 Þ0 ¼ X (7a) ðX \ YÞ0 ¼ X 0 [ Y 0 (7b) ðX [ YÞ0 ¼ X 0 \ Y 0 (8a) f \ X ¼ f (8b) f [ X ¼ X (8c) V \ X ¼ X (8d) V [ X ¼ V (8e) f0 ¼ V (8f) V0 ¼ f (9a) X [ ðX 0 \ YÞ ¼ X [ Y (9b) X 0 \ ðX [ Y 0 Þ ¼ X 0 \ Y 0 ¼ ðX [ YÞ0 Engineering Symbolism XY ¼ Y X XþY ¼Y þX XðY ZÞ ¼ ðXYÞZ XðYZÞ ¼ ðXYÞZ X þ ðY þ ZÞ ¼ ðX þ YÞ þ Z XðY þ ZÞ ¼ XY þ XZ XðY þ ZÞ ¼ XY þ XZ X þ Y Z ¼ ðX þ YÞðX þ ZÞ XX ¼ X XþX ¼X XðX þ YÞ ¼ X X þ XY ¼ X XX 0 ¼ f X þ X0 ¼ V ¼ I ðX 0 Þ0 ¼ X ðXYÞ0 ¼ X 0 þ Y 0 ðX þ YÞ0 ¼ X 0 Y 0 fX ¼ f fþX ¼X VX ¼ X VþX ¼V f0 ¼ V V0 ¼ f X þ X 0 Y ¼ X þ Y X 0 ðX þ Y 0 Þ ¼ X 0 Y 0 ¼ ðX þ YÞ0 Designation Commutative Law Associative Law Distributive Law Idempotent Law Low of Absorption Complementation de Morgan’s Theorem Operations with f and V These relationships are unnamed but are frequently useful in the reduction process. Source: NRC 1981. *The symbol I is often used instead of V to designate the Universal Set. In engineering notation V is often replaced by I and f by 0 5.1 91 APPLICATION OF RISK ASSESSMENT METHODS T E1 A E2 E3 B C C E4 A B Figure 5.17 Example of a Fault Tree. Boolean Equations from Figure 5.17 T ¼ E1E2 E1 ¼ A þ E3 E3 ¼ B þ C E2 ¼ C þ E4 E4 ¼ AB E2 can be expressed as: E2 ¼ C þ AB The next step in finding minimal cut sets is starting to put these pieces back together to form one equation that represents the entire fault tree. The following example was reproduced from the Fault-Tree Handbook (NRC 1981). As shown, the minimal cut sets of E2 are C and AB. In other words, the two ways to make system E2 fail are by either C failing or by E4 failing, which is equivalent to AB. As shown in Figure 5.17, B and C are minimal cut sets for E3. Three minimal cut sets A, B, and C are obtained by substituting into E1. The expression for T transforms as: T ¼ E1 E2 T ¼ ðA þ E3Þ ðC þ E4Þ T ¼ ðA þ B þ CÞðC þ ABÞ 92 APPLICATION OF RISK ASSESSMENT AND MANAGEMENT TOOLS Now that there is one equation representing the entire system of failure options, the rules of Boolean algebra, as presented in Table 5.4, can be applied to simplify the failure mechanisms. 1. Multiplying the events within each set of parentheses gives the top expression in the text box. 2. To obtain the second expression, the Idempotent law (4a in Table 5.4) was used to reduce AAB to simply AB, reduce BAB to AB, and simplify CC to just C. 3. The Idempotent law was used again to reduce AB þ AB ¼ AB 4. To obtain expression 4, the Law of Absorption was used to reduce C þ CAB ¼ C. 5. The terms were rearranged. 6. The Law of Absorption was used to reduce C = CA = C. 7. C þ BC ¼ was reduced to just C using the law of absorption again. Creating Minimal Cut Sets 1. 2. 3. 4. 5. 6. 7. T T T T T T T ¼ AC þ AAB þ BC þ BAB þ CC þ CAB ¼ AC þ AB þ BC þ AB þ C þ CAB ¼ AC þ AB þ BC þ C þ ABC ¼ AC þ AB þ BC þ C ¼ C þ AC þ AB þ BC ¼ C þ BC þ AB ¼ C þ AB T A·B C A B Figure 5.18 Equivalent Fault-Tree Derived through Boolean Analysis. 5.1 APPLICATION OF RISK ASSESSMENT METHODS 93 Overall, there are many different ways to use Boolean algebra rules to simplify these expressions and find the easiest calculation of failure. Many of these applications require a bit of creativity and get easier with practice. The results of the solution is the equivalent to the fault tree shown in Figure 5.18. With two minimal cut sets, (1) C and (2) A and B, the top-level events occur if either C occurs or both A and B occur. 5.1.3 Weibull Hazards Model Example The Weibull hazards model, as discussed in Chapter 4, provides a method to model the failure rate of a system with known failure data. Figure 5.19 shows an example of the percent failure found for inductive loop detectors (ILDs) and the percent failure as predicted by a calibrated Weibull distribution. As shown in the figure, the distribution peaks around the average failure rate of the device and then gradually decreases. To fit the Weibull distribution to a data set, the shape and scale parameters must be iteratively selected until the desired goodness of the fit is achieved. In some cases, the desired goodness of fit cannot be achieved after much iteration, indicating that the Weibull distribution is not the best model to predict the failure. In those cases, risk modelers should investigate the shape of the Figure 5.19 Example of a Weibull Distribution. 94 APPLICATION OF RISK ASSESSMENT AND MANAGEMENT TOOLS failure data, identify anomalies such as multiple peaks, and experiment with different probabilistic distributions, such as Poisson or binomial. 5.2 APPLICATION OF EVACUATION MODELS AND TRAFFIC MODELS FOR RESPONSE PLANNING Even with a comprehensive security plan in place, the chance remains for a deliberate attack on a transportation facility that may cripple evacuation mobility. Consequently, the security plan must include a response plan in case such an event ever occurs. These plans include immediate response to contain the impact, such as fire, chemical and nuclear containments, and medical attention. Evacuation of the victims from the affected site as well as atrisk populations near the site must be conducted efficiently. There have been numerous studies on evacuating at-risk populations during natural disasters, such as hurricane and floods.2 During Hurricane Katrina, the failure to use contra-flow to manage evacuation traffic volumes was one of many transportation problems (Litman 2006). U.S. public agencies subsequently developed evacuation plans for at-risk populations. These models may also be applied for planning evacuations due to security incidents. A systematic approach for evacuation planning will ensure the systematic and safe evacuation of at-risk populations in the shortest possible time. Figure 5.20 shows a systemic approach for planning such evacuations. This approach is applicable to planning for any evacuation, due to either natural disaster or man-made threat. As shown in Figure 5.20, the first task includes identifying at-risk areas. These areas can be determined by identifying possible terrorist targets and the areas that will be impacted by an attack. The estimation of the evacuation demand includes determining the at-risk population, the participation rate, the evacuation route, and the traffic distribution over time. The at-risk population and vehicle ownership can be determined by applying the United States Census data of the selected evacuating cities. A growth factor can be applied to each of these values to account for the population growth and urban development between the census and planning years. In an example scenario presented in the following discussion, travel demand was calculated by multiplying the at-risk population by the participation rate for hurricane evaluation planning in Charleston, South Carolina. Based on the findings of prior hurricane evacuations (USACE 2007), this case study assumed that all residents of storm surge areas and mobile homes evacuated and that evacuees used 65.75% of the vehicles available in each household. The evacuating volumes were determined using equation 5.6. 2 Chien and Opie 2006, Wolshon 2001, Tuydes and Ziliaskopoulos 2006; Theodoulou 2001. 5.2 95 APPLICATION OF EVACUATION MODELS AND TRAFFIC MODELS Determine at-risk areas Identify evacuation demand Select evacuation strategies Develop, calibrate, and validate model Configure network for different evacuation strategy simulation Run simulations for evacuation scenarios Analyze simulation results Figure 5.20 Scene Response Planning Using Simulation. Volume ¼ Average Vehicles ð# HouseholdsÞ ðGrowth FactorÞ Househould ð5:6Þ Evacuation strategies may include operational traffic plans, evacuation of the elderly and the sick, and the use of high-occupancy and emergency vehicles. To determine the distribution of evacuees over time, the behavioral curves, such as those developed by U.S. Army Corps of Engineers (2003) can be used to represent rapid, medium, and long responses to the evacuation order. An illustrative case study of a hurricane evacuation plan for South Carolina is presented in Figure 5.21. (The official South Carolina plan was modified in this case study to include a connector, as illustrated by the bold solid line.) These freeway operation strategies were combined with different response times and number of lanes contra-flowed to speed the evacuation. The existing geometry shown as dots in Figure 5.21, was considered to be used during the existing SCDOT evacuation plan and included a configuration to contra-flow inbound lanes. 96 Figure 5.21 Contra-flow Case Study. (Source: SCDOT 2006.) 5.2 APPLICATION OF EVACUATION MODELS AND TRAFFIC MODELS 97 Scenarios Tested Existing Geometry Proposed Connector Do Nothing 3 Lanes 2 Lanes 3 Lanes 2 Lanes 3 Lanes 2 Lanes 3 Lanes 2 Lanes 3 Lanes 2 Lanes D E F G H I J K L Long Response 2 Lanes C Medium Response 3 Lanes B Rapid Response Long Response Medium Response Rapid Response Long Response Medium Response Rapid Response A M N O Figure 5.22 Alternatives for Simulation Analysis. The proposed connector scenario includes the vehicle flow paths from the existing scenario (dots) and includes an additional path (bold solid line) to increase the use of contra-flowed lanes. The do-nothing scenario evaluated evacuation operations using only normal freeway operations; therefore, no contra-flow was evaluated. The simulation portion of the planning process includes developing the simulation model with traffic and geometric data, followed by calibrating and validating the simulation model for the local conditions so that the simulation models closely mimic the real world transportation network. Fifteen scenarios were simulated to determine the results of these different combinations of evacuation response and management, as illustrated in Figure 5.22. Since a description of the combination of highway geometry used, evacuee response time (long, medium, and rapid), and number of lanes used for contra-flow would be lengthy, the letter below each scenario in Figure 5.22 will be used to reference each scenario. Figure 5.23 was generated using the values from the simulation runs. As shown in the figure, the results include the evacuation duration and travel times for 15 different evacuation scenarios, categorized by the anticipated evacuee response. The results of this research suggested the any contra-flow scenario produces both shorter average vehicular travel times and evacuation 98 APPLICATION OF RISK ASSESSMENT AND MANAGEMENT TOOLS 19:12 Evacuation Duration (Hr:Min) 16:48 14:24 12:00 9:36 7:12 4:48 2:24 0:00 O F L K Long E N D J C I M Medium Evacuation Scenario B H A Rapid B H A Rapid G 6 Travel Time (hr) 5 4 3 2 1 0 O F L K Long E N D J C Medium I M Evacuation Scenario Figure 5.23 Results from Simulation Modeling. G REFERENCES 99 durations. In this case study, evacuation and travel time were chosen as measures of effectiveness. Any other measures of effectiveness, such as delay per vehicle or delay to nonevacuation routes, can also be selected based on the analysis objectives 5.3 APPLICATION OF OTHER METHODS In addition to the tools described in this chapter, several other methods (e.g., the Monte Carlo analysis presented in Chapter 4) can help in assessment of security risks for existing transportation infrastructure. Other methods also can be considered for risk assessment to create appropriate mitigating measures. For further study, the reader may consult the references listed in this chapter and in Chapter 4 detailing current risk assessment methods. REFERENCES AASHTO. 2002. ‘‘A Guide to Highway Vulnerability Assessment for Critical Asset Identification and Protection.’’ Prepared by SAIC. Washington, DC. Audigier, M. A., Kiremidjian, A. S. Chiu, S. S. and King. S. A. 2000. ‘‘Risk Analysis of Port Facilities.’’ Proceedings of the 12th World Conference on Earthquake Engineering, paper no. 2311. Babaei, K., and Hawkins. N. 1993. ‘‘Bridge Seismic Retrofit Planning Program.’’ Report WARD 217.1, Washington State Department of Transportation, Olympia, WA. Basoz, N., and Kiremidjian. A. S. 1995. ‘‘Prioritization of Bridges for Seismic Retrofitting.’’ Report No. 114, John Blume Earthquake Engineering Center, Department of Civil Engineering, Stanford University, Stanford, CA. Blue Ribbon Panel on Bridge and Transit Security. 2003. Recommendation for Bridge and Tunnel Security, FHWA/AASHTO, September. Chien, S. I.-J. and Opie. K. 2006. ‘‘Analysis and Modeling of Cape May County Roadway Elevations and Evacuation Routes.’’ Final Report for the New Jersey DOT Bureau of Research, FHWA-NJ-2005.022, May. Goicoechea, A., Hansen, D. R. and Duckestein. L. (1982). Multiobjective Decision Analysis With Engineering and Business Applications. New York: John Wiley & Sons. Hart Consultant Group et al. 1994. ‘‘Seismic Risk Decision Analysis for Kaiser Permanente Pasadena.’’ Final Project Report, Santa Monica, CA. Kim, S. H. 1993. A GIS-Based Risk Analysis Approach for Bridges against Natural Hazards. Ph.D. dissertation, Department of Civil Engineering, State University of New York, Buffalo, NY. King, S. A., and Kiremidjian.A. S. 1994. ‘‘Regional Seismic Hazard and Risk Analysis Through Geographic Information Systems. Report No. 111, John Blume Earthquake Engineering Center, Department of Civil Engineering, Stanford University, Stanford, CA. 100 APPLICATION OF RISK ASSESSMENT AND MANAGEMENT TOOLS Litman, T. 2006. ‘‘Lessons from Katrina and Rita: What Major Disasters Can Teach Transportation Planners,’’ ASCE Journal of Transportation Engineering 132 (January): 11–18. Maroney, B. 1990. ‘‘CALTRANS Seismic Risk Algorithm for Bridge Structures. Division of Structures California Department of Transportation, Sacramento, CA. Nuclear Regulatory Commission. 1981. Fault-Tree Handbook. Available online at www .nrc.gov/reading-rm/doc-collections/nuregs/staff/sr0492/#pub-info. Saaty, T. L. 1980. The Analytic Hierarchy Process. New York: McGraw-Hill. Sheng, L. H., and Gilbert.A. 1991. ‘‘California Department of Transportation Seismic Retrofit Program: The Prioritization and Screening Process,’’ Proceedings of the Third U.S. National Conference on Lifeline Earthquake Engineering, 1110–1119. South Carolina Department of Transportation. (2006). ‘‘South Carolina Hurricane Evacuation Plan’’. Theodoulou, G. (2001). ‘‘Contraflow Evacuation on the Westbound I-10 Out of the City of New Orleans’’ MS Thesis, Louisiana State University and Agricultural and Mechanical College, Baton Rouge, Louisiana. Tuydes, H., and Ziliaskopoulos.A. 2006. ‘‘A Tabu-Based Heuristic Approach for the Optimization of Network Evacuation Contraflow,’’Proceedings of the Transportation Research Board Annual Meeting, National Research Council. United States Army Corps of Engineers. (2003). ‘‘Delmarva Hurricane Evacuation Study’’. Prepared for the U.S. Army Corps of Engineers, Philadelphia Division. Available at www.nap.usace.army.mil/HES/Delmarva/index.html. Accessed October 20, 2007. United States Army Corps of Engineers. (2007). ‘‘BEHAVORIAL Data collected for Hurricane Evacuation Studies’’. Available online chps.sam.usace.army.mil/USHESdata/ Behave_Start_Frame.htm. Accessed February, 2007. U.S. Department of Justice. 2000. Fiscal Year 1999 State Domestic Preparedness Support Program. Washington, DC. Wolshon, B. 2001. ‘‘One Way Out,’’ Natural Hazards Review 6, no. 3 (August). 105–112. REVIEW QUESTIONS 1. Show an application of the Blue Ribbon Panel method for security risk assessment for a critical transportation infrastructure in your region. 2. Develop a fault-tree model for analyzing the failure risk of a highway tunnel. 3. If researchers have found that the average life span of a particular type of fiber optic line is 20 years and that the Weibull distribution with l = 23 and k = 1.2 fits the observed failure rates best, find the probability that this type of line will fail at five years. 4. Describe how simulation can be applied for planning for incident response and evacuating at-risk populations. 5. Find the probability of failure for the top event in the following fault tree. REVIEW QUESTIONS 101 Primary Event E1 A, P=0.001 E2 E3 A, P=0.001 B, P=0.005 C, P=0.03 E4 A, P=0.001 B, P=0.005 6. Find the minimal cut sets for the fault tree shown in question 5. CHAPTER 6 FUNDAMENTALS OF COMPUTER NETWORK SECURITY FOR ITS A s communications between centers, devices, vehicles, and travelers are the foundation of intelligent transportation systems (ITS), an understanding of computer networking is important for professionals working in this area. This chapter provides an overview of the major elements for securing these networks from both unintentional and deliberate attacks, where an attacker attempts either to gain unauthorized information and control or to disrupt network services. It is important to secure ITS elements from attacks, unintentional as well as deliberate, so that no disruption of services is experienced. This is especially true regarding security-related services, such as surveillance, detection, and response. Securing the ITS network is the foundation for providing reliable security services. This chapter discusses the fundamentals of computer network security for a secure ITS network. 6.1 INTRODUCTION There are many books on computer security. However, from the viewpoint of ITS professionals, they appear to be written by security experts for security experts. Such books tend to have detailed explanations of security protocols and encryption systems (e.g., the Rivest, Shamir and Adleman [RSA] algorithm, which is used for encryption of messages for secured communication between a sender and a receiver), or they focus on the details for building secure operating system kernels or databases. The references section of this chapter lists some recommended texts on these and other computer network security topics; Transportation Infrastructure Security Utilizing Intelligent Transportation Systems R. Fries, M. Chowdhury and J. Brummond Copyright © 2009 John Wiley & Sons, Inc. 102 6.2 ELEMENTS OF COMPUTER NETWORK SECURITY 103 however, because most transportation professionals are not security experts, these books will not be of much assistance to them without background information as it applies to ITS. There exist even fewer references to turn to for help with understanding and using secure computer network systems as they apply to ITS. This chapter explains the fundamental elements of a secure system and how to use such a system to protect your security objectives. Computer network security is presented from the viewpoint of security policy. Because a security policy is a set of rules that govern the security of a system or network, this chapter focuses on what secure systems can allow or forbid, not on the mechanisms that enforce the policy. 6.2 ELEMENTS OF COMPUTER NETWORK SECURITY Security is an essential part of any computer network. Computers have become more important than ever, primarily because of their ability to network with one another. In the past, isolated systems were easier to secure since they did not have many interfaces outside of a private network. Today’s networking capability enables sharing information and having interoperable systems, but it also introduces vulnerabilities. The computer network security can be organized into two categories, as shown in Figure 6.1. The two areas are (1) computer system security, which includes both source and destination computers and encompasses the physical asset (the computer), operating systems, databases, and software in the computer; and (2) communication security, which encompasses security of the physical links as well as the protocols used to transport information between the source and destination computers. A deliberate attack can alter, compromise, or damage the operating systems, databases, and programs in host computers to disrupt their functionalities. Computer Network Security Computer System Security (Source and Destination) Hardware Operating Systems Databases Programs Communication Security Network Communication Links Transportation Protocols Figure 6.1 Computer Network Security Elements. 104 FUNDAMENTALS OF COMPUTER NETWORK SECURITY FOR ITS Attackers can also access critical information, such as databases with sensitive personal information. Similarly, the threat can be on the communication link to access information in transit or disrupt services through interruption. 6.3 IMPORTANCE OF COMPUTER NETWORK SECURITY Every part of the world has experienced attacks against computer networks. For example, the Slammer worm in 2003, CodeRed in 2001, and the Melissa Virus in 1999 crippled computer networks worldwide for significant amounts of time, resulting in economic and other losses (Kurose et al. 2003). Attacks on computer networks can cause disruptions that result in significant harm to the services provided by a public or a private agency. To safe guard against the potential harm caused by these attacks, public and private organizations have invested a significant amount of their budgets in establishing and operating secured computer networks. With the increased functionality and coverage of the computer networks connected by the Internet, computer crimes have been on the rise. One problem with computer crimes is that it is difficult to identify the perpetrators, who may live anywhere in the world. Furthermore, it is not easy to prosecute computer crime perpetrators (Pfleeger et al. 2003). Supervisory control and data acquisition (SCADA) systems, those monitoring processes and autonomously making needed adjustments, are also vulnerable to network security threats. Although in SCADA and other control systems, security threats were previously managed by operating off-line, the control industry now relies on an increasing number of on-line systems, such as seen in most ITS applications (Wiberg 2006). It is critical to secure SCADA systems, particularly those operating critical transportation infrastructure. 6.4 APPROACH TO COMPUTER NETWORK SECURITY Computer network security must be addressed in a systematic manner, similar to the security plan for the transportation infrastructure (see Chapter 9). Current situations must be analyzed, and all possible vulnerabilities in the network must be identified. Then, precautions must be taken against possible attacks on critical systems, and recovery plans must be in place in case of an attack. Because mitigating all vulnerabilities is cost-prohibitive, a selection process should be used to rank and choose which systems and vulnerabilities are critical. A computer network security plan must address seven elements (Pfleeger et al. 2003): 1. Policy. 2. Current state. 3. Security requirements. 6.4 4. 5. 6. 7. APPROACH TO COMPUTER NETWORK SECURITY 105 Recommended controls. Accountability. Timetable. Continuing attention. A computer network security plan for ITS should be developed using these seven elements, as described in the next sections. 6.4.1 Policy Policy is at the heart of network security. A secure system is one that enforces a comprehensive policy. Without a policy, security is a rather nebulous concept. Policy describes which system and user actions are allowed and which ones are forbidden. Policy also describes the actions a system must perform and when it performs them. Policy rule statements contain subjects, actions, and objects. For example, a policy rule could be: Each system user must change his or her password every 90 days. The subject is the system user; the action is to change; and the password is the object that the subject is allowed to act on. Policy can also be conditional, for example: Between the hours of 6 A.M. and 10 A.M., the reversible lane gates shall be down in the southern direction of traffic flow. In this example, the condition of between the hours of 6 A.M. and 10 A.M. governs when the gates should be down. If the condition is true, then the policy is enforced; otherwise, it is not. Security systems usually identify subjects using the concept of credentials. The security system cannot control what a subject does; it can control only whether it will allow the subject to take actions. The policy governs what the system will or will not do for each subject. In order to enforce the policy, the system has to be able to distinguish between different subjects and make judgments about them. The system requires security attributes that fall into two categories: identities and privileges. Identity attributes are solely for individual subjects; privileges can be shared by many subjects. Credentials are collections of subject security attributes. The security system may need to use some or all of these attributes when making policy decisions. Policies can be regional in nature and also system specific. For a regional ITS computer network security policy, overarching security rules must be clearly documented. The regional security policy document should include: Regional ITS stakeholders’ goals for computer network security Responsible stakeholders and responsible persons within each stakeholder group A commitment from each stakeholder for security, including each person’s role(s) for upholding computer security in business practices (Pfleeger et al. 2003) 106 FUNDAMENTALS OF COMPUTER NETWORK SECURITY FOR ITS System-specific security policies must require that subjects provide some sort of authentication data (e.g., a password or retinal scan) to identify themselves. Once authenticated, subjects can be given certain privileges based on their credentials. Access control policy does not scale well if each subject is given a different set of privileges; therefore, many security systems use collective privileges (i.e., accountants and engineers) that reduce the number of rules to a more manageable set based on the subject’s role. Overall, the policy document should identify: Authorized personnel (subjects) to access the computer network (actions) and what resources (objects) each of these people can access and under what conditions Types of access (i.e., full or restricted access to all or part of the resources) to the computer network by authorized personnel Policy should take into account the threat of playback from a packet sniffer. Packet sniffers can be a combination of hardware and software that intercepts message traffic passing through a network. As the data flows through the network, the packet sniffer collects each packet of data and can eventually decode its content. It is also possible that the same stream of packet data can be reintroduced into the network called playback. 6.4.2 Current State The security plan should include a description of the existing security status, including the vulnerabilities and the risks of a successful attack due to these vulnerabilities. The plan identifies computer network assets, risks of those assets being attacked, a protection plan for resisting and detecting those attacks, and a response plan for when an attack occurs (Pfleeger et al. 2003). 6.4.3 Security Requirements The security requirements specify functional requirements to meet the security goals identified in the security policy. Table 6.1 presents security requirements. 6.4.4 Recommended Controls The recommended controls step of the security plan specifies the measures to be implemented. It identifies the planning, design, and development approaches to meet the security requirements identified in the preceding step. For example, it could specify the specific access control mechanisms (i.e., passwords and their characteristics), data encryption techniques, virus protection, specific firewall configurations, and auditing. 6.4 APPROACH TO COMPUTER NETWORK SECURITY 107 TABLE 6.1 Security Requirement Characteristics General Requirement Characteristics Correctness Consistency Completeness Realism Need Verifiability Traceability Privacy Non-repudiation Access control What It Means Requirements are error free and understandable. Requirements are not conflicting or ambiguous. Requirements include all possible scenarios. Requirements can be implemented. Requirements are not unnecessarily restrictive. Tests plans can be developed to evaluate conclusively and objectively whether the requirements are met and at what degree. Each requirement can be traced back to the functions and data related to it. Requirements do not violate federal, state, local, or company privacy policies. Requirements ensure integrity and traceability to the sender. Requirements allow only appropriate persons and systems access at allowable times. Source: Pfleeger et al. 2003. ‘‘Recommended Security Controls for Federal Information Systems,’’ a publication of the National Institute of Standards and Technology (NIST), presents a detailed list of recommended control measures for computer systems. NIST grouped the controls in the three general categories: access control, awareness and training, and physical and environmental protection. A complete list of these controls and their description as presented in Ross et al. 2007 can be found at http://csrc.nist.gov/publications/PubsSPs.html. 6.4.5 Accountability The security plan assigns responsibilities of each party involved in computer network security. For example, in a transportation management center, the database administrator may be responsible for availability and access to the database; human resources staff may be responsible for screening potential staff for security and for providing or arranging security-related training of the employees. 6.4.6 Timetable The security plan must identify a phased implementation schedule of the recommended countermeasures or mechanisms to address the identified vulnerabilities. This schedule also can be used to evaluate the implementation progress of the security plan. The recommended countermeasures should be 108 FUNDAMENTALS OF COMPUTER NETWORK SECURITY FOR ITS scheduled based on their prioritization in terms of risks of an attack due to the identified vulnerabilities. Benefit-cost analysis and other tools might aid in the prioritization of these items. This timetable should be a strategic and living document; for example, it should be able to adapt when a new threat is identified or when new tools become available to minimize identified vulnerabilities. Today some agencies are facing the challenge of addressing security in existing computer networks; it is always better to implement security mechanisms when the system is first deployed. 6.4.7 Continuing Attention As previously stated, the security plan is a living document. The plan should be evaluated periodically to identify its current effectiveness and to determine if changes are needed. The security plan may need to be revised based on new threats, technologies, and/or priorities. Proactive agencies may want to test their security plans. Employing external personnel to conduct a penetration test of their computer network can provide valuable information about network strengths and weaknesses. Identifying weaknesses through a benign attack such as a penetration test can prove less costly than identifying those weaknesses after a true network security breach. 6.5 COMPUTER NETWORK SECURITY IN ITS Computer network security is an important part of securing the ITS infrastructure so its functionalities are not compromised or halted. As shown in Figure 6.2, an ITS computer network includes computer systems at centers (e.g., traffic management and emergency management centers), computers in vehicles, computers in conjunction with roadside devices such as automated toll tag readers and traffic sensors, and computers used by travelers to access transport information, all of which are vulnerable to deliberate attacks. Similarly, these centers, roadside devices, vehicles, and travelers communicate with wireline and/or wireless media. Communication networks connecting these different ITS services at different locations are also vulnerable to deliberate attacks. The communication links between these systems must be evaluated for potential security threats. Chapter 7 discusses leveraging the National ITS Architecture to help quantify the threats to the flow of information and to the systems themselves. 6.6 NETWORK SECURITY OBJECTIVES Each computer network should be planned, designed, operated, and maintained with specific security objectives. Confidentiality, integrity, and availability are three primary security objectives for ITS. Consequently, the security 6.6 NETWORK SECURITY OBJECTIVES Computer System Computer System Center Center Center Field Center 109 Traveler Communication Media Center Vehicle Field Field Field Vehicle Vehicle Vehicle Figure 6.2 Computer Network in ITS. component of the National ITS Architecture was evaluated in terms of meeting these three objectives Chapter 7 discusses securing ITS in detail. However, authentication, nonrepudiation, and access control are related security objectives that that can overlap with the three objectives considered in the National ITS Architecture. The next sections discuss the computer network for these five security objectives: 1. 2. 3. 4. 5. Confidentiality. Authentication. Message integrity and nonrepudiation. Availability. Access control. 6.6.1 Confidentiality Confidentiality is an important part of computer network security. The security objectives related to confidentiality include the concept that only the receiver can understand the messages transmitted by the sender and vice versa. Encryption and decryption are widely used tools for encoding and decoding messages, so that unintended persons cannot understand the transmitted 110 FUNDAMENTALS OF COMPUTER NETWORK SECURITY FOR ITS encrypted, or ‘‘coded,’’ information. Thus, if unauthorized persons stole coded information from the computer network during transmission, they would learn nothing as the information was transmitted in a coded form; that is, unless the attackers can decode the encryption. In ITS, confidentiality must be maintained when critical information or control is being exchanged between ITS elements, such as between a traffic management center and a law enforcement agency about a potential threat or between a financial institution and a toll collection system regarding toll transactions. Cryptographic techniques are employed to encrypt and decrypt information within systems as well as data exchanged between computer systems. Two common terms associated with encryption and decryption are plaintext and ciphertext. Plaintext is defined as the original message; ciphertext is the encrypted message. A string of numbers or characters—a key—is used to encode or decode the messages. There are two types of key systems: 1. Sender and receiver both know the key. 2. A public key and a private key are utilized. In the first key system, both the sender and the receiver know a secret key (symmetrical key systems). The only proven early unbreakable cipher is the one-time pad. This system, developed in the mid-twentieth century, was used by spies of several nationalities who were given a pad of paper containing a randomly chosen secret key and told that it could be used for one encipherment only (Simmons 1992). The primary problem with this approach is that both the sender and the receiver must somehow obtain the secret key. This problem has led to the development of a key system that allows for secure systems to be built that require no secure transfer of any secret key. In an asymmetric key system, a pair of keys are used. One key, the public key, is available publicly; the secret key known only to the receiver or the sender is called a private key. Figure 6.3 shows the basic concepts of the encryption and decryption technique. A key to encrypt the plaintext into ciphertext using an encryption algorithm, and another key is used by the receiver to decode the system using a decryption algorithm. In symmetrical key systems, these two keys are identical and known only by the sender and the receiver. In public key systems, one key is known to both the sender and the receiver and the other, a private key, is known only by the sender or the receiver. Plaintext Plaintext Ciphertext Encryption Algorithm Decryption Algorithm Figure 6.3 Concept of Encryption and Decryption. 6.6 NETWORK SECURITY OBJECTIVES 111 Different encryption and decryption methods, such as the RSA algorithm, elliptical curve cryptography (ECC), Secure Shell (Version 1 and 2), Secure Socket Layer, and Transport Layer Security have been developed so that senders can encode information and receivers can decode information (Kurose and Ross 2005). Of these methods, the RSA algorithm has been the most widely used in the area of public key cryptography (Kurose and Ross 2005). As computing power increases, the most secure encryption/decryption algorithm and method changes as well. In the 1970s, for example, the U.S. government chose the Data Encryption Standard (DES) as a U.S. Federal Information Processing Standard (FIPS PUB 46). In May 2005, the DES FIPS 46.36 standard was officially withdrawn due in part to its small key size, but the NIST has approved Triple DES (three separate rounds of applying the DES) through the year 2030 for sensitive government information (NIST 2006). The Advanced Encryption Standard (AES) is a cipher adopted as an encryption standard by the U.S. government in May 2002. Like its predecessor, DES, AES has been analyzed extensively and is now used worldwide. AES was announced by NIST as U.S. FIPS PUB 197 in November 2001 after a five-year standardization process. As of 2006, AES was one of the most popular algorithms used in symmetric key cryptography. It is available by choice in many different encryption packages (Wikipedia, AES). A simple example of the application of RSA algorithm follows. In order to understand its depth and breadth, readers are encouraged to consult Simmons (1992) and other works on encryption and decryption in computer network security. For using RSA, two large prime numbers p and q are chosen. The larger these values are, the more difficult it is to decode by an unauthorized person (Kurose and Ross 2005). For simplicity in the following example, we choose p ¼ 3 and q ¼ 11 and encode the word ‘‘go’’. The following steps are taken to encode (by the sender) and decode (by the receiver) the message (Kurose and Ross 2005): 1. Choose values for p and q such that they are both prime. The larger these numbers are, the more difficult it will be for unauthorized persons to decode the message and the more computationally complex it will also be on the network. In this example, we will use p ¼ 3 and q ¼ 11. 2. Next, find the variables n and z. n is the product of p and q, and z is the product of 1 less than each p and q, respectively. In this example, n ¼ p q ¼ 3 11 ¼ 33 and z ¼ ð p 1Þ ðq 1Þ ¼ ð3 1Þ ð11 1Þ ¼ 2 10 ¼ 20. 3. Use the z-variable to select another variable, e, such that it and z have no common factors. In this example, we choose e ¼ 3, since 3 and 20 have no common factors. 4. Select another variable, d, such that e d 1 is evenly divisible by z. For the example, we select d ¼ 7, since 3 7 1 (i.e. e d 1) is exactly divisible by 20. 112 FUNDAMENTALS OF COMPUTER NETWORK SECURITY FOR ITS 5. The receiver makes the two values public, n and e, and keeps the value of d secret. The pair made public is called the K þ B pair and is written (n, e). The pair is used for the message encryption into ciphertext. The secret Kþ B number is also paired with n and is called the K B pair. In this example, the Kþ pair is (33, 3) and the K pair is (33, 7). B B 6. Use these variables to encrypt or decrypt a message. In encryption terminology, the plaintext is encrypted into ciphertext or the ciphertext is decrypted into plaintext. In this example, we will encrypt and decrypt the message ‘‘GO.’’ To convert alphabetical messages into a numeric representation, label each character as its corresponding numeric place in the alphabet. For example, the letter a is 1 and the letter b corresponds to 2. 7. The public key is (n, e), which the sender makes known to everyone, and the private key (n, d), is only known to the sender. Here are the equations for encryption and descriptions (Kurose et al. 2005): C ¼ Me MOD n M ¼ Cd MOD n If the sender sends a bit pattern, or number m where m is less than n, he or she encodes using the public key (n, e) and the equation for ciphertext c ¼ me mod n. This process converts plaintext into ciphertext; see Table 6.2. The receiver decrypts the ciphertext, c, to find m with the following equation using the private key (n, d) and the equation m ¼ cd mod n. The results of this process are displayed in Table 6.3. 6.6.2 Authentication Authentication for a computer network is a process of proving the sender’s identity. There are different types of user authentication mechanisms from three sources: user knowledge, user possessions, and user physical characteristics (Pfleeger et al. 2003). User knowledge authentications are popular for banking and other transactions where users are asked to enter a personal identification number (PIN) or password. User possessions can include identification cards and keys. User physical characteristics can include retinal scans or fingerprints, which are known as biometrics. TABLE 6.2 Sender’s RSA encryption using the K þ B pair, e ¼ 3, n ¼ 33 Plaintext Letter g o m: numeric representation me ciphertext c ¼ me mod n 7 15 343 3375 13 9 6.6 NETWORK SECURITY OBJECTIVES 113 TABLE 6.3 Receiver’s RSA decryption using the K B pair, d ¼ 7, n ¼ 33 Ciphertext c 13 9 c d m ¼ cd mod n Plaintext Letter 7 15 g o 62748517 4782969 The successful authentication process prevents someone with bad intentions from establishing a false identity. However, the authentication process can be quite complex and requires careful consideration of all possible ways an unauthorized user may try to establish a false identity to receive information or attack the computer network. For example, in a common scenario, the system identifies a sender through his or her Internet Protocol (IP) address. Reliance on only an IP address for authentication may pose a risk that a potential unauthorized system is spoofing the network. Spoofing is replacing the IP source address of the packet sent, in order to subject the system to an attack and hide the true source of the attack. A sender’s unique password could be a better way to authenticate him or her; however, it must be encrypted so that a potential attacker is not able to access the password during communication between the sender and the receiver. A more secure authentication protocol may require using private and public keys, as done in the encrypting and decrypting a message. Although the authentication process can be quite complex, it is necessary to ensure that only the correct personnel are allowed access to the computer network. 6.6.3 Message Integrity and Nonrepudiation Message integrity means that the original message has not been changed during communication. Nonrepudiation refers to the fact that the message or information sent by a person must be able to be traced back to that person. For example, an incident event notification sent from a traffic management center to an emergency management center over the Internet must satisfy two requirements: 1. It must not be changed in its content, format, or any other original features (message integrity). 2. It must be traceable to the sender (non-repudiation). Both of these objectives could be accomplished by a digital signature, which is a form of cryptographic technique. Digital signatures include use of private and public keys to ensure that the document that was received was not altered in any way and is traceable to the actual sender. Digital signature schemes normally use two algorithms, one for signing, which involves the user’s secret 114 FUNDAMENTALS OF COMPUTER NETWORK SECURITY FOR ITS key, and one for verifying signatures, which involves the user’s public key acting much like an actual signature on paper. 6.6.4 Availability Availability ensures that the system is available to authorized users. Over the past several years, computer networks all over the world have been attacked to disrupt availability or service. Such an attack is known as denial of service (DoS). In addition to intentional attacks, unpredictable events, such as transmission failure, may result in DoS. Enterprises that depend significantly on a computer network to perform business and provide services suffer significant economic losses due to a DoS event. Transmission failure is a common DoS incident experienced by computer networks around the world. Some reasons for transmission failure include (Pfleeger et al. 2003): Transmission line is cut accidentally or deliberately. Network noise corrupts transmission packets, so the communication message could not be recognized or delivered. Hardware or software failure makes a transmission sender or receiver system fail. A device is saturated with data; incoming data are rejected until overloading of the device is cleared. As can be seen, some of these attacks are physical in nature, such as the intentional cutting of transmission lines. However, some are electronic, such as connection flooding. In connection flooding, attackers send huge amounts of data through the network to oversaturate it; their aim is either to prevent other users from accessing the network or to significantly degrade the performance of the attacked network (Pfleeger et al. 2003). Some of these problems can be solved easily; however, others require replacement of the devices or communication lines. For example, the entire communication line may have to be replaced to restore services after a transmission line is cut. Redundancy of ITS devices or communication networks will improve system availability and reduce the risks of DoS under both accidental events and intentional attacks. For example, if a transmission line is cut, another redundant line can provide the function without any disruption of services. However, the cost of providing this redundancy may prevent its adoption. Selection of a distributed system architecture for ITS may also contribute to the increase in availability. For example, a distributed sensor network for ITS, where a cluster of sensors process data locally and send the processed data to the network’s cluster controllers, may reduce the risk of a single point of failure. Centralized control, where each sensor continuously sends data back to a single transportation management center increases the risk of a single point failure. 6.6 NETWORK SECURITY OBJECTIVES 115 In a centralized architecture, the operation of the entire highway system network may fail due to the failure of the central computer system at a transportation management center or be significantly impaired by the disabling of a fiber optic trunkline. Wireless communication is receiving significant attention for connecting ITS centers, devices, and vehicles for data exchange and control functions. Among a multitude of challenges in wireless communications, security has been one of the utmost concerns. For example, while Radio Frequency Identification Devices (RFID) are used in automated toll collection and other applications in ITS for automated wireless electronic identifications, it proves challenging in authentication and mitigating other security threats. Even advanced technologies, such as the Digital Signature Transponder (DST), which have used Advanced Encryption Standard (AES) and special cryptographic keys, have shown to be vulnerable to attacks (Brooks et al. 2008). It suggests that selection of specific technology in ITS for its security features will be as important as it functionality for many applications. Existing wireless ITS applications have broadly utilized cell phone infrastructure or Wi-Fi technologies. However, with the future potentials in WiMAX and 4G technologies, many ITS applications will adopt these systems for their potential broad coverage area and performance. Yet reliability of wireless communication systems remains an issue because of different environmental conditions and security threats. With new generation of ITS applications, such as vehicle-infrastructure integration, where vehicle-tovehicle (V2V) and vehicle-to-roadside (V2R) communications are needed, Vehicle Ad Hoc Networks (VANets) have been proposed in addition to other options, including WiFi and WiMAX. These systems can assist in vehicle collision avoidance and real–time traffic management through information dissemination and control. V2V or V2R networks may be vulnerable to terrorist attacks trying to cause harm in the traffic management and safety functions. Wireless communications will be an integral part of most future ITS applications so will be its security. Resources such as the Propagation Handbook for Wireless Communication System Design (Crane 2003) and the U.S. Center for Wireless Communications (USCWC, Stanford, California)1 can provide support to wireless communication network designers. ITS professionals should evaluate the reliability of any communication network, wireless or wireline, under different operational and environmental situations in order to assess its overall availability. Brooks et al., recently completed a survey on the challenges of state-of-the-art automotive system security that provides many insights on future wireless communications security for the transportation system (Brooks et al. 2008). 1 U.S. Center for Wireless Communications, P.O.Box 19789, STANFORD, CA 94309, USA. 6.6 NETWORK SECURITY OBJECTIVES 116 6.6.5 Access Control Access control refers to the objective for a computer network to allow access only to authorized users. Unauthorized access to a computer network can impact confidentiality, message integrity, nonrepudiation, and availability. A computer firewall is a method or device that regulates the level of trust between two or more networks. A firewall is usually a combination of hardware and software, and it is a widely used technique to protect a network from the Internet as well as regulate the traffic between networks within the same company. A firewall separates an enterprise’s internal computer network from the outside Internet to restrict access of packets of data. Packets that are not considered to be security threats are allowed to pass while the others have no access to the internal network (Kurose and Ross et al. 2003). A firewall should be required by all ITS centers, restricting unauthorized access to a center or agency’s internal network and permitting authorized access based on the security policy. As shown in Figure 6.4, a typical network would have one or more firewall servers on the network to regulate data traffic between computers on the network and the Internet. It could also regulate the data traffic between the computers on the network. The firewall box represents the filtering of all communication passing through the firewall. The firewall is then able to ensure that only authorized packets are allowed. Authorized packets are defined by packet-filtering rules that indicate which packets should be accepted and which packets should be denied. Further, packets can be inspected for tampering, called packet sniffing, to ensure the original message is intact. In this application, for example, if an untrusted server has previously flooded an ITS network with data, then a rule could be placed that blocks all incoming email from that host. There are also more complex types of firewalls called Guard, Application Proxy and Stateful Inspection Firewall for improved access control (Anderson 2001, Pfleeger et al. 2003). Computer on the Network Firewall … Computer on the Network Internet Firewall Server Figure 6.4 A Firewall for a Computer Network. REFERENCES 117 6.7 FUTURE OF NETWORK SECURITY AND ITS IMPACTS ON SECURING AN ITS NETWORK Technology has been changing at a rapid pace. As the trend is likely to continue, improved systems will provide better services and functionalities. The advances in technology will include advances in computer networking that will provide faster services and processing of information. Computer network security likely will become more complicated with the increase in speed, capacity, bandwidth, and throughput of network and network devices (Pfleeger et al. 2003). Synchronous with these advances, the possible attacks against computer networks around the world to gain unauthorized information or disrupt services likely will increase with more technologically savvy attacks that may be more malicious than ever. Computer network security experts will have new challenges to protect networks and respond to these attacks. ITS professionals must use the most up-to-date information to identify possible types of attacks and their risks and to implement measures to protect and respond to such attacks. For example, by creating a security policy within a security plan, by considering the security architecture as the system is developed, and by adhering to industry and ITS standards/protocols, the future security of ITS networks should improve. As described in Section 6.6.4, the migration from the existing centralized online traffic management model to a distributed model may reduce single points of failure, where the system could fail if the centralized control fails. Distributed systems also help with the distribution of processing requirements, eliminating the need to transfer all data through the network to a centralized processing center (Rambhia 2002). With computers in vehicles and roadside traffic devices, the breadth and depth of computer networks in ITS will likely increase. For example, the Vehicle-Infrastructure Integration (VII) initiative, in which vehicles and infrastructure units communicate with one another through wireless communication network(s), offers an opportunity to improve the effectiveness and efficiency of providing information to drivers, such as signing, speed limit, and traffic information. Opt-in or anonymous traffic surveillance collection data from vehicles on their speed, acceleration/deceleration, position, and maneuvering could provide unprecedented information for ITS systems (National VII Coalition 2007). The expected improvement in the quality and availability of information would increase the risk of vulnerabilities in supporting the security objective of confidentiality, authentication, access control, and availability. This and other ITS applications will increase the challenges for the ITS professionals to develop appropriate security policies, plans, and measures to protect the integrity of the network. REFERENCES Anderson, Ross J. 2001. Security Engineering – A Guide to Building Dependable Distributed Systems. John Wiley & Sons. 118 FUNDAMENTALS OF COMPUTER NETWORK SECURITY FOR ITS Brooks, R., Sander, S., Deng, J., and Taiber, J. (2008) Automotive Systems Security Challenges and State-of-the-art, submitted for review. Crane, R. K. 2003. Propagation Handbook for Wireless Communication System Design. Taylor & Francis. Kurose, James, and Keith Ross. 2005. Computer Networking, 3rd ed. Pearson Education. National Institute of Standards and Technology. 2006. Recommendation for Key Management – Part 1: General. NIST Special Publication 800–57. Available online at <http://csrc.nist.gov/publications/nistpubs/800–57/SP800–57-Part1.pdf> National VII Coalition. 2007. VII Coalition homepage [Online]. Available: www.vehicleinfrastructure.org. Pfleeger, Charles, and Shari Pfleeger. 2003. Security in Computing, 3rd ed. Prentice Hall. Rambhia, Ajay M. 2002. XML Distributed Systems Design. Sams. Ron Ross, Stuart Katzke, Arnold Johnson, Marianne Swanson, Gary Stoneburner, George Rogers, and Annabelle Lee. 2007. Recommended Security Controls for Federal Information Systems: Guidance for Selecting Cost-Effective Controls Using a Risk-Based Method. National Institute of Standards and Technology. <www.itl.nist.gov/lab/bulletns/ bltnmay05.htm > Simmons, Gustavus J. (Editor), Contemporary Cryptology, IEEE Press, The Institute of Electrical and Electronics Engineers, Inc., New York, 1992. U.S. Department of Commerce. 1999. Federal Information Processing Standards Publication 46. Wiberg, Kenneth C. 2006. Identifying Supervisory Control and Data Acquisition (SCADA) Systems on a Network via remote Reconnaissance. Masters Thesia. Naval Postgraduate School, Monterey, CA. REVIEW QUESTIONS 1. What are the differences between computer system and network security in terms of the security objectives? 2. Develop a computer network security policy for a basic traffic management center. 3. Describe the basic concepts of confidentiality in computer network security. Describe a method to achieve confidentially in the computer network. 4. Explain with an example the differences between message integrity and nonrepudiation. 5. What is a firewall? How does it help computer network security? 6. How could the advances in computing resources and network impact the security of the ITS computer network? 7. What do you think is the biggest security threat for an ITS computer network? Which security objectives may minimize this threat? 8. Explain the difference and advantages/disadvantages between private and public key encryption schemes. REVIEW QUESTIONS 119 9. Name the seven elements of a computer network security plan with a brief description of each element. 10. What is the most secure encryption technique providing perfect security? Explain how it works. 11. With the K B pair (33, 7), decode this message: 14 9 5. 12. Encrypt this message using the K þ B pair (33, 3): I T S. 13. Match the terms to their definition: Confidentiality ________ Authentication ________ Message integrity ________ Availability ________ Access control ________ Plain/clear text ________ Cipher text ________ Packet sniffing ________ Virus attacks ________ Spoofing ________ a. The process of confirming that a sender or receiver is who/what they say they are b. The original form of a message without considering confidentiality c. Ensures that only legitimate users may access a network d. Created by using an encryption algorithm on a plain text message e. Takes over an existing connection or computer and can fool other network connections by untrue authentication f. Can be used to monitor the transmission of packets within a network but can allow hackers to view passwords and verifications sent between users g. Only the sender and receiver of the message are able to understand it, preventing eavesdroppers from knowing the message h. Ensures that legitimate users can always access their network information i. Enacts programs that use a computer in an unwanted way, sending private information, deleting wanted information, or downloading other dangerous information j. Ensuring that messages have not been altered during a transmission either by error or from malicious intent CHAPTER 7 SECURING ITS C omputer systems are easy targets for a security breach. As intelligent transportation systems (ITS) are increasingly used for security purposes, the systems themselves could become targets for hindering their intended functions or creating situations hazardous to public safety. This chapter discusses how ITS can be vulnerable to security threats and ways to minimize these risks. It also presents the security aspects of various ITS deployment standards. 7.1 INTRODUCTION A commonly neglected aspect of ITS is recognizing system threats and vulnerabilities and taking the appropriate security-related actions. In the United States, after the September 11 terrorist attacks, there was a renewed interest in ensuring that our transportation infrastructure was as secure as possible. One of the key activities was updating the U.S. National ITS Architecture to include security more extensively. After much analysis, it was decided to create eight security areas within the ITS domain as well as an underlying ‘‘Securing ITS’’ foundation as depicted in Figure 7.1. The eight security areas of ITS functionality were introduced in Chapter 3. Securing ITS is an important paradigm for the transportation system. ITS is built on computerized information and communication systems. These systems could be accessed without authorization to interfere with their intended functions or create risks to public safety. Transportation Infrastructure Security Utilizing Intelligent Transportation Systems R. Fries, M. Chowdhury and J. Brummond Copyright © 2009 John Wiley & Sons, Inc. 120 7.1 INTRODUCTION 121 Figure 7.1 Securing ITS. (Source: RITA, Security Document, National ITS Architecture 6.0, May 2007.) ITS system security is founded on the interrelated concepts shown in Figure 7.2. The diagram shows the relationship among overall security objectives, identified security threats, and security services (also known as safeguards or countermeasures) chosen to support the security objectives and protect against identified threats. Security Threat Exploits Leads to Vulnerability Security Objectives Risk Directly affects ITS System Security Service Can damage Can be protected by a Figure 7.2 Applying Security to an ITS System. (Source: RITA, Security Document, National ITS Architecture 6.0, May 2007.) 122 SECURING ITS The analysis performed for a specific ITS system is based on three items (RITA, 2007): 1. Analysis of the real or perceived threats factoring in if they are credible or not. 2. Further analysis on whether the system is vulnerable to those threats. 3. Overall risk analysis that balances the cost (both monetary and the effect on operations) of security service(s) against the likelihood of the threat and the consequences if the threat is realized. As shown in Figure 7.2, security objectives start the process by defining what is to be accomplished to address security. The references to this chapter cite a number of excellent resources that fully explain the process of applying security in the design, development, and operation of an information system. Versions 5.0 of the National ITS Architecture, which was subsequently updated further to Version 6.0, included only some of the security concepts in Figure 7.2. Actual system vulnerabilities, assessment of risk, and the ITS system itself require specific system deployment characteristics. For that reason, it was decided to include general security objectives, threats, and security services that are independent of system implementation. Instead of the deployed computer and communications systems—the ‘‘ITS System’’ box in Figure 7.2, these general security concepts are applied to National ITS Architecture subsystems and information flows, as shown in Figure 7.3. Keep in mind that the security analysis included in the National ITS Architecture is high level in order to remain representative of the initial security analysis performed for any system. Figure 7.3 Applying Security to the National ITS Architecture. (Source: RITA, Security Document, National ITS Architecture 6.0, May 2007). 7.2 SECURITY OBJECTIVES 123 The remainder of this chapter discusses how the National ITS Architecture secures ITS. We define general security objectives and threat rankings and describe how those lead to candidate security services for subsystems and architecture flow groups. The chapter also describes how this general security analysis can serve as a starting point for a more in-depth analysis associated with a specific ITS system or regional ITS architecture. 7.2 SECURITY OBJECTIVES Security objectives help form the basis for evaluating appropriate security services and levels of service that satisfy those objectives. The major security objectives identified for the National ITS Architecture—confidentiality, integrity, and availability—very likely apply to some degree in almost any ITS implementation. All security services are used to support one or more of these objectives. Similarly, all threats undermine one or more of these objectives. How well a security system operates can be found by the extent to which it meets the desired objectives. The security objectives each have classifications of high, medium, low, and minimal. For example, one security system may provide a high level of confidentiality, a medium level of integrity, but only a low level of availability. Comparing security systems using these metrics can aid designers in selecting between alternatives. 7.2.1 Confidentiality The confidentiality objective prevents the disclosure of information to unauthorized individuals, processes, or systems (e.g., protecting the personal information of company employees). This security objective focuses on preventing unauthorized disclosure of information that is deemed sensitive and defines the level of restriction to sensitive information that is transmitted or stored within a system (RITA 2007). 7.2.2 Integrity The integrity objective aims to guarantee the reliability and accuracy information and systems defining the level of protection. This protection prevents the alteration of messages either from unauthorized intentions or authorized but unintentional acts. This objective directly relates to authentication, auditing accountability, and access control for sensitive information (RITA 2007). Integrity usually takes the form of a protected audit trail that links specific user accounts with the user’s actions on the system. 7.2.3 Availability The availability objective ensures that information and systems are open to and usable by authorized individuals and/or processes. In contrast to the previous 124 SECURING ITS two objectives, that focus on restricting access, the availability objective focuses on allowing access to the required information if a user or system is authorized and there are no time of day restrictions. 7.3 SECURITY THREATS A security threat is an event or circumstance that, if realized, would adversely impact the surface transportation system or communication between control systems. Threats can include errors, fraud, disgruntled employees, fire, water damage, hackers, terrorist acts, viruses, and natural disasters. In some cases, attackers purposely try to attack a user’s account or system. In a denial of service (DoS) attack, attackers may wish to prevent the legitimate users from using the system. There can also be threats to the transportation supply chain. Within the National ITS Architecture, the seemingly broad spectrum of threats are categorized in a general, uniformly applicable way. The four general threat categories defined in the architecture are: 1. 2. 3. 4. Deception. Disruption. Usurpation. Unauthorized disclosure. Their definitions from the Security Document of the National ITS Architecture are presented in the next sections. 7.3.1 Deception Deception is, ‘‘. . . a circumstance or event that may result in an authorized entity receiving false data and believing it to be true.’’ 7.3.2 Disruption Disruption is, ‘‘. . . a circumstance or event that interrupts or prevents the correct operation of system services and functions.’’ 7.3.3 Usurpation Usurpation is, ‘‘. . . a circumstance or event that results in control of system services or functions by an unauthorized entity.’’ 7.3.4 (Unauthorized) Disclosure (Unauthorized) disclosure is, ‘‘. . . a circumstance or event whereby an entity gains access to data for which the entity is not authorized.’’ 7.4 SECURITY SERVICES 125 7.4 SECURITY SERVICES The system designers, implementers, and system managers ultimately must identify and analyze specific threats to determine the probability of their occurrence and their anticipated damage to a specific transportation system. Security threats, along with security objectives, provide the basis for evaluating and selecting appropriate security services. Security services represent typical security mechanisms, safeguards, or countermeasures that help provide different aspects of security. Security services are driven by the security objectives and threats expected to adversely impact a system or its communication. Security services are partitioned into four broad areas: 1. 2. 3. 4. Information security. ITS personnel security. Operational security. Security management. 7.4.1 Information Security Information security includes securing the source, communication, and endpoint of the information itself. Information security is no different for ITS than for other computerized information systems. Information security provides security services that can be utilized based on the defined security threats and security objectives. In the U.S. National ITS Architecture, these security services, threats, and objectives are classified along with their importance for each group of architecture flows (i.e., emergency security group dealing with incident management). In addition, each National ITS Architecture subsystem has a description of potential security considerations. The seven areas of information security listed are: 1. 2. 3. 4. 5. 6. 7. Confidentiality. Integrity. Availability. Accountability. Authentication. Auditing. Access control. Further discussion of these information security services can be found in the National ITS Architecture Security document (RITA 2007). 7.4.2 ITS Personnel Security It is well known within the security industry that insider personnel can inadvertently or maliciously breach security from within. ITS personnel security deals with: 126 SECURING ITS Screening of personnel Giving supervisors policies and controls to ensure that personnel responsibilities are appropriate Providing regular awareness and training Separation of duties Least privilege Accountability through audit trails Ensuring that terminated or transferred personnel do not have unauthorized access Further definition of the ITS personnel security items can be found in the National ITS Architecture Security document (RITA 2007). 7.4.3 Operational Security Physical and environmental threats to ITS assets need operational security protection. Operational security provides access control, real-time monitoring, configuration control, and security incident and materials management of critical ITS assets. There are seven areas within operational security: 1. 2. 3. 4. 5. 6. 7. Adverse physical and environmental conditions protection. Physical access control. Security monitoring. Security incident management. Contingency planning. System maintenance. Sensitive materials management. Further definition of the operational security items can be found in the National ITS Architecture Security document (RITA 2007). 7.4.4 Security Management Security management provides the overall connections and associations necessary for information security, operational security, and ITS personnel security as well as supporting the eight ITS security areas. A system-wide security policy provides the basis for overall system security. A system security policy specifies the security procedures, roles and responsibilities, system configuration (both between subsystems and between subsystems and terminators), operational security needs, ITS personnel security, and ITS asset security. The security management service includes user and system assignment of appropriate access control, password management, and a host of other security mechanisms based on the identified risks. The military concept of defense in 7.5 SECURING ITS SUBSYSTEMS 127 depth can be used by having multiple layers of security mechanisms so that the compromise or failure of one security mechanism is mitigated by the other security layers. An example would be placing a password on your email client that is different from the password to log in to your system. Even if an attacker breeches the operating system password, the email account is still protected. Another principle is the concept of avoiding security by obscurity, which means that you should assume that the attacker knows what security mechanisms or services are in place. (Such situations arise with disgruntled former employees who are seeking revenge on previous employers, for example.) Another important principle of security management is to keep the security mechanisms as simple as possible. Complex security mechanisms are difficult to fully comprehend and have the potential for more vulnerabilities. 7.5 SECURING ITS SUBSYSTEMS The traditional computer, network, personnel, and communications foundational security tools are found in the area of securing ITS. In order to have available and operational ITS security areas, the underlying information technology security mechanisms must be secure. ITS security should be built on two major premises: 1. Securing ITS subsystems, which includes the integrated hardware and software that support particular ITS functions. 2. Securing the communication between the subsystems. Version 6.0 of the National ITS Architecture defines 22 subsystems, each of which has potential security considerations. These subsystems are divided into four classes: 1. 2. 3. 4. Travelers. Centers. Vehicles. Field. The Travelers class contains the Remote Traveler Support and Personal Information Access subsystems, which communicate to the traveling public. The Vehicles class contains these subsystems, which communicate to individual vehicles and vehicle fleets: Vehicle (functions applicable for all types of vehicles) Emergency vehicle Commercial vehicle Transit vehicle Maintenance and construction vehicle. 128 SECURING ITS The Field class (renamed in version 5.0 from what had been the Roadside class) contains these subsystems, which are field devices or systems in the field: Roadway Security monitoring Toll collection Parking management Commercial vehicle check The largest class of subsystems is the Centers class, which contains these subsystems: Traffic management Information service provider (traveler information) Emergency management Emissions management Toll administration Transit management Commercial vehicle administration Fleet and freight management Maintenance and construction management Archived data management These subsystems represent the controlling entities that manage the surface intelligent transportation system. The Physical Architecture document of the National ITS Architecture defines all these subsystems in detail. Appendix B of the National ITS Architecture Security Document describes potential security considerations for each subsystem. These high-level descriptions are intended to highlight the confidentiality, integrity, and availability objectives that apply to each subsystem. Because of the breadth of function and diverse nature of the processing within each subsystem, users must develop specific security considerations for a given ITS implementation based on an understanding of the objectives, threats, and system vulnerabilities to these subsystems. 7.6 SECURING COMMUNICATIONS BETWEEN SUBSYSTEMS One of the objectives of the U.S. ITS program is for systems to be able to exchange information seamlessly. Securing communications between subsystems and between subsystems and terminators is critical to securing ITS. The interfaces, or information flows (to use National ITS Architecture terminology) have been analyzed by the National ITS Architecture Team to ascertain the relative importance of applicable security services. In order to keep the security 7.6 SECURING COMMUNICATIONS BETWEEN SUBSYSTEMS 129 considerations for architecture flows manageable, groupings were created for architecture flows that share similar security objectives, threats, and candidate security services. Architecture flows have been placed into one of 16 groups based on their unique security considerations. In cases where an architecture flow could be allocated to multiple groups, the most appropriate security group was chosen. Each architecture flow group has been given typical security services, security objectives, and security threat classifications of high, medium, low, or minimal. Similar architecture flows are grouped together so that security services can be applied consistently. The security service classifications are based on the security objective and threat importance. For example, the combination of a high level of integrity (i.e., unauthorized modification of the information) and a high level for the threat of deception would necessitate, among other services, a high or great need for the Access Control security service. Keep in mind that these are general classifications representing a starting point for further security analysis as systems are deployed. The information content of the architecture flow coupled with its operational role was considered by the National ITS Architecture Team in the security service classifications. In some cases, the security service, objective, or threat is not applicable and thus will not be in the corresponding table. The security service considerations are typical; users must tailor the security considerations as appropriate to the ITS application (e.g., sensitive archive data might require a higher classification than the nominal ‘‘low’’ designation identified in the National ITS Architecture). The security information for all architecture flows is available in the hypertext presentation on the Web site (www.iteris.com/itsarch/html/ security/securingits.htm) and the National ITS Architecture Version 6.0 CDROM available from USDOT. The architecture flow groups are: Archived Data Architecture Flows Business Sensitive Architecture Flows Emergency Architecture Flows Enforcement/Crash Reporting Architecture Flows Financial/Personal Architecture Flows Map Data Architecture Flows Media Architecture Flows Not Applicable Architecture Flows Operational Information Architecture Flows Operational Information—Safety Architecture Flows Public Architecture Flows Secure Human Interface Architecture Flows System Control Architecture Flows Traveler Information Architecture Flows 130 SECURING ITS Traveler Information—Safety Architecture Flows Weather/Environmental Architecture Flows To illustrate the types of security information available, the Emergency Architecture Flows group is presented and explained here. The Emergency Architecture Flows architecture flow group contains architecture flows that support emergency response and related critical public safety activities. These flows have critical availability and integrity requirements. For each architecture flow group, there are three tables. Table 7.1 includes a list of TABLE 7.1 Emergency Architecture Flows Security Services Service Importance Service Description Confidentiality Medium Integrity High Availability High Accountability High Authentication High Auditing High Access Control High The system should prevent unauthorized disclosure of information deemed sensitive. The system should ensure that information is protected from unauthorized intentional or unintentional modifications. The system should protect critical ITS services in order to prevent degradation or denial of the ITS services to users of the services. Single points of failure should be avoided. The system should provide protection against a sender of an information transmission later denying that they sent the information. The system should provide protection against a receiver of an information transmission later denying that they received the information. This concept is known as Non-Repudiation or Accountability. The system should verify the identity of a user and/or other system prior to granting access to a requested resource. The system should have the capability to trace ITS subsystem and individual user actions and activities. The auditing function of the system places the actions and activities in an audit trail that is protected from unauthorized access and modification. The system should limit access to the resources of a subsystem to only those users and other subsystems that are properly authorized. After authenticating an entity, the system should have the capability to limit system access to information or resources based on that entity’s access privileges. The system should limit software modifications and upgrades to users and other systems that have authorization. Source: RITA, Security Document, National ITS Architecture, 2007. 7.6 SECURING COMMUNICATIONS BETWEEN SUBSYSTEMS 131 TABLE 7.2 Emergency Architecture Flows Security Objectives Objective Classification Confidentiality Medium Integrity High Availability High Class Description Information that is generally available to ITS personnel. Unauthorized or unintended modification of the information could result in degradation of public safety. Loss of the information could jeopardize public safety. Source: RITA, Security Document, National ITS Architecture, 2007. the applicable security services and their relative importance, which have been derived from the security objectives and threats depicted in Tables 7.2 and 7.3. Consider, for example, one of the architecture flows in this group, ‘‘border incident information,’’ representing information about an incident at the country’s border. As shown in Table 7.1, all of the security services for architecture flows in this group are of high importance except confidentiality. The disclosure of some of the border incident information may be sensitive or of medium importance; such information might include the number of fatalities at the border and their identities. The access control security service is important because the system, for security reasons, should protect against unauthorized system access. The security services and their importance (Table 7.1) have been derived from the security objectives and their classifications (Table 7.2) and the security threats and their importance (Table 7.3). The ‘‘medium’’ classification of the confidentiality security objective coupled with the ‘‘medium’’ importance of the threat of disclosure resulted in a ‘‘medium’’ importance for the confidentiality security service. Similarly, the level of importance assigned to each of the other security services was derived by taking into account the security objectives and threats. After the tables on the National ITS Architecture Web site and CD-ROM is a list of the architecture flows in this architecture flow group being considered. Table 7.4 shows the architecture flows for the ‘‘Emergency Architecture Flows’’ group. TABLE 7.3 Emergency Architecture Flows Security Threats Threat Importance Deception High Disclosure Medium Disruption High Threat Description A circumstance or event that may result in an authorized entity receiving false data and believing it to be true. A circumstance or event whereby an entity gains access to data for which the entity is not authorized. A circumstance or event that interrupts or prevents the correct operation of system services and functions. Source: RITA, Security Document, National ITS Architecture, 2007. 132 SECURING ITS TABLE 7.4 Architecture Flows for the ‘‘Emergency Architecture Flows’’ Group alarm alarm acknowledge alarm notification alert notification alert notification coordination alert status alerts and advisories border incident information border incident response status care facility status care facility status request commercial vehicle breach commercial vehicle data commercial vehicle data request decision support information disable commercial vehicle emergency acknowledge emergency data request emergency dispatch requests emergency dispatch response emergency notification emergency operations status emergency personnel information presentation emergency plan coordination emergency route request emergency routes emergency transit schedule information emergency transit service request emergency transit service response emergency vehicle tracking data evacuation coordination evacuation information fleet and freight threat information freight breach hazmat information hazmat information request hazmat spill notification incident command information coordination incident command information presentation incident information incident information for public incident notification incident notification response incident report incident response coordination incident response status incident status maint and constr resource request maint and constr resource response patient status public health request public health response rail incident response status remote vehicle disable resource coordination resource deployment status resource request safe vehicle disable secure area sensor data secure area surveillance data suggested route threat data for analysis threat information threat information coordination threat support data toll advisories transit emergency data transit incident information Source: RITA, Security Document, National ITS Architecture, 2007. The architecture flow group descriptions for all 16 groups are defined in Appendix C of the National ITS Architecture Security Document. Further information regarding the corresponding security objectives, threats, security services, and applicable architecture flows for each group can be found on the National ITS Architecture CD-ROM or Web site hypertext by selecting ‘‘Security’’ from the left-hand menu and following the links. 7.7 SECURITY AND ITS STANDARDS 133 7.7 SECURITY AND ITS STANDARDS ITS standards are necessary in order to establish an open (or nonproprietary) ITS system communications environment. Standards reach toward the goal of having deployment of seamless, interoperable systems at local, regional, and national levels. The ITS Joint Program Office (JPO) of the U.S. Department of Transportation (USDOT) is currently supporting Standards Development Organizations (SDOs) that are responsible for a consensus-based standards development process to facilitate successful ITS deployment in the United States. The USDOT ITS JPO’s Standards Site at www.standards.its .dot.gov/provides the current status on the ITS standards that are supported. In addition, this site contains resource documents, fact sheets, advisories, testing information, deployment contacts, training, and application area information. In the National ITS Architecture, each architecture (or information) flow has been mapped to any applicable ITS standards. Often architecture flows are mapped to several different standards because of the different layers of the communications stack where transport protocol, data dictionary, and message set standards are all required to share information between systems. Only ITS standards activities that have been initiated are included in the mapping. These organizations currently participate in ITS standards activities: AASHTO (American Association of State Highway and Transportation Officials) ANSI (American National Standards Institute) APTA (American Public Transportation Association) ASTM (American Society for Testing and Materials) IEEE (Institute of Electrical and Electronics Engineers) ITE (Institute of Transportation Engineers) NEMA (National Electrical Manufacturers Association) SAE (Society of Automotive Engineers) Table 7.5 presents the primary ITS standards families along with their corresponding SDO(s). The security aspects of each of these ITS standards families are discussed next. 7.7.1 National Transportation Communications for ITS Protocol The National Transportation Communications for ITS Protocol (NTCIP) is the largest family of standards in the ITS domain. Its focus is the Traffic Management Center-to-Center (C2C) and Traffic Management Center-to-Field (C2F) device interfaces. More information about each standard as well as access to the NTCIP standards can be found at www.ntcip.org. 134 SECURING ITS TABLE 7.5 Primary ITS Standards and Their Respective SDO(s) ITS Standards Category National Transportation Communications for ITS Protocol (NTCIP) Traffic Management Data Dictionary (TMDD) and Message Sets Commercial Vehicle Information Systems and Networks (CVISN) Archived Data Dedicated Short Range Communications (DSRC) Incident Management Transit Communications Interface Profiles (TCIP) Advanced Traveler Information Systems (ATIS) Standards Development Organization(s) AASHTO, ITE and NEMA AASHTO and ITE ANSI ASTM ASTM, IEEE, SAE IEEE APTA SAE 7.7.1.1 NTCIP Center-to-Center. There are three general NTCIP Centerto-Center transport protocols for communications between ITS centers. The most recently standardized and highly used protocol is the NTCIP 2306 XMLbased communications standard, leveraging Web Service Description Language (WSDL) with options for either the Simple Object Access Protocol (SOAP) or XMLDirect using the eXtensible Markup Language (XML). The second most used NTCIP C2C standard protocol is Data Exchange ASN (DATEX-ASN). The third primary C2C protocol is the Common Object Request Broker Architecture (CORBA); however, based on feedback from the experiences of the transportation community, the Federal Highway Administration and SDOs have decided not to pursue further CORBA standards development. ITS deployments utilizing CORBA may choose to continue to use CORBA but are encouraged to build WSDL/SOAP/XML or DATEX-ASN interfaces when integrating new systems and using XMLDirect or FTP for simple file transfers. One of the primary reasons that CORBA has fallen by the wayside was the lack of interoperability between the security services of different Object Request Broker (ORB) vendors. A brief introduction and discussion of security mechanisms for both XML and DATEX-ASN are presented next. 7.7.1.1.1 WSDL/SOAP/XML: NTCIP 2306 is the application profile standard for WSDL/SOAP/XML and is approved having successfully passed the ballot phase by the NTCIP SDOs. As a standard nears the possibility of publication, the SDO representatives vote on the standard through ballots, if the balloting is successful the standard is subsequently published. WSDL/SOAP/XML standardization is the newest arrival among the ITS C2C communications standards and leverages key information technology industry standards. Due to this leveraging of the information technology industry, many XML tools are available, 7.7 SECURITY AND ITS STANDARDS 135 including XML parsers and XML editors, and a large base of industry XML experts as well as literature. WSDL/SOAP/XML is an extension of the methods of encoding and formatting data used by the World Wide Web, or Internet. As such, this standard promises flexibility and relative simplicity. XML is a formatting language for messages and data; SOAP defines the packaging of messages and provides a framework for passing of the messages over a transport protocol similar to the way DATEX-ASN encodes ASN.1formatted data. WSDL, in conjunction with using SOAP and XML, provides services such as request/reply and publish/subscribe for coordinated C2C communications. For more information about the considerations when using XML-based technologies for ITS, review the ‘‘NTCIP 9010—XML in ITS Center-to-Center Communications’’ report mentioned in the references section. NTCIP 2306 also includes a mechanism for simple file-based information sharing called XMLDirect, which leverages the Internet’s File Transfer Protocol (FTP) standard to send and receive files. This profile is not a substitute for the more advanced WSDL/SOAP/XML or DATEX-ASN protocols; rather it complements these standards as a means to periodically deliver and accept files. From a security standpoint, NTCIP 2306 provides for secure message transport over the industry-standardized Secure HTTP (Hypertext Transport Protocol) Sockets protocol represented by the ‘‘HTTPS’’ designation. If the XMLDirect FTP-based transport protocol is used, it is recommended that FTPS, also commonly referred to as FTP/SSL, is used by FTP software file transfers. FTPS uses public key certificates that bind a public key with the identity of the owner. These certificates must be signed by a certificate authority (CA) who issues these digital certificates for use by other parties. CAs are instrumental to many public key infrastructure (PKI) schemes. If the certificate is not signed by a CA or the time frame expires, the FTPS client will generate a warning stating that the certificate is not valid. Since FTP is a port-hopping protocol, the data channels use a random port chosen during the communication interplay. Many firewalls have the ability to understand the FTP protocol and allow the secondary data connections. However, FTPS involves the use of a SSL/TLS (SSL/Transport Layer Security) layer below the standard FTP protocol to encrypt the control and/or data channels. If the control connection is encrypted using TLS/SSL (or other methods), the firewall is not able to get the port numbers of the data connections from the control connection since it is encrypted and the firewall cannot decrypt it. Therefore, in many firewalled networks, clear FTP connections will work while FTPS connections will either completely fail or require the use of passive mode. Therefore, use of a VPN or similar technology is recommended. 7.7.1.1.2 DATEX-ASN: At this time, XML seems to be the C2C protocol of choice for accommodating future technical advances and system enhancements, given its industry-wide acceptance as well as its flexibility and extensibility. However, the DATEX-ASN protocol has the advantage of efficient communications (i.e., requiring less computing processing resources to interpret messages 136 SECURING ITS than XML) and has an installed user base with a complete published standard profile. DATEX-ASN (NTCIP 2304) was adapted specifically for ITS C2C applications and uses predefined message sets, including the IEEE 1512 Incident Management (IM), SAE Advanced Traveler Information System (ATIS), APTA Transit Communications for ITS Profile (TCIP), and the Traffic Management Data Dictionary (TMDD) standards formatted in the ASN.1 syntax to exchange information in peer-to-peer networks between computers. ASN.1 is a defined computer-friendly (not as human-friendly as XML) format. DATEX-ASN works in conjunction with the Internet (Transport Level) protocols TCP/IP and UDP/IP, and Point-to-Point (PPP) protocols and is well suited for communications that require real-time, efficient, or fast data exchange with limited communications bandwidth. DATEX-ASN provides services such as publish-subscribe and request-response for coordinated C2C communications. It has been in use for the longest time of the C2C ITS transport protocols. 7.7.1.1.3 Summary: WSDL/SOAP/XML is increasingly being used in C2C ITS deployed projects having passed the SDO ballot phase and being now approved. As some regions are transitioning from DATEX-ASN to WSDL/ SOAP/XML, multiple protocols can be implemented on a single network (or a series of connected, interoperable networks), assuming that translators exist at the interfaces between computer systems using different protocols. Many of the ITS data/message set standards, including those mentioned in the last section, include both standardized ASN.1 and XML formats for their message and data elements. 7.7.1.2 NTCIP Center-to-Field. The primary NTCIP center-to-field (C2F) security document is the Global Objects NTCIP 1201v02. There are plans to remove the security content from the current Global Objects standard and place it in the NTCIP 1103 Transportation Management Protocols (TMP) standard. The primary purpose of the TMP security design is simply to prevent authorized users of the system from accessing data for which they are unauthorized. The standard states that it is the responsibility of the lower communication layers to address security by unauthorized users. During the early development of the NTCIP standards, it was widely understood that much of the security was provided by an isolated physical layer (dedicated ‘‘wires’’ in the ground) that prevented physical access to the communication system by typical hackers. Also, for dial-up networks, the NTCIP standards supported the capability to use Challenge-Handshake Authentication Protocol (CHAP) to authenticate a remote user. The NTCIP protocols are also fully compatible with additional security protocols, such as SSL and VPN. TMP provides different security mechanisms depending on which of the three protocols (Simple Network Management Protocol (SNMP), Simple Fixed Message Protocol (SFMP), and Simple Transportation Management Protocol (STMP) are being used. 7.7 SECURITY AND ITS STANDARDS 137 7.7.1.2.1 SNMP and SFMP Security: Both SNMP and SFMP have a common security scheme that is based on a simple authentication process. All SNMP data packets and all SFMP request data packets include a field called ‘‘community name.’’ This field identifies the request data packet with a user group. A community name administrator can be configured to provide different user groups with different levels of read/write data access through the use of MIB views. MIB stands for Management Information Base which is a database of objects that can be monitored by a network management system. An SNMP/ SFMP-compliant MIB contains definitions and information about the properties of managed resources and the services that the computer software supports. The SNMP community defines a MIB view as allowing objects that are defined as read-write to be viewed as if they were read-only or not-accessible when accessed via certain community names. The security node of the TMP MIB provides the mechanism to configure the visibility of data for each community name. The security node defines an object to hold the administrator community name. The administrator community name provides access to all objects defined in the device’s MIB. 7.7.1.2.2 STMP Security: The STMP provides its security because the STMPbased data packets are not self-defining. Each entity using this protocol needs to have prior knowledge of the configuration of each dynamic object in order to understand the contents of each data packet. Because of this security feature, the data packet configuration information is accessible only via SNMP or SFMP. 7.7.2 Traffic Management Data Dictionary and Message Sets The Version 3.0 of the Traffic Management Data Dictionary (TMDD) puts the burden of security on the ITS project implementation in alignment with an organization’s own security policies. TMDD 3.0 at the time of this writing is a draft proposed standard to the NTCIP Joint Committee. When the NTCIP Joint Committee accepts the recommended standard it will go to each of the NTCIP SDOs for ballot and upon approval of each ballot, be published. The TMDD standard does provide guidance on the needs to specify restrictions and message authentication. The TMDD and external message sets standard acknowledge that some traffic management data and operations to and from a traffic management center are quite sensitive and need protection against improper use. They also encourage encryption and the requesting center’s identity for authentication. The TMDD standard mentions in particular that an exchange agreement should be set up with any restrictions on relaying information to third parties, even down to a user level. 7.7.3 Commercial Vehicle Information Systems and Networks Commercial Vehicle Information Systems and Networks (CVISN, pronounced SEE-vision) is comprised of the ITS information system elements that support 138 SECURING ITS Commercial Vehicle Operations (CVO). CVISN covers information systems owned and operated by governments, carriers, and other stakeholders involving CVO. The CVISN program is coordinating the nationwide deployment of specific new capabilities in three areas: 1. Safety information exchange. 2. Credentials administration. 3. Electronic screening. Figure 7.4 shows the relationship between the CVISN Architecture in relationship to the International Border Clearance (IBC) Architecture and the U.S. National ITS Architecture within the context of the ITS, CVO, and International Trade Modernization domains. Before we can discuss the security aspects of CVISN, we must provide more background on the CVISN program. Many states are using the FMCSA’s CVIEW (Commercial Vehicle Information Exchange Window system or equivalent) or the SAFER (Safety and Fitness Electronic Records) system to exchange safety information and provide it to the roadside to facilitate commercial vehicle electronic screening and inspection operations. The EDI (Electronic Data Interchange) standards currently are being replaced by the XML standard. CVIEW systems have been designed to both receive and send Architectural Framework: A Way to Manage Complex Systems Commercial Vehicle Information Systems and Networks (CVISN) Architecture Intelligent Transportation Systems (ITS) ITS / CVO CVISN Commercial Vehicle Operations (CVO) I B C National ITS Architecture International Trade Modernization International Border Clearance (IBC) Architecture Figure 7.4 Federal Motor Carrier Safety Administration’s (FMCSA) Interoperability Diagram. (Source: http://cvisn.fmcsa.dot.gov/default.aspx?PageID=architecture.) 7.7 SECURITY AND ITS STANDARDS 139 information from the SAFER system, which also can independently push information to the CVIEW sites. This capability necessitates a persistent secure network connection between the CVIEW sites and SAFER. The common way of accomplishing this is to set up a secure two-way connection with SAFER over the Internet by establishing a persistent VPN LAN-to-LAN (local area network) connection between an appropriate firewall attached to the state’s network and the SAFER VPN Concentrator located at the Volpe National Transportation System Center in Washington, D.C. This method is currently used to connect Volpe and the Johns Hopkins University Applied Physics Laboratory in Maryland. In this scenario, the state’s firewall would protect the state network(s) from unauthorized Internet access and would have to be capable of being configured for the VPN/IPSec LAN-to-LAN connection. Once the described VPN/IPSec LAN-to-LAN persistent connection is in use, other users of FMCSA Field Systems applications connected to the same LAN as the CVIEW system can also connect to SAFER (FMCSA February 2002). 7.7.4 Archived Data Most standards are concerned about security but are rather vague about how to accomplish it. The December 2005 ‘‘Archived Data Management Systems—A Cross-Cutting Study’’ says that implementers should address firewall and security issues as early as possible (FHWA 2005). As time passes, most transportation information becomes less sensitive. However, information such as archived video images may be important to some jurisdictions to prove or disprove intent. 7.7.5 Dedicated Short-Range Communications Critical to the whole concept of the Vehicle Infrastructure Integration (VII) initiative is the safety applications that require high security in order to be viable. This interface involves both vehicle to roadside as well as vehicle to vehicle. The primary standards for dedicated short-range communications (DSRC) 5.9GHz are the IEEE 1609 family and the SAE J2735 message set. The primary security content can be found in the IEEE P1609.2, Standard for Wireless Access in Vehicular Environments (WAVE)—Security Services for Applications and Management Messages, which defines secure message formats and processing. This standard also defines the circumstances for using secure message exchanges and how those messages should be processed based on the purpose of the exchange. Figure 7.5 compares the OSI communications reference model, which is rather subjective in the definition of each layer by nature, with the WAVE/DSRC model and shows the layers that are affected by IEEE 1609.2’s security services. 140 SECURING ITS OSI Reference Model WAVE/DSRC Model Application, Presentation, Session Upper Layers IEEE 1609.1 SAE 2735 others Transport Network Networking Services IEEE 1609.3 Data Link LLC Sublayer IEEE 802.2 MAC Sublayer IEEE 1609.4 IEEE 802.11 Physical PHY Layer IEEE 802.11p Security Services IEEE 1609.2 Figure 7.5 Communications Protocol Stack and WAVE/DSRC Standards. 7.7.6 Incident Management Public safety agencies must have assurances that their data and data transmissions are secure. IEEE has been working these past years to develop a family of incident management standards to meet the needs of the surface transportation in conjunction with the public safety communities. They are relying on the NTCIP C2C transport protocols and Internet-based VPNs to address their security concerns. 7.7.7 Transit Communications Interface Profiles The Transit Communications Interface Profiles TCIP standards family is championed by the American Public Transportation Association. This family of standards contains extensive standardization of processes involving security. The TCIP standards have at their core the security-related content for these areas: Security and Incident Management Process Manage Incidents and Security Business Process Outputs Fare Collection and Revenue Management Security business area The Security and Incident Management Process facilitates the provision for a safe and secure environment for transit employees and customers as well as a response plan for incidents affecting service and/or posing a potential hazard to transit employees or customers. The charter of the Manage Incidents and Security Business Process Outputs is the prevention of incidents to the extent 7.7 SECURITY AND ITS STANDARDS 141 feasible, the prompt and effective detection of incidents that do occur and responding in a prompt and effective manner to incidents that are detected. The Manage Revenue and Fare Collection business process consists of 8 major sub processes: fare policy, fare media sales/vending, revenue/media collection, revenue reconciliation, banking, security, system maintenance and system configuration. 7.7.7.1 Security and Incident Management Process. The Security and Incident Management Process includes seven stages: 1. 2. 3. 4. 5. 6. 7. Planning. Preparation. Incident detection, classification, and verification. Incident notification. Incident response. Incident recovery. Incident follow-up. Key organizations in the incident planning process are transit planners, transit operations and maintenance managers, external agencies including public safety agencies, DOTs, and other transit agencies. Transit agency contractors may have a role as well in some agencies. The Key TCIP Model Architecture components involved in the Security and Incident Management Process are: Transit Security. This business system is used to detect and to manage security incidents. Computer Aided Dispatch/Automatic Vehicle Location (CAD/AVL). This business system may include incident management application(s) for use by transit dispatchers, supervisors, managers, and so on. External agency systems. Their involvement is required for data-based coordination and notifications of incident information and status. Geographic Information Systems (GIS). This business system maintains the base map and transit features, and may be used as an incident analysis tool. Asset management. This business system deals with scheduling Public Transportation Vehicle (PTV) maintenance and repairs and in PTV assignments, including assignment changes that may occur as a result of incidents. Operator assignment system. This business system deals with PTV operator assignments to work (runs), including changes to operator assignments resulting from last-minute changes prior to pull-outs and changes that occur en-route as a result of incidents (American Public Transportation Association 2006). 142 SECURING ITS 7.7.7.2 Manage Incidents and Security Business Process. Once the incident is reported to the control center, the response stage is executed. In this stage, resources are mobilized to resolve, clear, and close an incident. During this stage, the control center may need to: Request/provide assistance to/from external agencies. Request/provide status to/from external agencies. View video images of events at the incident location. Receive and distribute incident updates from/to transit employees. Implement and cancel detours. Exchange text messages with PTV operator(s), transit supervisors, or transit maintenance vehicle operators. Monitor covert audio from a stop point or PTV. Clear/cancel a silent alarm from a PTV. Communicate by voice radio with PTV operators or other employees. Change vehicle or operator assignments. Dispatch agency responders to the incident (e.g., agency-owned tow truck). Disable/enable a PTV (American Public Transportation Association 2006). 7.7.7.3 Fare Collection and Revenue Management Security. Security in this business process has two major components: physical security and information security. In general, TCIP does not provide information security; however, TCIP messages can be exchanged over encrypted links or through virtual private networks or other tunnel-based encryption mechanisms. Physical security requires a multipronged approach including surveillance, locks, alarms, barriers, and other techniques. TCIP defines mechanisms for conveying security camera images (real time or archived) and also provides notifications of cash box events, which help management to keep track of the status and contents of cash boxes. Finally, TCIP provides fare box health alarms, which include break-in alarms to assist transit security and management in detecting events that may indicate a security incident (American Public Transportation Association 2006). 7.7.8 Advanced Traveler Information Systems The primary standard for the Advanced Traveler Information Systems (ATIS) domain is SAE’s J2354, currently finished with the SDO ballot phase. The current revision is 3.0.80-2006. It is a message set standard and advises users to use the NTCIP XML standards to expose the top-level messages defined by the ATIS standard. This will establish a messaging environment that supports the dialogs of request and response messages. It does not mention VPNs but does acknowledge the need for user authorization or security. The standard also REFERENCES 143 mentions that the depth and complexity of the message filtering to be supported in such a deployment is to be determined locally. The Traveler Settings Reply message provides a way for a data provider to reply to a data consumer and list the supported settings for that consumer as well as those policies and capabilities it is willing to provide regarding security mechanisms. Data suppliers may restrict the information that they are willing to support with this message, depending on various other considerations, such as the security of the underlying connection protocol. Note that in order to use the Traveler Information Request message, some systems may require the establishment of a user account; on other systems no prior contact may be required. If prior contact is required, it will require manually establishing a user account and following some C2C security procedures. 7.8 CONCLUSIONS Any ITS design must include a security element to protect it from unauthorized use. ITS provides tools for minimizing risks to surface transportation systems, at the same time it could be potential targets to create hazard to public safety. ITS professionals must be aware of the need to secure these systems. Consider having a security evaluation done through vendors that have been evaluated by a government organization, such as the National Information Assurance Partnership (NIAP). The NIAP coordinates with both the National Institute of Standards and Technology (NIST) and the National Security Agency (NSA) with the aim of improving consumer confidence in networking and information systems. This chapter provides practical strategies that can be adopted for securing ITS by leveraging the security content in the U.S. National ITS Architecture and ITS standards. Chapter 8 discusses the relationship between ITS security areas and other modes of transportation. REFERENCES American Association of State Highway and Transportation Officials, Institute of Transportation Engineers, and National Electrical Manufacturers Association. 2003. NTCIP 9010 v01.07, National Transportation Communications for ITS Protocol XML in ITS Center-toCenter Communications, October. American Association of State Highway and Transportation Officials, Institute of Transportation Engineers, and National Electrical Manufacturers Association. 2005. NTCIP 2304:2002 v01.08, National Transportation Communications for ITS Protocol Application Profile for DATEX-ASN (AP-DATEX), September. American Association of State Highway and Transportation Officials, Institute of Transportation Engineers, and National Electrical Manufacturers Association. 2006. NTCIP 1201:2005 v02.32. National Transportation Communications for ITS Protocol Global Object (GO) Definitions, version 2, October. 144 SECURING ITS American Association of State Highway and Transportation Officials, Institute of Transportation Engineers, and National Electrical Manufacturers Association. 2007 NTCIP 2306 v01.68b, National Transportation Communications for ITS Protocol Application Profile for XML in ITS Center to Center Communications (AP-C2CXML), currently a recommended standard, sent to SDOs for ballot and approval. American Public Transportation Association. 2006. APTA TCIP-S-001 3.0.0, APTA Standard for Transit Communications Interface Profiles, Version 3.0.0, Volume 1, June. Anderson, Ross J. Security Engineering—A Guide to Building Dependable Distributed Systems. John Wiley & Sons, 2001. Federal Highway Administration. 2005. Archived Data Management Systems A CrossCutting Study. Available online at http://www.itsdocs.fhwa.dot.gov/JPODOCS/ REPTS_TE/14128/14128.pdf Federal Motor Carrier Safety Administration. 2002. Commercial Vehicle Information Systems and Networks, Guide to Safety Information Exchange Appendix E, POR-99-7191, V1.0, February. Harris, Shon. 2002. All-in-One CISSP Certification Exam Guide. McGraw-Hill. Institute of Electrical and Electronics Engineers. 2006. IEEE Standard for Common Incident Management Message Sets for Use by Emergency Management Centers, IEEE Std 1512TM, June 8. Institute of Electrical and Electronics Engineers. 2006. Standard 1609.2-2006, IEEE Trial-Use Standard for Wireless Access in Vehicular Environments (WAVE), Security Services for Applications and Management Messages. King, C. 2001. Security Architecture: Design, Deployment, and Operations. RSA Press. Mitretek Systems. 1997. ‘‘Intelligent Transportation Systems (ITS) Information Security Analysis,’’ FHWA-JPO-98-009, November. Mitretek Systems. 2003. ‘‘Protecting Our Transportation Systems: An Information Security Awareness Overview,’’ FHWA-OP-03-094 (Revised), April. National Institute of Standards and Technology SP-800 Series Publications: ‘‘Computer Security Considerations in Federal Procurements: A Guide for Procurement Initiators, Contracting Officers, and Computer Security Officials,’’ 1992. National Research Council. 1999. Improving Surface Transportation Security—A Research and Development Strategy. National Academy Press. National Research Council. 2002. Making the Nation Safer—The Role of Science and Technology in Countering Terrorism. National Academy Press. Research and Innovative Technology Administration (RITA). May 2007. Physical Architecture Document—The National ITS Architecture, Version 6.0, www.its.dot.gov/arch/index.htm. Research and Innovative Technology Administration (RITA). May 2007. Security Document—The National ITS Architecture, Version 6.0, www.its.dot.gov/arch/index.htm. Society of Automotive Engineers. 2006. Ballot draft, SAE J2735 Message Sets for Advanced Traveler Information System (ATIS), Version 3.0.80-2006. REVIEW QUESTIONS 1. Why is securing ITS important for public safety? 2. How can security risks to ITS can be assessed? REVIEW QUESTIONS 145 3. Discuss ways to minimize risks to ITS. 4. Provide two scenarios in which an ITS system could become a target for unauthorized access. Discuss how this particular threat can be minimized. 5. Explain why most of the ITS center-to-center standards do not list specific security mechanisms. 6. Which standard(s) would you use to implement NTCIP center-to-field device communications? 7. Which National ITS Architecture subsystem was created solely for security-related purposes? 8. Using the National ITS Architecture Web site or CD-ROM, find the section on securing architecture flows. How many groups are there? 9. For a given architecture flow, explain how you would find the security considerations for it in the National ITS Architecture. 10. Explain how security threats, objectives, and services are related. CHAPTER 8 ITS SECURITY AREAS AND MULTIMODAL TRANSPORTATION SECURITY T he U.S. National ITS Architecture focuses on roadway transportation solutions, providing less guidance for other modes about transportation security. This chapter provides further details on common practices and best practices in surface transportation modes other than solely roadway. Because there are often large overlaps in practice between modes, this chapter presents material dealing with protecting people, vehicles and infrastructure, freight, and integrated systems. 8.1 PROTECTING PEOPLE The next sections discuss different ways people can be protected at different multimodal facilities. They highlight existing technologies and innovative concepts that are to be realized to protect people against deliberate attacks. 8.1.1 Airports This section focuses on how the surface transportation system integrates with airports, discussing evacuation and demand management, information dissemination, and passenger screening procedures. 8.1.1.1 Demand Management and Evacuation. Travel demand is anything but consistent, and all modes of transport must adapt to the peaks and lulls Transportation Infrastructure Security Utilizing Intelligent Transportation Systems R. Fries, M. Chowdhury and J. Brummond Copyright © 2009 John Wiley & Sons, Inc. 146 8.1 PROTECTING PEOPLE 147 in demand. The pattern of arriving and departing flights has a significant impact on traffic and parking demands at and around airports. As the number of air travelers is expected to increase, it is critical that attention be paid to managing not only air traffic capacity but also the ground transportation for an airport. Interconnecting the flight landing information and ground transportation systems (e.g., shuttle, transit, and rail) could better prepare ground transportation operators. In addition, coordinating anticipated flight volumes with transportation staffing, particularly for airports with high passenger variability, could help reduce travel times. However, the challenge to do so is complex under normal circumstances, let alone when external factors cause additional flight time delay. Airport evacuation, which is vital when many people are at risk and need to be evacuated to safety immediately, may stress the surrounding surface transportation network the most. It is during operations such as these that having universally accepted procedures for each local transportation or public safety agency is essential. Developing such information-sharing agreements and operational plans should be addressed during the development of a regional ITS security architecture as presented in Chapter 9. Shuttle, transit, and rail operations are valuable tools to transport travelers away from airports, each with its own benefits and disadvantages. Rail and fixed-guideway vehicles operating to and from airports have higher capacities than many shuttle and transit systems, but their fixed routes are at risk for malevolent acts that seek to disrupt the evacuation. Shuttle and transit buses can select alternate routes but do not have the capacity of many rail systems. The use of reversible lanes has proven effective during both daily peak periods and hurricane evacuation. However, the practice is untested for facilities nearby an airport. Because travelers do not need to evacuate great distances and because the facilities near most airports are riddled with intersections, merges, and diverges, lane reversal may not be a feasible solution. Reversible lanes and many other highway traffic management strategies can be evaluated using commercially available traffic simulation software. These software can include CORSIM which stands for corridor simulation (McTrans 2008), VISSIM, a German acronym for Verkehr in Stadten Simulation, translating roughly to traffic simulation in cities (PTV 2008), and PARAMICS which stands for parallel microscopic simulation (Quadstone, 2002). Chapter 5 shows example of traffic simulation application to evaluate different contra-flow strategies for evacuation of at-risk areas during a hurricane warning. 8.1.1.2 Information Dissemination. Intelligent transportation systems also are capable of informing travelers of changing information regarding parking availability, security levels, and shuttle arrival estimates. Multiple technologies can assist with these tasks, including advisory radios, 511 systems, variable message signs (portable and static), and in-vehicle announcements (audio, visual, or both) on shuttle buses. 148 ITS SECURITY AREAS AND MULTIMODAL TRANSPORTATION SECURITY For transportation managers and operators, communications about passenger demand, route changes, and incident reporting are important functionalities. In general, radios with dedicated frequencies are widely used, particularly 900 MHz (megahertz) systems. Because these radios are in common use, they are considered a best practice by law enforcement agencies involved in incident management (assuming that they are using the same set of frequencies). 8.1.1.3 Passenger Screening Procedures. Multiple methods are available to screen airport travelers to prevent the transport of explosives, weapons, or drugs aboard aircraft. The same technologies are used to inspect cargo on other transport modes. In airports, X-rays, canines, and vapor and trace detection systems are commonly used to screen travelers. Tools for the screening of baggage are presented in Section 8.3. 8.1.1.3.1 X-Ray: There are five primary types of X-ray scanning tools (Sheridan 2002), depending on the type of transmission: 1. 2. 3. 4. 5. Standard. Dual energy. Dual view. Backscatter Computed tomography (CT). While all these tools are similar in operation to gamma ray systems, the key difference is the wavelength output. Gamma rays have the shortest wavelength within the electromagnetic spectrum and are therefore the most powerful. Because gamma rays destroy human DNA and can cause cancer, less powerful electromagnetic emissions, such as those produced during X-rays, are more safe for scanning passengers. Standard-transmission X-rays are similar to those used in the medical profession, releasing a burst of radiation and examining the reflected or absorbed radiation to identify dense objects. Dual-energy-transmission X-rays use two distinct energy levels and therefore wavelengths, to provide a clearer representation of the cargo and better identification of contraband. Dual-view X-rays simply record X-rays from two different vantage points. Backscatter X-rays can use multiple sources of radiation, including one transmission X-ray and at least one image using the Compton Backscatter technique (Sheridan 2002). Such X-rays can identify contraband that standard transmission X-rays miss, including explosives and plastic weapons (Singh and Singh 2003). Computed tomography uses multiple X-ray views similar to dual-view transmission, to develop a three-dimensional view of cargo. This technique, popularized by medical practice and known more commonly as CT scanning, also has applications in cargo screening. Various X-ray strengths and types have different accuracies at detecting different materials. 8.1 PROTECTING PEOPLE 149 Primary Transportation Security Uses of X-Ray Screening Screen passengers Screen cargo Screen small ships 8.1.1.3.2 Canine Inspection: Canines are one of the most effective ways to detect drugs and explosives in cargo and are widely used around the world. Even though canines have a low threshold for detecting scents (Myers and Pugh 1985), they rarely give false positives (Rountree and Demetsky 2004). To maintain these standards, certification programs exist through the U.S. Department of Defense (Hannum and Parmeter 1998) and the North American Police Work Dog Association (NAPWDA 1998), among others. Factors evaluated in these certification programs generally include team alertness, canine responsiveness to the handler, and handler proficiency in interpreting the canine’s reactions. Certification is difficult, but it ensures that canine detection teams are equivalent to or better than instrumented methods (Furton and Myers 2001). Some researchers have determined that rats, bees, and plants may also are able to detect explosives (Harper et al. 2005), their training has yet to be realized. Primary Transportation Security Uses of Canine Inspection Screen passengers Screen cargo Screen vehicles 8.1.2 Public Transit As discussed in Chapter 2, events such as the Madrid commuter rail bombings in 2004 and the London Underground bombings in 2005 have had a significant impact on the security environment of public transit in the United States. With over 10 billion transit trips per year in the United States alone (APTA 2007), public transit is a key subset of transportation infrastructure and a significant part of the economy. In the United States, public transportation includes bus, rail, ferry, guideway, and paratransit. Various types of rail public transportation exist, including light rail (mixed with roadway traffic), commuter rail (from the suburbs to the city), and heavy rail (exclusive right-of-way that is commonly under- or aboveground). Because heavy rail stations, particularly those of 150 ITS SECURITY AREAS AND MULTIMODAL TRANSPORTATION SECURITY subways, commonly have stations with confined spaces and high passenger volume, they have been the focus of many research efforts. Securing these entities requires timely identification of threats to passengers, employees, vehicles, and facilities. Sources of real-time threat identification (Balog et al. 2002) include: Advisories from federal sources including Department of Homeland Security Transportation Security Administration Information Analysis and Infrastructure Protection Directorate Homeland Security Advisory System Department of Transportation Federal Transit Administration Department of Defense Department of Justice Federal Bureau of Investigation Advisories from local law enforcement and emergency management entities Reporting from transit operators, police, and management News reports of open-source information Reorganization efforts at the federal level have shifted the sources of threat information dissemination to create a more streamlined process and will likely continue. Changes are also occurring within public transportation agencies to promote three-dimensional communication: 1. Bottom-up communication. Includes reports from transit operators and police regarding suspected activities, vulnerable locations, and reporting of actual security incidents. 2. Top-down communication. Provides information from federal sources. 3. Lateral communication. Includes other public transportation agencies or transportation agencies with shared infrastructure and/or similar operational concerns (Balog et al. 2002). Many efforts have been made to organize these communication links to protect people who travel on public transit. Other efforts have addressed more technological problems of real-time threat identification including chemical, radiation, and biological sensor systems. 8.1.2.1 Chemical Sensors Systems. Vapor and trace detection systems are two types of chemical sensor systems in use. Vapor detection systems essentially sniff the air e.g. inside cargo shipping centers, and analyze the chemical 8.1 PROTECTING PEOPLE 151 makeup of the trace elements (Rountree and Demetsky 2004). These devices are valuable because of their ability to detect explosives from a distance. Because explosive materials are often volatile, their elements easily evaporate into the air. Some perpetrators may attempt to wrap explosives well to avoid detection, but the trace amounts on their fingers or gloves while wrapping can still be detected (Moore 2004). Trace detection systems require operators to wipe the cargo with a collection strip, which is then inserted into a detection machine. The particulate matter from the collection strip is then analyzed for traces of explosives (Sheridan 2002). Primary Transportation Security Uses of Chemical Detection Systems Screen cargo and transit facilities Screen passengers Screen small ships As these technologies evolve and are able to detect explosives in larger areas with better accuracy, the need for operators will decrease. When autonomous devices are deployed, the U.S. National ITS Architecture should be followed to improve the intermodal communication and overall safety and efficiency of the surface transportation system. Research is under way on the development of a chemical threat detection system in a transit system (see Chapter 2 for a discussion of the differences between biological and chemical weapons). The chemical agents included in this project are nerve agents such as sarin gas, phosgene, chlorine, and nitrates found in explosives. The goal of this research is to provide a system that can detect and classify chemical threats in a transit facility, such as a subway station, in real time and report it to the appropriate authorities (Bango 2006). 8.1.2.2 Radiation Detection Systems. Radiation detection systems are not new. One of the earliest such devices, the Geiger counter, has been used since the 1930s. Since then, research and development efforts have greatly advanced the sensitivity, power, size, and deployment ability of these devices. A key challenge of radiation detection devices is differentiating among the many types of radioactive materials currently used for beneficial and malevolent intents. For example, if a cargo package is declared to have radioactive material for medicinal use, detection devices must discern the difference between medicinal isotopes and those used to create weapons. These systems operate by detecting trace amounts of radiation from cargo with the goal of preventing the illegal transport of radioactive materials for use 152 ITS SECURITY AREAS AND MULTIMODAL TRANSPORTATION SECURITY in atomic weapons or dirty bombs (Rountree and Demetsky 2004). Because radioactive material emits gamma rays capable of traveling through matter without being diffracted or absorbed, unlike light waves, radiation detection devices can determine the presence and type of radiation emitted. Primary Transportation Security Uses of Radiation Detection Systems Screen cargo Screen transit facilities Screen vehicles These devices are not limited to detection at mode-changing locations but can be used alongside freeways. One such deployment, the Southeast Transportation Corridor Pilot Program, aimed to deploy radiation detection systems at interstate weigh stations across the southeastern United States (Domestic Nuclear Detection Office 2007). The autonomous deployment of these devices should follow the framework identified in the U.S. National ITS Architecture, particularly under the transportation infrastructure protection market package. This adherence can ensure that radiation detections are reported to the proper authorities. Radiation detection systems are also being tested for use in subway stations in both Washington, D.C., and Connecticut. These systems use proprietary radiation detectors in multiple stations linked to a central computer in order to detect the presence and/or spread of radiation from a dirty bomb or other radiological source. Initial findings suggest that pedestrians accessing the subway system would be unable to carry enough radiation shielding to hide a significant source of radiation (Rubenstein 2006). 8.1.2.3 Biological Agent Sensors. Biological agent sensors, although frequently used by the military, are still relatively new to the transportation industry. Research has tested a biological agent detection technology for use in subway stations as part of the Transit Cooperative Research Program (TCRP). Specifically, this project examined if current technologies could identify, in real time, the presence and nature of malevolent biological agents in the rail particulate matter common to New York City subway stations. This technology holds promise for subways around the world and other transit agencies with facilities similar to subway stations (Rivers 2006). 8.1.2.4 Disaster Recovery. Many other support tools exist for recovery from security incidents and these tools are common among all modes. The disaster response and evacuation security area within the National ITS 8.1 PROTECTING PEOPLE 153 Architecture provides the most contexts to this area, although it does not specifically focus on the tools themselves. This lack of focus likely comes from the fact that recovery is specific to incident, location, and agency. The coordination agreements fostered during the development of a regional ITS security architecture, as discussed in Chapter 9, will provide the most support for recovery as these plans will have been tailored to the local modes, facilities, and agencies. One technology being researched is a decontamination system to clean subway stations after a biological or chemical security incident. Although systems exist to decontaminate rail cars and buses, the complexity of subway stations requires innovative techniques (Athanassiu 2006). 8.1.2.5 Design for Security. The changing security climate has changed the design of future passenger rail systems. For example, the Denver, Colorado, Regional Transportation District (RTD) was one of the first agencies in the United States to include safety and security in the planning and design of its light rail transit projects. This inclusion was accomplished by multiple meetings and workshops with a panel of experts from engineering, rail and bus operations, transportation planning, facilities maintenance, construction operations and scheduling, and of course safety and security. The end product of these meetings was a design guide for the light rail transit stations (USF CUTR2005). There are many other examples of how public transit design has changed to include security measures. All illuminate the fact that all vulnerabilities need to be identified. Including a panel of experts in the process is a great way to capture opinions from the multiple disciplines that are now integral to all modes of transportation. 8.1.3 Perception of Security Although neither freight nor vehicles are impacted by the aesthetics of a secure environment, people are. One study found that increased lighting and the presence of police officers were the most influential factors in increasing transit riders’ perceptions of safety and security (Wallace et al. 1999). To increase the presence of uniformed and undercover officers on all modes of transportation, the Transportation Security Administration deployed VIPER (Visible Intermodal Protection and Response) teams across the country as a pilot program in 2005, aimed at conducting surveillance and countering terrorist activities on all modes of transportation. These teams still are in operation across the United States. The visibility of security cameras and emergency phones also increases perceptions of security. Unfortunately, many security technologies and operations are not as visible to the traveling public, a problem common to many intelligent transportation systems. This visibility problem reduces travelers’ perception of ITS benefits and of security as well. 154 ITS SECURITY AREAS AND MULTIMODAL TRANSPORTATION SECURITY 8.2 PROTECTING VEHICLES AND INFRASTRUCTURE Many tools exist to help transportation practitioners protect the vehicles and infrastructure of a multimodal transportation system. This section identifies current practices and future efforts to improve security in these areas. 8.2.1 Airports Although protecting people is the first priority, security must also include protecting property. Here we discuss existing and innovative systems for use at airports for protecting vehicles and infrastructure. 8.2.1.1 Private Vehicle Parking. Parking fees are significant, sometimes the largest, incomes to many airports (TRB1 2003). Therefore, the proper management and security of parking lots plays a vital role in sustaining the financial stability of the airport. To manage and secure parking facilities, many airport operating agencies have turned to technological solutions. These types of security technologies are identified under the transportation infrastructure security area of the U.S. National ITS Architecture. Surveillance is a popular tool to help secure parking facilities. For example, the operators of the Newark-Liberty International Airport in New Jersey have installed a surveillance system in select parking lots and along bus routes. At locations where cabling to security cameras was not feasible, such as at the edge of airport property, wireless communication capabilities were used (Business Wire 2003). Although this system was installed to monitor employee access to the airport, it provides lessons upon which to launch further parking surveillance initiatives. Surveillance of airport parking facilities has two main applications: surface lots and garages. There are different constraints for the design of each of these systems. For example, surface lots likely have lighting poles readily available for the mounting and powering of surveillance equipment, but trees and large vehicles can block view, limiting their coverage area. Parking garages also provide many opportunities for the mounting and powering of surveillance equipment but present a whole new range of coverage area obstacles, including support columns, low ceilings, overhead signs, slopes, and tall vehicles. Because installing a surveillance system with full coverage requires a large investment in equipment and monitoring personnel, systems can monitor the entrances and exits from these facilities. Placing surveillance equipment at the entrances and exits of parking facilities provides an opportunity for installing vehicle identification technologies, such as automated license plate recognition (ALPR). These tools typically use infrared paired with video data to identify the license plate and scan its information. Software is then used to identify each letter and number. The identified license plate can be checked against stolen vehicles, Amber Alert lists, and other security lists. These tools have been installed in police patrol cars, such as the Washington, D.C., Area Vehicle Enforcement Unit (McFadden 2005), and 8.2 PROTECTING VEHICLES AND INFRASTRUCTURE 155 represent a valuable transportation technology to aid in the security of airport parking facilities. Some airports, including Washington-Dulles and CharlotteDouglas, use license plate capture to correlate the license plate with the parking ticket when paid. If the parking ticket is lost, the previous picture of the license plate can be uploaded to determine the correct parking fee. Some states have laws against this type of technology to protect citizen privacy. The trade-off between security and privacy will likely be a long-term debate and is discussed further in Chapter 10. 8.2.1.2 Shuttles and Ground Fleet Vehicles. Airport shuttles are one of the first mode changes that many travelers make when parking or arriving at an airport and are addressed under the transit security area of the National ITS Architecture. These vehicles can have panic buttons, surveillance systems, and automatic vehicle identification technologies to enhance their security and efficiency. Panic buttons, as the name suggests, enable drivers to report a security or other immediate problem to dispatch. To aid in the response to such emergency requests, shuttles and buses can support surveillance systems, both visual and audio, to identify the severity of an emergency. Researchers have tested such a system on transit vehicles in Pittsburgh, Pennsylvania, and found that wireless video surveillance is economical and feasible. The research evaluated the efficacy of using a hot spot or an ad hoc wireless network topology, transmitting a resolution of 640 480 at more than a frame per second. This transmission speed, chosen to best integrate with the existing surveillance equipment used by the transit operators, utilized only approximately 25 percent of the bandwidth, indicating that higher resolutions and speeds are possible (Cai 2006). Because airport parking lots are closed access and shuttle buses require fast access, automatic vehicle identification technologies can be used to control access gates. These systems can operate as standard garage door opener remotes or increase in complexity to systems that read vehicle identification from an in-vehicle transponder, review the access list in real time, and record the time vehicles access each entrance and/or exit. The Philadelphia airport operates an automatic vehicle identification system for limousines, bus companies, vans, and shuttles that enter and exit the parking structures frequently, distributing transponders to each authorized vehicle. To aid with the security of vehicles on the tarmac and throughout the airport property, airports can use automated vehicle location technology. The NewarkLiberty airport has tested a wireless fleet management system that tracks and verifies authorized access to airport-owned vehicles, including ground support equipment, fuel trucks, and ramp vehicles. The goal of this system is to ensure that only authorized personnel have access to vehicles and that they are not in unauthorized or inappropriate locations (Cerino 2004). 8.2.1.3 Future Resources. The Airport Cooperative Research Program (ACRP) was founded in 2005 by the Federal Aviation Administration 156 ITS SECURITY AREAS AND MULTIMODAL TRANSPORTATION SECURITY (FAA) to address the various research needs of airports. Initial contracted research projects generally address airport performance measures, airport and airline agreements, leasing policies, air quality and noise, peak-period operations, passenger conveyance, wildlife interactions, wayfinding, common-use facilities, and the impacts of parking constraints on employee and public access (ACRP 2007). Findings from these initial endeavors can aid in the future planning, design, and operation of airports. 8.2.2 Public Transit Bus systems also have significant risks from security incidents such as terrorist attacks. Transit agencies operating buses have used many tools to address these risks. For example, the Charlotte, North Carolina, transit system, which includes over 300 buses and a historic trolley, has improved security by using employee identification/key cards; operating security management that allows real-time access control and alarm condition adjustment; and recording surveillance video of key facilities including bus garages, employee parking garages, and new transit centers (USF CUTR1 2005). Similarly, the Central Florida Regional Transportation Authority has formed contracts with a security company to promote best security practices for transit agencies operating buses including (USF CUTR2 2005): Lock and key management Fire and life safety system Video surveillance Employee training Facility and perimeter security 8.2.2.1 Personnel Authentication. Other efforts focus on securing the operations of transit vehicles and facilities from unauthorized personnel. For example, the Transportation Security Administration is running a Transportation Worker Identification Card Program. This program, established under the Maritime Transportation Security Act, provides authorized personnel with biometric credentials that are tamper-resistant, allowing them access to the secured facilities and vehicles. To enhance this program, research efforts are developing a system of real-time communication of unauthorized access attempts, communicating with security officials via text messages, email, or phone (Dean 2006). 8.2.2.2 Access Management. Closely related to personnel authentication, access management practices ensure that only authorized persons gain access to transit infrastructure and vehicles. Tools for access management include: Intrusion and detection alarms using these detection systems: Microwave 8.2 PROTECTING VEHICLES AND INFRASTRUCTURE 157 Infrared Electromechanical Acoustic Access control systems Simple: fences, locks, vehicle barriers, and vaults Technological: magnetic card readers and access control software Communication systems Dedicated frequency radios for employees Traveler information systems (visual and audio) Silent alarms to transit management authorities The two largest ferry systems in North America, operating in the Pacific Northwest between Washington State and British Columbia, provide insight into security of this unique public transportation option. Best practices suggest that all freight and baggage (architectural drawings, luggage, blood shipments, medical equipment, and prescriptions) be accompanied by a traveler and that bomb-sniffing canines be used to inspect vehicles prior to loading onto the ferry (WSDOT 2008). 8.2.2.3 Surveillance Systems. Surveillance systems are valuable tools in protecting transit system infrastructure and vehicles. Multiple transit authorities throughout the nation are installing these systems. For example, the New York Metropolitan Transportation Authority has installed $250 million worth of camera systems and Chicago has deployed over 700 cameras on El trains (Sahm 2006). Best practices in the design and installation of a surveillance system give attention to maximizing the coverage areas, avoiding obstruction, and focusing on access points (public and private). Other factors that can influence a design are power availability, accessibility of cameras by the public and authorized maintenance personnel, type of communication (wired or wireless), type of lighting provided in the area, and clear sight range needed by the selected camera type. As an example, the subway platform shown in Figure 8.1 has many possible camera locations, each with distinct advantages and disadvantages. Assuming the use of cameras that can pan, tilt, and zoom (PTZ), location A in the lower left corner can provide a good unobstructed view of the platform but could potentially miss someone accessing the service door below it and might not be able to clearly view those entering the platform from the stairs/escalator on the far right side. To aid in the identification of these potential problems, it is useful to draw the minimum and maximum surveillance range of a selected camera location. Drawing these circles around each camera location can also notify designers to the requirements of a particular camera during a system design. 158 ITS SECURITY AREAS AND MULTIMODAL TRANSPORTATION SECURITY Figure 8.1 Security Camera Placement Example. Similarly, a camera placed in the corner at B or C could potentially miss someone accessing the rail tunnel directly below the camera. A camera at location D can provide a clear view of travelers exiting the platform and possibly those entering but leaves the already shadowed corner at D unmonitored. Many technological solutions have arisen to process the massive amounts of data that surveillance systems provide, including motion-activated recorders, facial recognition software, and automated license plate recognition. These tools hold promise for the future of surveillance systems, but sufficient training and funding of monitoring personnel is just as significant. 8.2.2.4 Personnel Training. Often the first line of defense is the observation abilities of the transit employees themselves. Proper training can help them identify suspicious behavior and potential security problems. The Washington, D.C., Metropolitan Area Transit Authority (WMATA) hosts the nation’s only personnel training center that is available 24 hours a day, 7 days a week. To help train emergency responders, the facility includes a mock train tunnel to help simulate the impact of train collisions, fires, and smoke and terrorist attacks (USF CUTR3 2005). Because security is a constantly evolving field, frequent security training on up-to-date response practices is essential. 8.2 PROTECTING VEHICLES AND INFRASTRUCTURE 159 8.2.3 Rail Vehicles and Infrastructure Because over 40 percent of the nation’s freight, including 67 percent of the coal for energy, travels by rail, protecting rail vehicles and infrastructure is of great importance. Much of this transport occurs on lines used by both passengers and freight. Due to the sheer size of the U.S. rail network, the traditional tactics of policing, restricting access, and cordoning are not sufficient (Plant and Young 2007). Instead, risk-based approaches such as those presented in Chapters 4 and 5 hold more promise for focusing security efforts properly. Risk-based analyses have identified that rail vehicles holding toxic cargo are at more significant risk to terrorist attacks than passenger rail vehicles because of their potential to harm mass populations. For example, one rail car (90-ton) carrying chlorine can harm or kill approximately 100,000 people in only 30 minutes if ruptured by terrorist or other incidents (Cantrell et al. 2006). Improving security focus on rail vehicles transporting such materials is a likely outcome of risk analysis efforts. The HAZMAT security area of the National ITS Architecture provides guidelines for the consistent application of ITS tools to aid these efforts. 8.2.3.1 Highway Rail Intersections. As discussed in Chapter 3, the rail security ITS security area focuses on highway-rail intersections. Because these intersections create a significant safety risk to both motorists and rail cars, it is clear that these breaches could be used for malevolent intent. Surveillance systems can deter potential attacks; however, there is no feasible way to protect the countless highway rail intersections throughout the United States. Instead, focus can remain on the safety of rail vehicles in the event of a collision, to protect passengers and freight from intentional crashes. 8.2.3.2 Monitoring Track Infrastructure. It is also infeasible to monitor all of the approximately 160,000 miles of rail track in the United States (Kaplan 2007). Until autonomous monitoring technologies are available at lower costs and more federal funding is directed toward protecting the railways, best practices continue to monitor key infrastructure, including rail yards, key bridges and tunnels, and communication and command hubs. 8.2.3.3 Trade-off between Safety and Security. Traditionally safety and security efforts have complemented each other. For example, security cameras installed to detect traffic crashes can be used to identify suspicious activities. Unfortunately, in today’s security environment, there have arisen some important disparities between safety and security goals, particularly in the field of incident management. To prevent the labeling of potential targets, some have suggested removing placards that denote the type of cargo on rail cars and trucks. By doing so, terrorists would not be able to distinguish between the various types of cargo in freight rail; neither would responders be able to identify the cargo type when 160 ITS SECURITY AREAS AND MULTIMODAL TRANSPORTATION SECURITY responding to a derailment or crash. After an incident occurs, incident managers must quickly identify the types and nature of the cargo involved in order to ensure a timely response. There comes a tipping point where the safety of citizens is more important than preventing or discouraging a possible attack. 8.2.4 Ships and Ports Countries around the world depend on maritime commerce for economic success. Some unique security concerns arise when protecting ships and ports. Protecting every ship traveling on the high seas throughout the world is an unreasonable expectation. History has shown that the most significant risks arise from four key types of threats to ships (GAO 2007): 1. Suicide attacks wherein a boat of explosives is driven into the side of a tanker or freight ship. In 2002, off the coast of Yemen, the French ship Limburg was attacked by a suicide bomber in this fashion. 2. Standoff attacks, such as using a rocket or other projectile explosive to damage a ship from a distance. The intervening space protects the attackers from defensive firearms. 3. Armed assault attacks use high-speed boats to damage or destroy tankers, cargo ships or other infrastructure. In 2004, terrorists used an armed assault attack to damage tankers and disrupt loading operations at two offshore oil loading facilities. 4. Other threats include sabotage by crew members and intentional collisions by other terrorist-controlled vessels, representing less of a threat. To address suicide and standoff threats, the Coast Guard has increased patrols of U.S. waters near ports; however, there are few ways to defend against these threats in a significant way on the open seas. Instead, safety and communications improvements have the potential to improve security particularly from collisions. For example, shipboard automatic identification systems (AIS) can allow vessels at sea and in ports to learn the identity of approaching ships, among other information. The goals of these AIS systems are to assist in collision avoidance, alert customs and other trade organizations about the manifest of incoming ships, and serve as a tool for vessel traffic management operations (TRB 2003). These goals focus on improving safety and efficiency of maritime trade, but security improvements also can be realized from such systems. Cargo inspection agencies can be given notified regarding the arrival of at-risk cargo, including its nature and volume. AIS communications links also can serve as redundant communication links in case of open-sea attacks, Further, these systems can support panic buttons to alert authorities, such as the Coast Guard, of suspicious activities of other vessels. Figure 8.2 shows a container ship docking. 8.2 PROTECTING VEHICLES AND INFRASTRUCTURE 161 Figure 8.2 Maritime Cargo Freight. Other efforts aimed at securing the global maritime supply chain include the International Ship and Port Facility Security Code adopted by the International Maritime Organization. Although individual nations can set higher security standards (such as the U.S. Maritime Security Act of 2002), this international agreement 162 ITS SECURITY AREAS AND MULTIMODAL TRANSPORTATION SECURITY sets a baseline for international shipping security to follow. Unfortunately, these baseline standards lack a mechanism to verify compliance (GAO 2007). With the current congestion at U.S. ports and the anticipated future growth, it is likely that capacity improvements will increasingly utilize technological solutions as well as traditional infrastructure expansions. With support provided through the National ITS Architecture’s security areas, the maritime industry has valuable opportunities to employ dual-use technologies to improve both efficiency and security. 8.3 PROTECTING FREIGHT This section focuses on air, rail, and maritime freight in an integrated fashion due to the common use of screening techniques. Note that trucking cargo is addressed in other chapters of this text. 8.3.1 Containers The container security initiative launched by the U.S. Customs Service in 2002 identified four key areas of focus for maritime security: 1. Developing and using technology to secure containers. 2. Identifying high-risk containers. 3. Prescreening those containers prior to arrival in the United States. 4. Using technology to prescreen high-risk containers. The changing cargo from one mode of transportation to another often requires security screening. This section reviews some of the more common threat detection and security screening tools. Threat detection systems generally are classified into two categories, active and passive. Active detection systems stimulate the material that is inspected and record the reaction. Passive detection systems rely on emanations from the material that is inspected, such as radiation or particulate matter (Sheridan 2002). Examples of passive and active cargo inspection tools are presented in Table 8.1. TABLE 8.1 Cargo Inspection Tools Technologies and Their Categories Passive Canines Radiation detection Vapor and trace detection Visual inspection Active Acoustic systems Gamma ray systems Pulsed fast neutron analysis (PFNA) Thermal neutron activation (TNA) X-ray Infrared Resonance (quadrupole or nuclear magnetic) 8.3 PROTECTING FREIGHT 163 8.3.1.1 Visual Inspections. It is difficult to detect explosives and radioactive material from visual inspection of cargo. The key problem is that cargo vessels must be opened for inspection. Even then, detection is challenging. Best practice suggests using technology to aid the intelligence and training of detection personnel rather than relying solely on visual inspections. Primary Transportation Security Uses of Visual Inspections Screen passengers Screen inside cargo Screen inside and under vehicles 8.3.1.2 Gamma Ray. Gamma ray detection systems use radioactive elements, usually cesium or cobalt, to generate gamma rays into cargo and then sense the resulting reaction, creating a picture of the cargo contents (Sheridan 2002). Passive radiation detection systems wait for incoming radiation; gamma ray detection systems actively emit radiation. Based on the return rate of the radiation, these systems can identify cargo and threats within. Primary Transportation Security Uses of Gamma Ray Inspections Screen inside cargo Screen vehicles Gamma ray detection systems are particularly useful because they can scan both large and small cargo items. Some applications can scan container trucks as they move through an inspection gantry or tunnel; other gamma ray detection systems are handheld. 8.3.1.3 Pulsed Fast Neutron Analysis and Thermal Neutron Activation. A pulsed neutron analysis machine releases pulses of neutrons through a piece of cargo. These neutrons react with the nuclei of the inspection material, emitting secondary gamma rays. The analysis machine records the secondary gamma rays produced from the interaction. Because every material releases secondary gamma rays with different energy characteristics when bombarded with neutrons, inspectors can identify each type of material in a unit of cargo without opening it (Rountree and Demetsky 2004). The release of neutrons is pulsed to record the returning gamma rays during the breaks. Pulsed fast 164 ITS SECURITY AREAS AND MULTIMODAL TRANSPORTATION SECURITY neutron analysis is also applicable for large cargo, using an inspection tunnel through which trucks pass. Because of the radiation emitted from this inspection method, nearby personnel require shielding. Thermal neutron activation is essentially the same method. Its name is derived from the interaction of neutrons with the inspection material; the neutrons thermally activate the material to produce gamma rays. Primary Transportation Security Uses of Pulsed Fast Neutron Analysis and Thermal Neutron Activation Screen inside cargo Screen vehicles The previous methods discussed in this chapter, summarized in boxes, can also be used for air cargo screening. Those of particular importance to air cargo are radiation detection, vapor detection, canines, trace detection, X-ray machines, gamma ray, thermal neutron activation, and pulsed fast neutron analysis (Rountree and Demetsky 2004). Tools that could also be used for ISO (International Organization for Standardization) container inspection for maritime, freight, or rail include canine, radiation detection systems, vapor and trace detection systems, gamma ray, pulsed fast neutron analysis, thermal neutron activation, X-ray, and resonance. 8.3.1.4 Future Directions in Detection Systems. The U.S. Department of Defense has expressed interest in interoperable and networked threat sensing systems (Tiron 2003). Unfortunately, investments continue to favor separate systems instead of integration (Philpot 2007). Because ITS provides a well-established framework for integrating transportation technologies, including those used for security, its increased use can help integration and interoperability. 8.3.2 HAZMAT Both safety and security measures serve to protect the transport of hazardous materials (HAZMAT) freight. The importance of security for this type of freight is underscored by its separate security area in the National ITS Architecture with respect to roadways. Nevertheless, the three major functions of this security area—tracking sensitive cargo, detecting hazardous cargo, and authentication of vehicle operators—easily parallel the other modes. The first function, tracking sensitive cargo, while more applicable to maritime transportation than to rail transport, can use the same technologies, namely global positioning satellite (GPS), and the same communication 8.3 PROTECTING FREIGHT 165 structure between transportation management and the field vehicles (ships or rail cars). The second function, detecting hazardous cargo, is accomplished by using the inspection technologies discussed earlier in this chapter. The communication of hazardous detection should be integrated based on an ITS or a transportation security architecture, as discussed in Chapter 9. The third function of the HAZMAT security area of the National ITS Architecture is the authentication of vehicle operators. The use of secure authorized personnel identification cards, similar to those discussed for transit, provides an opportunity for rail and maritime operators to restrict these unauthorized uses. 8.3.3 Liquids The security of liquids pertains to maritime tankers transporting oil and other petroleum products and to tanker trucks and rail cars transporting a variety of chemicals. To ensure that these cargos do not contain explosives, drugs, or other security-sensitive materials smuggled within them, acoustic detection systems hold promise. These systems place an ultrasonic transducer in contact with the container and interpret the reflected noise waves to generate a picture of the objects within (Sheridan 2002). Because these devices interact with the cargo using sound waves, they are, by definition, active not passive. Primary Transportation Security Uses of Acoustic Sensors Screen liquid cargo Acoustic sensors can detect explosives immersed in liquid cargo. This use is applicable mainly for rail and truck cargo, as air transport of liquids is expensive. Some suggest that acoustic sensors should be installed as integral parts of cargo shipping containers, in particular ISO cargo containers, in order to monitor the integrity of the cargo unit during its travel (Whiffen and Naylor 2005). This use would be applicable to maritime, rail, and trucking security as ISO containers can use any of these transport forms. 8.3.4 Military Freight The requirements of military freight transport and its security significantly impact commercial transportation. For example, 95 percent of the equipment and cargo for Operations Desert Shield and Desert Storm was shipped via commercial carriers. Due to this level of dependence on commercial carriers, close coordination between carriers and the military is required (Brown et al. 166 ITS SECURITY AREAS AND MULTIMODAL TRANSPORTATION SECURITY U.S. Transportation Command (USTRANSCOM) Air Force’s Air Mobility Command Navy’s Military Sealift Command Army’s Military Traffic Management Command Figure 8.3 U.S. Military Transportation Command Structure. 2000). To manage this coordination between the military and commercial carriers, the U.S. Transportation Command oversees three different commands focusing on air, water, and ground transportation. Figure 8.3 illustrates the command structure that coordinates transport within the military. The U.S. Maritime Administration is meeting its goals for transportation security, focusing on supporting the amount of military shipments required to support security activities (USDOT 2007). U.S. maritime military forces also have improved the coordination among the Coast Guard, the Marines, and the Navy. Although little has been published about the best practices specifically used by military transport operations within the United States and abroad, the presence of military experts on policy-making panels for transportation security provides the needed downward flow of security best practices. Unfortunately, private sector transportation agencies are more constrained by budgets than the military and cannot afford the same number of personnel or technologies. 8.4 THE FUTURE New threats to multimodal facilities will necessitate new thinking and approaches to protect people and infrastructure. New concepts and technologies may provide better security more efficiently in the future. Multimodal facilities also are focal points of trade, so ensuring their security is important for economic security of a region and a nation. As consensus grows about the proper amount of societal privacy on public facilities and transit systems, in international airports, and on international waters, technologies such as vehicle tracking, license plate recognition and surveillance systems can be used to their full potential. Additionally, as integration of transportation technologies becomes more commonplace, a regional, statewide and national ITS architectures will play an increasingly important role in ensuring the interoperability and interchangeability of systems, not only between agencies but between modes. REFERENCES 167 REFERENCES Airport Cooperative Research Program. 2007. ‘‘Announcement of Airport Research Projects.’’ Transportation Research Board, National Academies. Available online at www.trb.org/ NotesDocs/ACRP_Announcement.pdf. American Public Transportation Association. 2007. ‘‘Americans Take More than 10 Billion Trips on Public Transportation for the First Time in Almost Fifty Years.’’ Press Release. Available online at www.apta.com/media/releases/documents/070312_ten_billion.pdf. Athanassiu, C. 2006. ‘‘Chemical and Biological Decontamination System for Rail Transit Facilities: Transit IDEA Project 45.’’ In the Transit IDEA Program Annual Progress Report, Transportation Research Board. Balog, J. N., M. G. Devost,, and J. P. Sullivan. 2002. ‘‘Public Transportation Security: Volume 1 Communication of Threats,’’ Transit Cooperative Research Program Report 86. Bango, J. J. 2006. ‘‘Counter-Terrorism Chemical Detector for Rail Transit Systems: Transit IDEA Project 40.’’ In the Transit IDEA Program Annual Progress Report, Transportation Research Board. Brown, S. E., H. M. Bennett, and R. B. Honea, 2000. ‘‘U.S. Military Transportation.’’ Transportation in the New Millenium. Transportation Research Board. Cai, Y. 2006. ‘‘Bandwidth Expansion and Real-Time Surveillance for Security on Transit Buses: Transit IDEA Project 37.’’ In the Transit IDEA Program Annual Progress Report, Transportation Research Board. Cantrell, B., M. Lazo, and R. Ruttenberg 2006. ‘‘Training in Hazmat and Rail Security: Current Status and Future Needs of Rail Workers and Community Members.’’ Retrieved December11, 2006 via Citizens for Rail Safety Inc. Available online at www.citizensforrailsafety.org/docs/CRS_PAPER1.doc. Cerino, A. T. 2004. ‘‘Newark-Liberty International Airport Vehicle Tracking Demonstration Wireless Fleet Management System: Phase Zero Test Plan.’’ Prepared for the Transportation Security Administration, Report no. PB2005-100116. Dean, M. 2006. ‘‘Biometric Notification Network for Transit Employees: Transit IDEA Project 48.’’ In the Transit IDEA Program Annual Progress Report, Transportation Research Board. Domestic Nuclear Detection Office. 2007. ‘‘DHS Announces Additional Grant Awards for Radiological/Nuclear Detection in the Southeast Transportation Corridor.’’ Available online at www.dhs.gov/xnews/releases/pr_1189796880249.shtm. Furton, K. G., and L. J. Myers, 2001. ‘‘The Scientific Foundation and Efficacy of the Use of Canines as Chemical Detectors for Explosives.’’ Talenta 54, No. 3: 487–500. Government Accountability Office. 2007. ‘‘Federal Efforts Needed to Address Challenges in Preventing and Responding to Terrorist Attacks on Energy Commodity Tankers,’’ GAO08-141, Washington, DC. Hannum, D. W., and J. E. Parmeter, 1998. ‘‘Survey of Commercially Available Explosives Detection Technologies and Equipment,’’ Sandia National Laboratories, National Institute of Justice, NCJ 171133, September. Harper, R. J., J. R. Almirall, and K. G. Furton, 2005. ‘‘Identification of Dominant Odor Chemicals Emanating from Explosives for Use in Developing Optimal Training Aid Combinations and Mimics,’’ Talanta. 67, No 2: 313–327. 168 ITS SECURITY AREAS AND MULTIMODAL TRANSPORTATION SECURITY Kaplan, E. 2007. ‘‘Rail Security and the Terrorist Threat,’’ Backgrounder, Council on Foreign Relations. Available online at www.cfr.org/publication/12800/rail_security_and_the_ terrorist_threat.html. McFadden, T. 2005. ‘‘Automatic License Plate Recognition Systems Emerge as a Law Enforcement Tool,’’ Office of Law Enforcement Technology Commercialization, April. McTrans at University of Florida, CORSIM microscopic traffic simulation model, http:// mctrans.ce.ufl.edu/featured/TSIS/Version5/corsim.htm. Moore, D. S. 2004. ‘‘Instrumentation for Trace Detection of High Explosives.’’ Review of Scientific Instruments 75, No. 8: 2499–2512. Myers, L. J., and R. Pugh. 1985. ‘‘Thresholds of the Dog for Detection of Inhaled Eugenol and Benzaldehyde Determined by Electroencephalographic and Behavioral Olfactometry,’’ American Journal of Veterinary Research 46, No. 11: 2409–2412. North American Police Work Dog Association. 1998. NAPWDA Certification Rules. NAPWDA, Perry, OH, 1–23. Paramics Traffic Simulation Model, www.Paramics-online.com/, Quadstone Limited 2002. Philpot, D. 2007. ‘‘Maritime and Port Security.’’ Homeland Defense Journal, May. Plant, J. F., and R. R. Young. 2007. ‘‘Securing and Protecting America’s Railroad System: US Railroad and Opportunities for Terrorist Threats.’’ Report prepared for the Citizens for Rail Safety. PTV (2008). ‘‘VISSIM version 5.0’’. www.ptvag.com/cgi-bin/traffic/traf_vissim.pl. Rivers, D, B. 2006. ‘‘Innovative Bioterrorism Detection Technology for Transit Security: Transit IDEA Project 35.’’ In the Transit IDEA Program Annual Progress Report, Transportation Research Board. Rountree, C. D., and M. J. Demetsky, 2004. ‘‘Development of Counter Measures to Security Risks from Air Cargo Transport,’’ Center for Transportation Studies at the University of Virginia, Research Report No. UVACTS-5-14-63, July. Rubenstein, E. P. 2006. ‘‘Detection of Radioactivity in Transit Stations: Transit IDEA Project 42.’’ In the Transit IDEA Program Annual Progress Report, Transportation Research Board. Sahm, C. 2006. ‘‘Hard Won Lessons: Transit Security.’’ Safe Cities Project. Available online at www.cpt-mi.org/pdf/scr_05.pdf. Sheridan, R. 2002. ‘‘Volume 6—Report on Non-intrusive Detection Technologies,’’ U.S. Treasury Advisory Committee on Commercial Operations of The United States Customs Service Subcommittee on U.S. Border Security Technical Advisory Group and Customs Trade Partnership Against Terrorism, June 14. Available online at www.cargosecurity.com/ ncsc/coac/Non-intrusive.pdf. Singh, S., and M. Singh. 2003. ‘‘Explosives Detection Systems (EDS) for Aviation Security.’’ Signal Processing 83, No. 1. 31–55. Tiron, R. 2003. ‘‘Security Technologies Should Be Networked, Pentagon Says.’’ National Defense, July. Transportation Research Board, Committee for Evaluating Shipboard Display of Automatic Identification Systems. 2003. ‘‘Shipboard Automatic Identification System Displays.’’ Special Report 273. REVIEW QUESTIONS 169 University of South Florida Center for Urban Transportation Research 1. 2005. ‘‘Case Study: Charlotte Area Transit System (CATS) Charlotte, North Carolina.’’ Available online at www.cutr.usf.edu/security/documents/UCITSS/CATS.pdf. University of South Florida Center for Urban Transportation Research 2. 2005. ‘‘Case Study: Central Florida Regional Transit Authority (LYNX) Orlando, Florida.’’ Available online at www.cutr.usf.edu/security/documents/UCITSS/LYNX.pdf. University of South Florida Center for Urban Transportation Research 3. 2005. ‘‘Case Study: Washington Metropolitan Area Transit Authority (WMATA) District of Columbia.’’ Available online at www.cutr.usf.edu/security/documents/UCITSS/WMATA.pdf. University of South Florida Center for Urban Transportation Research 4. 2005. ‘‘Case Study: Regional Transportation District (RTD) Denver, Colorado.’’ Available online at www .cutr.usf.edu/security/documents/UCITSS/RTD.pdf. U.S. Department of Transportation. 2007. ‘‘Performance Report: Security Strategic Roles.’’ Available online at www.dot.gov/perfacc2007/perfreportSeSG.htm. ‘‘Vanguard Managed Solutions and OMNI Security Services, Inc. Enhance Employee Parking Lot Security and Operations at Newark Liberty International Airport.’’2003. Business Wire, March, 3. Available online at http://findarticles.com/p/articles/mi_m0EIN/is_ 2003_March_3/ai_98259249. Wallace, R. R., et al. 1999. ‘‘Who Noticed, Who Cares? Passenger Reactions to Transit Safety Measures.’’ Transportation Research Record, No. 1666: 133–138. Washington State Department of Transportation. 2008. ‘‘Security at Washington State Ferries.’’ Available online at www.wsdot.wa.gov/ferries/security/. Whiffen, J., and M. Naylor. 2005. ‘‘Acoustic Signal Processing Techniques for Container Security.’’ IEEE Seminar on Signal Processing Solutions for Homeland Security. October. REVIEW QUESTIONS 1. What factors influence the coverage area of parking lot surveillance systems in garages and surface lots? 2. What cargo screening method(s) would you use to examine a rail car listed as transporting oil? Discuss why. 3. Why should you not use gamma ray or pulsed fast neutron analysis to inspect people? 4. List three factors that influence public transit traveler’s perception of security. 5. Why are HAZMAT rail cars at higher risk of attack than passenger rail cars? What locations and times of day would influence vulnerabilities? 6. Because ITS systems commonly operate out of the public view, how does this lack of visibility impact security? 7. In the sample parking lot bus terminal shown, discuss the pros and cons of each camera location. (Note that camera locations 1 and 2 are on the roof.) 170 ITS SECURITY AREAS AND MULTIMODAL TRANSPORTATION SECURITY 2-Story Building Camera 1 Bus Shelter Exit Tree Sidewalk Sidewalk Tree Camera 2 Enter Camera 3 Grass Sidewalk Sidewalk 1-Story Building 8. What are the three key risks for ships? CHAPTER 9 PROCESS FOR DEVELOPING A REGIONAL TRANSPORTATION SECURITY PLAN S ecurity should be considered as an integral part of transportation, especially for intelligent transportation systems (ITS) planning and deployment. It is common knowledge that it is very difficult to implement security measures properly and successfully after a system has been developed and deployed. This chapter deals with developing regional and project security architectures where project and network security should be integrated early in the system life cycle. Considering security ramifications when traversing the steps of the system’s engineering process for project development will lead to an overall security plan that can be further refined into security system design and implementation guidelines. 9.1 INTRODUCTION Despite the publicity that security-related incidents receive, some transportation professionals tend to think of computer security as an afterthought. Security usually comes in at the bottom of their list, which looks something like this (Gasser 1988): Functions: What does it do? Price: How much does it cost? Transportation Infrastructure Security Utilizing Intelligent Transportation Systems R. Fries, M. Chowdhury and J. Brummond Copyright © 2009 John Wiley & Sons, Inc. 171 172 PROCESS FOR DEVELOPING A REGIONAL TRANSPORTATION SECURITY PLAN Performance: How fast does it run? Compatibility: Does it work with earlier products/systems? Reliability: Will it perform its intended functions? Human interface: How easy is it to use? Availability: How often will it break? Security functions: What protection features does it provide? Security assurance: How foolproof are the protection features? Advances in the security industry have made using security mechanisms much easier than in the past. Digital security is also less of a nuisance than, say 15 years ago, due to established Internet security mechanisms. As regions develop their ITS planning by creating or maintaining regional ITS architectures and following the systems engineering process for ITS projects, they must recognize that their efforts provide an opportunity to address security early in the planning process. Due primarily to the fact that the U.S. Department of Transportation requires a regional ITS architecture of any region using funds from the Highway Trust Fund for projects involving ITS, most regions already have a regional ITS architecture. This chapter addresses planning for security at two levels: 1. The regional level, taking into account regional security issues and legacy systems. 2. The ITS project level, where a more detailed security analysis and implementation takes place as the project follows the systems engineering process. Since a regional ITS architecture provides the framework for ITS integration in a region, it is recommended that this framework also address security. If this occurs, the integration opportunities identified by the architecture will not ultimately lead to vulnerabilities that adversely impact the mission-readiness of the regional transportation system. The regional ITS architecture provides a natural beginning for a top-level security policy and strategy for a secure regional transportation system. Because each region has unique transportation assets, goals, and stakeholders, the security planning process described in this chapter is not the only way to apply security considerations to regional ITS architecture planning processes. The primary objective of this chapter is to increase awareness of security and its implications within a region for project deployment. We discuss a number of security-related products; collectively, these products are referred to as a security plan for the region. This term is used to refer to the collection of security products or services, but it is not meant to imply that the security products must be packaged as a single ‘‘security plan’’ document. This chapter does not focus solely on regional ITS architecture; more important, it provides advice on the security projects themselves. 9.2 DEVELOPING A REGIONAL TRANSPORTATION SECURITY ARCHITECTURE 173 Recall that security in the National ITS Architecture has two dimensions: 1. Eight ITS security areas that define different ways that ITS can improve surface transportation security (discussed in Chapter 3). 2. Securing ITS, which defines the security services necessary to secure ITS (discussed in Chapter 7). Security in a regional ITS architecture can be viewed from these same perspectives. This chapter focuses on defining security considerations that will improve the security of the ITS systems in the region as a whole. The second dimension, the eight ITS security areas, can be incorporated into a regional ITS architecture like any other ITS service since the National ITS Architecture has been updated to include this security functionality. A few examples of these security services are disaster response and evacuation, transit security, and wide area alerts. The Regional ITS Architecture Guidance, Version 2.0 document (RITA July 2006), describes the process to include these services in a regional ITS architecture. 9.2 DEVELOPING A REGIONAL TRANSPORTATION SECURITY ARCHITECTURE Security plans for ITS projects and transportation systems in general must enable fast and coordinated reactions to prevent, limit the severity of, or manage security incidents, such as terrorist attacks and natural disasters. The individual security plans of various projects and transportation agencies should follow a regional, statewide, or national framework to ensure proper coordination and continuing interoperability. Such interaction often is difficult because of the varying interests and goals of the public and private agencies within the transportation industry. Creating an architecture that incorporates transportation or ITS security can simplify the process by focusing on responsible agencies, information communications between these agencies, and infrastructure. ‘‘Providing the right information to the proper authorities and infrastructure elements can make the difference between repeating the mistakes of the past and preventing or managing disasters in the future’’ (Fries et al. 2008). In the United States, a security framework can coordinate with the National Strategy for Homeland Security in several areas. Transportation is listed as one of the 13 critical infrastructure sectors in the strategy, and allocating responsibility through a security architecture meets the objective of assigning accountability in transportation security. Creating a transportation security architecture also promotes several strategy initiatives, including emergency preparedness and response, science and technology, and information sharing and systems (Office of Homeland Security 2005). This section presents two methods for developing regional transportation security architectures. The first method shows how to include security 174 PROCESS FOR DEVELOPING A REGIONAL TRANSPORTATION SECURITY PLAN initiatives in a process parallel to that of a standard regional ITS architecture development. The second method, while significantly including ITS, also incorporates other areas of transportation in developing a regional transportation security architecture. When selecting between these two methods, it is important to identify the focus of the proposed regional transportation security architecture. For example, if ITS is the main focus, the first method is more applicable. 9.2.1 Security in a Regional ITS Architecture Development Process Figure 9.1 identifies the steps in developing a regional security plan using the National ITS Architecture. The figure shows security-related activities associated with ‘‘Securing ITS.’’ Each of these activities is further defined in the sections that follow. 9.2.1.1 Identify Security Objectives. The regional ITS architecture development effort should always focus on the institutions and people involved in the region, also known as the region’s stakeholders. They should establish a basic Security Considerations Regional ITS Architecture Development Process STEP #1: GET STARTED Identify Threats Identify Critical Assets Roles and Responsibilities Define Security Requirements Identify Security Boundaries Isolate Critical Assets Identify Sensitive Information Need Champions Boundary Stakeholders STEP #2: GATHER DATA Inventory Systems Operational Concept Needs and Services Functional Reqmnts Iterative Process Identify Security Objectives STEP #3: DEFINE INTERFACES Interconnects Information Flows STEP #4: IMPLEMENTATION Threat Analysis Identify Security Services Select Security Standards Risk Analysis Define Security Mechanisms Implement Security Mechanisms Monitor and Revise Project Sequencing ITS Standards List of Agency Agreements STEP #5: STEP #6: USE THE ARCHITECTURE MAINTAIN ARCHITECTURE Figure 9.1 Addressing Security in a Regional ITS Architecture. (Source: RITA, Security Document, National ITS Architecture, May 2007.) 9.2 DEVELOPING A REGIONAL TRANSPORTATION SECURITY ARCHITECTURE 175 commitment to security. While the geographical boundary of the region is being established and stakeholders continue to be identified, the basic security objectives should be incorporated into the foundations of the regional architecture (RITA, Security Document, 2007). Initially, the objectives can be included in a high-level security strategy statement that guides the region’s ITS planning in subsequent steps. The statement of objectives defined at this step are elaborated and refined as each step further-defines the region’s critical assets; threats and security-related roles and responsibilities. Establishing the stated need for security at the beginning of an ITS planning process is particularly important because of the number of various ITS systems that rely on participation and support from emergency management, public safety, and other security-critical organizations. This variety in stakeholders often creates differences in acceptable levels of risk. For example, the videos collected by a traffic management center are not held to the same security standards as those collected by law enforcement agencies. The security objectives formed in this step provide common ground that can encourage organizations to participate in the region’s ITS deployment and successive integration projects (RITA, Security Document, 2007). One example of differing security levels is a certain state highway patrol (SHP) office where security is of the utmost importance. Because SHP is afraid that any direct computer connection could compromise its computer security, interfacing entities may have to screen scrape the SHP Web site, extracting information from the webpage using software tools. Screen scraping is a technique where a software program takes an output (in this case a webpage) intended only for viewing and extracts the pertinent content while ignoring the formatting and binary graphics data. Everyone has access to the information on the Web site, but any change to it will cause the interface between this agency and SHP to fail since the parsing is Web site dependent. Creating common security goals through an ITS regional architecture can encourage this particular SHP to provide the Web site information to interfacing entities, significantly reducing their colleague’s data collection efforts compared to screen scrapes which are not set up for easy parsing of data content. Security Objectives Confidentiality Integrity Availability Once the stakeholders have established a fundamental commitment to the security objectives for the region, a review of the existing regional security 176 PROCESS FOR DEVELOPING A REGIONAL TRANSPORTATION SECURITY PLAN plans, policies, or architecture (if it exists) should be performed. Securityrelated information can be collected, and an initial security investigation can be performed and documented for later use in this process (RITA, Security Document, 2007). 9.2.1.2 Identify Threats. Chapter 4 presents background on how to identify threats and critical assets in general terms for any transportation system, small or large. This chapter focuses on regional transportation systems and provides steps beyond risk assessment frameworks. The National ITS Architecture contains broad threat categories that can be used as a source for identifying threats that may apply to a regional transportation system (RITA, Security Document, 2007). If threat assessments for ITS systems in the region exist, those findings should also be compiled and used. Each threat category found in the National ITS Architecture identifies a broad range of threats that should be reviewed for the region (RITA, Security Document, 2007). Further details about threat categories (also termed threat consequences) and their connection to specific threats are provided in RFC 2828: Internet Security Glossary (Shirey 2000) (RITA Security Document, 2007). Upon inception of an ITS architecture, users need to identify, clarify, and document specific threats to the envisioned system. 9.2.1.3 Identify Critical Assets. In coordination with threat identification, the regional inventory compiled for ITS should be reviewed to identify critical assets, defined as systems that if disrupted, would endanger the ability of the regional transportation system to function or would threaten public safety. Other existing analysis of critical assets in the region, for example infrastructure asset management systems, can be used as a starting point, if available. In later steps, the content of the regional ITS architecture can be organized to guard these critical assets and security services. Security mechanisms that can isolate these critical assets from noncritical assets are preferred, in order to reduce the quantity of assets that require stringent security mechanisms (RITA, Security Document, 2007). The concepts presented in Chapters 4 and 5 can provide options for the identification and sorting of the security-critical elements in the ITS inventory. 9.2.1.4 Define Roles and Responsibilities. For both the regional and project concepts of operation development processes, operational roles and responsibilities should be identified. The key roles and responsibilities from a security perspective are those focused at making sure the security requirements are satisfied and those responsible for examining the ever-changing security environment. Leveraging against the expertise and interests of local organizations in the region can help in populating these roles. 9.2.1.5 Define Security Requirements. In combination with defining the regional ITS functional requirements, security requirements also should be 9.2 DEVELOPING A REGIONAL TRANSPORTATION SECURITY ARCHITECTURE 177 identified and defined to protect the integrity, confidentiality, and availability of the connected systems and the information that will pass between them. These initial high-level security requirements at the regional level will be defined in more detail as each ITS project is initiated and implemented. Overall, the security requirements of a regional ITS architecture will focus on system integration and sharing of information between systems, such as between a traffic management center and a state highway patrol office. Each individual project resulting in deployed systems will have the responsibility for protecting its components and data within its domain. Because regional architectures are macroscopic in nature, they usually do not focus on internal system security requirements. A regional security architecture is created to solidify the regional security objectives, identified local threats, security requirements, and roles and responsibilities that ensure that those security objectives will be met and the security threats are mitigated. The security architecture accounts for the region’s needs and services that require any significant level of security while remaining consistent with the region’s operational concept. Because the next step defines the connections between ITS systems, this step defines the security implications for the interfaces between systems. After defining the security requirements, the security plan will broadly define the types of access to system data and the conditions under which access is permitted (RITA, Security Document, 2007). As an ITS project defines its requirements, the security requirements should further identify security constraints and functions that will protect the confidentiality, integrity, and availability of the ITS project and its connected systems and the data that will pass among them. 9.2.1.6 Identify Security Boundaries. Each ITS project or system may be governed by its own security policy, by an overall policy for the organization, by a specific policy for interfacing systems, or by a combination of these. It is possible that organizations may not have a formally documented security policy, so their system(s) should be treated as insecure until proven otherwise (RITA, Security Document, 2007). For instance, a local transit system does not have the funding for security upgrades on its computer systems and is therefore treated with caution by the other integrating systems. The interfaces between each ITS system represents a security boundary between the different governing security policies that should be identified and addressed (RITA, Security Document, 2007). It is critical to identify the interfaces between secure and unsecure systems. Defining the security boundary between systems or surrounding a given project or system will help identify the level of security mechanisms needed to meet security objectives. Systems that share the same security mechanisms and policies are more likely to share their information and delegate more advanced ITS capabilities, such as device control. For example, because security policies are usually the same throughout a state department of transportation, a local district office can have access to tilt 178 PROCESS FOR DEVELOPING A REGIONAL TRANSPORTATION SECURITY PLAN or pan a local traffic camera even though the regional traffic management center retains control precedence. 9.2.1.7 Isolate Critical Assets. The interfaces between ITS systems that were identified as critical assets in Section 9.2.1.3 should be segregated to limit interface content and allow only authorized information exchange between the critical asset and other ITS systems in the region. The region’s ITS architecture inherently helps to partition ITS systems from each other by focusing on the information exchanges. Isolating critical assets help identify other security concerns as architecture flows or interconnects to and from critical ITS systems in the region’s architecture are reduced. In the previous state highway patrol example from section 9.2.1.1, the systems are interfacing with each other only to the extent of the incident information content available on the SHP Web site. No metadata is tied to the incident information, isolating the SHP assets. 9.2.1.8 Identify Sensitive Information. The flow of information in a region or project is represented by architecture flows present in the regional ITS architecture. The National ITS Architecture contains these architecture flows and links each architecture flow group to the three security objectives of availability, confidentiality, and integrity. Depending on the content of each architecture flow, these security objectives help identify sensitive information and which interfaces require more security protection. Along with the security objectives, the National ITS Architecture characterizes the general threat categories and provides a classification for each architecture flow group. These threat categories are shown in the text box. National ITS Architecture Threat Categories Deception Disruption Usurpation Unauthorized disclosure These threats to system interfaces can be used to help further identify which interfaces need different levels of security for the information flowing among ITS systems. The threat analysis performed in this section and Section 9.3 will culminate in an overall documented threat analysis, as discussed in section 9.3. Agency agreements are needed when information is shared between systems. It is important to document the needed level(s) of security, security policies, security services, and any assumptions in these agreements. In 9.2 DEVELOPING A REGIONAL TRANSPORTATION SECURITY ARCHITECTURE 179 particular, what the receiving system can do with the information should be defined (i.e., can it act as a delegate for the initiating system and forward the information to other system). It is important the security mechanisms are agreed to as projects are deployed, in order to promote interoperable exchange of information. 9.2.1.9 Threat Analysis. Leveraging the high-level threat identification in Section 9.3 for system functionality and Section 9.9 for interfaces, a documented overall threat analysis should be completed. A threat analysis considers the potential threats, the likelihood of occurrence, the region or system’s vulnerability to those threats, and the damage that may happen if the threat occurs (RITA, Security Document, 2007). The deliverable of this step should be a threat analysis report that identifies the threats that pose the most significant risk to the system. The threat report should identify areas of the surface transportation network that are widely used by the public and are vulnerable to terrorist attacks, such as multimodal transfer points, bridges, tunnels, and chokepoints. Various threat scenarios involving these identified threat areas should be explored based on one or more failures of the surface transportation network. 9.2.1.10 Identify Security Services. The next step is to select security services or countermeasures that will mitigate the threats under each threat scenario. As mentioned in Chapter 7, the National ITS Architecture includes a set of security services, interrelated with security objectives and threats and associated with specific architecture flows, that can provide a starting point for security service definition for the region. As discussed, the seven security services are confidentiality, integrity, availability, accountability, authentication, auditing, and access control. We have shown how these security services can be associated with the ITS systems (elements in the regional ITS architecture) and the interfaces (architecture or information flows in the architecture) among these systems. Each ITS system works with other ITS systems through the exchange of information on the interfaces. Each system, interface, and piece of information may require the use of a partitioned security strategy, or it may be decided that the system and all of its interfaces require the same level of security services. For example, emergency management systems are usually identified as critical assets. All information communication may be deemed sensitive, necessitating all interfacing systems to have the same level of security. 9.2.1.11 Select Security Standards. In Chapter 7 we spent considerable space discussing each of the ITS standard families and their relationship to security. It is critical that proper ITS standards are chosen with security requirements in focus (RITA, Security Document, 2007). Agencies should consider ITS and other standards that address the security services they identified in the previous section, or in other words if the information security 180 PROCESS FOR DEVELOPING A REGIONAL TRANSPORTATION SECURITY PLAN services are important requirements, select ITS and other standards that support appropriate encryption and access control. Although many message sets are being standardized to attain interoperability, incompatible security policies, requirements, and services among ITS systems have the potential to significantly hamper interoperability. Security architecture developers should consider interoperability and portability in the identified security services so that the security capabilities will be effective among the multiple jurisdictions included in a regional ITS architecture. Once developed, a regional ITS architecture with emphasis on security can support the integration of security objectives into all future transportation planning and project implementation. In particular, the security objectives, general threat analysis, security requirements, security services, and securityrelated standards defined in the previous steps of the architecture development, are all products that can be used toward project implementation in the region (RITA 2007). The key differences between ITS and traditional transportation solutions are the level of interdependency between projects and the amount of information, facilities, and infrastructure that can be shared with mutual advantage (RITA 2007). It is hoped that the new version of the Turbo Architecture Version 4.0 tool, which provides links to other architectures, will aid in the interoperability among architectures. An added feature in Version 4.0 relates general or parent elements to specific or child elements when working with multitiered architectures. 9.2.1.12 Risk Analysis. Chapter 4 explained the qualitative and quantitative concepts of different infrastructure risk assessment tools. Chapter 5 gave examples of the application of these tools under different practical scenarios for assessing and mitigating risks by identifying the relationship between risks and associated factors. Relative ranking of competing systems to be protected may require the analyst to estimate the value of the system or information to be protected; estimate the anticipated loss, including both monetary loss and intangibles, possibly annualized; and also estimate the cost of the specific security mechanisms. As discussed, a variety of tools can be used to identify the risks that should be addressed and to characterize the residual risk that will remain when the security mechanisms are implemented. The object is not to drive the residual risk to zero, because it is normally costprohibitive (and virtually impossible) to eliminate all risk and because competing operational needs must be addressed. Further, it may be necessary to modify or alter security objectives due to other operational requirements (RITA, Security Document, 2007) and their costs. This is an important point. Throughout this security analysis, it is a good idea to revisit the previous steps to make sure everything in the regional security plan is consistent, especially as security-related projects are deployed. 9.2.1.13 Define Security Mechanisms. As part of a project implementation, security mechanisms, such as access control, public key encryption, 9.2 DEVELOPING A REGIONAL TRANSPORTATION SECURITY ARCHITECTURE 181 Secure Socket Layer (SLL), Challenge-Handshake Authentication Protocol (CHAP), virtual private networks (VPN), firewalls, virus and bot protection, and intrusion detection systems, will need to be defined. The need for backup systems can require a distributed network with redundancy. Having systems and field devices IP-addressable in a private Internet-based network allows for great flexibility for distributed networking. The defined project security mechanisms implement the security services identified in the regional or project security plan. Multiple layers of security are needed for critical assets that have identified threats in order to protect the system from advanced security attacks. Since security has a cost both in real dollars and in operational efficiency, every security mechanism that is implemented should be justified. ‘‘Every security mechanism should support one or more security services, and every security service should support one or more security objectives’’ (RITA, Security Document, 2007). A benefit-cost analysis can help determine the most cost-effective security alternatives (RITA, Security Document, 2007). 9.2.1.14 Implement Security Mechanisms. The next step is to implement the identified security mechanisms. Although it is possible to implement these mechanisms in a region-wide approach supporting the architecture, it is more likely that they will be smaller and therefore applicable to ITS project security planning processes, as discussed later in this chapter. 9.2.1.15 Monitor and Revise. Vulnerabilities will always exist in a system as large and complex as a regional surface transportation system. Sometimes the vulnerabilities will be known and remain unmitigated due to cost considerations or trade-offs for operational efficiency. Other times vulnerabilities may not be identified until a system is tested or until threats evolve. To identify new vulnerabilities, organizations should establish capabilities to detect and respond to evolving security threats and actual attacks. Organizations should also work to manage single points of failure in their systems, and to implement a reporting strategy. When new vulnerabilities are identified, their presence and risks should be reflected back into the regional architecture. New and evolving stakeholders also need to be considered as the region grows. To help manage these changes to the architecture, including changes in security considerations, a configuration management process, should be established and maintained (RITA, Security Document, 2007). 9.2.2 Developing a Regional Transportation Security Architecture This section presents a process for creating a transportation security architecture without the presence of an existing regional ITS architecture using the U.S. National ITS Architecture for guidance. This type of transportation security architecture can contribute to a future regional ITS architecture by adding the security subsystems, if not already included. 182 PROCESS FOR DEVELOPING A REGIONAL TRANSPORTATION SECURITY PLAN Transportation Security Architecture Identifying Security Risks Selecting Security Services to Mitigate Risks Input from Transportation Stakeholders • Historical Data • Existing Trends • Expert Opinions Regional and National ITS Architectures Developing a Concept of Operations Developing an Implementation Plan Evaluating Architecture Figure 9.2 Developing a Regional Transportation Security Architecture. (Source: Fries et al. 2008.) As shown in Figure 9.2, a transportation security architecture can be developed in five steps, highlighting the security-related subsystems and interfaces from the National ITS architecture. Overall, this approach seeks to identify standards related to communications or interfaces between security architecture to ensure interoperability among the often-diverse transportation agencies involved and to ensure secure interconnects and information flows to prevent unauthorized use, so that the system itself remains secure (Fries et al. 2008). 9.2.2.1 Identify Security Risks. This step analyzes security risks to the regional transportation infrastructure, including three parts. The first part of this step identifies areas in the transportation network that are frequently used by the public and vulnerable to terrorist threats. These systems commonly include bridges, transit services, and tunnels. The second part identifies different threat scenarios that could lead to the failure of the selected infrastructure. Chapter 2 can assist with these first two parts. The third and final part ranks the risk scenarios from most probable to least probable in terms of their likelihood to occur. Tools from Chapters 4 and 5 can aid in this ranking of identified security risks. 9.2.2.2 Select Security Services to Mitigate Risks. This step identifies security measures to mitigate the threats from each scenario. Services can be selected from the National ITS Architecture and could include transit security and evacuation and reentry management. Chapters 3 and 7 discuss the security areas as presented in the context of the National ITS Architecture and should be reviewed during this step. 9.3 DEVELOPING A PROJECT SECURITY PLAN 183 9.2.2.3 Develop a Concept of Operations. This step identifies the roles and responsibilities of each transportation stakeholder in operating the security services, similar to Section 9.2.1.4. This step also includes identifying the information needs of each stakeholder and the communication mediums each can send and receive for transportation security threat identification. Securing these response communication mediums is of particular importance because terrorists might also try to disrupt incident response operations after an attack. 9.2.2.4 Develop an Implementation Plan. This step sets a schedule and budget for deploying key services based on priority for regional transportation security. This step should also identify funding sources and track deployment. Where significant problems or schedule deviations are encountered, the plans should be revised to keep security initiatives from being derailed. 9.2.2.5 Evaluate the Architecture. As with most engineering endeavors, evaluation should be performed to ensure that the transportation security architecture still meets the needs of the region’s transportation system as security risks, stakeholders, and technology changes. Evaluation findings can guide decision makers in the selection of future projects to meet the region’s transportation security needs (Fries et al. 2008). 9.3 DEVELOPING A PROJECT SECURITY PLAN For the ITS project level, the U.S. Department of Transportation requires that a systems engineering analysis (SEA) be performed when using funds from the Highway Trust Fund. Many different systems engineering process models have been developed over the past 30 years that define a series of steps that make up the systems engineering approach. Among these models, the V model, shown in Figure 9.3, has emerged as the de facto standard for the transportation industry to represent systems engineering for ITS projects. To improve this approach’s applicability to ITS projects, ‘‘wings’’ have been added to the V diagram to incorporate the broader ITS project life cycle into the project development process. Starting from the left wing, the figure shows the regional ITS architecture, feasibility studies and concept exploration that support primary identification and scoping of an ITS project derived from regional needs. Because the security objectives of each project should be consistent with the region’s security objectives or regional security architecture, it is important to review these sources before starting the detailed project-specific design and implementation of security mechanisms. A gap proceeds the regional architecture(s) step in the figure because the regional ITS architecture is a broader, more general product of the ITS planning process that covers all ITS projects in a given region and the subsequent steps are for a specific ITS project. The center of the diagram shows the project PROCESS FOR DEVELOPING A REGIONAL TRANSPORTATION SECURITY PLAN Operations Changes and and Maintenance Upgrades Feasibility Regional Architecture Study/Concept Exploration efin D and Detailed Design Unit/Device Testing n itio Software / Hardware Development Field Installation Implementation Development Processes eco mp osi ti Subsystem Verification tion High-Level Design gra n itio pos com De Time Line System Verification& Deployment System Reqm’ts on System Validation Concept of Operations Inte Life Cycle Processes Retirement/ Replacement and R 184 Document/Approval Figure 9.3 Systems Engineering V Diagram. (Source: FHWA, Systems Engineering for Intelligent Transportation Systems.) definition, implementation, and verification processes. The right wing contains the operations and maintenance, changes and upgrades, and eventual retirement stages of the system. Because it is important to consider the entire life cycle during project development the wings were a key addition to the V model (FHWA 2007). Central to the systems engineering approach is the notion that project concepts of operation and requirements are defined prior to making technology choices and deploying the system. On the left side of the V diagram, the system definition progresses from user needs of the system to a detailed system design. As the left side is traversed, the envisioned system follows decomposition into subsystems, with the subsystems being decomposed further into subsubsystems, sometimes called components or units. This decomposition happens at the requirements level first and then at the design level. By following this process, designers can progress through the often-complex task of designing a system that meets all of the requirements of a concept of operations. The reverse happens as the right side of the V diagram is traversed. Unit/ device testing is performed on the fully decomposed software and hardware configuration items followed by subsystem verification, which checks the functionality of each collection of units/devices. The subsystems are integrated together to support the next step of system verification and deployment. These tests prove that the system was built according to the requirements. The final test phase of the V diagram is system validation, where the system is tested against the concept of operations. A successful test proves that the proper system was designed and built to meet user needs (FHWA 2007). 9.3 DEVELOPING A PROJECT SECURITY PLAN 185 Milestones as each of the central phases of the V diagram are completed result in documentation and approval before the subsequent phase is begun. The concept of traceability between each phase of the V diagram is also important to make sure that all the requirements are met and that there is no unnecessary implementation beyond the requirements (scope creep). An excellent source for more information about systems engineering applied to ITS is the ‘‘Systems Engineering for Intelligent Transportation Systems’’ document (January 2007). For the more detailed project level (as opposed to the regional level), security planning for an ITS project is considered for the most part on the left-hand side of the V diagram, as shown in Figure 9.4. It is critical that security be considered up front in project development. The following steps are specific to ITS project security planning. Project ITS architectures should focus on the project’s security needs and its interfaces to other projects. There is often significant cost for integrating ITS systems, particularly with respect to security. In some cases, such as instituting security services across legacy ITS systems, costs may be prohibitive. In those cases, careful planning and adherence to the architecture baseline, including the regional security architecture, is needed to minimize the impact to future interoperability in the region (RITA, Security Document, 2007). It is important to reiterate that the security needs to be integrated early in the project planning phase; it is very difficult to retrofit security mechanisms into an existing project. Except for handling passwords and encryption keys, system security should not depending on the secrecy of any part of the system’s security mechanisms. It is not safe to assume that users will not be able to break into a Regional Identify Security Objectives Architecture Identify Threats Identify Critical Assets Roles and Responsibilities Feasibility Study/Concept Exploration Concept of Operations Define Security Requirements System Reqm’ts Identify Security Boundaries Isolate Critical Assets Identify Sensitive Information High-Level Design Detailed Design Software / Hardware Threat Analysis Development Risk Analysis Field Installation Identify Security Services Select Security Standards Define and Implement Security Mechanisms Figure 9.4 Steps of a Project Security Plan in Relationship to the Systems Engineering V Diagram. 186 PROCESS FOR DEVELOPING A REGIONAL TRANSPORTATION SECURITY PLAN system because they do not have information or software source code. The safest assumption is that the penetrator knows everything (Gasser 1988). 9.4 CONCLUSION This chapter presented security planning on both the regional level and the project level. Regional level security architectures can parallel the steps in creating or updating a regional ITS architecture as defined in the National ITS Architecture’s Security document or can follow the National ITS Architecture, broadening the focus to general transportation security, not specifically ITS. At the project level, further detail allowed us to explore some of the steps in more depth and their relationship to the systems engineering process shown by the V diagram. Sadly, most if not all transportation agencies are under severe financial constraints that lead to a tendency to minimize security-related functionality. ITS holds great promise for solving or helping minimize the challenges faced by transportation agencies, particularly as many ITS tools can serve multiple purposes. As the worldwide influence of ITS grows, it will become a target and is susceptible to electronic and physical threats to its mission. This chapter discussed a diverse set of general countermeasures or safeguards that improve system security, address security threats, and help to fulfill the system’s security objectives. Security is costly; generally it is an afterthought, which usually impedes interoperability and system performance. Security must to be considered at the beginning of a regional ITS security plan or ITS project, so it is adequately embedded in the deployment of ITS and other transportation assets. Security requirements set the stage for the inclusion of security throughout the systems engineering process. The security areas and securing ITS activities are most effective when they are defined at the beginning of ITS deployment. Retrofitting existing systems with security services must be done with the utmost care and sensitivity to the overall design of the project and/ or regional network. It is strongly recommended that the ITS community consider security-related ITS standards in their planning and implementation endeavors. Readers are encouraged to use additional security resources to further investigate mechanisms that implement and satisfy the security services discussed in this chapter. REFERENCES Fries, R., M. Chowdhury, and A. Dunning, 2008. ‘‘Transportation Security Framework for a Medium-Sized City.’’ European Journal of Transportation and Infrastructure Research. In press. Gasser, Morrie. 1988. Building a Secure Computer System. Van Nostrand Reinhold. National ITS Architecture Team. 2006. ‘‘Regional ITS Architecture Guidance—Developing, Using, and Maintaining an ITS Architecture for Your Region,’’ FHWA-OP-06-112, Version 2.0, July. REVIEW QUESTIONS 187 National ITS Architecture Team. 2007. ‘‘Systems Engineering for Intelligent Transportation Systems—An Introduction for Transportation Professionals,’’ FHWA-HOP-07–069, January. Office of Homeland Security. 2005. National Strategy for Homeland Security. Available online at www.dhs.gov/interweb/assetlibrary/nat_strat_hls.pdf. Research and Innovative Technology Administration (RITA). 2006. Regional ITS Architecture Guidance—Developing, Using and Maintaining an ITS Architecture for Your Region, Version 2.0 document. Research and Innovative Technology Administration (RITA). 2007. Security Document— The National ITS Architecture, Version 6.0, May. Shirey, R. 2000. ‘‘RFC 2828: Internet Security Glossary’’. Available online at ftp://ftp.isi.edu/in-notes/rfc2828.txt Shirey, R. 2000. ‘‘RFC 2828: Internet Security Glossary’’. Available online at <ftp://ftp.isi .edu/in-notes/rfc2828.txt> REVIEW QUESTIONS 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Why is securing ITS important for public safety? What are the steps in the systems engineering V diagram process? What are some of the pitfalls related to using security in agency systems? Name some of the security mechanisms that are available today. What are the three security objectives for ITS systems? Explain how to handle critical assets. Explain how risk mitigation is related to ITS security. Show the relationship of the V diagram to a project security plan. What is the toughest challenge in adding more security to ITS? What are security boundaries? Choose a local city and identify the key stakeholders to participate in developing a regional ITS architecture. CHAPTER 10 ISSUES AND OPPORTUNITIES FOR TRANSPORTATION INFRASTRUCTURE SECURITY T he surface transportation security industry has many opportunities for future growth and improvement. Key issues to be addressed include stakeholder cooperation, privacy, and funding. This chapter focuses on these issues and opportunities as they relate to surface transportation security. The topics covered include security versus privacy, the roles of the public and the private sector, stakeholder cooperation and coordination requirements, funding sources and constraints, human resources, and future directions and opportunities. 10.1 ITS SECURITY VERSUS PRIVACY There exist trade-offs between security and privacy; in most cases, more security results in less privacy. Many security measures that are implemented through intelligent transportation systems (ITS) may be potentially invasive to privacy. For example, many people may perceive a video surveillance system of a highway intersection or transit station as tracking the movements of users of the facilities, and thus invading their privacy. To address privacy issues, agencies have had to limit the pan functions of traffic cameras where residential areas were adjacent to monitored freeways and have developed Transportation Infrastructure Security Utilizing Intelligent Transportation Systems R. Fries, M. Chowdhury and J. Brummond Copyright © 2009 John Wiley & Sons, Inc. 188 10.2 PUBLIC AND PRIVATE ROLES 189 protocols to limit the view of traffic incident scenes to mere traffic flow observations. Another example includes employees trying to gain access to critical transportation infrastructure that requires a detailed personal validation process that may be construed as too invasive. Still another example is toll tag readers that have the potential of tracking and determining the whereabouts of particular vehicles and their occupants and even their speed. Because toll roads also accept cash, those who wish to remain anonymous can do so at the cost of a little extra time during toll collection. Additionally, some states have outlawed the use of tag reader information for speed ticketing, fostering this technology in a critical time of early development. Using ITS for security may be more invasive than using it only for traffic management purposes. For example, for traffic management purposes, it may be sufficient to use video cameras adjacent to the roadway to capture the image of the vehicle, not the occupant, and to discard the collected images after a certain time. Many agencies discard the tapes from camera feeds of traffic to avoid playing a role in law enforcement functions; this is the case in Phoenix, Arizona (USDOT 2000). However, by incorporating security within traffic management functions, the camera images might be used to track certain vehicles or individuals to detect unusual behavior that may indicate a harmful intention, requiring the retention of the images. Although using ITS for the dual purposes of traffic management and security poses a challenge, transportation professionals should find ways to balance security and privacy, as they have with other uses of technology. One approach could be to retain only that information required to perform the traffic management and security-related functions and to discard any unnecessary information. Another option would be to define how the tapes can be used for law enforcement, similar to how automated toll collection tag data was outlawed from speed enforcement uses. However, some people may deem some information and other details necessary for carrying out security functions too invasive or a threat to privacy. In these cases, clearly communicating the benefits of such measures in protecting lives and property may minimize many concerns. After the September 11 terrorist attack, airport security procedures have become much more invasive than prior to the attack. Because the air travelers understand that the critical measures at airports are for their security, they more or less have accepted thorough checking at airports. However, there seems to be room for continual improvement based on the perceived threats. 10.2 PUBLIC AND PRIVATE ROLES Many public and private agencies, departments, administrations, and associations shape the current and future surface transportation security industry. Their roles include passing legislation that allocates transportation funding, creating partnerships, distributing intelligence information, and ranking and selecting security-related transportation projects. 190 ISSUES AND OPPORTUNITIES FOR TRANSPORTATION INFRASTRUCTURE SECURITY Many public bodies at the federal level impact the future of transportation security. Congress and the president help set long-term goals and guide industry focus by making laws such as SAFETY-LU (Safe, Accountable, Flexible, Efficient Transportation Equity Act: A Legacy for Users). Within this legislation, security is addressed primarily in three areas: congestion management, transportation planning, and research. The category of congestion management is included because these systems already monitor transportation infrastructure in some manner and seem a natural fit for future security initiatives. The transportation planning and the research topics both mention security, and serve as suggestions for how funding in these areas may be used. Overall, SAFETYLU promotes activities in surface transportation security that use current infrastructure in congestion management, encourages planning processes that include security, and supports research into best practices for security (SAFETY-LU 2005). The U.S. Department of Transportation (DOT), part of the president’s cabinet, oversees the federal government’s interests in transportation including the Federal Highway Administration, the newly formed Research and Innovative Technology Administration (now home to the ITS Joint Program Office), the National Highway Traffic Safety Administration, and the Pipeline and Hazardous Materials Administration, to name a few. The general role of all programs under the DOT is to provide a transportation system that promotes our national interests and improves our quality of life. The Federal Highway Administration addresses transportation security with its emergency transportation operations program. With this program, the Federal Highway Administration aims to improve transportation security by focusing on: Facilitating improved communication and creating partnerships Assembling and distributing best practices Providing for education, awareness, training Engaging in research and development activities Coordinating with other federal agencies Distributing information on threats Ensuring the transportation system will support military deployments Advocating planning and preparation, and having in place a program of active management of the transportation network (FHWA 2006) The Federal Transit Administration (FTA) addresses security through its Office of Safety and Security. This office conducts transit risk and vulnerability assessments, provides security technical assistance and collaboration support, and funds security preparedness drills across the United States. These security drills serve as a valuable tool to identify and evaluate issues with transit security incident management. The FTA has identified many issues to consider when developing drills and evaluating their outcomes. Issues related to ITS or technologies include the capacity of internal and external incident alerting 10.2 PUBLIC AND PRIVATE ROLES 191 and communication systems and the calibration and proper use of substance detection tools (USDOT 2003). Another part of the executive branch of the federal government, the Department of Homeland Security, covers transportation security under the Transportation Security Administration (TSA). This administration’s role under its emergency transportation operations program includes: Receive, assess, and distribute intelligence information Assess threats to transportation Develop policies, strategies, and plans for dealing with threats Make other plans related to transportation security; Serve as liaison to the intelligence and law enforcement communities Manage and provide operational guidance to the field security resources Enforce security-related regulations and requirements Identify and undertake research and development activities Inspect, maintain, and test security facilities, equipment, and systems Ensure the adequacy of security measures for cargo Oversee the implementation and ensure adequacy of security measures Require background checks for . . . transportation security personnel Carry out such other duties, and exercise such other powers (FHWA 2005) The TSA was originally under the DOT and was moved under the Department of Homeland Security in 2003. Regardless of this move, this administration continues to oversee the national security of highways, buses, mass transit systems, railroads, ports, and airports. Much of the TSA’s recent focus has been on airports. The hope is that the TSA will focus on providing opportunities toward increased security in surface transportation modes. At the federal level, security roles are diverse. Because the transportation industry is so diverse, it is difficult to determine whether the existing U.S. government structure causes unneeded redundancy. Although a certain level of redundancy is a good practice in transportation security, opportunities exist for identifying security areas where there is too little or too much federal redundancy. While federal-level transportation agencies in the United States set the goals and funding opportunities for transportation security, state and local transportation agencies meet the daily needs of protecting infrastructure systems. These needs include not only the protection of transportation infrastructure during peacetime but providing mobility to citizens during times of emergency. State DOTs have long relied on detour routes to divert traffic around freeway crash sites. More recently, many have developed evacuation routes. These two oftenseparate planning efforts have presented an opportunity for state DOTs to integrate all of these plans into one database or plan for quick reference and implementation before, during, or after a disaster. State-level transportation agencies (either the DOT or the Department of Motor Vehicles [DMV]) issue drivers’ licenses and state identification cards. 192 ISSUES AND OPPORTUNITIES FOR TRANSPORTATION INFRASTRUCTURE SECURITY These agencies have the opportunity to work toward a standardized U.S. driver’s license, and some already have. For example, the North Carolina DOT implemented an optical variable device on all newly issued drivers’ licenses in 2006 (NCDOT 2006). Optical variable devices, similar to holograms, improve security by producing an image or code only when activated by a laser. While it is still too early to identify the direction of this trend, inconsistencies between state-issued drivers’ licenses are certainly a security issue. Standardization holds much promise for resolving these and other issues. Trade associations, which sometimes offer a blend between public and private stakeholders, also have a role in transportation security. Trade associations include the American Association of State Highway and Transportation Officials, the American Public Transportation Association, the Association of Metropolitan Planning Organizations, the Association of American Railroads, and many more. These organizations serve as a forum for promoting best practices and making contacts between the public and private sectors and between different regions of the country. These best practices and contacts serve to group transportation professionals into a cohesive assembly, all heading for common goals. Private agencies operating toll roads, bridges, and transit systems often do not have the resources to fund their own security research. These agencies have an opportunity to use the resources of federal and state governments and those of trade associations to strengthen their security practices. Although operated for profit, these agencies have similar issues with funding, solutions to security, and opportunities to learn from best practices. The public sector traditionally has had the full responsibility for monitoring the freeways, but motorists are beginning to recognize and embrace their own role as monitors. This trend is likely due to the increasing prevalence of cellular phones and has the potential to increase in coming years. Public education about the reporting of suspicious activities is key, but this type of reporting is still voluntary and is not always reliable. Public reporting presents an excellent opportunity to help secure our surface transportation infrastructure, but challenges exist. Not enough reporting can allow security breaches to occur unnoticed; too much reporting can overwhelm hotlines and response teams with false alarms. Achieving the proper amount of public reporting likely will require significant educational efforts by public agencies. Public educational efforts include the ‘‘Say Something’’ campaign started by the Massachusetts Bay Transportation Authority in 2003. This campaign seeks to encourage citizens to help protect their transit system and uses pamphlets distributed at transit stops to educate the public about what to report and how to do so (MTBA 2007). 10.3 STAKEHOLDER COOPERATION AND COORDINATION REQUIREMENTS Fostering the cooperation and coordination of stakeholders involved in transportation security parallels that of developing statewide and regional ITS 10.3 STAKEHOLDER COOPERATION AND COORDINATION REQUIREMENTS 193 architectures because it requires the participation of diverse stakeholders from varying levels of the public and private sector. To that end, previous ITS architecture endeavors will help identify the key stakeholders in the transportation industry. Further, previous transportation security architectures can prioritize transportation security initiatives and define each agency’s role in the process. Cooperation and coordination are difficult when stakeholders are asked to share either information or resources because liability, cost-sharing, and bureaucratic issues must be addressed. Two key items important to transportation security that require extensive interagency cooperation and coordination are information sharing and resource sharing. 10.3.1 Information Sharing Information sharing is one of the most critical elements in minimizing security threats. As of 2003, the U.S. Government Accountability Office made the following recommendations to the Department of Homeland Security about actions needed to improve transportation security information sharing: Developing a comprehensive and coordinated national plan to facilitate information sharing on critical infrastructure. Developing productive information sharing relationships between the federal government and state and local governments and the private sector. Providing appropriate incentives for nonfederal entities to increase information sharing with the federal government and enhance other critical infrastructure protection efforts (GAO 2003). This report focuses on real-time threat information dissemination to the appropriate transportation entities. Currently, the TSA operates the Tactical Information Sharing System, which has formalized the coordinated dissemination of transportation threat information to state and local transportation and law enforcement agencies (DHS 2007). Opportunities also exist to pass on threat information from private citizens and local transportation agencies to federal agencies. Although many other efforts continue in regard to information sharing within the transportation industry, their focus is predominantly on education. One such effort is the Federal Highway Association’s Office of Professional and Corporate Development, which operates 58 technology transfer centers throughout the United States and Puerto Rico (FHWA 2007). These centers develop and host courses that meet the needs of local and state transportation officials and represent an opportunity to disseminate transportation security best practices and foster stakeholder coordination. Because traffic cameras capture a large amount of information every day, images are not usually recorded; if they are recorded, the tapes are not saved for 194 ISSUES AND OPPORTUNITIES FOR TRANSPORTATION INFRASTRUCTURE SECURITY extensive periods (USDOT 2007). The decreasing cost of computer memory provides an opportunity for agencies operating surveillance systems, public and private, to begin recording surveillance information for possible sharing for transportation security and law enforcement purposes. As discussed, several issues hinder this information sharing. Privacy has been discussed in Section 10.1, but the staffing needs of traffic management centers might also constrain the taping of traffic camera feeds. Current staffing is sufficient for traffic management operations, but it is feared that requests for traffic camera data could require several additional personnel. 10.3.2 Resource Sharing Agreements Because infrastructure promoting surface transportation security is often expensive, resource-sharing agreements offer a valuable opportunity. Resource sharing is the partnership of organizations, often public and private, to provide mutual benefit and functionality to all involved. A common example is the installation of fiber optic lines along freeway rights-of-way. Because these rights-of-way have been in place, in many cases for 50 years, they represent some of the last undeveloped corridors available for communications infrastructure. In response, communications companies and state DOTs have ironed out agreements allowing communication companies to install equipment on DOT rights-of-way in exchange for the use of part of that communication capability. For example, a communication company agrees to install fiber optic lines along 20 miles of freeway and provides three strands for exclusive DOT use. In return, the communication company can use the remaining installed lines as it desires. Resource-sharing agreements including fiber optic lines exist throughout the United States, including the Arkansas, Colorado, Kansas, Louisiana, Massachusetts, Missouri, New Mexico, New York, Rhode Island, Wisconsin, and Wyoming Departments of Transportation (FHWA 2004). Resource-sharing agreements can also include wireless communication, such as the placement of cell phone towers on DOT property in exchange for usage rights (Chowdhury and Sadek 2003). Because transportation security requires large amounts of data, particularly from surveillance operations, communication resource sharing represents a valuable opportunity, more so than for strictly ITS projects. Other resource-sharing issues arise from the need for mass evacuations. Mutual aid agreements offer the most significant opportunity for this type of planning. In general, mutual aid agreements identify each entity involved, how the costs will be shared, and under what type of significant incidents these agreements are applicable. In the end, coordination and cooperation are heavily rooted in human relations and therefore are difficult to predict. In ideal cases, strong leaders will compromise and/or find common ground on which to begin security initiatives. 10.5 HUMAN RESOURCES 195 10.4 FUNDING SOURCES AND CONSTRAINTS It has been demonstrated that ITS use can improve safety, reduce delay, and contribute to the reduction of air pollution and energy consumption. Besides reducing travel time and improving safety, ITS technologies, both current and those that will be implemented in the future, could contribute to security. Funding for ITS infrastructure will improve transportation security, adding value to ITS projects and demonstrating a valuable opportunity. However, traditionally, roadway construction projects have been more likely to receive political and public support than ITS projects because their benefits are visible to the public (Chowdhury and Sadek 2003). Most ITS infrastructure, such as sensors and communication networks, are not in the direct view of travelers, so their presence and benefits are not intuitive. Communicating ITS benefits in both security and traffic management to the public and decision makers may bridge the gap between the reality of ITS and its perception. Funding for transportation security projects using ITS may be sought from various different sources. For example, funding may be sought through the Congestion Management and Air Quality fund, as ITS contributes to the improvement of air quality. Other funding opportunities exist from safety improvement and congestion mitigation programs, as ITS also contributes to congestion mitigation and safety. The Clarus research initiative was formed to promote the development of road weather observation and forecasting information products for improving transportation safety and is currently available online at www.clarus.mixonhill.com. This initiative builds on the partnership between the Federal Highway Administration and the National Oceanic and Atmospheric Administration to improve the safety and efficiency of commerce and safety improvements. Some of the infrastructure acquired through this program could be expanded to include security features, such as severe weather alerts. Cooperative opportunities between different state agencies, such as departments of transportation, public safety, and emergency management services, can provide opportunity to complement each other’s resources, including utilizing funding sources, to implement ITS systems for mobility as well as security. Procurement strategies may include using funding from both state and federal grants. 10.5 HUMAN RESOURCES Operators in traffic management centers are an essential part of the incident management process regardless of the new technologies constantly being developed and tested. Their role has added purpose now that traffic cameras are used for both incident detection and security surveillance. Human resources are also an issue during evacuations. In particular, a significant problem during the evacuation of New Orleans, Louisiana, before the landfall of Hurricane 196 ISSUES AND OPPORTUNITIES FOR TRANSPORTATION INFRASTRUCTURE SECURITY Katrina was securing drivers for evacuations using public transit vehicles. The Federal Transit Administration has identified the need to strengthen security and evacuation planning efforts (USDOT 2006). Smaller towns often have human resources limitations and are unable to participate in transportation technology planning meetings, which limits their voice (USDOT 1999). The same issue likely will persist in security planning processes; therefore, county governments have a responsibility to represent these smaller communities in such efforts. Because transportation security has become an additional responsibility of state highway patrol officers, freeway service patrol operators, and traffic management center employees, technology can assist these professionals in their expanding responsibilities. Technologies such as automated license plate recognition, global positioning systems, and computer-aided dispatch systems can provide the needed support to meet these new responsibilities. 10.6 FUTURE DIRECTIONS AND OPPORTUNITIES The Intelligent Transportation Society of America has documented how ITS can enhance homeland security in preparedness, prevention, protection, response, and recovery (ITS America 2002). Federal transportation departments in the United States have agreed with ITS America and transportation pundits in the assertion that ITS can contribute to transportation as well as homeland security with the inclusion of security as a major component in the National ITS Architecture (FHWA 2007). ITS concepts have begun improving transportation mobility and safety without the need for costly expansion of the transportation system. With the existing and future needs to secure our transportation systems, these same technologies can provide improved transportation security without adding more significant costs. The newer ITS technologies and concepts will expand the functionalities of security applications. For example, newer types of traffic cameras that can track a vehicle throughout a long corridor and real-time communications between cameras will provide increased functionalities in identifying a ‘‘flagged’’ vehicle that is identified as a possible threat to transportation security. Another recent concept is vehicle-highway integration, where vehicles and roadside agents communicate to provide information to vehicle occupants and receive information from vehicles on traffic and road conditions along each vehicle’s travel path. This concept may provide opportunities to use vehicles as potential information sources for identifying threats, informing drivers of imminent threats, providing evacuation guidance under the real-time changes of traffic conditions. Currently available and future technologies will lead to the improvement of security functionality using ITS infrastructure. As ITS systems are deployed beyond the urban areas, the increased geographical coverage will provide opportunities to protect rural communities, medium-size cities, and even small towns against deliberate attacks. As REFERENCES 197 terrorists recognize that large urban areas are well protected and that breaching their security may be relatively difficult, they may focus more on rural communities and medium-size cities. ITS can potentially help these communities to improve mobility and safety while providing security. Transportation professionals should make security an integral part of their overall ITS planning, design, and operation. Incorporating security at the planning stage and while developing their regional ITS architecture will help achieve the dual use of ITS: improving mobility and contributing to transportation security. The future could be promising with more ITS coverage and capabilities with the additional focus of transportation professionals to secure the surface transportation infrastructure. REFERENCES Chowdhury, M., and A. Sadek. 2003. Fundamentals of Intelligent Transportation Systems Planning. Artech House. Department of Homeland Security. 2007. ‘‘Privacy Impact Assessment for the Tactical Information Sharing System.’’ Available online at www.dhs.gov/xlibrary/assets/privacy/ privacy_pia_tsa_tiss.pdf. Federal Highway Administration. 2004. ‘‘Resource Sharing: State-by-State Status Report.’’ Available online at www.fhwa.dot.gov/REALESTATE/utilsr.htm. Federal Highway Administration. 2005. ‘‘TSA Roles and Responsibilities.’’ Available online at www.ops.fhwa.dot.gov/OpsSecurity/about/tsa_resps_slides.htm. Federal Highway Administration. 2006. ‘‘FHWA’s Role in Surface Transportation Security.’’ Available online at www.ops.fhwa.dot.gov/OpsSecurity/about/fhwa_role.htm. Federal Highway Administration. 2007. ‘‘FHWA Office of Professional and Corporate Development: Affiliate Programs.’’ Available online at www.fhwa.dot.gov/opd/ affiliateprogram.htm. Government Accountability Office. 2003. ‘‘Homeland Security: Information Sharing Responsibilities, Challenges, and Key Management Issues.’’ Testimony before the Committee on Government Reform, House of Representatives, May 8. Intelligent Transportation Society of America. 2002. ‘‘ITS and Homeland Security. Using Intelligent Transportation Systems to Improve and Support Homeland Security,’’ supplement to the ‘‘National ITS Program Plan: A Ten-Year Vision,’’ Washington, DC. Massachusetts Bay Transportation Authority. 2007. ‘‘Say Something Campaign.’’ News and Events. Available online at www.mbta.com/about_the_mbta/news_events/?id= 11143&month=3&year=07. North Carolina Department of Transportation. 2006. ‘‘Top Accomplishments for the North Carolina Department of Transportation.’’ Available online at www.ncdot.org/download/ about/goals/accomplishments_2006.pdf. SAFETY-LU. 2005. Safe, Accountable, Flexible, Efficient Transportation Equity Act: A Legacy for Users. Available online at www.fhwa.dot.gov/safetealu/legis.htm. 198 ISSUES AND OPPORTUNITIES FOR TRANSPORTATION INFRASTRUCTURE SECURITY U.S. Department of Transportation, Federal Highway Administration. 2000. ‘‘What Have We Learned about Intelligent Transportation Systems.’’ ITS Electronic Document Library. Available at www.its.dot.gov/welcome.htm. U.S. Department of Transportation, Federal Highway Administration. 2006. ‘‘Catastrophic Hurricane Evacuation Plan Evaluation: Appendix I: US DOT Evacuation-Related Responsibilities.’’ Available online at www.fhwa.dot.gov/reports/hurricanevacuation/ appendixi.htm. U.S. Department of Transportation, Federal Highway Administration. 2007. ‘‘Common Issues in Emergency Transportation Operations Preparedness and Response.’’ Available online at http://ops.fhwa.dot.gov/publications/etopr/common_issues/etopr_common_issues.pdf. U.S. Department of Transportation, Federal Transit Administration. 2003. ‘‘The Public Transportation System Security and Emergency Preparedness Planning Guide,’’ DOTFTA-MA-26-50110-03-01. U.S. Department of Transportation, Intelligent Transportation Systems Joint Program Office. 1999. Regional ITS Architecture Development, Arizona’s Rural Statewide ITS Architecture. REVIEW QUESTIONS 1. Why does using ITS to provide transportation security raise more privacy concerns than using ITS for traffic management? 2. Can privacy concerns related to ITS for transportation security be overcome? 3. What are some ways to address the privacy concerns over the use of ITS for transportation security so that they do not constrain ITS implementation? 4. Describe some innovative funding sources for implementing ITS for security. 5. Create a box and line diagram showing the relation between all of the federal agencies responsible for transportation security. 6. If you were the operator of a transit organization responsible for evacuating part of your city, how would you encourage your drivers to help with the evacuation? 7. Where is the closest transportation technology transfer center, and what is the focus of its course offerings? 8. Describe two examples of transportation resource sharing. Be sure to include the challenges to implementation and the benefits realized by each agency. APPENDIX A NATIONAL ITS ARCHITECTURE SUBSYSTEM SECURITY DESCRIPTIONS T he following descriptions of the security aspects of the subsystems of the U.S. National ITS Architecture were taken verbatim from Version 6.0 of the National ITS Architecture’s Security Document, Appendix B. The primary authors for these subsystem security descriptions were Ron Ice and Jeff Brummond with input and review by the rest of the key members of the National ITS Architecture Team. The security considerations for each of the subsystems are included here for your reference. We have also included the overall ITS Subsystem Diagram (Figure A.1, sometimes called the Sausage Diagram due to the communication links), which includes the subsystem classes and high-level communications links. A.1 SUBSYSTEM SECURITY DESCRIPTIONS The National ITS Architecture defines 22 subsystems, each of which have potential security considerations. This appendix provides a description of these potential security considerations for each subsystem. These high-level descriptions are intended to highlight the confidentiality, integrity, and availability objectives that apply to each subsystem. Because of the breadth of function and diverse nature of the processing within each subsystem, the specific security considerations for a given ITS implementation must be developed by understanding the objectives, threats, and the system vulnerabilities to these threats. Transportation Infrastructure Security Utilizing Intelligent Transportation Systems R. Fries, M. Chowdhury and J. Brummond Copyright © 2009 John Wiley & Sons, Inc. 199 200 APPENDIX A Figure A.1 National ITS Architecture Subsystem Diagram. (Source: RITA, National ITS Architecture, May 2007, www.its.dot.gov/arch/index.htm.) A.1.1 Archived Data Management The Archived Data Management Subsystem security considerations are directly related to the sensitivity of the data contained in the archive. Some ITS archives include crash reports, personal information, and other sensitive information that requires significant security safeguards. Most archives are much less sensitive, containing bulk ITS information that is not confidential and does not require special security measures. Like confidentiality, the required availability of each archive must be considered based on the archive’s application. In many, but not all, cases, archives are used for off-line applications where short-term loss of availability will not cause serious impact to the transportation system. In many cases, the most critical objective for data archives will be data integrity. Since archives are frequently used to measure performance of the transportation system and provide data that supports operations and planning, the accuracy and reliability of the data contained in the archive is paramount. Each archive should be reviewed by the system manager and data owners to ensure that security is consistent with the sensitivity of the archived data. A.1.2 Commercial Vehicle Administration The Commercial Vehicle Administration Subsystem manages credentials, financial data, border clearance, safety data, and other sensitive information. In general, the Commercial Vehicle Administration Subsystem handles personal APPENDIX A 201 and business sensitive information, such as financial data information that needs to have a relatively high degree of confidentiality in order to safeguard the information. In addition, it is important that the information is available in order to ensure that cargo is transported as safely and efficiently as possible. The integrity of the information is also important to consider in order to prevent unauthorized clearance. A.1.3 Commercial Vehicle Check The Commercial Vehicle Check Subsystem contains safety and credentials data to support electronic screening. The safety data also supports roadside safety inspections. For international borders, data from border inspection administration systems (i.e. Department of Homeland Security) supports commercial vehicle border screening. In general, the Commercial Vehicle Check Subsystem handles personal and business sensitive commercial vehicle information that needs to have a relatively high degree of confidentiality in order to safeguard the information. In addition, it is important that the information is available to support safety inspections and electronic screening for safe and efficient commercial vehicle checking. The integrity of the information is also important to consider in preventing possible deceptive screening. A.1.4 Commercial Vehicle Subsystem The Commercial Vehicle Subsystem contains screening and safety data, and is used to support roadside electronic screenings. Cargo content information should be protected from unauthorized access for knowledge of this information, especially security sensitive HAZMAT cargo, could target the vehicle for hijacking or terrorist attack. In support of driver authentication, driver identity characteristics (i.e. biometrics, Personal Identification Number (PIN)) would be stored on-board the vehicle and appropriate measures should be taken to protect this personal information. In general, the Commercial Vehicle Subsystem handles personal and business sensitive information about the commercial vehicle including container content information that needs to have a relatively high degree of confidentiality in order to safeguard the information. In addition, it is important that the information about the commercial vehicle and its cargo is available to the Commercial Vehicle Administration subsystem. The integrity of the information from the commercial vehicle is also important to prevent deceptive practices. A.1.5 Emergency Management The Emergency Management Subsystem provides critical functions that directly impact public safety. It handles sensitive information, must ‘‘operate through’’ and be available in distressed environments, and is subject to numerous threats including both physical and cyber attacks. The Emergency 202 APPENDIX A Management Subsystem represents an extremely broad group of call-taking, dispatch, command post, and operations centers. In addition to these public safety and emergency management centers, the Emergency Management Subsystem also represents private sector telematics service providers, service patrol dispatch systems, and security monitoring systems. Each of these systems has unique security vulnerabilities that must be considered in defining appropriate security services. Systems represented by the Emergency Management Subsystem operate in environments ranging from tightly controlled, secure command centers through open field environments when command posts are established in the vicinity of a major incident or disaster. The command post environment, with its reliance on wireless communications and relative lack of physical and environmental protection, has different vulnerabilities than systems operating in a fixed center. The availability requirements for an individual center must be assessed in the context of the concept of operations for the region. For example, the availability requirements for a service patrol dispatch system may not be high because the dispatch operation may be moved to an emergency operations center in times of crisis. The emergency operations center would have much more stringent availability requirements in this scenario. Similarly, the sensitivity and value of the information handled by each specific system must be evaluated to determine appropriate security safeguards for integrity and confidentiality. While it is good practice for all systems, a rigorous evaluation of security objectives, threats, vulnerabilities, and countermeasures is particularly important for each system represented by the Emergency Management Subsystem. A.1.6 Emergency Vehicle The Emergency Vehicle Subsystem (EVS) is the communications lifeline that connects emergency personnel in the field with emergency dispatch, other emergency personnel, and other resources that support emergency response. The EVS handles potentially sensitive information, must ‘‘operate through’’ and be available in distressed environments, and is exposed to numerous threats including eavesdropping (disclosure), unauthorized access or control, and disruption of services. Although confidentiality is a concern, the most critical security objectives for EVS are availability and integrity - the services and information provided by EVS must be available and accurate so that incident response is not degraded. Although the EVS provides the same basic driver communications, tracking, and routing functions that are provided by the other fleet vehicle subsystems, these functions are frequently safety critical for this subsystem since they directly impact the ability to provide an effective response to emergencies, which in turn impacts public safety. The EVS represents a wide range of vehicles including police cruisers, command vehicles, various types of fire apparatus, service patrol vehicles, ambulances, towing and recovery vehicles, and many different specialized response vehicles. This collection of vehicles may have very different security APPENDIX A 203 requirements, depending on the functions supported, the data that is stored, and the mission criticality of the services provided. For example, maintaining confidentiality of police vehicle locations is a public safety concern and frequently a key security objective. Tow vehicle locations are generally not a public safety concern, but tow truck operators may still want to prevent unauthorized vehicle location disclosure for business reasons. Finally, the current location of a service patrol vehicle may not be considered to be particularly sensitive. There are also other variables that impact security that are independent of vehicle type. For example, initial EVS data services will supplement voice communications that frequently will continue to carry all mission critical information. The security requirements for these initial implementations might be less robust until the agency gains experience with the EVS data services and begins to rely on them for mission critical information. As the role of the data services evolves and expands the security requirements and the systems themselves must be revised so that mission critical systems are available and reliable when they are needed most. The specific analysis of the security objectives, threats, vulnerabilities to those threats, and appropriate security services to address the vulnerabilities should be undertaken for systems associated with the EVS. A.1.7 Emissions Management The Emissions Management Subsystem processes vehicle emissions data and regional air quality data that are generally not sensitive to public disclosure. Also, while air quality is extremely important to everyone, the services provided by the Emissions Management Subsystem are generally not mission critical and could be lost or delayed for short periods of time without serious implications for public safety or operational efficiency of the transportation system. In most cases, normal precautions that are taken to protect data integrity will also suffice here since the threat of inadvertent or malicious tampering with data is not particularly high. There are scenarios where the security associated with Emissions Management will be more significant. For example, data integrity and confidentiality are more significant if the specific emissions management system is identifying emissions/pollution violators and collecting personal information and evidence of infractions. This information is both sensitive and subject to tampering. In most cases, system availability will not be critical, but a specific system may require higher availability if the network of sensors and data collected are relied upon to detect and report dangerous levels of pollutants or other airborne materials in emergency situations. A.1.8 Fleet and Freight Management The Fleet and Freight Management Subsystem is responsible for submitting credential applications, enrolling in international goods movement programs and 204 APPENDIX A paying tax bills, which contain personal and financial data. Driver identification information, including biometric parameters, is managed by this subsystem and it contains sensitive personal information. Since knowing freight equipment locations and cargo contents, especially security sensitive HAZMAT could lead to unintended consequences like hijackings or terrorist acts, security measures should be in place to protect this information. In general, the Fleet and Freight Management Subsystem handles personal and business sensitive information, including financial data, that needs to have a relatively high degree of confidentiality in order to safeguard the information. In addition, it is important that the location and cargo content information is available. The integrity of the information is also important to prevent deceptive practices. A.1.9 Information Service Provider The Information Service Provider security considerations are related to the sensitivity of the requests being made for information as well as the sensitivity of the information being provided. Some ISPs may charge their clients for information and services, in which case security measures should be in place to protect the client’s personal information including their credit information as well as unauthorized access to premium services. Information such as evacuation information and emergency alerts can jeopardize public safety if the information is unauthorized, inaccurate, or not delivered in a timely fashion. Traveler information that contains financial data or other highly sensitive information should have a relatively high degree of confidentiality in order to safeguard the information. In addition, it is important that traveler information is available in times of crisis. The integrity of the information is also important to prevent deceptive practices. Most traveler information will not require this level of safeguarding. A.1.10 Maintenance and Construction Management The security considerations for the Maintenance and Construction Management Subsystem relate to the physical security of transportation assets and maintenance personnel. This subsystem is involved in coordinating the response to certain incidents by dispatch, routing and allocating maintenance vehicles and other resources in coordination with other center subsystems. This subsystem collects and processes environmental sensor information from the roadside that might contribute to the detection, classification and response to security threats. In general, the Maintenance and Construction Management Subsystem’s information security needs to have a relatively low degree of confidentiality in order to safeguard the information. In addition, it is important that the information is available and has integrity in order to prevent improper reporting of assets needed to support emergencies. APPENDIX A 205 A.1.11 Maintenance and Construction Vehicle The security considerations for the Maintenance and Construction Vehicle Subsystem relate to physical security of the vehicle, operators and the roadway on which the vehicle operates. The maintenance vehicles can be mobile environmental sensing platforms that could contribute to the detection, classification and response to security threats. Maintenance vehicles might be deployed as movable barriers in response to certain security threats. In general, the Maintenance and Construction Vehicle Subsystem’s information security needs to have a relatively low degree of confidentiality in order to safeguard the information. In addition, it is important but not essential that the information is available and has integrity in order to prevent improper reporting of the vehicle’s location and sensing capabilities. A.1.12 Parking Management The primary security consideration for the Parking Management Subsystem is related to the financial information collected from the customer vehicles and exchanged with center subsystems for electronic payment processing. Additional security sensitivity is for the personal information associated with electronic accounts used for parking payment. Parking lots may be capable of uniquely identifying each vehicle that enters and exits, for the purpose of computing the correct parking fee, and this information could also be used for security purposes. High profile parking lots may require special monitoring and classification of vehicles requiring a relatively higher degree of confidentiality, availability and integrity of the information than most parking lots. A.1.13 Personal Information Access Security considerations for Personal Information Access include the measures necessary to safeguard the personal and financial information that may be entered by individual users. Personal Information Access subsystem equipment is typically privately owned and operated, and includes the use of portable or handheld devices. Devices such as these are prone to theft and misuse. Information coming from these personal devices should be authenticated to verify that the requester is who they say they are and that the information they are given is limited to the information requested or to information that is available to the public. In general, the Personal Information Access Subsystem handles personal and financial information that needs a relatively low degree of confidentiality to safeguard the information. In addition, it is important but not essential that the information is available. The integrity of the information is also important in order to prevent improper financial transactions and accessibility to unauthorized information. 206 APPENDIX A A.1.14 Remote Traveler Support The Remote Traveler Support subsystem security considerations relate to the potential locations of the types of equipment included in this subsystem. Kiosks and other publicly accessible information access points can be target areas for criminal elements trying to rob or harm travelers. As such the RTS should include appropriate physical security measures including the placement in welllit areas and the use of video and audio surveillance to secure the use of the equipment. Travelers may be using the RTS to request emergency services and measures should be in place to secure the information and ensure the availability and integrity of the system. Travelers may also be using the RTS to make reservations and trip plans that involve the transmission of personal and financial data. Those transactions should also be secured. A.1.15 Roadway The security considerations for the Roadway Subsystem (RS) are directly related to the types of field equipment that are included in a particular implementation. The RS performs a broad range of roadway network monitoring and control services and includes both safety-critical and non-safety critical systems. Safety-critical systems include traffic signal systems, gates and barriers that control facility access, and future systems that may support automated vehicle control systems. Since improper operation of these systems can directly endanger motorists, security services should be established so that these systems operate with very high levels of integrity and availability and system operation degrades in a fail-safe manner. In contrast, the information associated with operation of these systems is not confidential and typically will not need special measures to protect it from disclosure. Surveillance and environmental sensor systems provide information that may be safety critical if this information is used to monitor for incidents or dangerous road conditions. Although malicious tampering is possible, the more likely threats to sensor and surveillance information involve inadvertent loss or corruption of the provided information. Again, availability and integrity are the paramount security objectives. Although the surveillance and sensor data is generally not sensitive to disclosure, confidentially is important when CCTV cameras are zoomed in on a crash and other scenarios where individuals can be identified from the surveillance data. The driver information systems included in the RS, such as dynamic message signs and highway advisory radio, are generally not considered to be safety-critical, but have their own set of security considerations. These systems are perhaps the most likely in the RS to be the target of unauthorized access attempts and must be protected against such attacks by emphasizing security services that enhance integrity. The availability requirements associated with DMS and HAR may increase as these systems are used increasingly in critical services like Amber Alert. APPENDIX A 207 Other RS systems, including short range communications equipment, will increasingly warrant attention in the future with the advent of Vehicle Infrastructure Integration (VII)-enabled safety critical applications. These applications range from probe surveillance to intersection collision avoidance to weather advisory dissemination. Special security considerations will be needed based on the criticality of the supported applications. A.1.16 Security Monitoring The Security Monitoring Subsystem (SMS) includes surveillance and sensor equipment used to provide enhanced security and safety for transportation facilities or infrastructure. The SMS handles information used to support safe operation of the transportation system and to support emergency response. The threat sensor, object detection and infrastructure integrity monitoring equipment represented by this subsystem perform safety critical functions. Since improper operation of these systems can directly endanger motorists and communities, security services should be established so that these systems operate with very high levels of integrity and availability and system operation degrades in a failsafe manner. The information associated with operation of these systems is confidential and typically will need special measures to protect it from disclosure. Although malicious tampering is possible, the more likely threats to SMS sensor and surveillance information involve inadvertent loss or corruption of the provided information. Again, availability and integrity are the paramount security objectives. The surveillance and sensor data is not meant for public disclosure so confidentially is important. Limited processing of collected sensor and surveillance data is also included in this subsystem to support threat detection and classification. Physical security around the SMS sensors and surveillance equipment may be necessary to protect the equipment from usurpation and disruption. A.1.17 Toll Administration The primary security consideration for the Toll Administration Subsystem is related to the financial information collected from the field and exchanged between other agencies using common electronic payment media that needs to have a relatively high degree of confidentiality in order to safeguard the information. Additional security sensitivity is for the personal information associated with electronic accounts. In addition, it is important that the information is available to the Toll Administration subsystem in order to ensure that tolls are properly accounted for. The integrity of the information is also important to consider in order to prevent disruption of toll fee collection operations. A.1.18 Toll Collection The primary security consideration for the Toll Collection Subsystem relates to the financial information collected in the field that is sent to the Toll Administration Subsystem, and to any personal information associated with 208 APPENDIX A the financial transactions. Electronic toll payment needs to have a relatively high degree of confidentiality in order to safeguard the information. Additional security sensitivity is for the personal information associated with electronic accounts. In addition, it is important that the information is available from the Toll Collection subsystem to the Toll Administration subsystem in order to ensure that tolls are properly accounted for. The integrity of the information is also important to consider in order to prevent disruption of toll fee collection operations. A.1.19 Traffic Management The Traffic Management Subsystem (TMS) represents centers that control freeway systems, rural and suburban highway systems, and urban and suburban traffic control systems. This includes safety critical control of traffic signals, dynamic message signs, gates and barriers, and other traffic control equipment. It also supports important coordination with other centers to adapt traffic management to address incidents and the special needs of other systems and agencies. The majority of the information handled by the TMS is not particularly sensitive; public disclosure of DMS messages, traffic signal control plans, and the bulk of the other information managed by the TMS is not a key concern. The integrity of this information is more important since the principal threats are those that allow undetected errors or unauthorized control of field equipment. For example, errors that cause loss of control of traffic signals or malicious attacks that usurp control of a dynamic message sign. Both insider and outsider attacks must be considered in developing the overall security strategy for a traffic management center. Availability may also be important, depending on the role of the specific traffic management center in the region. State, regional, and local traffic management centers are all represented by the TMS. In addition to traditional centers, the TMS also represents portable computers and other simple solutions that allow remote monitoring and control of field equipment. Each of these implementations may have different implications for security. For example, a regional traffic management center may take control from a local traffic management center during off-hours and under special circumstances. In these types of implementations, the security-related availability requirements could be much more stringent for the regional traffic management center and the associated remote control capability than they would be for the local traffic management center. The functions performed by a specific TMC and the ability of the Roadway Subsystem to operate autonomously when the TMC is off-line are also factors that determine how critical availability is for a particular TMC. While confidentiality is not a special concern for most traffic management data, confidentiality may be important if the specific system supports speed enforcement, HOV occupancy enforcement, or other applications that identify specific vehicles and individuals and other information that must be protected from public disclosure. APPENDIX A 209 A.1.20 Transit Management The Transit Management Subsystem (TRMS) represents centers that control public transportation vehicle fleets, including buses and light and commuter rail, in rural, suburban, or urban settings. It provides operations (schedules, routes, fare structures), maintenance, customer information, planning and management functions for the transit property, and spans the central dispatch and garage management systems. Security considerations for the TRMS include safety critical control of the physical transit assets, operational security of the facilities that house the transit management center and the maintenance garage, and transit personnel security. The TRMS also supports coordination with other centers to adapt transit management to address incidents, event data, and the special needs of other systems and agencies, and to provide real-time information on current transit services. The majority of the information handled by the TRMS is not particularly sensitive; public disclosure of transit operational data, passenger loading, ridership, and vehicle maintenance data, and the bulk of the other information managed by the TRMS is not a key security concern. The integrity of this information is more important since the principal threats are those that allow undetected errors or unauthorized control of physical transit assets, i.e., buses or light rail. For example, malicious attacks on the computer system that controls light rail would be a serious security concern. Both insider and outsider attacks must be considered in developing the overall security strategy for a transit management center. Security considerations at the Transit Management Center itself should include closing and locking outside doors, badge access to outside doors, at least password control when logging onto computers, a dispatcher in-house at all times service is operational, etc. Security considerations at the garage should include badge access to outside doors, password access when logging onto the bus (including transit vehicle operator authentication by the center). From an information standpoint the primary security issues relate to financial transactions associated with electronic payment media or certain security sensitive operations, such as remote disabling of a transit vehicle during an incident such as a hijacking. A.1.21 Transit Vehicle The Transit Vehicle Subsystem (TRVS) is the communications path that connects transit personnel in the field with central dispatch at the transit management center. This subsystem provides the functions necessary to support the safe and efficient movement of passengers. Most of the information that is handled by the TRVS is not particularly sensitive except for financial transactions associated with electronic payment media, and the information flows used for operator authentication on the vehicle or remote vehicle disabling. Operator authentication is used to prevent unauthorized vehicle operation, and remote disabling is provided as one aspect of response to on-board threats. 210 APPENDIX A The security considerations for the Transit Vehicle Subsystem relate to physical security of the vehicle, transit vehicle operators, and travelers using the vehicle. The TRVS is exposed to certain threats including unauthorized access or control (hijacking) and disruption of services. Other security objectives for TRVS are availability and integrity – the services and information provided by the TRVS must be available and accurate so that transit operations are not degraded. The basic transit vehicle operator communications, tracking, and routing functions provided by the TRVS are not particularly sensitive from a security standpoint. They do not directly affect public safety – disruption of service would be mainly an inconvenience. The TRVS represents a wide range of vehicles including articulated and double-decked buses, paratransit vehicles, ferryboats, light and commuter rail, monorail vehicles, school buses, trolley buses, vans, tow trucks, shelter service trucks. This collection of vehicles may have different security requirements, depending on the functions supported, the data that is stored, and the services provided. Passenger carrying transit vehicles have additional security concerns beyond those vehicles that do not carry passengers, namely the physical security of the passengers, and the protection of financial or personal information relating to electronic fare payment systems. For example, threat sensors, surveillance, and alarms are used to identify threats on-board a vehicle, and there are confidentiality issues associated with all financial transactions. The primary security consideration for supervisory or support vehicles is the physical security of the vehicle and the vehicle operator. There are also other variables that impact security that are independent of vehicle type. For example, as new systems are deployed on a bus, the transit vehicle operator must become familiar and comfortable with their usage. Until the operator is familiar with these systems, they may be vulnerable to attack (or the information that is stored and sent to the TRMS may be vulnerable) and security may be an issue. The specific analysis of the security objectives, threats, vulnerabilities to those threats, and appropriate security services to address the vulnerabilities should be undertaken for systems associated with the TRVS. A.1.22 Vehicle The primary security consideration for the Vehicle Subsystem relates to the security of the basic vehicle and the driver and passengers in the vehicle. A vehicle Mayday capability might allow the driver or passengers to provide center subsystems with information about security threats or incidents. Various safety systems in the vehicle might protect the occupants from some security hazards. The electronic toll and parking payment capabilities expose the financial information of the owner to certain risks of unauthorized disclosure. The vehicle may anonymously broadcast its location and key sensor readings and receive critical safety information from roadside equipment. In general, the Vehicle Subsystem needs to have a relatively high degree of confidentiality in order to safeguard transmitted information. APPENDIX B SECURING ARCHITECTURE FLOWS T he following introduction to securing architecture flows as well as the architecture flow group descriptions and definitions in the U.S. National ITS Architecture were taken verbatim from the National ITS Architecture’s Version 6.0 Web site. The primary authors for this section were Ron Ice and Jeff Brummond with input and review by the rest of the key members of the National ITS Architecture Team. Chapter 7 of this book highlighted only one of these security architecture flow groups, the Emergency Security Group. This appendix includes the entire set of the 16 securing architecture flow groups your reference. The focus of the ITS Standards program is for systems to be able to seamlessly exchange information. Protecting system interfaces is critical to securing ITS. The interfaces, or architecture flows, as defined in the National ITS Architecture have been analyzed to ascertain applicable security services importance. In order to keep the security considerations for architecture flows manageable, architecture flow groupings were created for architecture flows that share similar security objectives, threats and security services Architecture flows have been placed into one of fifteen groups that are based on unique security considerations. In cases where an architecture flow could be allocated to multiple groups, the most appropriate security group was chosen. Each architecture flow group has been given typical security service, security objectives and security threat classifications of high, medium, low or minimal. Similar architecture flows are grouped together so that security services can be consistently applied. The security service classifications are based on the security objective and threat importance. For example, the combination of a high level of integrity (i.e., unauthorized modification of the information) and a Transportation Infrastructure Security Utilizing Intelligent Transportation Systems R. Fries, M. Chowdhury and J. Brummond Copyright © 2009 John Wiley & Sons, Inc. 211 212 APPENDIX B high level for the threat of deception would necessitate, among other services, a high or great need for the Access Control security service. The information content of the architecture flow coupled with its operational role was considered in the security service classifications. In some cases, the security service, objective or threat is not applicable and thus will not be in the corresponding table. The security service considerations are typical, it is incumbent on the user to tailor the security considerations as appropriate to the ITS application (e.g., sensitive archive data might require a higher classification than the nominal ‘‘Low’’ designation identified in the National ITS Architecture). The architecture flow groups are as follows: B.1 ARCHIVED DATA SECURITY GROUP The ‘‘Archived Data’’ architecture flows support data archival and retrieval. Archives may include a broad range of information with varied sensitivity. The security considerations for this group are for the general case for archives with nominal data sensitivity. Each specific archive must be evaluated so that appropriate security services can be identified, commensurate with the sensitivity and value of the information contained. TABLE B.1 Archived Data Security Group Security Services Service Importance Service Description Confidentiality Low Integrity Low Availability Low Authentication Low Access Control Low The system should prevent unauthorized disclosure of information deemed sensitive. The system should ensure that information is protected from unauthorized intentional or unintentional modifications. The system should protect critical ITS services in order to prevent degradation or denial of the ITS services to users of the services. Single points of failure should be avoided. The system should verify the identity of a user and/or other system prior to granting access to a requested resource. The system should limit access to the resources of a subsystem to only those users and other subsystems that are properly authorized. After authenticating an entity, the system should have the capability to limit system access to information or resources based on that entity’s access privileges. The system should limit software modifications and upgrades to users and other systems that have authorization. APPENDIX B 213 TABLE B.2 Archived Data Security Group Security Objectives Objective Classification Confidentiality Low Integrity Low Availability Low Class Description Information that is generally available to ITS personnel Unauthorized or unintended modification of the information could result in minor impact to the operation of the transportation system Loss of the information could result in minor impact to the operation of the transportation system. TABLE B.3 Archived Data Security Group Security Threats Threat Importance Threat Description Deception Low Disclosure Low Disruption Low A circumstance or event that may result in an authorized entity receiving false data and believing it to be true. A circumstance or event whereby an entity gains access to data for which the entity is not authorized. A circumstance or event that interrupts or prevents the correct operation of system services and functions. TABLE B.4 Archived Data Security Group Architecture Flows archive analysis requests archive coordination archive management requests archive requests archived data product requests asset archive data commercial vehicle archive data emissions archive data government reporting system data maint and constr archive data other data source archive data probe archive data toll archive data transit archive data traveler archive data archive analysis results archive management data archive request confirmation archive status archived data products border information archive data emergency archive data government reporting data receipt intermodal freight archive data multimodal archive data parking archive data roadside archive data traffic archive data transportation weather information weather archive data B.2 BUSINESS SENSITIVE SECURITY GROUP The ‘‘Business Sensitive’’ architecture flows carry information that could be deemed sensitive by a commercial firm. This information is critical to the businesses involved, and its accuracy is important to both the business and agencies that manage and monitor this information. 214 APPENDIX B TABLE B.5 Business Sensitive Security Group Security Services Service Importance Service Description Confidentiality Medium Integrity Medium Availability Medium Authentication Medium Auditing Medium Access Control Medium The system should prevent unauthorized disclosure of information deemed sensitive. The system should ensure that information is protected from unauthorized intentional or unintentional modifications. The system should protect critical ITS services in order to prevent degradation or denial of the ITS services to users of the services. Single points of failure should be avoided. The system should verify the identity of a user and/ or other system prior to granting access to a requested resource. The system should have the capability to trace ITS subsystem and individual user actions and activities. The auditing function of the system places the actions and activities in an audit trail that is protected from unauthorized access and modification. The system should limit access to the resources of a subsystem to only those users and other subsystems that are properly authorized. After authenticating an entity, the system should have the capability to limit system access to information or resources based on that entity’s access privileges. The system should limit software modifications and upgrades to users and other systems that have authorization. TABLE B.6 Business Sensitive Security Group Security Objectives Objective Classification Class Description Confidentiality Medium Integrity Medium Availability Medium Information that is sensitive and is intended for use only by specified ITS personnel Unauthorized or unintended modification of the information could result in financial loss or significantly impact the operation of the transportation system. Loss of the information could result in financial loss or significantly impact the operation of the transportation system. APPENDIX B 215 TABLE B.7 Business Sensitive Security Group Security Threats Threat Importance Deception High Disclosure High Disruption Medium Threat Description A circumstance or event that may result in an authorized entity receiving false data and believing it to be true. A circumstance or event whereby an entity gains access to data for which the entity is not authorized. A circumstance or event that interrupts or prevents the correct operation of system services and functions. TABLE B.8 Business Sensitive Security Group Architecture Flows arrival notification border clearance data border clearance event border pass/pull-in clearance notification client verification information commercial vehicle breach compliance review report credentials information daily site activity data driver log driver to fleet request electronic lock data request expected driver identity characteristics expedited clearance registration fleet to driver update freight equipment information freight transport booking intermod CVO coord intermodal freight traffic confirmation manifest receipt confirmation on-board vehicle request pre-arrival notification route deviation alert route request tag data trip declaration identifiers trip log trip log request booking status border clearance data request border clearance status breach response client id client verification request commercial vehicle disable credential application credentials status information driver alert response driver log request electronic lock data electronic screening request expedited clearance information expedited clearance status freight breach freight monitoring parameters identities intermodal freight event information manifest data on-board vehicle data pass/pull-in request tag data route plan screening event record transportation border clearance assessment trip identification number trip log information B.3 EMERGENCY SECURITY GROUP The ‘‘Emergency’’ group includes architecture flows that support emergency response and related critical public safety activities. These flows have critical availability and integrity requirements. 216 APPENDIX B TABLE B.9 Emergency Security Group Security Services Service Importance Service Description Confidentiality Medium Integrity High Availability High Accountability High Authentication High Auditing High Access Control High The system should prevent unauthorized disclosure of information deemed sensitive. The system should ensure that information is protected from unauthorized intentional or unintentional modifications. The system should protect critical ITS services in order to prevent degradation or denial of the ITS services to users of the services. Single points of failure should be avoided. The system should provide protection against a sender of an information transmission later denying that they sent the information. The system should provide protection against a receiver of an information transmission later denying that they received the information. This concept is known as NonRepudiation or Accountability. The system should verify the identity of a user and/or other system prior to granting access to a requested resource. The system should have the capability to trace ITS subsystem and individual user actions and activities. The auditing function of the system places the actions and activities in an audit trail that is protected from unauthorized access and modification. The system should limit access to the resources of a subsystem to only those users and other subsystems that are properly authorized. After authenticating an entity, the system should have the capability to limit system access to information or resources based on that entity’s access privileges. The system should limit software modifications and upgrades to users and other systems that have authorization. TABLE B.10 Emergency Security Group Security Objectives Objective Classification Class Description Confidentiality Medium Integrity High Availability High Information that is sensitive and is intended for use only by specified ITS personnel Unauthorized or unintended modification of the information could result in degradation of public safety. Loss of the information could jeapordize public safety. APPENDIX B 217 TABLE B.11 Emergency Security Group Security Threats Threat Importance Deception High Disclosure Medium Disruption High Threat Description A circumstance or event that may result in an authorized entity receiving false data and believing it to be true. A circumstance or event whereby an entity gains access to data for which the entity is not authorized. A circumstance or event that interrupts or prevents the correct operation of system services and functions. TABLE B.12 Emergency Security Group Architecture Flows alarm alarm notification alert notification coordination alerts and advisories border incident response status care facility status request commercial vehicle data decision support information emergency acknowledge emergency dispatch requests emergency notification emergency personnel information presentation emergency route request emergency transit schedule information emergency transit service response evacuation coordination fleet and freight threat information hazmat information hazmat spill notification incident command information presentation incident information for public incident notification response incident response coordination incident status maint and constr resource response public health request rail incident response status resource coordination resource request secure area sensor data suggested route threat information threat support data transit emergency data alarm acknowledge alert notification alert status border incident information care facility status commercial vehicle breach commercial vehicle data request disable commercial vehicle emergency data request emergency dispatch response emergency operations status emergency plan coordination emergency routes emergency transit service request emergency vehicle tracking data evacuation information freight breach hazmat information request incident command information coordination incident information incident notification incident report incident response status maint and constr resource request patient status public health response remote vehicle disable resource deployment status safe vehicle disable secure area surveillance data threat data for analysis threat information coordination toll advisories transit incident information 218 APPENDIX B B.4 ENFORCEMENT/CRASH REPORTING SECURITY GROUP The ‘‘Enforcement/Crash Reporting’’ architecture flows carry information about individual drivers that is used for crash reporting and enforcement applications. These flows carry sensitive information that can violate privacy principles if disclosed to unauthorized sources. B.5 FINANCIAL/PERSONAL SECURITY GROUP The ‘‘Financial/Personal’’ architecture flows can carry sensitive financial or personal information. The value of the information makes these flows subject to theft, fraud, and other disclosure threats. TABLE B.13 Enforcement/Crash Reporting Security Group Security Services Service Importance Confidentiality High Integrity Medium Availability Medium Authentication High Auditing Medium Access Control High Service Description The system should prevent unauthorized disclosure of information deemed sensitive. The system should ensure that information is protected from unauthorized intentional or unintentional modifications. The system should protect critical ITS services in order to prevent degradation or denial of the ITS services to users of the services. Single points of failure should be avoided. The system should verify the identity of a user and/or other system prior to granting access to a requested resource. The system should have the capability to trace ITS subsystem and individual user actions and activities. The auditing function of the system places the actions and activities in an audit trail that is protected from unauthorized access and modification. The system should limit access to the resources of a subsystem to only those users and other subsystems that are properly authorized. After authenticating an entity, the system should have the capability to limit system access to information or resources based on that entity’s access privileges. The system should limit software modifications and upgrades to users and other systems that have authorization. APPENDIX B 219 TABLE B.14 Enforcement/Crash Reporting Security Group Security Objectives Objective Classification Confidentiality High Integrity Medium Availability Medium Class Description Information that is extremely sensitive and is intended for use only by named individuals within a particular agency or company Unauthorized or unintended modification of the information could result in financial loss or significantly impact the operation of the transportation system. Loss of the information could result in financial loss or significantly impact the operation of the transportation system. TABLE B.15 Enforcement/Crash Reporting Security Group Security Threats Threat Importance Threat Description Deception Medium Disclosure High Disruption Low A circumstance or event that may result in an authorized entity receiving false data and believing it to be true. A circumstance or event whereby an entity gains access to data for which the entity is not authorized. A circumstance or event that interrupts or prevents the correct operation of system services and functions. TABLE B.16 Enforcement/Crash Reporting Security Group Architecture Flows accident report emissions violation notification information on violators payment violation notification request for enforcement traffic violation notification citation expected driver identity characteristics license request registration speed monitoring information violation notification B.6 MAP DATA SECURITY GROUP The ‘‘Map Data’’ architecture flows carry geospatial ‘‘map’’ information that is used in the operation of ITS. Map Data Security Group Architecture flows map update request map updates 220 APPENDIX B TABLE B.17 Financial/Personal Security Group Security Services Service Importance Confidentiality High Integrity High Availability Medium Accountability High Authentication High Auditing High Access Control High Service Description The system should prevent unauthorized disclosure of information deemed sensitive. The system should ensure that information is protected from unauthorized intentional or unintentional modifications. The system should protect critical ITS services in order to prevent degradation or denial of the ITS services to users of the services. Single points of failure should be avoided. The system should provide protection against a sender of an information transmission later denying that they sent the information. The system should provide protection against a receiver of an information transmission later denying that they received the information. This concept is known as NonRepudiation or Accountability. The system should verify the identity of a user and/or other system prior to granting access to a requested resource. The system should have the capability to trace ITS subsystem and individual user actions and activities. The auditing function of the system places the actions and activities in an audit trail that is protected from unauthorized access and modification. The system should limit access to the resources of a subsystem to only those users and other subsystems that are properly authorized. After authenticating an entity, the system should have the capability to limit system access to information or resources based on that entity’s access privileges. The system should limit software modifications and upgrades to users and other systems that have authorization. TABLE B.18 Financial/Personal Security Group Security Objectives Objective Classification Confidentiality High Integrity High Availability Medium Class Description Information that is extremely sensitive and is intended for use only by named individuals within a particular agency or company Unauthorized or unintended modification of the information could result in degradation of public safety. Loss of the information could result in financial loss or significantly impact the operation of the transportation system. APPENDIX B 221 TABLE B.19 Financial/Personal Security Group Security Threats Threat Importance Deception High Disclosure High Disruption Medium Threat Description A circumstance or event that may result in an authorized entity receiving false data and believing it to be true. A circumstance or event whereby an entity gains access to data for which the entity is not authorized. A circumstance or event that interrupts or prevents the correct operation of system services and functions. TABLE B.20 Financial/Personal Security Group Architecture Flows audit data credential fee coordination cv driver record demand responsive transit plan interactive traveler information parking reservations request payment request request for bad tag list request tag data tag update toll coordination toll instructions traffic probe data transit fare and passenger status transit fare information travel service information traveler card information traveler profile trip confirmation yellow pages request bad tag list cv driver credential cv driver record request fare collection data parking lot reservation confirmation payment registration request for payment tag data tax filing toll data request toll transactions transaction status transit fare coordination transit request confirmation travel service information request traveler card update traveler request trip request B.7 MEDIA SECURITY GROUP The ‘‘Media’’ architecture flows support distribution of information to the media. The loss or inaccuracy of this information can inconvenience the traveling public and potentially impact the reputation of the providing agency. B.8 NOT APPLICABLE SECURITY GROUP The ‘‘Not Applicable’’ group includes architecture flows that do not carry information; for example, flows that represent the physical environment. 222 APPENDIX B TABLE B.21 Map Data Security Group Security Services Service Importance Service Description Confidentiality Low Integrity Low Availability Low Authentication Low Access Control Low The system should prevent unauthorized disclosure of information deemed sensitive. The system should ensure that information is protected from unauthorized intentional or unintentional modifications. The system should protect critical ITS services in order to prevent degradation or denial of the ITS services to users of the services. Single points of failure should be avoided. The system should verify the identity of a user and/ or other system prior to granting access to a requested resource. The system should limit access to the resources of a subsystem to only those users and other subsystems that are properly authorized. After authenticating an entity, the system should have the capability to limit system access to information or resources based on that entity’s access privileges. The system should limit software modifications and upgrades to users and other systems that have authorization. TABLE B.22 Map Data Security Group Security Objectives Objective Classification Confidentiality Low Integrity Low Availability Low Class Description Information that is generally available to ITS personnel Unauthorized or unintended modification of the information could result in minor impact to the operation of the transportation system Loss of the information could result in minor impact to the operation of the transportation system. TABLE B.23 Map Data Security Group Security Threats Threat Importance Threat Description Deception Low Disruption Low A circumstance or event that may result in an authorized entity receiving false data and believing it to be true. A circumstance or event that interrupts or prevents the correct operation of system services and functions. APPENDIX B 223 TABLE B.24 Media Security Group Security Services Service Importance Service Description Integrity Low Availability Low The system should ensure that information is protected from unauthorized intentional or unintentional modifications. The system should protect critical ITS services in order to prevent degradation or denial of the ITS services to users of the services. Single points of failure should be avoided. TABLE B.25 Media Security Group Security Objectives Objective Classification Class Description Confidentiality Integrity Minimal Low Availability Low Non-sensitive information available for public release Unauthorized or unintended modification of the information could result in minor impact to the operation of the transportation system Loss of the information could result in minor impact to the operation of the transportation system. TABLE B.26 Media Security Group Security Threats Threat Importance Threat Description Deception Low Disruption Low A circumstance or event that may result in an authorized entity receiving false data and believing it to be true. A circumstance or event that interrupts or prevents the correct operation of system services and functions. TABLE B.27 Media Security Group Architecture Flows air quality information incident information for media road network conditions transit incidents for media traveler information for media external reports maint and constr work plans roadway maintenance status transit information for media work zone information TABLE B.28 Not Applicable Security Group Security Objectives Objective Classification Class Description Confidentiality Integrity Minimal Minimal Availability Minimal Non-sensitive information available for public release Unauthorized or unintended modification of the information would have negligible impact on the operation of the transportation system Loss of the information would have negligible impact on the operation of the transportation system 224 APPENDIX B TABLE B.29 Not Applicable Security Group Architecture Flows basic transit vehicle controls commercial vehicle measures crossing call CVO weight and presence driver inputs driver updates field device status presentation fleet manager inquiry identification information ISP operator inputs maint and constr field personnel information presentation maint and constr operations information presentation maint and constr vehicle control parking status pollutant levels position fix request for service roadway characteristics secure area characteristics toll operator information presentation traffic characteristics transit vehicle operator availability traveler interface updates work zone warning boarding and alighting crew movements crossing permission driver information driver parking information environmental conditions field device status request hazmat environmental factors in-vehicle transaction status maint and constr center personnel inputs maint and constr field personnel inputs maint and constr vehicle condition presentation parking operator inputs physical presence pollution data parameters request for performance data roadside transaction status route assignment toll information presentation toll operator requests transit operations status traveler inputs vehicle characteristics B.9 OPERATIONAL INFORMATION SECURITY GROUP The ‘‘Operational Information’’ architecture flows carry information that is used to support operation of the transportation system. While not intended for general public distribution, this information has no special sensitivity. Transportation system operation does rely to some degree on the information’s integrity and availability. B.10 OPERATIONAL INFORMATION—SAFETY SECURITY GROUP The ‘‘Operational Information—Safety’’ architecture flows carry information used to support operation of the transportation system that is safety critical; the loss of such information could impact public safety. The primary security considerations for these flows are ensuring the integrity and availability of the information. APPENDIX B 225 TABLE B.30 Operational Information Security Group Security Services Service Importance Service Description Confidentiality Low Integrity Low Availability Low Authentication Low Access Control Low The system should prevent unauthorized disclosure of information deemed sensitive. The system should ensure that information is protected from unauthorized intentional or unintentional modifications. The system should protect critical ITS services in order to prevent degradation or denial of the ITS services to users of the services. Single points of failure should be avoided. The system should verify the identity of a user and/ or other system prior to granting access to a requested resource. The system should limit access to the resources of a subsystem to only those users and other subsystems that are properly authorized. After authenticating an entity, the system should have the capability to limit system access to information or resources based on that entity’s access privileges. The system should limit software modifications and upgrades to users and other systems that have authorization. TABLE B.31 Operational Information Security Group Security Objectives Objective Classification Class Description Confidentiality Low Integrity Low Availability Low Information that is generally available to ITS personnel Unauthorized or unintended modification of the information could result in minor impact to the operation of the transportation system Loss of the information could result in minor impact to the operation of the transportation system. TABLE B.32 Operational Information Security Group Security Threats Threat Disruption Importance Threat Description Low A circumstance or event that interrupts or prevents the correct operation of system services and functions. 226 APPENDIX B TABLE B.33 Operational Information Security Group Architecture Flows area pollution data asset inventory asset status update current asset restrictions demand responsive transit request equipment maintenance status event information event plans field device status freeway control status hri advisories infrastructure conditions data ISP coordination lane management inputs logged vehicle routes maint and constr administrative request maint and constr equipment repair status maint and constr material information maint and constr resource request maint and constr vehicle conditions maint and constr vehicle measures maint and constr vehicle status coordination maint and constr work performance maintenance and repair needs multimodal information multimodal service data parking demand management request parking information parking lot inputs pollution state data request request for right-of-way request transit information road data road network traffic probe data roadway information system status roadway treatment system status security field equipment status signal control status storage facility request toll service change request traffic control priority status traffic images traffic probe data transit demand management request transit information request asset damage assessment asset restrictions basic vehicle measures demand response passenger and use data equipment availability event confirmation event information request fare management information field equipment status hov data hri status infrastructure monitoring sensor data ISP operations information presentation lighting system status maint and constr administrative information maint and constr dispatch status maint and constr fleet information maint and constr resource coordination maint and constr resource response maint and constr vehicle location data maint and constr vehicle operational data maint and constr vehicle system control maint and constr work plans maintenance materials storage status multimodal information request parking coordination parking demand management response parking lot data request pollution data display railroad schedules request for vehicle measures reversible lane status road network conditions roadway information system data roadway maintenance status security equipment maintenance status selected routes speed monitoring information toll probe data toll service change response traffic flow traffic information coordination transit and fare schedules transit demand management response transit multimodal information APPENDIX B 227 TABLE B.33 Continued transit probe data transit service coordination transit traveler information coordination transit vehicle loading data transit vehicle measures transit vehicle schedule performance travel service reservation request vehicle location work plan coordination work zone information work zone warning notification transit schedule information transit system data transit vehicle conditions transit vehicle location data transit vehicle operator information transportation information for operations vehicle emissions data widearea statistical pollution information work plan feedback work zone status work zone warning status TABLE B.34 Operational Information—Safety Security Group Security Services Service Importance Service Description Confidentiality Low Integrity High Availability High Accountability High Authentication High Auditing High Access Control High The system should prevent unauthorized disclosure of information deemed sensitive. The system should ensure that information is protected from unauthorized intentional or unintentional modifications. The system should protect critical ITS services in order to prevent degradation or denial of the ITS services to users of the services. Single points of failure should be avoided. The system should provide protection against a sender of an information transmission later denying that they sent the information. The system should provide protection against a receiver of an information transmission later denying that they received the information. This concept is known as NonRepudiation or Accountability. The system should verify the identity of a user and/or other system prior to granting access to a requested resource. The system should have the capability to trace ITS subsystem and individual user actions and activities. The auditing function of the system places the actions and activities in an audit trail that is protected from unauthorized access and modification. The system should limit access to the resources of a subsystem to only those users and other subsystems that are properly authorized. After authenticating an entity, the system should have the capability to limit system access to information or resources based on that entity’s access privileges. The system should limit software modifications and upgrades to users and other systems that have authorization. 228 APPENDIX B TABLE B.35 Operational Information—Safety Security Group Security Objectives Objective Classification Class Description Confidentiality Low Integrity High Availability High Information that is generally available to ITS personnel Unauthorized or unintended modification of the information could result in degradation of public safety. Loss of the information could jeopardize public safety. TABLE B.36 Operational Information—Safety Security Group Security Threats Threat Importance Threat Description Deception High Disclosure Low Disruption High A circumstance or event that may result in an authorized entity receiving false data and believing it to be true. A circumstance or event whereby an entity gains access to data for which the entity is not authorized. A circumstance or event that interrupts or prevents the correct operation of system services and functions. TABLE B.37 Operational Information—Safety Security Group Architecture Flows AHS control data AHS status alerts barrier system status commercial vehicle disable emergency traffic control information emergency vehicle alert hri operational status inspection results intersection status on-board safety data rail system status assessment road network status assessment roadway information system data safety inspection record safety inspection request safety system status short range communications status transit system status assessment transit vehicle operator authentication information transportation system status vehicle signage data AHS control information AHS vehicle data arriving train information border agency clearance results cv repair status emergency traffic control request highway control status infrastructure monitoring sensor data intersection blockage notification multimodal crossing status on-board safety request railroad advisories roadway equipment coordination safeguard system status safety inspection report safety status information screening results track status transit vehicle location data transit vehicle operator authentication update vehicle safety data vehicle to vehicle coordination APPENDIX B 229 B.11 PUBLIC SECURITY GROUP The ‘‘Public’’ group includes architecture flows that have no specific security sensitivity. These flows are not sensitive with respect to confidentiality, integrity, or availability. B.12 SECURE HUMAN INTERFACE SECURITY GROUP The ‘‘Secure Human Interface’’ architecture flows carry sensitive and safety critical data to and from operators and drivers (e.g., Mobile Data Terminal in a law enforcement vehicle). B.13 SYSTEM CONTROL SECURITY GROUP The ‘‘System Control’’ architecture flows are used to control ITS systems. These flows should be protected so that only authorized individuals or systems can control these systems. B.14 TRAVELER INFORMATION SECURITY GROUP The ‘‘Traveler Information’’ architecture flows carry traveler information, the loss of which can provide inconvenience to the traveling public and potentially impact the reputation of the providing agency. TABLE B.38 Public Security Group Security Objectives Objective Classification Class Description Confidentiality Minimal Integrity Minimal Availability Minimal Non-sensitive information available for public release Unauthorized or unintended modification of the information would have negligible impact on the operation of the transportation system Loss of the information would have negligible impact on the operation of the transportation system TABLE B.39 Public Security Group Architecture Flows broadcast advisories toll administration requests route restrictions toll data 230 APPENDIX B TABLE B.40 Secure Human Interface Security Group Security Services Service Importance Confidentiality High Integrity High Availability Medium Accountability High Authentication High Auditing High Access Control High Service Description The system should prevent unauthorized disclosure of information deemed sensitive. The system should ensure that information is protected from unauthorized intentional or unintentional modifications. The system should protect critical ITS services in order to prevent degradation or denial of the ITS services to users of the services. Single points of failure should be avoided. The system should provide protection against a sender of an information transmission later denying that they sent the information. The system should provide protection against a receiver of an information transmission later denying that they received the information. This concept is known as Non-Repudiation or Accountability. The system should verify the identity of a user and/ or other system prior to granting access to a requested resource. The system should have the capability to trace ITS subsystem and individual user actions and activities. The auditing function of the system places the actions and activities in an audit trail that is protected from unauthorized access and modification. The system should limit access to the resources of a subsystem to only those users and other subsystems that are properly authorized. After authenticating an entity, the system should have the capability to limit system access to information or resources based on that entity’s access privileges. The system should limit software modifications and upgrades to users and other systems that have authorization. B.15 TRAVELER INFORMATION—SAFETY SECURITY GROUP The ‘‘Traveler Information—Safety’’ architecture flows distribute information to the traveling public that is safety-critical. Information like evacuation information and emergency alerts can jeopardize public safety if the information is unauthorized, inaccurate, or not delivered in a timely fashion. APPENDIX B 231 TABLE B.41 Secure Human Interface Security Group Security Objectives Objective Classification Confidentiality High Integrity High Availability Medium Class Description Information that is extremely sensitive and is intended for use only by named individuals within a particular agency or company Unauthorized or unintended modification of the information could result in degradation of public safety. Loss of the information could result in financial loss or significantly impact the operation of the transportation system. TABLE B.42 Secure Human Interface Security Group Security Threats Threat Importance Deception High Disclosure High Disruption Medium Usurpation High Threat Description A circumstance or event that may result in an authorized entity receiving false data and believing it to be true. A circumstance or event whereby an entity gains access to data for which the entity is not authorized. A circumstance or event that interrupts or prevents the correct operation of system services and functions. A circumstance or event that results in control of system services or functions by an unauthorized entity. TABLE B.43 Secure Human Interface Security Group Architecture Flows alert response CVO driver initialization CVO inspector input driver identity characteristics emergency personnel inputs fleet status traffic operator data transit operations personnel inputs transit vehicle operator inputs work zone warning CVC override mode CVO inspector information CVO pass/pull-in message emergency operations inputs fleet and freight alerts incident command inputs traffic operator inputs transit vehicle operator display trip identification number input 232 APPENDIX B TABLE B.44 System Control Security Group Security Services Service Importance Service Description Integrity Medium Availability Medium Authentication Medium Auditing Medium Access Control Medium The system should ensure that information is protected from unauthorized intentional or unintentional modifications. The system should protect critical ITS services in order to prevent degradation or denial of the ITS services to users of the services. Single points of failure should be avoided. The system should verify the identity of a user and/or other system prior to granting access to a requested resource. The system should have the capability to trace ITS subsystem and individual user actions and activities. The auditing function of the system places the actions and activities in an audit trail that is protected from unauthorized access and modification. The system should limit access to the resources of a subsystem to only those users and other subsystems that are properly authorized. After authenticating an entity, the system should have the capability to limit system access to information or resources based on that entity’s access privileges. The system should limit software modifications and upgrades to users and other systems that have authorization. TABLE B.45 System Control Security Group Security Objectives Objective Classification Class Description Confidentiality Integrity Minimal Medium Availability Medium Non-sensitive information available for public release Unauthorized or unintended modification of the information could result in financial loss or significantly impact the operation of the transportation system. Loss of the information could result in financial loss or significantly impact the operation of the transportation system. TABLE B.46 System Control Security Group Security Threats Threat Importance Threat Description Deception Medium Disruption Medium Usurpation High A circumstance or event that may result in an authorized entity receiving false data and believing it to be true. A circumstance or event that interrupts or prevents the correct operation of system services and functions. A circumstance or event that results in control of system services or functions by an unauthorized entity. APPENDIX B 233 TABLE B.47 System Control Security Group Architecture Flows barrier system control emissions sensor control freeway control data hri request lighting system control data local signal priority request pollution sensor control reversible lane control safeguard system control secure area surveillance control speed monitoring control traffic control priority request vehicle control work zone warning device control data collection and monitoring control environmental sensors control hri control data infrastructure monitoring sensor control local signal preemption request maint and constr dispatch information remote surveillance control roadway treatment system control secure area sensor control signal control data traffic control coordination traffic sensor control video surveillance control TABLE B.48 Traveler Information Security Group Security Services Service Importance Service Description Integrity Low Availability Low The system should ensure that information is protected from unauthorized intentional or unintentional modifications. The system should protect critical ITS services in order to prevent degradation or denial of the ITS services to users of the services. Single points of failure should be avoided. TABLE B.49 Traveler Information Security Group Security Objectives Objective Classification Class Description Confidentiality Integrity Minimal Low Availability Low Non-sensitive information available for public release Unauthorized or unintended modification of the information could result in minor impact to the operation of the transportation system Loss of the information could result in minor impact to the operation of the transportation system. TABLE B.50 Traveler Information Security Group Security Threats Threat Importance Threat Description Deception Low Disruption Low A circumstance or event that may result in an authorized entity receiving false data and believing it to be true. A circumstance or event that interrupts or prevents the correct operation of system services and functions. 234 APPENDIX B TABLE B.51 Traveler Information Security Group Architecture Flows air quality information broadcast traveler information interactive traveler information road network conditions transit information user request transit traveler request traveler inputs trip confirmation trip request voice-based traveler information yellow pages information border crossing status information fare and price information personal transit information toll data transit traveler information travel service reservations traveler request trip plan vehicle signage data voice-based traveler request yellow pages request TABLE B.52 Traveler Information—Safety Security Group Security Services Service Importance Confidentiality Low Integrity Medium Availability Medium Authentication Medium Auditing Medium Access Control Medium Service Description The system should prevent unauthorized disclosure of information deemed sensitive. The system should ensure that information is protected from unauthorized intentional or unintentional modifications. The system should protect critical ITS services in order to prevent degradation or denial of the ITS services to users of the services. Single points of failure should be avoided. The system should verify the identity of a user and/ or other system prior to granting access to a requested resource. The system should have the capability to trace ITS subsystem and individual user actions and activities. The auditing function of the system places the actions and activities in an audit trail that is protected from unauthorized access and modification. The system should limit access to the resources of a subsystem to only those users and other subsystems that are properly authorized. After authenticating an entity, the system should have the capability to limit system access to information or resources based on that entity’s access privileges. The system should limit software modifications and upgrades to users and other systems that have authorization. APPENDIX B 235 TABLE B.53 Traveler Information—Safety Security Group Security Objectives Objective Classification Confidentiality Low Integrity Medium Availability Medium Class Description Information that is generally available to ITS personnel Unauthorized or unintended modification of the information could result in financial loss or significantly impact the operation of the transportation system. Loss of the information could result in financial loss or significantly impact the operation of the transportation system. TABLE B.54 Traveler Information—Safety Security Group Security Threats Threat Importance Threat Description Deception Medium Disruption Medium A circumstance or event that may result in an authorized entity receiving false data and believing it to be true. A circumstance or event that interrupts or prevents the correct operation of system services and functions. TABLE B.55 Traveler Information—Safety Security Group Architecture Flows emergency traveler information shelter information voice-based alert notification emergency traveler information request vehicle signage data B.16 WEATHER/ENVIRONMENTAL SECURITY GROUP The ‘‘Weather/Environmental’’ architecture flows carry weather and environmental information that is used for operational purposes. This is generally public information, but it must be accurate and available to support transportation system operation. 236 APPENDIX B TABLE B.56 Weather/Environmental Security Group Security Services Service Importance Integrity Low Availability Low Service Description The system should ensure that information is protected from unauthorized intentional or unintentional modifications. The system should protect critical ITS services in order to prevent degradation or denial of the ITS services to users of the services. Single points of failure should be avoided. TABLE B.57 Weather/Environmental Security Group Security Objectives Objective Classification Class Description Confidentiality Integrity Minimal Low Availability Low Non-sensitive information available for public release Unauthorized or unintended modification of the information could result in minor impact to the operation of the transportation system Loss of the information could result in minor impact to the operation of the transportation system. TABLE B.58 Weather/Environmental Security Group Security Threats Threat Importance Threat Description Deception Low Disruption Low A circumstance or event that may result in an authorized entity receiving false data and believing it to be true. A circumstance or event that interrupts or prevents the correct operation of system services and functions. TABLE B.59 Weather/Environmental Security Group Architecture Flows environmental conditions data environmental probe data qualified environmental conditions data road weather information transportation weather information request environmental conditions data status environmental sensor data road network environmental probe data transportation weather information weather information APPENDIX C USDOT FHWA FINAL RULE T he following is the United States Department of Transportation Federal Highway Administration’s Final Rule on ITS Architecture and Standards verbatim from the Federal Register for your reference. This rule applies to ITS projects funded in part by the Highway Trust Fund as well as requiring regional ITS architectures as mentioned in Chapter 9 of this book. C.1 PREFACE Monday, January 8, 2001 Part IV Department of Transportation Federal Highway Administration 23 CFR Parts 655 and 940 Intelligent Transportation System Architecture and Standards; Final Rule Federal Transit Administration Federal Transit Administration National ITS Architecture Policy on Transit Projects; Notice 1446 Federal Register/Vol. 66, No. 5/Monday, January 8, 2001/Rules and Regulations C.2 SUMMARY The purpose of this document is to issue a final rule to implement section 5206(e) of the Transportation Equity Act for the 21st Century (TEA–21), enacted on June 9, 1998, which required Intelligent Transportation System (ITS) projects funded through the highway trust fund to conform to the Transportation Infrastructure Security Utilizing Intelligent Transportation Systems R. Fries, M. Chowdhury and J. Brummond Copyright © 2009 John Wiley & Sons, Inc. 237 238 APPENDIX C National ITS Architecture and applicable standards. Because it is highly unlikely that the entire National ITS Architecture would be fully implemented by any single metropolitan area or State, this rule requires that the National ITS Architecture be used to develop a local implementation of the National ITS Architecture, which is referred to as a ‘‘regional ITS architecture.’’ Therefore, conformance with the National ITS Architecture is defined under this rule as development of a regional ITS architecture within four years after the first ITS project advancing to final design, and the subsequent adherence of ITS projects to the regional ITS architecture. The regional ITS architecture is based on the National ITS Architecture and consist of several parts including the system functional requirements and information exchanges with planned and existing systems and subsystems and identification of applicable standards, and would be tailored to address the local situation and ITS investment needs. EFFECTIVE DATE: February 7, 2001. FOR FURTHER INFORMATION CONTACT: For technical information: Mr. Bob Rupert, (202) 366–2194, Office of Travel Management (HOTM–1) and Mr. Michael Freitas, (202) 366–9292, ITS Joint Program Office (HOIT–1). For legal information: Mr. Wilbert Baccus, Office of the Chief Counsel (HCC–32), (202) 366–1346, Federal Highway Administration, 400 Seventh Street, SW., Washington, DC 20590. Office hours are from 8 a.m. to 4:30 p.m., e.t., Monday through Friday, except Federal holidays. C.3 ELECTRONIC ACCESS AND FILING You may submit or retrieve comments online through the Docket Management System (DMS) at: http//dmses.dot.gov/submit. Acceptable formats include: MS Word (versions 95 to 97), MS Word for Mac (versions 6 to 8), Rich Text Format (RTF), American Standard Code Information Interchange (ASCII) (TXT), Portable Document Format (PDF), and WordPerfect (version 7 to 8). The DMS is available 24 hours each day, 365 days each year. Electronic submission and retrieval help and guidelines are available under the help section of the web site. An electronic copy of this document may be downloaded by using a computer, modem, and suitable communications software from the Government Printing Office’s Electronic Bulletin Board Service at (202) 512–1661. Internet users may also reach the Office of the Federal Register’s home page at http:// www.nara.gov/fedreg and the Government Printing Office’s web page at: http://www.access.gpo.gov/nara. The document may also be viewed at the DOT’s ITS web page at http://www.its.dot.gov. C.4 BACKGROUND A notice of proposed rulemaking (NPRM) concerning this rule was published at 65 FR 33994 on May 25, 2000, and an extension of the comment period to September 23, 2000, was published at 65 FR 45942 on July 26, 2000. APPENDIX C 239 In the NPRM on this rule, the FHWA had proposed that the regional ITS architecture follow from the ITS integration strategy proposed in another NPRM entitled ‘‘Statewide Transportation Planning; Metropolitan Transportation Planning’’ published at 65 FR 33922 on May 25, 2000. That rule is being developed according to a different schedule and will be issued separately. For this reason, all references to the proposed integration strategy have been removed from this rule. However, it is still the intent of this rule that regional ITS architectures be based on established, collaborative transportation planning processes. The other major changes to the final rule relate to options for developing a regional ITS architecture and the time allowed to develop such an architecture. Additional changes to the final rule largely deal with clarification of terms, improved language dealing with staging and grandfathering issues, and clarification of use of ITS standards. Intelligent Transportation Systems represent the application of information processing, communications technologies, advanced control strategies, and electronics to the field of transportation. Information technology in general is most effective and cost beneficial when systems are integrated and interoperable. The greatest benefits in terms of safety, efficiency, and costs are realized when electronic systems are systematically integrated to form a whole in which information is shared with all and systems are interoperable. In the transportation sector, successful ITS integration and interoperability require addressing two different and yet fundamental issues; that of technical and institutional integration. Technical integration of electronic systems is a complex issue that requires considerable up-front planning and meticulous execution for electronic information to be stored and accessed by various parts of a system. Institutional integration involves coordination between various agencies and jurisdictions to achieve seamless operations and/or interoperability. In order to achieve effective institutional integration of systems, agencies and jurisdictions must agree on the benefits of ITS and the value of being part of an integrated system. They must agree on roles, responsibilities, and shared operational strategies. Finally, they must agree on standards and, in some cases, technologies and operating procedures to ensure interoperability. In some instances, there may be multiple standards that could be implemented for a single interface. In this case, agencies will need to agree on a common standard or agree to implement a technical translator that will allow dissimilar standards to interoperate. This coordination effort is a considerable task that will happen over time, not all at once. Transportation organizations, such as, transit properties, State and local transportation agencies, and metropolitan planning organizations must be fully committed to achieving institutional integration in order for integration to be successful. The transportation agencies must also coordinate with agencies for which transportation is a key, but not a primary part of their business, such as, emergency management and law enforcement agencies. Successfully dealing with both the technical and institutional issues requires a high-level conceptual view of the future system and careful, 240 APPENDIX C comprehensive planning. The framework for the system is referred to as the architecture. The architecture defines the system components, key functions, the organizations involved, and the type of information shared between organizations and parts of the system. The architecture is, therefore, fundamental to successful system implementation, integration, and interoperability. Additional background information may be found in docket number FHWA–99–5899. C.5 THE NATIONAL ITS ARCHITECTURE The Intermodal Surface Transportation Efficiency Act of 1991, Public Law 102–240, 105 Stat. 1914, initiated Federal funding for the ITS program. The program at that time was largely focused on research and development and operational tests of technologies. A key part of the program was the development of the National ITS Architecture. The National ITS Architecture provides a common structure for the design of ITS systems. The architecture defines the functions that could be performed to satisfy user requirements and how the various elements of the system might connect to share information. It is not a system design, nor is it a design concept. However, it does define the framework around which multiple design approaches can be developed, each one specifically tailored to meet the needs of the user, while maintaining the benefits of a common approach. The National ITS Architecture, Version 3.0 can be obtained from the ITS Joint Program Office of the DOT in CD–ROM format and on the ITS web site http://www.its.dot.gov. The effort to develop a common national system architecture to guide the evolution of ITS in the United States over the next 20 years and beyond has been managed since September 1993 by the DOT. The National ITS Architecture describes in detail what types of interfaces should exist between ITS components and how they will exchange information and work together to deliver the given ITS user service requirements. The National ITS Architecture and standards can be used to guide multilevel government and private-sector business planners in developing and deploying nationally compatible systems. By ensuring system compatibility, the DOT hopes to accelerate ITS integration nationwide and develop a strong, diverse marketplace for related products and services. It is highly unlikely that the entire National ITS Architecture will be fully implemented by any single metropolitan area or State. For example, the National ITS Architecture contains information flows for an Automated Highway System that is unlikely to be part of most regional implementations. However, the National ITS Architecture has considerable value as a framework for local governments in the development of regional ITS architectures by identifying the many functions and information sharing opportunities that may be desired. It can assist local governments with both of the key elements: technical interoperability and institutional coordination. APPENDIX C 241 The National ITS Architecture, because it aids in the development of a highlevel conceptual view of a future system, can assist local governments in identifying applications that will support their future transportation needs. From an institutional coordination perspective, the National ITS Architecture helps local transportation planners to identify other stakeholders who may need to be involved and to identify potential integration opportunities. From a technical interoperability perspective, the National ITS Architecture provides a logical and physical architecture and process specifications to guide the design of a system. The National ITS Architecture also identifies interfaces where standards may apply, further supporting interoperability. C.6 TRANSPORTATION EQUITY ACT FOR THE 21ST CENTURY As noted above, section 5206(e) of the TEA–21, Public Law 105–178, 112 Stat. 457, requires ITS projects funded from the highway trust fund to conform to the National ITS Architecture, applicable or provisional standards, and protocols. One of the findings of Congress in section 5202 of the TEA–21, is that continued investment in systems integration is needed to accelerate the rate at which ITS is incorporated into the national surface transportation network. Two of the purposes of the ITS program, noted in section 5203(b) of the TEA– 21, are to expedite the deployment and integration of ITS, and to improve regional cooperation and operations planning for effective ITS deployment. Use of the National ITS Architecture provides significant benefits to local transportation planners and deployers as follows: 1. The National ITS Architecture provides assistance with technical design. It saves considerable design time because physical and logical architectures are already defined. 2. Information flows and process specifications are defined in the National ITS Architecture, allowing local governments to accelerate the process of defining system functionality. 3. The architecture identifies standards that will support interoperability now and into the future, but it leaves selection of technologies to local decision makers. 4. The architecture provides a sound engineering framework for integrating multiple applications and services in a region. C.7 ITS ARCHITECTURE AND STANDARDS NPRM DISCUSSION OF COMMENTS The FHWA received 105 comments on this docket from a wide range of stakeholders, including major industry associations, State departments of transportation, Metropolitan Planning Organizations (MPOs), and local 242 APPENDIX C agencies. The comments were generally favorable about the scope and content, but requested additional clarification and guidance on implementation of specific items. On many issues, some commenters wanted more specific requirements, while others wanted more flexibility. Most commenters, including major industry associations and public sector agencies, agreed with the overall scope, but some felt that the specifics might be difficult to implement and asked for clarification of key terms. A few commenters wanted the FHWA to reduce the number of requirements or convert the rulemaking into a guidance activity until more ITS deployment experience is gained. In summary, the FHWA received a large number of generally favorable comments about the NPRM that suggested minor specific changes and expressed a need for further guidance on implementation. Since the general tenor of the comments was positive, the FHWA has kept the scope of the NPRM and made appropriate clarifications to the text of the final rule to address concerns raised in comments. In response to the many comments requesting it, starting in early 2001, the FHWA will also provide a program of guidance, training, and technical support to assist with the implementation of this rule. The following is a detailed discussion of the comments and their disposition, organized by subject matter. C.7.1 Final Rule Section 940.3: Definitions ITS Project. There were 34 comments submitted to the docket concerning the definition of an ITS project. Many of the commenters felt the definition was not clear enough, was too broad, or was too subject to interpretation. Some comments questioned how much of a project’s budget would have to be spent on ITS before a project would be considered an ITS project. Some suggested specific language to more narrowly define an ITS project by focusing on the portion of the overall project that is actually ITS or by suggesting language that would narrow the definition of an ITS project to only include projects which introduce new or changed integration opportunities. Since the intent of this rule and the supporting legislation is to facilitate the deployment of integrated ITS systems, it is the position of the FHWA that the definition of an ITS project must be fairly broad to include any ITS system being funded with highway trust fund dollars. It is only by properly considering all planned ITS investments in the development of a regional ITS architecture that the integration opportunities and needs can even be identified. This consideration should be carried out in the development of an architecture prior to the specific project being advanced. If, in the development of a regional ITS architecture, it is determined that a specific planned project offers no real integration opportunities for the region, then the impact of this rule on that specific project is minimal. As a response to the comments concerning the clarity of the definition, the definition of an ITS project has been slightly modified to remove the examples since they were considered misleading. The FHWA recognizes that any APPENDIX C 243 definition will be subject to interpretation by the stakeholders and acknowledges the need for guidance in this area to ensure clear and consistent interpretation of this rule. Guidance on what constitutes an ITS project (including examples) will be developed to assist the various stakeholders, including the FHWA Division Offices, to better understand what projects should be considered ITS projects. Region. There were 26 comments submitted related to the definition of a region. Seven comments supported the open definition provided in the NPRM, arguing that the possible integration opportunities in an area should define the region and that there were too many possible variations to allow a restrictive definition. Six commenters who expressed concern over varying conditions interpreted the definition to mean Metropolitan Planning Area (MPA). Five comments suggested an MPA was too restrictive. Eight other comments indicated that the proposed definition of a region did not clearly identify what entity would have the lead in developing a regional ITS architecture or thought the definition implied the MPO should have the lead. Nine comments suggested various limits or boundaries to fit specific situations. Ten comments expressed a need for greater clarification of the definition for a region. The intent of the proposed definition was to allow considerable flexibility on the part of the stakeholders in defining the boundaries of a region to best meet their identified integration opportunities. While there was no intent to generally restrict the definition to MPAs or States, the FHWA determined that regional ITS architectures should be based on an integration strategy that was developed by an MPO or State as part of its transportation planning process. Given that the final rule does not require or reference an integration strategy, the FHWA feels a need to provide more specific guidance on the definition of a region. As such, the definition of a region has been revised to indicate that the MPA should be the minimum area considered when establishing the boundaries of a region for purposes of developing a regional ITS architecture within a metropolitan area. This should not be interpreted to mean that a region must be an MPA, or no less than an MPA, but the MPA and all the agencies and jurisdictions within the MPA should be at least considered for inclusion in the process of developing a regional ITS architecture within a metropolitan area. This rule is silent on other possible limits or minimum areas for defining a region, relying on the flexible nature of this rule to accommodate those special circumstances. The FHWA also acknowledges it is possible that overlapping regions could be defined and overlapping regional ITS architectures be developed to meet the needs of the regions. Other Definitions. There were 20 comments suggesting that other terms used in the NPRM be defined. These included ‘‘interoperability,’’ ‘‘standards,’’ ‘‘concept of operations,’’ ‘‘conceptual design,’’ and ‘‘integration strategy.’’ Several of these are no longer used in the final rule and, therefore, were not defined. Other terms, such as ‘‘interoperability’’ and ‘‘standards,’’ were determined to be common terms whose definition did not effect the implementation 244 APPENDIX C of the final rule. Furthermore, language regarding standards conformity has been clarified in the body of the final rule. C.7.2 Final Rule Section 940.5: Policy Twenty-eight commenters addressed the issue of consistency between the two related FHWA notices of proposed rulemaking (23 CFR parts 940 and 1410) and the Federal Transit Administration’s (FTA) notice (FTA Docket No. FTA– 99–6417) on National ITS Architecture published at 65 FR 34002 on May 25, 2000. The comments revealed a lack of understanding about the relationship between the regional ITS architecture and the integration strategy proposed as part of the revisions to FHWA’s transportation planning rules. There were five comments suggesting a single DOT rule addressing how all ITS projects would meet the National ITS Architecture conformance requirements of the TEA–21 instead of an FHWA rule for highway projects and an FTA policy for transit projects. Four other comments acknowledged the need for two policies, but recommended they articulate the same process. A final transportation planning rule is being developed on a different schedule than this rule, and comments regarding the portions of the National ITS Architecture conformity process included in the transportation planning rule will be addressed as it proceeds toward issuance. The FHWA and FTA have chosen to go forward with policies that have been developed cooperatively to implement the National ITS Architecture conformance process. This FHWA rule and the parallel FTA policy have been developed without reference to the proposed changes to the transportation planning process, including no mention of the development of an integration strategy. However, the policy statement of this rule notes a link to established transportation planning processes, as provided under 23 CFR part 450. This rule fully supports these collaborative methods for establishing transportation goals and objectives, and does not provide a mechanism for introducing projects outside of the transportation planning processes. This final rule on National ITS Architecture conformance and the FTA policy on the same subject have been developed cooperatively and coordinated among the agencies to ensure compatible processes. Any differences between this rule and the parallel FTA policy are intended to address differences in highway and transit project development and the way the FHWA and the FTA administer projects and funds. Fifteen commenters questioned the need for an integration strategy, and the relationship between the strategy and the regional ITS architecture. Given the fact that proposed revisions to the FHWA’s transportation planning rules are being developed according to a different schedule, this rule has been revised to remove any references to an integration strategy. Comments regarding the integration strategy will be addressed in the final transportation planning rule, and the discussion of the regional ITS architecture in § 940.9 has been revised to clarify its content. APPENDIX C 245 C.7.3 Final Rule Section 940.7: Applicability A few commenters noted that the proposed rule had not addressed the TEA–21 language that allows for the Secretary to authorize certain exceptions to the conformity provision. These exceptions relate to those projects designed to achieve specific research objectives or, if three stated criteria are met, to those intended to upgrade or expand an ITS system in existence on the date of enactment of the TEA–21. The legislation also included a general exemption for funds used strictly for operations and maintenance of an ITS system in existence on the date of enactment of the TEA–21. The FHWA acknowledges this omission and has included the appropriate language in this section of the rule. C.7.4 Final Rule Section 940.9: Regional ITS Architecture Several comments were received related to the way the proposed rule referred to developing regional ITS architectures. Eight comments, from State agencies and metropolitan planning organizations, supported an incremental approach to developing regional ITS architectures, starting with project ITS architectures and building them together. Four other comments, from metropolitan planning organizations and industry associations, noted that an ad hoc regional ITS architecture developed incrementally through projects would result in an architecture less robust than if there were a single, initial effort to develop it. Also, thirteen comments from the Association of American State Highway and Transportation Officials (AASHTO) and a number of States recommended extending the time for developing regional ITS architectures, as the proposed two year implementation would be too short. Ten of the commenters preferred four years in order to acquire the necessary resources for developing regional ITS architectures. Most commenters were in agreement with the content of the regional ITS architecture as defined in the proposed rule. However, there were 19 comments that dealt with confusion over the definition of both ‘‘conceptual design’’ and ‘‘concept of operations.’’ In addition, there were 17 other comments on the makeup of the stakeholders, involvement of the private sector, and the need and desirability of ‘‘agreements’’ between stakeholders. The comments indicated confusion regarding the development of regional ITS architectures, and especially so in discussing the period of time for their development. Therefore, the final rule has clarified the time period for developing regional ITS architectures by adopting the proposed extension to four years subsequent to beginning to deploy ITS projects (§ 940.9(c)), or four years from the effective date of this rule for those areas that are currently deploying ITS projects (§ 940.9(b)). In clarifying the time for development, this rule has eliminated any references to specific methods for developing regional ITS architectures. By not prescribing any methods, the rule provides flexibility to a region in deciding how it should develop its regional ITS architecture. 246 APPENDIX C Guidance and information related to developing regional ITS architectures is available from FHWA Division Offices and from the ITS web site, http:// www.its.dot.gov, and will be expanded to provide assistance in meeting the intent of the rule. Both the terms ‘‘conceptual design’’ and ‘‘concept of operations’’ have been deleted from the final rule. In their stead are descriptions of the content that is expected to form the basis for a regional ITS architecture. This content has not significantly changed from that defined in the NPRM but is now contained in § 940.9(d). The level of detail required is to the architecture flow level as defined in the National ITS Architecture. The regional ITS architecture must identify how agencies, modes, and systems will interact and operate if the architecture is to fulfill the objective of promoting ITS integration within a region. The relevant stakeholders for a region will vary from region to region. The list articulated in § 940.9(a) is representative only and not meant to be inclusive or exclusive. On the specific issue of private sector participation, if the private sector is deploying ITS systems in a region or otherwise providing an ITS-based service, it would be appropriate to engage them in the development of a regional ITS architecture. Because of these variations from region to region, the FHWA felt it inappropriate to attempt to define an all inclusive list of stakeholders. The group of relevant stakeholders will be a function of how the region is defined and how transportation services are provided to the public. Section 940.9(d) (4) specifies that in the development of the regional ITS architecture, it shall include ‘‘any agreements (existing or new) required for operations.’’ The formalization of these types of agreements is at the discretion of the region and participating stakeholders. There were 14 comments from a broad range of organizations questioning how existing regional ITS architectures, strategic plans or ITS Early Deployment Plans would be treated under this rule. It is the intent of the FHWA that any existing ITS planning documents should be used to the extent practical to meet the requirements of this rule. If a regional ITS architecture is in place, is up to date, and addresses all the requirements of a regional ITS architecture as described in this rule, there is no requirement to develop a ‘‘new’’ one. If the existing regional ITS architecture does not address all the requirements of the rule, it may be possible to update it so that it meets the regional ITS architecture requirements of this rule. What is necessary is that the end result is an architecture that meets the requirements of this rule and properly addresses the ITS deployments and integration opportunities of that region. This issue is specifically addressed in § 940.9(e) of this rule. There were five comments related to the impact of this rule on legacy systems (i.e., ITS systems already in place) and requesting some sort of ‘‘grandfathering’’ for them. The language in § 940.11(g) of the final rule clarifies the grandfathering or staging aspects of the process. The final rule does not require any changes or modifications to existing systems to conform to the National ITS Architecture. It is very likely that a regional ITS architecture developed by the local agencies and other stakeholders would call for changes APPENDIX C 247 to legacy systems over time to support desired integration. However, such changes would not be required by the FHWA; they would be agreed upon by the appropriate stakeholders as part of the development of the regional ITS architecture. There were 15 comments dealing with the maintenance process and status of the National ITS Architecture. Two comments suggested the need for the FHWA to formally adopt the National ITS Architecture. Four other comments also supported the formalization of a process for maintaining or updating it with the full opportunity for public input. Conformance with the National ITS Architecture is interpreted to mean the use of the National ITS Architecture to develop a regional ITS architecture, and the subsequent adherence of all ITS projects to that regional ITS Architecture. This rule requires that the National ITS Architecture be used as a resource in developing a regional ITS architecture. As a technical resource, it is important that the National ITS Architecture be maintained and updated as necessary in response to user input or to add new user services, but formal adoption of the National ITS Architecture is not necessary. However, the FHWA recognizes the need to maintain the National ITS Architecture and to establish an open process for configuration control that includes public participation. The process currently used by the DOT to maintain the National ITS Architecture is very rigorous and involves significant public participation. That process is currently being reviewed by the DOT with the intent of establishing a configuration management process that engages the public at key stages and ensures a consensus for updating the National ITS Architecture. Four comments suggested that this rule should not be implemented until the National ITS Architecture was complete. The National ITS Architecture will never stop evolving since there always is a potential need to regularly update it as more is learned about ITS deployment. The FHWA believes the National ITS Architecture is developed to a stage where it can be used as a resource in developing regional ITS architectures, as required by this rule. Seventeen comments asked the FHWA to define the agency that is responsible for the development and maintenance of the regional ITS architecture; specifically MPOs and/or the State as those entities that are already responsible for the planning process. The FHWA did not define the responsibility for either creating or maintaining the regional ITS architecture to a specific entity because of the diversity of transportation agencies and their roles across the country. It is recognized that in some regions traditional State and MPO boundaries may not meet the needs of the traveling public or the transportation community. This is also why the FHWA did not rigidly define a region. The FHWA encourages MPOs and States to include the development of their regional ITS architectures as part of their transportation planning processes. However, the decision is best left to the region to determine the approach that best reflects their needs, as indicated in § 940.9. It is clear that the value of a regional ITS architecture will only be 248 APPENDIX C realized if that architecture is maintained through time. However, in accepting federal funds under title 23, U.S.C., the State is ultimately responsible for complying with Federal requirements, as provided in 23 U.S.C. 106 and 133. Four commenters noted that the proposed rule did not adequately address planning for, or committing to, a defined level of operations and maintenance. The final rule addresses this concern on two primary levels, in the development of the regional ITS architecture and the development of individual projects. Section 940.9(d) (4) specifies that in the development of the regional ITS architecture, it shall include ‘‘any agreements (existing or new) required for operations.’’ The formalization of these types of agreements is at the discretion of the region and participating stakeholders. Also, relative to operations and management at a project level, § 940.11(c) (7) specifies that the systems engineering analysis (required of all ITS projects) includes ‘‘procedures and resources necessary for the operations and management of the system.’’ C.7.5 Final Rule Section 940.11 Project Implementation In addition to the comments on regional ITS architecture development noted above, the docket received 86 comments on systems engineering and project implementation. These comments revealed that the structure of the NPRM in discussing regional ITS architecture development, project systems engineering analysis, and project implementation was confusing and difficult to read. To clarify these portions of the rule, the systems engineering and project implementation sections of the NPRM have been combined into § 940.11, Project Implementation. Also, paragraphs that were in the regional ITS architecture section of the NPRM that discussed major ITS projects and the requirements for developing project level ITS architectures have been rewritten to clarify their applicability. Since these paragraphs deal with project development issues, they have been moved to § 940.11(e). A definition for ‘‘project level ITS architecture’’ was added in § 940.3 and a description of its contents provided in § 940.11(e). The docket received 33 comments regarding systems engineering and the systems engineering analysis section of the proposed rule. Most of the comments related to the definition, the process not being necessary except for very large projects, and confusion as to how these requirements relate to existing FHWA policy. In response to the docket comments, the definition of systems engineering in § 940.3 has been clarified and is more consistent with accepted practice. In order to provide consistency in the regional ITS architecture process, the systems engineering analysis detailed in §§ 940.11(a) through 940.11(c) must apply to all ITS projects regardless of size or budget. However, the analysis should be on a scale commensurate with project scope. To allow for the greatest flexibility at the State and local level, in § 940.11(c), a minimum number of elements have been clearly identified for inclusion in the systems engineering analysis. Many of APPENDIX C 249 those elements are currently required as provided in 23 CFR 655.409, which this rule replaces. Recognizing the change in some current practices this type of analysis will require, the FHWA intends to issue guidance, training, and technical support in early 2001 to help stakeholders meet the requirements of the final rule. Fifty-three comments were submitted regarding ITS standards and interoperability tests. The commenters expressed concern about requiring the use of ITS standards and interoperability tests prematurely, the impact on legacy systems of requiring ITS standards, and confusion regarding the term ‘‘adopted by the DOT.’’ In response to the comments, the FHWA has significantly modified the final rule to eliminate reference to the use of standards and interoperability tests prior to adoption in § 940.11(f). Section 940.11(g) addresses the applicability of standards to legacy systems. It is not the intent of the DOT to formally adopt any standard before the standard is mature; and also, not all ITS standards should, or will, be formally adopted by the DOT. Formal adoption of a standard means that the DOT will go through the rulemaking process, including a period of public comment, for all standards that are considered candidates for adoption. The DOT has developed a set of criteria to determine when a standard could be considered for formal adoption. These criteria include, at a minimum, the following elements: 1. The standard has been approved by a Standard Development Organization (SDO). 2. The standard has been successfully tested in real world applications as appropriate. 3. The standard has received some degree of acceptance by the community served by the standard. 4. Products exist to implement the standard. 5. There is adequate documentation to support the use of the standard. 6. There is training available in the use of the standard where applicable. Therefore, the intent of the rule is to require the use of a standard only when these criteria have been met, and there has been a separate rulemaking on adoption of the standard. The only interoperability tests that are currently contemplated by the DOT are those associated with the Commercial Vehicle Operations (CVO) program. These tests are currently being used by States deploying CVO systems and will follow a similar set of criteria for adoption as those defined for standards. C.7.6 Final Rule Section 940.13 Project Administration There were nine comments related to how conformity with the final rule would be determined, and by whom. There were 11 comments about how conformity 250 APPENDIX C with the regional ITS architecture would be determined, and by whom. Six comments specifically suggested methods for determining conformance, including a process similar to current Federal planning oversight procedures. Six other commenters suggested that determination be made by the MPO or State. For either case, the comments reflected a lack of clarity as to what documentation would be necessary. There were six related comments suggesting the level of documentation be commensurate with the scale of the planned ITS investments in the region. In § 940.13 of the final rule, the FHWA has attempted to clarify the process for determining conformance. Conformance of an ITS project with a regional ITS architecture shall be made prior to authorization of funding for project construction or implementation as provided in 23 U.S.C. 106 and 133. We do not intend to create new oversight procedures beyond those provided in 23 U.S.C. 106 and 133, but in those cases where oversight and approval for ITS projects is assumed by the State, the State will be responsible for ensuring compliance with this regulation and the FHWA’s oversight will be through existing processes. There were 14 comments concerning the documentation requirements of the proposed rule and generally suggesting they be reduced. Certainly the development of a regional ITS architecture and evidence of conformance of a specific project to that regional ITS architecture implies some level of documentation be developed. However, to allow flexibility on the part of the State or local agency in demonstrating compliance with the final rule, no specific documentation is required to be developed or submitted to the FHWA for review or approval. The FHWA recognizes the need to be able to scale the regional ITS architecture and the associated documentation to the needs of the region. Section 940.9(a) of the final rule contains specific language allowing such scaling. C.8 SUMMARY OF REQUIREMENTS C.8.1 The Regional ITS Architecture This final rule on the ITS Architecture and Standards requires the development of a local implementation of the National ITS Architecture referred to as a regional ITS architecture. The regional ITS architecture is tailored to meet local needs, meaning that it does not address the entire National ITS Architecture and can also address services not included in the National ITS Architecture. The regional ITS architecture shall contain a description of the region and the identification of the participating agencies and other stakeholders; the roles and responsibilities of the participating agencies and other stakeholders; any agreements needed for operation; system functional requirements; interface requirements and information exchanges with planned and existing systems; identification of applicable standards; and the sequence of projects necessary APPENDIX C 251 for implementation. Any changes made in a project design that impact the regional ITS architecture shall be identified and the appropriate revisions made and agreed to in the regional ITS architecture. Any region that is currently implementing ITS projects shall have a regional ITS architecture within four years of the effective date of this rule. All other regions not currently implementing ITS projects shall have a regional ITS architecture within four years of the first ITS project for that region advancing to final design. In this context, a region is a geographical area that is based on local needs for sharing information and coordinating operational strategies among multiple projects. A region can be specified at a metropolitan, Statewide, multi-State, or corridor level. Within a metropolitan area, the metropolitan planning area should be the minimum area that is considered when establishing the boundaries of a region for purposes of developing a regional ITS architecture. A regional approach promotes integration of transportation systems. The size of the region should reflect the breadth of the integration of transportation systems. C.8.2 Project Development Additionally, this rule requires that all ITS projects be developed using a systems engineering analysis. All ITS projects that have not yet advanced to final design are required to conform to the system engineering requirements in § 940.11 upon the effective date of this rule. Any ITS project that has advanced to final design by the effective date of this rule is exempt from the requirements of § 940.11. When the regional ITS architecture is completed, project development will be based on the relevant portions of it which the project implements. Prior to completion of the regional ITS architecture, major ITS projects will develop project level ITS architectures that are coordinated with the development of the regional ITS architecture. ITS projects will be required to use applicable ITS standards and interoperability tests that have been officially adopted by the DOT. Where multiple standards exist, it will be the responsibility of the stakeholders to determine how best to achieve the interoperability they desire. C.9 RULEMAKING ANALYSES AND NOTICES C.9.1 Executive Order 12866 (Regulatory Planning and Review) and DOT Regulatory Policies and Procedures The FHWA has determined that this action is not a significant regulatory action within the meaning of Executive Order 12866 or significant within the meaning of the Department of Transportation’s regulatory policies and procedures. It is anticipated that the economic impact of this rulemaking will be minimal. This determination is based upon preliminary and final regulatory assessments prepared for this action that indicate that the annual impact of the rule will 252 APPENDIX C not exceed $100 million nor will it adversely affect the economy, a sector of the economy, productivity, jobs, the environment, public health, safety, or State, local, or tribal governments. In addition, the agency has determined that these changes will not interfere with any action taken or planned by another agency and will not materially alter the budgetary impact of any entitlements, grants, user fees, or loan programs. Copies of the preliminary and final regulatory assessments are included in the docket. C.9.1.1 Costs. The FHWA prepared a preliminary regulatory evaluation (PRE) for the NPRM and comments were solicited. That analysis estimated the total costs of this rule over 10 years to be between $38.1 million and $44.4 million (the net present value over 10 years was between $22.3 million and $31.2 million). The annual constant dollar impact was estimated to range between $3.2 million and $4.4 million. We believe that the cost estimates as stated in the PRE are negligible. The FHWA received only one comment in response to the PRE. That commenter, the Capital District Transportation Committee of Albany, New York suggested that our cost estimates were too low, but provided no further detail or rationale which would cause us to reconsider or increase our cost estimates in the initial regulatory evaluation. These 10-year cost estimates set forth in the PRE included transportation planning cost increases, to MPOs ranging from $10.8 million to $13.5 million, and to States from $5.2 million to $7.8 million associated with our initial requirement to develop an ITS integration strategy that was proposed as part of the metropolitan and statewide planning rulemaking effort. The agency now plans to advance that proposed ITS integration strategy in the planning rule on a different time schedule than this final rule. Thus, the costs originally set forth in the PRE for the ITS integration strategy have been eliminated from the final cost estimate in the final regulatory evaluation (FRE) for this rule. In the FRE, the agency estimates the cost of this rule to be between $1 million an $16 million over ten years, which are the estimated costs of this rule to implementing agencies for the development of the regional ITS architectures. These costs do not include any potential additional implementation costs for individual projects which are expected to be minimal and were extremely difficult to estimate. Thus, the costs to the industry are less than that originally estimated in the agency’s NPRM. C.9.1.2 Benefits. In the PRE, the FHWA indicated that the non-monetary benefits derived from the proposed action included savings from the avoidance of duplicative development, reduced overall development time, and earlier detection of potential incompatibilities. We stated that, as with project implementation impacts, the benefits of the rule are very difficult to quantify in monetary terms. Thus, we estimated that the coordination guidance provided through implementation of the rule could provide savings of approximately $150,000 to any potential entity seeking to comply with the requirements of section 5206(e) of the TEA–21 as compared with an entity having to undertake APPENDIX C 253 compliance individually. The costs may be offset by benefits derived from the reduction of duplicative deployments, reduced overall development time, and earlier detection of potential incompatibilities. In developing a final regulatory evaluation for this action, we did not denote a significant change in any of the benefits anticipated by this rule. This is so notwithstanding the fact that our planning costs for the ITS integration strategy have been eliminated from the final cost estimate. The primary benefits of this action that result from avoidance of duplicative development, reduced overall development time, and earlier detection of potential incompatibilities will remain the same. In sum the agency believes that the option chosen in this action will be most effective at helping us to implement the requirements of section 5206(e) of the TEA–21. In developing the rule, the FHWA has sought to allow broad discretion to those entities impacted, in levels of response and approach that are appropriate to particular plans and projects, while conforming to the requirements of the TEA–21. The FHWA has considered the costs and benefits of effective implementation of ITS through careful and comprehensive planning. Based upon the information above, the agency anticipates that the economic impact associated with this rulemaking action is minimal and a full regulatory evaluation is not necessary. C.9.2 Regulatory Flexibility Act In compliance with the Regulatory Flexibility Act (5 U.S.C. 601–612), the FHWA has evaluated, through the regulatory assessment, the effects of this action on small entities and has determined that this action will not have a significant economic impact on a substantial number of small entities. Small businesses and small organizations are not subject to this rule, which applies to government entities only. Since § 940.9(a) of this rule provides for regional ITS architectures to be developed on a scale commensurate with the scope of ITS investment in the region, and § 940.11(b) provides for the ITS project systems engineering analysis to be on a scale commensurate with the project scope, compliance requirements will vary with the magnitude of the ITS requirements of the entity. Small, less complex ITS projects have correspondingly small compliance documentation requirements, thereby accommodating the interest of small government entities. Small entities, primarily transit agencies, are accommodated through these scaling provisions that impose only limited requirements on small ITS activities. For these reasons, the FHWA certifies that this action will not have a significant impact on a substantial number of small entities. C.9.3 Unfunded Mandates Reform Act of 1995 This action does not impose unfunded mandates as defined by the Unfunded Mandates Reform Act of 1995 (Pub. L. 104–4, March 22, 1995, 109 Stat. 48). 254 APPENDIX C This rule will not result in an expenditure by State, local, and tribal governments, in the aggregate, or by the private sector, of $100 million or more in any one year. C.9.4 Executive Order 13132 (Federalism) This action has been analyzed in accordance with the principles and criteria contained in Executive Order 13132, dated August 4, 1999, and the FHWA has determined that this action does not have sufficient federalism implications to warrant the preparation of a federalism assessment. The FHWA has also determined that this action does not preempt any State law or State regulation or affect the State’s ability to discharge traditional State governmental functions. C.9.5 Executive Order 12372 (Intergovernmental Review) Catalog of Federal Domestic Assistance Program Number 20.205, Highway planning and construction. The regulations implementing Executive Order 12372 regarding intergovernmental consultation on Federal programs and activities apply to this program. C.9.6 Paperwork Reduction Act of 1995 This action does not contain information collection requirements for the purposes of the Paperwork Reduction Act of 1995, 44 U.S.C. 3501–3520. C.9.7 Executive Order 12988 (Civil Justice Reform) This action meets applicable standards in sections 3(a) and 3(b) (2) of Executive Order 12988, Civil Justice Reform, to minimize litigation, eliminate ambiguity, and reduce burden. C.9.8 Executive Order 13045 (Protection of Children) We have analyzed this action under Executive Order 13045, Protection of Children from Environmental Health Risks and Safety Risks. This rule is not an economically significant rule and does not concern an environmental risk to health or safety that may disproportionately affect children. This rule does not effect a taking of private property or otherwise have taking implications under Executive Order 12630, Government Actions and Interference with Constitutionally Protected Property Rights. C.9.9 National Environmental Policy Act The agency has analyzed this action for the purposes of the National Environmental Policy Act of 1969, as amended (42 U.S.C. 4321–4347), and has APPENDIX C 255 determined that this action will not have any effect on the quality of the environment. C.9.10 Regulation Identification Number A regulation identification number (RIN) is assigned to each regulatory action listed in the Unified Agenda of Federal Regulations. The Regulatory Information Service Center publishes the Unified Agenda in April and October of each year. The RIN contained in the heading of this document can be used to cross reference this proposed action with the Unified Agenda. C.9.11 List of Subjects 23 CFR Part 655 Design standards, Grant programs transportation, Highways and roads, Incorporation by reference, Signs and symbols, Traffic regulations. 23 CFR Part 940 Design standards, Grant programs transportation, Highways and roads, Intelligent transportation systems. Issued on: January 2, 2001. Kenneth R. Wykle, Federal Highway Administrator. In consideration of the foregoing, the FHWA amends Chapter I of title 23, Code of Federal Regulations, as set forth below: PART 655—[AMENDED] 1. The authority citation for part 655continues to read as follows: Authority: 23 U.S.C. 101(a), 104, 109(d), 114(a), 217, 315, and 402(a); 23 CFR 1.32, and 49 CFR 1.48(b). Subpart D—[Removed and reserved] 2. Remove and reserve subpart D of part 655, consisting of §§ 655.401, 655.403, 655.405, 655.407, 655.409, 655.411. 3. Add a new subchapter K, consisting of part 940, to read as follows: Subchapter K—Intelligent Transportation Systems C.10 PART 940—INTELLIGENT TRANSPORTATION SYSTEM ARCHITECTURE AND STANDARDS Sec. 940.1 Purpose. 940.3 Definitions. 940.5 Policy. 940.7 Applicability. 940.9 Regional ITS architecture. 940.11 Project implementation. 940.13 Project administration. Authority: 23 U.S.C. 101, 106, 109, 133, 315, and 508; sec 5206(e), Public Law 105–178, 112 Stat. 457 (23 U.S.C. 502 note); and 49 CFR 1.48. 256 APPENDIX C C.10.1 § 940.1 Purpose This regulation provides policies and procedures for implementing section 5206(e) of the Transportation Equity Act for the 21st Century (TEA–21), Public Law 105–178, 112 Stat. 457, pertaining to conformance with the National Intelligent Transportation Systems Architecture and Standards. C.10.2 § 940.3 Definitions Intelligent Transportation System (ITS) means electronics, communications, or information processing used singly or in combination to improve the efficiency or safety of a surface transportation system. ITS project means any project that in whole or in part funds the acquisition of technologies or systems of technologies that provide or significantly contribute to the provision of one or more ITS user services as defined in the National ITS Architecture. Major ITS project means any ITS project that implements part of a regional ITS initiative that is multijurisdictional, multi-modal, or otherwise affects regional integration of ITS systems. National ITS Architecture (also ’’national architecture’’) means a common framework for ITS interoperability. The National ITS Architecture comprises the logical architecture and physical architecture which satisfy a defined set of user services. The National ITS Architecture is maintained by the United States Department of Transportation (DOT) and is available on the DOT web site at http://www.its.dot.gov. Project level ITS architecture is a framework that identifies the institutional agreement and technical integration necessary to interface a major ITS project with other ITS projects and systems. Region is the geographical area that identifies the boundaries of the regional ITS architecture and is defined by and based on the needs of the participating agencies and other stakeholders. In metropolitan areas, a region should be no less than the boundaries of the metropolitan planning area. Regional ITS architecture means a regional framework for ensuring institutional agreement and technical integration for the implementation of ITS projects or groups of projects. Systems engineering is a structured process for arriving at a final design of a system. The final design is selected from a number of alternatives that would accomplish the same objectives and considers the total life-cycle of the project including not only the technical merits of potential solutions but also the costs and relative value of alternatives. C.10.3 § 940.5 Policy ITS projects shall conform to the National ITS Architecture and standards in accordance with the requirements contained in this part. Conformance with the National ITS Architecture is interpreted to mean the use of the National ITS APPENDIX C 257 Architecture to develop a regional ITS architecture, and the subsequent adherence of all ITS projects to that regional ITS architecture. Development of the regional ITS architecture should be consistent with the transportation planning process for Statewide and Metropolitan Transportation Planning. C.10.4 § 940.7 Applicability (a) All ITS projects that are funded in whole or in part with the highway trust fund, including those on the National Highway System (NHS) and on non- NHS facilities, are subject to these provisions. (b) The Secretary may authorize exceptions for: (1) Projects designed to achieve specific research objectives outlined in the National ITS Program Plan under section 5205 of the TEA–21, or the Surface Transportation Research and Development Strategic Plan developed under 23 U.S.C. 508; or (2) The upgrade or expansion of an ITS system in existence on the date of enactment of the TEA–21, if the Secretary determines that the upgrade or expansion: (i) Would not adversely affect the goals or purposes of Subtitle C (Intelligent Transportation Systems Act of 1998) of the TEA–21; (ii) Is carried out before the end of the useful life of such system; and (iii) Is cost-effective as compared to alternatives that would meet the conformity requirement of this rule. (c) These provisions do not apply to funds used for operations and maintenance of an ITS system in existence on June 9, 1998. C.10.5 § 940.9 Regional ITS architecture (a) A regional ITS architecture shall be developed to guide the development of ITS projects and programs and be consistent with ITS strategies and projects contained in applicable transportation plans. The National ITS Architecture shall be used as a resource in the development of the regional ITS architecture. The regional ITS architecture shall be on a scale commensurate with the scope of ITS investment in the region. Provision should be made to include participation from the following agencies, as appropriate, in the development of the regional ITS architecture: Highway agencies; public safety agencies (e.g., police, fire, emergency/medical); transit operators; Federal lands agencies; State motor carrier agencies; and other operating agencies necessary to fully address regional ITS integration. 258 APPENDIX C (b) Any region that is currently implementing ITS projects shall have a regional ITS architecture by February 7, 2005. (c) All other regions not currently implementing ITS projects shall have a regional ITS architecture within four years of the first ITS project for that region advancing to final design. (d) The regional ITS architecture shall include, at a minimum, the following: (1) A description of the region; (2) Identification of participating agencies and other stakeholders; (3) An operational concept that identifies the roles and responsibilities of participating agencies and stakeholders in the operation and implementation of the systems included in the regional ITS architecture; (4) Any agreements (existing or new) required for operations, including at a minimum those affecting ITS project interoperability, utilization of ITS related standards, and the operation of the projects identified in the regional ITS architecture; (5) System functional requirements; (6) Interface requirements and information exchanges with planned and existing systems and subsystems (for example, subsystems and architecture flows as defined in the National ITS Architecture); (7) Identification of ITS standards supporting regional and national interoperability; and (8) The sequence of projects required for implementation. (e) Existing regional ITS architectures that meet all of the requirements of paragraph (d) of this section shall be considered to satisfy the requirements of paragraph (a) of this section. (f) The agencies and other stakeholders participating in the development of the regional ITS architecture shall develop and implement procedures and responsibilities for maintaining it, as needs evolve within the region. C.10.6 § 940.11 Project implementation (a) All ITS projects funded with highway trust funds shall be based on a systems engineering analysis. (b) The analysis should be on a scale commensurate with the project scope. (c) The systems engineering analysis shall include, at a minimum: (1) Identification of portions of the regional ITS architecture being implemented (or if a regional ITS architecture does not exist, the applicable portions of the National ITS Architecture); APPENDIX C 259 (2) Identification of participating agencies roles and responsibilities; (3) Requirements definitions; (4) Analysis of alternative system configurations and technology options to meet requirements; (5) Procurement options; (6) Identification of applicable ITS standards and testing procedures; and (7) Procedures and resources necessary for operations and management of the system. (d) Upon completion of the regional ITS architecture required in §§ 940.9(b) or 940.9(c), the final design of all ITS projects funded with highway trust funds shall accommodate the interface requirements and information exchanges as specified in the regional ITS architecture. If the final design of the ITS project is inconsistent with the regional ITS architecture, then the regional ITS architecture shall be updated as provided in the process defined in § 940.9(f) to reflect the changes. (e) Prior to the completion of the regional ITS architecture, any major ITS project funded with highway trust funds that advances to final design shall have a project level ITS architecture that is coordinated with the development of the regional ITS architecture. The final design of the major ITS project shall accommodate the interface requirements and information exchanges as specified in this project level ITS architecture. If the project final design is inconsistent with the project level ITS architecture, then the project level ITS architecture shall be updated to reflect the changes. The project level ITS architecture is based on the results of the systems engineering analysis, and includes the following: (1) A description of the scope of the ITS project; (2) An operational concept that identifies the roles and responsibilities of participating agencies and stakeholders in the operation and implementation of the ITS project; (3) Functional requirements of the ITS project; (4) Interface requirements and information exchanges between the ITS project and other planned and existing systems and subsystems; and (5) Identification of applicable ITS standards. (f) All ITS projects funded with highway trust funds shall use applicable ITS standards and interoperability tests that have been officially adopted through rulemaking by the DOT. (g) Any ITS project that has advanced to final design by February 7, 2001 is exempt from the requirements of paragraphs (d) through (f) of this section. 260 APPENDIX C C.10.7 § 940.13 Project administration (a) Prior to authorization of highway trust funds for construction or implementation of ITS projects, compliance with § 940.11 shall be demonstrated. (b) Compliance with this part will be monitored under Federal-aid oversight procedures as provided under 23 U.S.C. 106 and 133. [FR Doc. 01–391 Filed 1–5–01; 8:45 am], BILLING CODE 4910–22–P APPENDIX D USDOT FTA POLICY ON TRANSIT PROJECTS T he following is the United States Department of Transportation Federal Transit Administration’s National ITS Architecture Policy on Transit Projects verbatim from the Federal Register for your reference. This policy is a sister policy to the FHWA final rule as defined in Appendix C with application to ITS transit projects funded in part by the Highway Trust Fund and requiring regional ITS architectures, as mentioned in Chapter 9 of this book. The reason given as to why the FHWA has a final rule and the FTA has a final policy is that they each have different processes and procedures for the context of ITS project development; however, the required elements for regional ITS architectures and ITS projects are the same. DEPARTMENT OF TRANSPORTATION Federal Transit Administration Federal Transit Administration National ITS Architecture Policy on Transit Projects AGENCY: Federal Transit Administration (FTA), DOT. ACTION: Notice. D.1 SUMMARY The Federal Transit Administration (FTA) announces the FTA National ITS Architecture Policy on Transit Projects, which is defined in this document. The National ITS Architecture Policy is a product of statutory changes made by Transportation Infrastructure Security Utilizing Intelligent Transportation Systems R. Fries, M. Chowdhury and J. Brummond Copyright © 2009 John Wiley & Sons, Inc. 261 262 APPENDIX D the Transportation Equity Act for the 21st Century (TEA-21) (Pub. L. 105-178) enacted on June 9, 1998. The National ITS Architecture Policy is also a product of the Request for Comment on the National ITS Architecture Consistency Policy for Project Development that was published in the Federal Register on May 25, 2000. Because it is highly unlikely that the entire National ITS Architecture would be fully implemented by any single metropolitan area or State, this policy requires that the National ITS Architecture be used to develop a local implementation of the National ITS Architecture, which is referred to as a ‘‘regional ITS architecture.’’ Therefore, conformance with the National ITS Architecture is defined under this policy as development of a regional ITS architecture within four years after the first ITS project advancing to final design, and the subsequent adherence of ITS projects to the regional ITS architecture. The regional ITS architecture is based on the National ITS Architecture and consists of several parts including the system functional requirements and information exchanges with planned and existing systems and subsystems and identification of applicable standards, and would be tailored to address the local situation and ITS investment needs. DATE: Effective Date: This policy is effective from February 7, 2001. ADDRESSES: For FTA staff, Federal Transit Administration, Department of Transportation (DOT), 400 Seventh Street, SW., Washington, DC 20590. FOR FURTHER INFORMATION CONTACT: For Technical Information: Ron Boenau, Chief, Advanced Public Transportation Systems Division (TRI-11), at (202) 366-0195 or Brian Cronin, Advanced Public Transportation Systems Division (TRI-11), at (202) 366-8841. For Legal Information: Richard Wong, Office of the Chief Council (202) 366-1936. The policy is posted on the FTA website on the Internet under http://www.fta.dot.gov. Electronic Access: An electronic copy of this document may be downloaded using a computer, modem and suitable communications software from the Government Printing Office’s Electronic Bulletin Board Service at (202) 5121661. Internet users may reach the Office of the Federal Register’s home page at: http://www.nara.gov/fedreg and the Government Printing Office’s web page at: http://www.access.gpo.gov/nara. Internet users may access all comments received by the U.S. DOT Dockets, Room PL-401, for the Request for Comment that was issued on May 25, 2000 which were used to clarify this Policy, by using the universal resource locator (URL): http://dms.dot.gov. It is available 24 hours each day, 365 days each year. Please follow the instructions online for more information and help. The docket number for the Request for Comment was FTA-99-6417. D.2 SUPPLEMENTARY INFORMATION D.2.1 Background The Federal Transit Administration (FTA) published a Request for Comment on May 25, 2000, to implement section 5206(e) of the Transportation Equity APPENDIX D 263 Act for the 21st Century (TEA-21) (Pub. L. 105-178), which was enacted on June 9, 1998. Section 5206(e) of TEA-21 requires that the Secretary of the DOT must Ensure that intelligent transportation system projects carried out using funds made available from the Highway Trust Fund, conform to the national architecture, applicable standards or provisional standards, and protocols developed under subsection(a). The objectives for the FTA’s National ITS Architecture Policy for Transit Projects are to: Provide requirements for ITS project development for projects implemented wholly or partially with highway trust funds. Achieve system integration of ITS projects funded through the highway trust fund with other transportation projects planned for the region, which will thereby enable electronic information and data sharing for advanced management and operations of the ITS infrastructure. Engage stakeholders (state DOT’s, transit agencies, public safety agencies, other transportation operating agencies) in the project development and implementation process. Facilitate future expansion capability of the ITS infrastructure. Save design time through use of the National ITS Architecture requirements definitions and market packages. FTA has developed this policy to meet the TEA-21 requirement contained in Section 5206(e) and the DOT/FTA goal to encourage effective deployment of ITS projects. Additionally, DOT and FTA encourage the coordination of local ITS strategies and projects to help meet national and local goals for mobility, accessibility, safety, security, economic growth and trade, and the environment. The National ITS Architecture documents were developed by the US DOT, and are updated on an as-needed basis. Current work to update the National ITS Architecture is the Archive Data User Service, which provides the ability to store and process data over an extended period of time. FTA is pursuing the addition of a Rail ITS program for travel management, vehicles, and users. New versions of the documents, when they are issued, will be available from the US DOT on the DOT website at http://frwebgate.access.gpo.gov/cgi-bin/leaving .cgi?from=leavingFR.html&log=linklog&to=http://www.its.dot.gov. Version 3.0 is the latest version of the National ITS Architecture. The first section of this policy contains a complete analysis of and response to the comments provided to the docket. The remainder of the Notice contains the FTA National ITS Architecture Policy for Transit Projects. Public Comments Eighteen comments were submitted to the FTA National ITS Architecture Consistency Policy for Project Development docket by the September 23, 264 APPENDIX D 2000, close of the comment period. Comments were submitted by transit operators (3), state and local governments (5), metropolitan planning organizations (4), industry associations (3), and consultants (3). As indicated earlier, a complete analysis and response to the docket comments is provided. In order to facilitate focused comments, FTA asked a series of questions about the policy. The public comment section is organized first by analysis and response to the specific questions asked; second by responses to comments not specifically related to one of the nine questions; and finally by an explanation of other changes. In general, the comments received were positive. Therefore, the FTA has kept the scope of the policy and made appropriate clarifications to the text of the policy to address concerns raised in comments. In response to the many comments requesting it, the FTA, in association with the ITS Joint Program Office, in the Federal Highway Administration (FHWA) will also provide a program of guidance, training, and technical support to assist with the implementation of this policy. Questions 1. Do reviewers understand the definition of a major ITS investment as defined in Section IV, ‘‘Regional ITS Architecture,’’ or is more clarification needed, and if so please explain? Comments: Nine commenters submitted responses to this question. In general, commenters found the definition confusing, and did not understand why major ITS projects need to be called out over other ITS projects. One commenter noted that small dollar projects can have a major impact on future development, while an expensive system may have no impact. Another commenter was unclear about the term ‘‘supporting national interoperability.’’ Response: Of specific concern to the agency is the timing in which requirements for this policy are enacted. As such, the terms ‘‘major ITS investment’’ and ‘‘major ITS project’’ were provided so as to distinguish between projects that will require immediate correlation to the regional ITS architecture and those that do not. The term ‘‘major ITS investment’’ was also found to be redundant to ‘‘major ITS project’’ and was removed from the policy. Guidance on the classification of ‘‘ITS projects’’ and ‘‘major ITS projects’’ will be provided upon enactment of the policy. 2. Do reviewers understand the definition of an ITS project, or is more clarification needed, and if so please explain? Comments: Nine commenters submitted responses to this question. Commenters found this term less confusing than ‘‘major ITS investments,’’ but requested more clarification. Some commenters proposed alternative language or asked for clarification on particular examples. Response: The agency has clarified the definition by deleting the potentially ambiguous examples provided and will develop guidance material that provides examples of projects that will be considered ITS projects and those that will not be considered ITS projects. In general, unless a technology project is APPENDIX D 265 implementing one of the ITS user services defined in the National ITS Architecture, it would not be considered an ITS project. 3. Do reviewers understand the difference between a ‘‘major ITS investment,’’ and an ‘‘ITS project’’, or is more clarification needed, and if so please explain? Comments: Eight commenters submitted responses to this question. Commenters had mixed responses, as some commenters found the differences to be clear, while others requested that guidance material be provided to further explain the differences. Commenters did suggest that a ‘‘project’’ is a ‘‘project’’ and should not be quantified in terms of dollar amounts. Response: As described in the response to question 1, the agency has removed the term ‘‘major ITS investment’’ and will provide guidance on the term ‘‘ITS project.’’ 4. Are the requirements for development of a Regional ITS Architecture clear? If not, what is not clear about the requirement? Comment: Nine commenters provided responses to the question. Most commenters found the requirements to be unclear and/or did not agree with the requirements. One commenter suggested that a region will have different definitions. One commenter noted that a concept of operations and conceptual design are normally conducted at the project level. One commenter requested clarification as to the appropriate place to program projects, in the regional ITS architecture, or in the planning process. Response: Of specific concern to the agency is providing a flexible policy that allows the transportation stakeholders to define their region and the roles and responsibilities of each stakeholder during the development of a regional ITS architecture. As such, the agency has clarified the requirements of a regional ITS architecture and also removed the specific requirements for a Concept of Operations and a Conceptual Design. Instead, the agency has listed the specific requirements for a regional ITS architecture and has left the development, documentation, and maintenance of the regional ITS architecture to the stakeholders involved. Also, the region is defined as ‘‘a geographical area that is based on local needs for sharing information and coordinating operational strategies among multiple projects.’’ A region can be specified at a metropolitan, Statewide, multi-State, or corridor level. Additional guidance on this topic will be provided after enactment of the policy. 5. What additional guidance, if any, is required to explain how to implement this proposed policy? Comments: Ten commenters provided responses to this question. All the comments called for additional guidance on the specifics of implementing this policy. Commenters requested guidance on the definition of a ‘‘region,’’ the ownership of the regional ITS architecture, determination of stakeholders, regional ITS architecture maintenance, certification and simplification of definitions. One commenter requested that the policy be limited to only the ITS Integration Requirements defined in the Metropolitan and Statewide Planning NPRM. 266 APPENDIX D Response: The agency will provide guidance materials to address the comments suggested. The ITS Integration Strategy, as defined in the NPRM, is part of the planning process and as such does not satisfactorily address project level requirements. 6. The proposed rule allows regions to develop a Regional Architecture as a separate activity, or incrementally, as major ITS investments are developed within a region. Do reviewers anticipate particular difficulties with implementing and documenting either approach? Comments: Nine commenters provided responses to this question. Commenters largely did not favor one approach over the other. One commenter suggested that a regional ITS architecture with a twenty year time horizon is impractical and infeasible. One commenter suggested that either approach would require additional staff resources. Response: The agency was concerned about the time horizon and development process needed to create a regional ITS architecture within the time period required and as a result suggested both an incremental and initial comprehensive approach. Based on the responses, the agency has modified the policy to be silent on the approach used to develop the regional ITS architecture. Instead, the agency focused on the products included in the regional ITS architecture, the effective date of the requirements, and the catalyst for requiring the development of a regional ITS architecture. 7. Do reviewers understand the relationships between the Integration Strategy, the Regional ITS Architecture, and the ITS Project Architecture? Comment: Seven commenters provided a response to this question. In general, commenters did not understand the relationship between the Integration Strategy, regional ITS architecture, and the ITS Project Architecture. One commenter suggested that flexibility in application of project architecture must be maintained to accommodate legacy systems and to take advantage of technological innovation, while maintaining the outcome of interoperability, where applicable. Response: The Agency is concerned with linkage between the planning process and the project development process. However, this policy only deals with the project level requirements. Planning level requirements, including the Integration Strategy, will be explained as the Metropolitan and Statewide Planning Process rulemaking process is advanced. This policy only requires that the regional ITS architecture should be consistent with the transportation planning process. A definition for a project level ITS architecture has been added to the policy. 8. What additional guidance, if any, is required regarding phasing of this rule? Comments: Six commenters submitted responses to this question. In general, the commenters stated that the phasing was clear. However, one commenter requested a three-year phase-in period. Several commenters requested that existing projects be exempt from the policy. APPENDIX D 267 Response: The agency has clarified the policy statements that refer to the project status and the applicability of this policy. Projects that have reached final design by the date of this policy are exempt from the policy requirements. The agency has extended the time period for regional ITS architecture development to four years. Any region that is currently implementing ITS projects shall have a regional architecture within four years of the effective date of the final policy. All other regions not currently implementing ITS projects shall have a regional ITS architecture in place within four years of the first ITS project for that region advancing to final design. 9. Are the oversight and documentation requirements clear? If not, what is not clear about the requirements? Comments: Eight commenters submitted responses to this question. Commenters in general requested more guidance from FTA on oversight and documentation requirements, but few provided suggestions to clarify the requirements. One commenter suggested that checklists to verify consistency requirements will be needed. Other commenters suggested that self-certification should be allowed, but also needs to be clearly defined. Response: The agency will continue to use normal existing oversight procedures to review grantee compliance with FTA policies and regulations. Normal oversight procedures include the annual risk assessment of grantees performed by regional office staff, triennial reviews, planning process reviews, and project management oversight reviews, as applicable. In TEA-21, FTA was granted authority to use oversight funds to provide technical assistance to grantees in which oversight activities suggested non-compliance with agency policies and regulations. FTA is using oversight funds to specifically hire contractors with ITS experience who will monitor and assist grantees who are at risk of NOT meeting the National ITS Architecture Policy requirements. Additional guidance on oversight and documentation requirements will be provided. D.2.3.1 Additional Comments. One commenter suggested that the proposed guidance circular requires that all of the agencies in a region agree before a project can be implemented, thus conferring ‘‘veto’’ power over the project. The agency does not intend for the policy to halt ITS deployment in areas where agencies cannot agree on project designs. As part of the regional ITS Architecture development, the agencies can agree to disagree, however, the regional ITS architecture should include a representation of the stand-alone ITS deployments. One commenter suggests that the proposal infers that existing agreements between agencies will now need to be amended or redone, which would result in a halt in operations of successful ITS projects and prevent the completion of other ITS projects. In response to the comment, the agency has clarified the regional ITS architecture requirements to specify that existing agreements that address the regional ITS architecture requirements are sufficient and that new agreements are not necessarily required. 268 APPENDIX D One commenter noted that a definition of ITS was not included in the policy. The commenter suggested that the definition provided in TEA-21 section 5206(e) should be included in the policy. The agency agrees and has added the definition of ITS to the list of definitions. However, the legislative definition of ITS is broad and other commenters have suggested that if the policy is written to include every new piece of electronics or hardware, then the policy would be too limiting. As a result, the policy is intended to apply only to projects meeting the definition of an ‘‘ITS project’’ listed in the ‘‘Definitions’’ section of the policy. One commenter suggested that DOT should ensure that the Federal Highway Administration’s (FHWA’s) regulation and the FTA policy have the same statutory standing and that their requirements in ITS planning and deployment be consistent if not identical. The FTA and FHWA have different processes and procedures for project development. Therefore, the FHWA has issued a regulation, and FTA has issued the policy. The policy language in each document is consistent and will be carried out in a coordinated fashion, as applicable under FTA and FHWA project management and oversight procedures. FTA and FHWA planning procedures are a joint regulation and as such will be identical. FTA received some comments regarding the use of standards. Several comments concern the premature use of required standards and interoperability tests, their impact on legacy systems, and confusion regarding the term ‘‘adopted by the USDOT.’’ In response to the comments, FTA has significantly modified the final policy to eliminate reference to the use of standards and interoperability tests prior to adoption through formal rulemaking. It is not the intent of the USDOT to formally adopt any standard before the standard is mature; also, not all ITS standards should, or will, be formally adopted by the USDOT. The only interoperability tests that are currently contemplated by the USDOT are those associated with the Commercial Vehicle Operations (CVO) program. These tests are currently being used by States deploying CVO systems and will follow a similar set of criteria for adoption as those defined for standards. D.2.3.2 Other Changes. Several commenters expressed concern about linkages to the planning rule and the integration strategy. Comments regarding the portions of the National ITS Architecture conformity process included in the proposed transportation planning rule will be addressed as that rule proceeds to its issuance. The FHWA rule and the parallel FTA policy have been developed without direct reference to the proposed changes to the transportation planning process, including no mention of the development of an integration strategy. However, the policy statement of this guidance notes a link to transportation planning processes, and fully supports those collaborative methods for establishing transportation goals and objectives. APPENDIX D 269 D.3 POLICY CONTENTS I. II. III. IV. V. VI. VII. VIII. D.3.1 Purpose Definitions Policy Applicability Regional ITS Architecture Project Implementation Project Oversight FTA Guidance Purpose This policy provides procedures for implementing section 5206(e) of the Transportation Equity Act for the 21st Century, Public Law 105-178, 112 Stat. 547, pertaining to conformance with the National Intelligent Transportation Systems Architecture and Standards. D.3.2 Definitions Intelligent Transportation Systems (ITS) means electronics, communications or information processing used singly or in combination to improve the efficiency or safety of a surface transportation system. ITS project means any project that in whole or in part funds the acquisition of technologies or systems of technologies that provide or significantly contribute to the provision of one or more ITS user services as defined in the National ITS Architecture. Major ITS project means any ITS project that implements part of a regional ITS initiative that is multi-jurisdictional, multi-modal, or otherwise affects regional integration of ITS systems. National ITS Architecture (also ‘‘national architecture’’) means a common framework for ITS interoperability. The National ITS Architecture comprises the logical architecture and physical architecture which satisfy a defined set of user services. The National ITS Architecture is maintained by U.S. DOT (Department of Transportation) and is available on the DOT web site at http:// frwebgate.access.gpo.gov/cgi-bin/leaving.cgi?from=leavingFR.html&log= linklog&to=http://www.its.dot.gov. Project level ITS architecture is a framework that identifies the institutional agreement and technical integration necessary to interface a major ITS project with other ITS projects and systems. Region is the geographical area that identifies the boundaries of the regional ITS architecture and is defined by and based on the needs of the participating agencies and other stakeholders. A region can be specified at a metropolitan, Statewide, multi-State, or corridor level. In metropolitan areas, a region should be no less than the boundaries of the metropolitan planning area. 270 APPENDIX D Regional ITS architecture means a regional framework for ensuring institutional agreement and technical integration for the implementation of ITS projects or groups of projects. Systems engineering is a structured process for arriving at a final design of a system. The final design is selected from a number of alternatives that would accomplish the same objectives and considers the total life-cycle of the project including not only the technical merits of potential solutions but also the costs and relative value of alternatives. D.3.3 Policy ITS projects shall conform to the National ITS Architecture and standards in accordance with the requirements contained in this part. Conformance with the National ITS Architecture is interpreted to mean the use of the National ITS Architecture to develop a regional ITS architecture in support of integration and the subsequent adherence of all ITS projects to that regional ITS architecture. Development of the regional ITS architecture should be consistent with the transportation planning process for Statewide and Metropolitan Transportation Planning (49 CFR part 613 and 621). D.3.4 Applicability (a) All ITS projects that are funded in whole or in part with the Highway Trust Fund (including the mass transit account) are subject to these provisions. (b) The Secretary may authorize exceptions for: (1) Projects designed to achieve specific research objectives outlined in the National ITS Program Plan under section 5205 of the Transportation Equity Act for the 21st Century or the Surface Transportation Research and Development Strategic Plan developed under section 5208 of Title 23, United States Code; or (2) The upgrade or expansion of an ITS system in existence on the date of enactment of the Transportation Equity Act for the 21st Century if the Secretary determines that the upgrade or expansion– a. Would not adversely affect the goals or purposes of Subtitle C (Intelligent Transportation Systems) of the Transportation Equity Act for the 21st Century and b. Is carried out before the end of the useful life of such system; and c. Is cost-effective as compared to alternatives that would meet the conformity requirement of this rule (c) These provisions do not apply to funds used for Operations and Maintenance of an ITS system in existence on June 9, 1998. APPENDIX D D.3.5 271 Regional ITS Architecture (a) A regional ITS architecture shall be developed to guide the development of ITS projects and programs and be consistent with ITS strategies and projects contained in applicable transportation plans. The National ITS Architecture shall be used as a resource in the development of the regional ITS architecture. The regional ITS architecture shall be on a scale commensurate with the scope of ITS investment in the region. Provision should be made to include participation from the following agencies, as appropriate, in the development of the regional ITS architecture: Highway agencies; public safety agencies (e.g., police, fire, emergency/medical); transit agencies; federal lands agencies; state motor carrier agencies; and other operating agencies necessary to fully address regional ITS integration. (b) Any region that is currently implementing ITS projects shall have a regional ITS architecture February 7, 2005. (c) All other regions not currently implementing ITS projects shall have a regional ITS architecture within four years of the first ITS project for that region advancing to final design. (d) The regional ITS architecture shall include, at a minimum, the following: (1) A description of the region; (2) Identification of participating agencies and other stakeholders; (3) An operational concept that identifies the roles and responsibilities of participating agencies and stakeholders in the operation and implementation of the systems included in the regional ITS architecture; (4) Any agreements (existing or new) required for operations, including at a minimum those affecting integration of ITS projects; interoperability of different ITS technologies, utilization of ITS- related standards, and the operation of the projects identified in the regional ITS architecture; (5) System functional requirements; (6) Interface requirements and information exchanges with planned and existing systems and subsystems (for example, subsystems and architecture flows as defined in the National ITS Architecture); (7) Identification of ITS standards supporting regional and national interoperability; (8) The sequence of projects required for implementation of the regional ITS architecture. (e) Existing regional ITS architectures that meet all of the requirements of section V (d) shall be considered to satisfy the requirements of V (a). 272 APPENDIX D (f) The agencies and other stakeholders participating in the development of the regional ITS architecture shall develop and implement procedures and responsibilities for maintaining the regional ITS architecture, as needs evolve within the region. D.3.6 Project Implementation (a) All ITS projects funded with mass transit funds from the highway trust fund shall be based on a systems engineering analysis. (b) The analysis should be on a scale commensurate with the project scope. (c) The systems engineering analysis shall include, at a minimum: (1) Identification of portions of the regional ITS architecture being implemented (or if a regional ITS architecture does not exist, the applicable portions of the National ITS Architecture). (2) Identification of participating agencies’ roles and responsibilities; (3) Requirements definitions: (4) Analysis of alternative system configurations and technology options to meet requirements; (5) Analysis of financing and procurement options; (6) Identification of applicable ITS standards and testing procedures; and (7) Procedures and resources necessary for operations and management of the system; (d) Upon completion of the regional ITS architecture required in section V, the final design of all ITS projects funded with highway trust funds shall accommodate the interface requirements and information exchanges as specified in the regional ITS architecture. If the final design of the ITS project is inconsistent with the regional ITS architecture, then the regional ITS architecture shall be updated as per the process defined in V (f) to reflect the changes. (e) Prior to completion of the regional ITS architecture, any major ITS project funded with highway trust funds that advances to final design shall have a project level ITS architecture that is coordinated with the development of the regional ITS architecture. The final design of the major ITS project shall accommodate the interface requirements and information exchanges as specified in this project level ITS architecture. If the project final design is inconsistent with the project level architecture, then the project level ITS architecture shall be updated to reflect the changes. The project level ITS architecture is based on results of the systems engineering analysis, and includes the following: (1) A description of the scope of the ITS project (2) An operational concept that identifies the roles and responsibilities APPENDIX D 273 of participating agencies and stakeholders in the operation and implementation of the ITS project; (3) Functional requirements of the ITS project; (4) Interface requirements and information exchanges between the ITS project and other planned and existing systems and subsystems; and (5) Identification of applicable ITS standards (f) All ITS projects funded with Mass Transit Funds from the Highway Trust Funds shall use applicable ITS standards and interoperability tests that have been officially adopted through rulemaking by the United States Department of Transportation (US DOT). (g) Any ITS project that has advanced to final design by (effective date of policy) is exempt from the requirements of VI. D.3.7 Project Oversight (a) Prior to authorization of Mass Transit Funds from the Highway Trust Fund for acquisition or implementation of ITS projects, grantees shall self-certify compliance with sections V and VI. Compliance with this policy shall be monitored under normal FTA oversight procedures, to include annual risk assessments, triennial reviews, and program management oversight reviews as applicable. (b) Compliance with the following FTA Circulars shall also be certified: C5010.1C, Grant Management Guidelines C6100.1B, Application Instructions and Program Management Guidelines D.3.8 FTA Guidance FTA will develop appropriate guidance materials regarding the National ITS Architecture Consistency Policy. Issued on: January 2, 2001. Nuria I. Fernandez, Acting Administrator. [FR Doc. 01-392 Filed 1-501; 8:45 am] BILLING CODE 4910-57-P APPENDIX E WEIBULL DISTRIBUTION SUPPORT T his appendix provides support on using the Weibull hazards model as presented in Chapters and 5. The material provides examples of the distribution shape and other useful formulas for your reference. As presented in Chapter 5, the Weibull distribution takes the form shown in equation E.1. k x k1 ðx=lÞk ðE:1Þ e f ðx; k; lÞ ¼ l l There are three variables, x which represents time, k which represents the shape, and l represents the scale. It is important to understand that the variable k is closely related to the failure rate of the system being plotted. For example, if the failure rate of a system decreases over time, then k will be less than 1; if the failure rate is constant, the k will equal 1; and if the failure rate increases as time goes on, the k will be greater than 1. Further, when k ¼ 1, meaning that the failure rate is constant over time, the Weibull distribution reduces to the exponential distribution. Figure E.1 illustrates that the Weibull distribution can be bell-shaped and shows how the distribution begins to skew when it either gets too close or too far from the time 0. Adjusting both k and l influences these characteristics. Other useful equations derived from the Weibull distribution are: The failure rate, or hazard rate, is found with k x k1 hðx; k; lÞ ¼ l l Transportation Infrastructure Security Utilizing Intelligent Transportation Systems R. Fries, M. Chowdhury and J. Brummond Copyright © 2009 John Wiley & Sons, Inc. 274 APPENDIX E 275 0.350 0.300 Probability 0.250 0.200 λ=3 k=2 λ=5 k=3 0.150 λ=7 k=4 λ=10 k=5 0.100 0.050 0.000 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Time (years) Figure E.1 Example Weibull Distributions. The cumulative distribution is found with f ðx; k; lÞ ¼ 1 eðx=lÞ k It is also useful to understand that a three-variable Weibull distribution also exists. In this version of the Weibull distribution, k and l represent the same characteristics, but a third variable, u, provides a location parameter. The general form of the three-parameter Weibull probability distribution function is as follows. k k x u k1 ðxu f ðx; k; l; uÞ ¼ e lÞ l l The cumulative probability distribution function is: xu k f ðx; k; l; uÞ ¼ 1 eð l Þ Other applications of the Weibull distribution, particularly in the life sciences, use different variables. These applications function the same way. To understand them, simply match each variable to the definition as a shape parameter, a scale parameter, or a location parameter. INDEX Access control, 9, 14, 16–19, 52, 54, 71, 75, 106–108, 116, 123, 125, 129– 131, 179, 180 gates, 24, 155 information, 39, 104, 127 limited, 7, 27 management, 157 mode of, 79–82 reversible lane, 23 scene, 35, 63, 65 Accountability, 105, 107, 123–130, 173, 181 Acoustic sensors, 165 Ad hoc network, 115, 155 Advanced encryption standard, 111, 115 public transportation systems (APTS), 33 Railroad Grade Crossing Market Package, 50 Airport, 146–148, 154–156 Airport Cooperative Research Program (ACRP), 155 parking facilities, 147, 154–156 shuttles, 155 Algorithms Encryption /Decryption, 110–112, 119 RSA, 102, 111 Amber alert, 49, 154 American Association of State Highway and Transportation Officials (AASHTO), 15, 17, 133–134, 192 National Standards Institute (ANSI), 133–134 Public Transportation Association (APTA), 133–134, 136 Society for Testing and Materials (ASTM), 133–134 Analytic Hierarchy Process (AHP), 77 AND gate, 66–68, 86 Architecture flow, 33 Archived data management, 139 Assets critical, 17, 61–64, 126, 174–176, 178, 185 fixed, 6, 49 management, 12, 141 network, 106 Attack biological, 22, 152 cyber, 23 deliberate, 60–66, 75, 84, 94, 103, 108, 198 terrorist, 15–19, 62, 94, 115, 189 At–risk population, 10, 69, 94, 147 Auditing, 106, 123, 125, 130, 179 Transportation Infrastructure Security Utilizing Intelligent Transportation Systems R. Fries, M. Chowdhury and J. Brummond Copyright © 2009 John Wiley & Sons, Inc. 277 278 INDEX Authentication Challenge–Handshake Authentication Protocol, 136, 181 commercial vehicle driver, 46–47, 164, 165 identity, 106, 109, 112–113, 123, 125, 129, 137 personnel, 156 Automatic vehicle location (AVL), 141, 155 Availability communication, 22 data, 72, 85, 107–109, 125 electric, 157 parking, 147 personnel, 62 roadway, 62 as a security objective, 114, 123–124, 130–131, 172, 175–179 Basic event, 84–86, 89 Behavioral curves, 95 Benefit–cost analysis, 71, 82, 84, 108, 181 Biological agent, 22, 152 Blackout, 20 Blue ribbon panel method, 4, 65, 74–84 Boolean algebra, 66, 85–87 Bridges, 4–7, 17, 20, 39, 65, 74, 159, 179, 192 Canine Inspection, 148–149, 157, 162, 164 Cargo, 43–45, 162–165 Cellular phones, 56, 115, 192 Challenge–Handshake Authentication Protocol (CHAP). See Authentication Chemical attacks, 22, 35–36, 52, 150– 151, 153, 165 Ciphertext, 110–113 Closed circuit TV (CCTV), 24 CodeRed, 104 Commercial vehicle (CV) Administrative Processes Market Package, 45–46 check station (CVCS), 46 Driver Security Authentication Market Package, 46–48 Information Exchange Window System (CVIEW), 138–139 Information Systems and Networks (CVISN), 41 Communication network simulation, 69 security, 103 Computer aided dispatch (CAD), 141 Computer system security, 103 Concept of operation (CONOPS), 182–185 Confidentiality, 108–110, 116, 123, 125, 128, 130–131 Congestion, 10, 56, 162, 190, 195 Containers, 40, 41, 162, 165 Contra–flow, 94–99. See also Lane reversal CORSIM, 147 Cost effective, 10, 28, 181 Cost–sharing, 193 Countermeasures, 17, 61–64, 70–71, 107, 121, 125, 179, 186 Credentials, 41, 45–47, 105–106, 138, 156 Critical assets. See Assets information, 104, 110 infrastructure / systems, 2, 5–6, 16, 58, 63–64, 72, 173 CT scan, 148–149 Cyber attack. See Attack Data archive, 128–129, 134, 139 Deception, 124, 129, 131, 178 Decision matrix, 71 Decryption, 109–113 Dedicated short range communication (DSRC), 134, 139–140 INDEX Deliberate attack. See Attack Denial of service, 114, 124 Department of Defense (DOD). See United States Department of Homeland Security (DHS). See United States Department of Justice (DOJ). See United States Department of Motor Vehicle (DMV), 191–192 Derailment, 17, 23 Digital signature transponder, 115 Disaster Response and Evacuation security area (DRE), 34–40 Disaster Response and Recovery market package, 37–38 Disaster Traveler Information market package, 39–40 Disruption, 104, 114, 124, 131 Early Warning System market package, 36, 37 Earthquakes, 15, 17–18 Electronic fare payment system / toll collection (ETC), 7–8, 38, 48–49, 108, 110, 115, 128 tag information, 45 Emergency management (EM), 87, 108, 112, 128, 150, 175, 179, 195 management subsystem (EMS), 33–50, 52–54 operations center (EOC), 6, 8, 35, 42–46, 55 Encryption, 109–113 En–route travel information, 141 Equipment package (EP), 32 Evacuation and Reentry Management market package, 38–39 route, 39, 75, 94, 99, 191 eXtensible Markup Language (XML), 134–136, 138, 142 279 Fault-tree analysis, 65–67, 74, 84–93 handbook, 89 Fires, 17–18 Firewall, 106, 116, 135, 139 Federal Aviation Administration (FAA), 155 Highway Administration (FHWA), 5, 7, 134, 190, 195 Highway administration rule 940.11, 28 Motor Carrier Safety Administration (FMCSA), 41, 138 Transit Administration (FTA), 72, 150, 190, 196 Fleet Administration Market Package, 42, 46 Fleet and Freight Management Subsystem (FMS), 41–43 Floods, 1, 10, 17, 22–23, 35, 94 connection (computer network), 114, 116 Florida, 35 Central Florida Regional Transportation Authority, 156 Department of Transportation, 37 Miami–Dade County, 16–18 Freeway and incident management systems (FIMS), 7, 24 operations, 95–97 service patrols (FSP), 9 Freight Assignment Tracking market package and Commercial Vehicle Security, 34, 40–58 containers. See Containers maritime, 160–161 operations, 15, 128 protection, 162–166 rail, 18, 159 Funding Sources, 188–193, 195 280 INDEX Gamma ray detection systems (GRDS), 148, 152, 162–164 Geiger counter, 151 Geographic information systems (GIS), 141 Global positioning systems (GPS), 164, 196 Guide to Highway Vulnerability Assessment for Critical Asset Identification and Protection, 15 Hampton Roads, 37–39 Hazardous materials (HAZMAT), 17, 19–20, 24, 62, 132, 158, 164–165 security, 34, 44–47 Highway advisory radio (HAR), 48 rail intersection (HRI), 49–51 History attack, 27 threat, 75 Homeland Security Advisory System (HSAS), 37, 150 Human resources (HR), 188, 195–196 Hurricane, 1, 10, 16–17, 20–21, 54, 58, 69, 71, 147 evacuation planning, 94 Floyd, 17 Hampton Roads Hurricane Gates, 39 Katrina, 20–21, 35, 38, 94, 195–196 See also National Hurricane Center Identities driver, 41, 44–45, 48 freight, 41 ship, 160 user, 105, 112–113, 130–132, 135, 137 Imaging, 45 Impact assessment, 65–69 Implementation plan, 182–183 Incident biological, 3 chemical, 22, 153 command system (ICS), 6, 35, 37, 132 denial of service, 114 detection, 24, 36, 52, 195 dispatch, 49 hazardous material, 35–36 impact of, 9, 14, 16, 54, 62, 71 information, 39–40, 50, 54, 58, 113, 131–132, 148, 178, 190 management (IM), 7, 38, 55–56, 125–126, 134, 136, 140–142, 148, 159–160, 173, 190, 195 potential, 8 response, 50, 53, 55, 58, 183 scene, 8, 14, 189 security, 5, 25–28, 43, 54, 94, 126, 141–142, 150, 152–153, 156, 171, 173 traffic incident management system (TIMS), 50–52 Inductive loop detectors (ILD), 93 Information collection, 1 commercial. See Commercial vehicle disaster traveler, 39 dissemination, 7, 17, 24, 35, 115, 146–147, 150, 190, 196 evacuation, 38–40 flows, 32, 34–35, 108, 122, 129– 130, 133, 174, 178–179, 182 management, 117, 137, 189 material, 19 modification, 129 personal, 24, 40, 104, 123, 127 real–time, 7–8, 22 security, 4, 125–126, 129, 143, 176, 179, 189 service provider (ISP), 32–33, 36, 42, 128 sharing / sharing agreements, 6, 36, 38, 103, 147, 173, 177–180, 193 Sharing and Analysis Centers (ISAC) INDEX surveillance. See Surveillance technology, 18, 127, 134 traveler, 8, 36, 40, 128, 136, 142–143, 157 Infrared sensors, 154, 157, 162 Institute of Electrical and Electronics Engineers (IEEE), 133 of Transportation Engineers (ITE), 133 Integrity, 107–110, 113–114, 116– 117, 123–125, 128–131 Interchangeability, 166 Internet protocol (IP) address, 113 Interoperability, 6, 28, 56, 134, 138, 164, 166, 173, 180, 182, 185–186 In-vehicle information, 48, 147 Intelligent Transportation Systems (ITS) America, 196 Architecture, 10, 31–58, 109, 120–125, 138, 152, 164–166, 176–183, 193, 196 communication security, 128–132 control of, 23 functions, 9, 120 infrastructure, 20, 28, 61, 195–196 integration, 172 Joint Program Office, 133, 190 legacy systems, 185 network security, 108, 116 operational security, 126 perception of, 153, 195 personnel security, 125–126 planning, 171–172, 197 professionals, 102, 115, 117 redundancy, 114 regional, 105, 123, 153, 172–178, 192 security areas, 31, 120, 155, 159, 162, 173 security management, 126–127 security vs. privacy, 188 281 securing subsystems, 127, 173 standards, 28, 117, 120, 133–143, 179–183 wireless applications, 115 Lane reversal, 9, 20, 39, 96, 147 License driver’s, 191–192 plate recognition, 154–155 Likelihood, 61, 65, 75, 89, 122, 179, 182 Liquid cargo, 165 Local area network (LAN), 139 Logical architecture, 32 Maintenance and construction operations (MCO), 35–38, 48, 52 Maritime Transportation Security Act (MTSA), 156 Market package (MP), 31 Mayday, 52 Melissa Virus, 104 Message Integrity, 113, 125 Microscopic traffic simulation models, 69, 147 Military freight, 165–166 Minimal cut sets, 89–93 Mitigation, 46–47, 62, 70, 79–80, 83, 195 Mitigating options, 60, 63–64, 70–71 Monte Carlo analysis, 69–70, 99 Mutually exclusive, 85–87 National Electrical Manufacturers Association (NEMA), 133–134 Hurricane center (NHC), 36 Infrastructure Protection Center (NIPC), 37 Institute of Standards and Technology (NIST), 107, 143 ITS Architecture. See Intelligent Transportation Systems Response Team (NRT), 6 282 INDEX National (Continued ) Transportation Communications for ITS Protocol (NTCIP), 133–137, 140, 142 Warning System (NAWAS), 36 Weather Service (NWS), 36 Nerve agents, 22, 151 Network surveillance market package, 32–33 Non-repudiation, 107, 109, 113, 116, 130 Operational security, 12, 66, 125–126 Optical variable device, 192 OR gate, 66–68, 85–87 Packet sniffing, 116 PARAMICS, 147 Participation rate, 94 Passenger screening procedures, 146, 148 Perception of security, 153 Physical architecture, 31–32, 35 Plaintext, 110–113 Policy, 4, 28, 56, 62, 103–106, 116– 117, 126, 141, 166, 172, 177, 189 Ports, 7, 15, 160–164, 191 Privacy, 107, 155, 166, 188–189 Private key, 110–112 Privileges, 105–106, 130 Public key, 110–112 Publicity, 65–66, 171 Pulsed Fast Neutron Analysis (PFNA), 162–164 Quantitative evaluation, 85–89 Radiation detection systems (RDS), 151–152 Radio frequency identification device (RFID), 115 Railroad Operations Coordination Market Package, 51–54 Rail security, 58–59 Ranking alternatives, 61, 71, 75, 78–83 Recommended controls, 105–107 Redundancy for security, 14, 22, 24 of ITS devices, 114 route, 62, 181 traffic management center, 62 unneeded, 191 Regional ITS architecture, 172–186 Research and Innovative Technology Administration (RITA), 190 Responsibilities, 28, 107, 126, 136, 173–177, 183–184, 192, 196 Resource sharing, 2, 193–194 Remote sensing, 45 Remote Traveler Support (RTS), 36, 39–40, 53–54 Risk at–risk, 5, 10, 19, 24, 147, 160 analysis / assessment (RA), 15, 61–72, 74–94, 122, 174, 180 management (RM), 16, 60–61 man–made, 1 mitigation, 24, 182 Roadside HAZMAT Security Detection and Mitigation Market Package, 46–47 Roles, 35, 126, 174–177, 183–185, 189–192 SAFETEA–LU, 190 Safety and Fitness Electronic Records (SAFER), 138–139 Security architecture, 117, 128–132, 153–154, 173, 177, 181 areas, 31–54, 120, 127, 154, 162–173 boundaries, 16, 174, 177–178, 185 breach, 120 bridge and tunnel, 74–84 business process, 140, 142 center to center, 143 checkpoint, 16 INDEX communication, 103, 115, 156 computer network, 103–112, 117, 171, 175 concept of, 1–4, 122 countermeasures, 63, 71 design for, 153 drills, 16, 22, 24, 190 of fare collection and revenue management, 142 framework, 82, 173 freight and commercial vehicle, 40–44 group, 129 HAZMAT, 44–47, 159, 164 inspections, 16 level of, 65–66, 75, 178 liquids, of, 165 management, 127, 154–156 mechanisms, 127, 135, 143, 172–176, 179–185 monitoring, 54, 128 needs, 15, 183–185 objectives, 103, 109, 117, 121–124, 129, 131–132, 174–183 obscurity, 127 parking lots, of, 155 perception of, 1–2, 153 plan, 69, 94, 104, 117, 171–173, 181, 185 policy, 103, 105–106, 116, 137, 172, 178 protocols, 102, 136 rail, 49–50, 159 requirements, 104, 176–177, 180, 185 responsibilities, 28 safety, and, 159 screening, 16, 149–153, 162–164 services, 122, 125–132, 139, 173–174, 179–183 standards, 175, 179–180, 185 training. See Security drills transit, 50–53, 141, 156 transportation infrastructure security area, 54 283 transport layer, 111, 135 traveler, 57–58 versus privacy, 188–189 sensitive information, 123 Ships, 5, 149–151, 160–162, 165 Simple Fixed Message Protocol (SFMP), 136–137 Simple Network Management Protocol (SNMP), 136–137 Simple Object Access Protocol (SOAP), 134–136 Simple Transportation Management Protocol (STMP), 136–137 Simulation analysis, 68–69, 95–99, 148 Slammer worm, 104 Smart Traffic Center (STC), 54–56 Society of Automotive Engineers (SAE), 134 Spoofing, 113 Stakeholders, 6, 10, 15, 62, 64, 77–78, 105, 138, 172–176, 181–183, 192–193 Standard development organization (SDO), 133 Standard Railroad Grade Crossing Market, 51 Storm surge, 21 Subway, 16–22, 27, 150–153, 157 Supervisory control and data acquisition (SCADA), 104 Surveillance, 17, 62, 194 bridge, 71 business, 8 closed circuit television, 24 commercial vehicle, 40 control, 33, 36, 52 freeway, 7 market package, 32 network, 33 parking facilities, of, 154–155 rail, 50, 159, 188 sharing, 194 toll, 8 transit, 8, 16, 52–53, 155–157 284 INDEX Terminator, 32 Terrorist attacks, 2–3, 5, 9, 15–18, 22, 58, 62–63, 115, 120, 156, 158–159, 173, 179, 189 Thermal Neutron Activation, 162–164 Threat(s) analysis, 174, 179 categories, 176, 178 common, 17–24 deliberate, 1, 61–62 deterring, 63 history of, 65–66, 75 identifying, 2, 64, 80, 108, 121, 174, 176–177, 181–185 information, 36, 42–45, 53–54, 57, 150, 194 management of, 27, 115, 193 network security, 104 ranking, 123 regional, 26 sensors, environmental, 42, 52–54, 164 Timetable, 105, 107–108 Toll administration, 38, 49, 128, 192 advisories, 132 automated, 108, 115 collection, 8, 110, 128, 189 Traceability–based ITS planning, 185 Trace detection systems, 148, 150–152, 162, 164 Trade associations, 192 Traffic assignment, 8 camera. See Surveillance control, 9, 15, 37, 39, 62 demands, 8, 61, 147 engineering, 6 flow, 6–8, 33, 105, 189 incidents, 24, 50–52, 159, 189 management, 10, 17, 21, 32, 35–39, 49–58, 69, 89, 115, 117, 128, 147, 160, 189, 195 management center (TMC), 14–15, 20, 23–24, 62, 68, 87, 108, 110, 113, 133, 175, 177, 194, 196 management data dictionary (TMDD), 134, 136 message, 106 military, 166 monitoring, 8 re–routing, 7, 9, 69, 191 sensors, 17, 33, 108, 117 signals, 17, 20, 24 simulation models, 69, 94–99, 147 Trailers, 40, 43 Transit Communications Interface Profiles (TCIP), 134, 136, 140–142 control, 15 emergency services, 8 Management and Emergency Management subsystems management, 7, 24, 37–39, 47–49, 128 Massachusetts Bay Transit Authority, 5 public /mass, 5, 6, 16, 18, 20, 27, 147, 149–153, 156–158, 191 Security Market Package, 33–34, 50–54 station, 16, 58, 188 vehicle, 127, 155, 196 Vehicle and Emergency Management subsystems, 53 Vehicle and Transit Management subsystems, 53 Transportation Information Architecture Flows, 129 Infrastructure Protection market package, 57 Infrastructure Security, 34, 54–57 management protocols (TMP), 136–137 regional and state agencies, 6 Security Administration (TSA), 28, 150, 153, 156, 191 INDEX Traveler advanced traveler information system (ATIS), 134, 136, 142 information, 8, 21, 23, 36, 39, 48, 55, 108, 128, 143, 147, 157 remote support, 49, 54, 127 security, 34, 57–58 Tunnel, 4–5, 17–18, 39, 58, 65, 74–84, 158–159, 163–164 Turbo Architecture, 180 Ultrasonic detectors, 165 Unauthorized disclosure, 123–125, 130 Uncertainty, 61, 70 Unified command (UC), 6 United States Center for Wireless Communications (USCWC), 115 Department of Defense (USDOD), 149–150, 164 Department of Homeland Security (USDHS), 15, 28, 64, 150, 191, 193 Department of Justice (USDOJ), 150 Department of Transportation (USDOT), 17, 34, 133, 150, 172, 183, 190 Usurpation, 124 285 Vapor detection systems, 148–151, 162 Variable message signs (VMS)/ dynamic message sign (DMS), 20, 48, 55, 147 Venn diagram, 87 Video surveillance. See Surveillance Virginia Department of Transportation (VDOT), 39, 54–56 VISSIM, 147 Visual inspections, 62–63 Volpe National Transportation System Center (VNTSC), 139 Vulnerability assessment, 163 Washington, D.C. Metropolitan Area Transit Authority (WMATA), 158 Weibull Hazard Models, 70, 93–94 Web Service Definition Language (WSDL), 134–136 Wide area alert market package, 48–49 Wi–Fi, 115 WiMAX, 115 Wireless, 89, 108, 115–117, 139, 154–157, 194 X–Ray, 148–149 XML. See eXtensible Markup Language

Log In

TRANSPORTATION INFRASTRUCTURE SECURITY UTILIZING INTELLIGENT TRANSPORTATION SYSTEMS

TRANSPORTATION INFRASTRUCTURE SECURITY UTILIZING INTELLIGENT TRANSPORTATION SYSTEMS

Related Papers

RELATED PAPERS