cybersecurity literature review and …onlinepubs.trb.org/onlinepubs/...literature_review.pdf ·...

CYBERSECURITY LITERATURE REVIEW

AND EFFORTS REPORT

Prepared for:

NCHRP Project 03-127

Cybersecurity of Traffic Management Systems

Prepared by:

Marisa C. Ramon

Daniel A. Zajac

SOUTHWEST RESEARCH INSTITUTE®

Intelligent Systems Division

Post Office Drawer 28510, 6220 Culebra Road

San Antonio, Texas 78228-0510

(January, 2018)

The information contained in this report was prepared as part of NCHRP Project 03-127, National

Cooperative Highway Research Program.

SPECIAL NOTE: This report IS NOT an official publication of the National Cooperative Highway

Research Program, the Transportation Research Board, or the National Academies of Sciences,

Engineering, and Medicine.

Acknowledgements (include in report)

This study was conducted with funding provided through the National Cooperative Highway

Research Program (NCHRP) Project 03-127, Cybersecurity of Traffic Management Systems.

The NCHRP is supported by annual voluntary contributions from the state Departments of

Transportation. Project 03-127 is developing guidance for state and local transportation agencies

on mitigating the risks from cyber-attacks on the field side of traffic management systems

(including traffic signal systems, intelligent transportation systems, vehicle-to-infrastructure

systems (V2I), and closed-circuit television systems) and, secondarily, on informing the agency’s

response to an attack. This document summarizes a variety of efforts applicable to the objective

and will be updated throughout the life of the project. The report was prepared by Daniel Zajac

and Marisa Ramon of the Southwest Research Institute. The work is being guided by a technical

working group and managed by Ray Derr, NCHRP Senior Program Officer.

Disclaimer (include in report)

The opinions and conclusions expressed or implied are those of the research agency that

performed the research and are not necessarily those of the Transportation Research Board or its

sponsoring agencies. This report has not been reviewed or accepted by the Transportation

Research Board Executive Committee or the National Academies of Sciences, Engineering, and

Medicine; or edited by the Transportation Research Board.

NCHRP 03-127 Task 1 - Security Literature Review and Efforts Report Cybersecurity of Traffic Management Systems Final

January 12,2018 of 48

TABLE OF CONTENTS

PAGE

EXECUTIVE SUMMARY ....................................................................................................................... 6

1. INTRODUCTION ......................................................................................................................... 7

Project Background .......................................................................................................................... 7

Project Goals .................................................................................................................................... 7

Purpose of this Document ............................................................................................................... 7

2. SECURITY STANDARDS AND BEST PRACTICES .............................................................................. 8

Standards ......................................................................................................................................... 8

2.1.1 ISO/IEC JTC 1/SC 27 – IT Security Techniques ......................................................................... 8 2.1.1.1 ISO/IEC 15408 - Common Criteria .................................................................................... 8 2.1.1.2 ISO/IEC 27000 Series - ISMS Family of Standards ............................................................ 9 2.1.1.3 ISO/IEC DIS 29147 Vulnerability disclosure and ISO/IEC 30111 Vulnerability Handling Process 9 2.1.1.4 ISO/IEC 29100:2011 Privacy Framework ....................................................................... 11

2.1.2 IEC 61508 Functional Safety of Electrical/Electronic/Programmable Electronic Safety-related Systems .................................................................................................................................. 11 2.1.3 SAE J3061 Cybersecurity Guidebook for Cyber-Physical Vehicle Systems ............................ 12

Capability Models and Frameworks............................................................................................... 12

2.2.1 NIST Cyber Physical Systems Framework .............................................................................. 12 2.2.2 DHS Cybersecurity Capability Maturity Model (C2M2) ......................................................... 13 2.2.3 Center for Internet Security's (CIS) Critical Security Controls (CSC) ..................................... 14 2.2.4 OWASP Application Security Verification Standard (ASVS) .................................................. 14 2.2.5 NIST Cybersecurity Framework (CSF) .................................................................................... 15

2.2.5.1 Federal Information Processing Standards (FIPS) Publication 200 ................................ 15 2.2.5.2 Framework for Improving Critical Infrastructure Cybersecurity ................................... 15

Past Studies, Research Efforts, and Reports .................................................................................. 18

2.3.1 Issues in Autonomous Vehicle Deployment .......................................................................... 18 2.3.2 Cyber security challenges in Smart Cities: Safety, security and privacy ............................... 18 2.3.3 US-CERT Critical Infrastructure Cyber Community (C3) Voluntary Program ......................... 18 2.3.4 DHS Study on Mobile Device Security ................................................................................... 19

Best Practices and Guidance .......................................................................................................... 19

2.4.1 DHS Roadmap to Secure Control Systems in the Transportation Sector .............................. 19 2.4.2 Transportation Industrial Control Systems (ICS) Cybersecurity Standards Strategy ............ 20 2.4.3 TSS Cybersecurity Framework Implementation Guidance ................................................... 20 2.4.4 TRB Guidebook on Best Practices for Airport Cybersecurity ................................................ 21 2.4.5 National Infrastructure Protection Plan (NIPP) ..................................................................... 21 2.4.6 APTA Cybersecurity Considerations for Public Transit .......................................................... 22 2.4.7 Surface Transportation Cybersecurity Toolkit ...................................................................... 22 2.4.8 NHTSA Cybersecurity Best Practices for Modern Vehicles ................................................... 22 2.4.9 Protection of Transportation Infrastructure from Cyber Attacks: A Primer ......................... 22 2.4.10 Airport Cooperative Research Program Guidebook on Best Practices for Airport Cybersecurity ...................................................................................................................................... 23

Working Groups ............................................................................................................................. 23


January 12, 2018 of 48

2.5.1 Automotive Information Sharing and Analysis Center (Auto-ISAC) ...................................... 23 2.5.2 United States Computer Emergency Readiness Team (US-CERT) ......................................... 23 2.5.3 Industrial Control Systems Computer Emergency Readiness Team (ICS-CERT) ................... 24 2.5.4 Critical Infrastructure Partnership Advisory Council (CIPAC) ................................................ 24 2.5.5 SAE Automotive Systems Security Committee ..................................................................... 25 2.5.6 Transportation System Cybersecurity Framework (TSCF) Partnership ................................. 25 2.5.7 CTIA Cybersecurity Working Group....................................................................................... 25 2.5.8 Harmonization Task Groups (HTGs) ...................................................................................... 26

2.5.8.1 HTG1 & HTG3: ITS Security and Communication Protocols........................................... 26 2.5.8.2 HTG2: Harmonization of US Basic Safety Message (BSM) and EU Cooperative Awareness Message (CAM) ........................................................................................................... 27 2.5.8.3 HTG4/5: Infrastructure Messages .................................................................................. 27 2.5.8.4 HTG6: Cooperative ITS Security Policy ........................................................................... 27 2.5.8.5 HTG7: Standards Selection, Gap Analysis, and Identifiers for Connected Vehicle (CV) architectures .................................................................................................................................. 27

3. UNITED STATES DEPARTMENT OF TRANSPORTATION (USDOT) RELATED PILOT PROGRAMS AND ARTIFACTS ....................................................................................................................................... 28

National Highway Traffic Safety Administration (NHTSA) ............................................................. 28

3.1.1 Security Credential Management System (SCMS) ................................................................ 28

Federal Highway Administration (FHWA) ...................................................................................... 31

CV Safety Pilot Model Deployment Program (SPMD) .................................................................... 31

CV Safety Pilot Sites ....................................................................................................................... 31

3.4.1 New York City (NYC) DOT Pilot Site ....................................................................................... 32 3.4.2 Tampa-Hillsborough Expressway Authority (THEA) Pilot Site ............................................... 32 3.4.3 Wyoming (WY) DOT Pilot Site ............................................................................................... 32

4. STATE AND LOCAL RELATED PROGRAMS AND ARTIFACTS ......................................................... 34

5. OTHER RELATED TECHNOLOGIES AND DATA SOURCES .............................................................. 35

NIST National Vulnerability Database (NVD) ................................................................................. 35

NISTIR 8138 Vulnerability Description Ontology (VDO) ................................................................ 35

CybOXTM, STIXTM, and TAXIITM ........................................................................................................ 35

Cyber Security Assessment & Management (CSAM) ..................................................................... 35

6. CONCLUSION ........................................................................................................................... 36

7. REFERENCES ............................................................................................................................ 37

APPENDIX A – ATTACHED



TABLE OF FIGURES

PAGE

Figure 1. Mapping of ISO/IEC 29147 and ISO/IEC 30111 [6] ....................................................................... 10

Figure 2. Vulnerability Information Exchange [6] ....................................................................................... 11

Figure 3. IEC 61508 and Related Standards ................................................................................................ 12

Figure 4. CPS Framework Domains ............................................................................................................. 13

Figure 5. CPS Conceptual Model ................................................................................................................. 13

Figure 6. Framework Core Functions [13] ................................................................................................... 16

Figure 7. Framework Implementation Tiers ............................................................................................... 16

Figure 8. Highway/Roadway Network System [18] .................................................................................... 20

Figure 9. NIPP Risk Management Framework and Data Flow .................................................................... 21

Figure 10. Simplified SCMS Architecture Design [36] ................................................................................. 29

Figure 11. SCMS Roadmap [37] ................................................................................................................... 30



EXECUTIVE SUMMARY

This document summarizes a variety of cybersecurity efforts applicable to the development of a state and local agency web based guidance tool and provides a fresh overview of cybersecurity efforts in the traffic management and related domains. The goal of this document is to inform readers of:

• The ongoing cybersecurity efforts in traffic management • Current state of the art security regarding TMS and V2X Technologies • Cybersecurity efforts in adjacent domains that may be applicable to TMS • Desired future security state of these systems and technologies • Identify resources in the web guidance development

Security standards and best practices are the basis of recommendations for web guidance tool development. Lessons learned can be obtained by reviewing adjacent domains efforts, such as airport or public transit. The capability models and frameworks can be researched to identify the best possible organizational cybersecurity programs.

Much organizational guidance is based on the National Institute Standards and Technology (NIST) Cybersecurity Framework (CSF). Since the NIST CFS was developed to be flexible and applicable to a wide variety of organizations, the parent guidance is focused on general policy requiring extensive organizational specific development. A variety of best practices and guidance have been produced in this study that leverage the core principles of the NIST Framework while providing specifics to implementing the framework in each traffic management domain.

In addition, incorporating Connected Vehicle (CV) technologies into existing traffic management systems is through the use of RSU and DSRC technology. Securing the communication between devices and device-to-infrastructure is defined by IEEE standard 1609.2 and tested through the Security Credential Management System (SCMS) proof-of concept (POC). As CV pilot efforts are still ongoing, cybersecurity testing has not yet been performed and industry is still not certain whether DSRC technology will be widely adapted with the push for cellular vehicle-to-everything (V2X) technologies (i.e. 4G and 5G).

Lastly, cybersecurity efforts by state and local agencies is an area for future research. The team will be reaching out to contacts within these organizations to document any programs, ongoing research, or frameworks they have implemented. Cybersecurity is a sensitive topic at most organizations and content in this section is likely to be written to protect the organization except where permission has been given.

This document is intended to be a living document throughout the duration of this effort and will be occasionally revisited. With each revision, new sources will be added and possibly others removed. Cybersecurity is a very dynamic topic and there is considerable information that is ever evolving with new technology.



1. INTRODUCTION

Project Background

The objective of the research is to develop guidance for state and local transportation agencies on mitigating the risks from cyber-attacks on the field side of traffic management systems (including traffic signal systems, intelligent transportation systems, vehicle-to-infrastructure systems (V2I), and closed-circuit television systems) and, secondarily, on informing the agency’s response to an attack. The guidance will address the vulnerability of field devices (e.g., traffic signal controllers and cabinets, dynamic message signs, V2I roadside units, weigh-in-motion systems, road-weather information systems, remote processing and sensing units, and other IP-addressable devices), field communications networks, and field-to-center communications. It will not address vulnerabilities within a traffic management center, within center-to-center communications, or due to insider risk (accidental or intentional).

Project Goals

The goal of this project is to improve the cybersecurity posture of Traffic Management Systems (TMSs) by:

• Performing a strategic literature review and investigation of ongoing security efforts

• Review state of the art technologies across multiple disciplines

• Assess representative TMS systems and equipment

• Suggest “Red Team” high risk equipment

• Develop Guidance for state and local agencies that aids in identifying: o Risks to their current field networks o Recommended changes they may implement to reduce those risks o Implications of CV and AV technologies on the field networks o Best practices for wide deployment of CV and AV technologies

• Promote adoption and industry participation

Purpose of this Document

This document is intended to capture information regarding the current Transportation and Connected and Autonomous Vehicle (CAV) security standards and the various efforts in which these standards are being used. To keep this paper within a reasonable size, the information in the current standards and related activities is summarized and links to more information is provided as footnotes.

The resources list is not exhaustive. During the performance this project, the research team will make periodic updates to this list. Additional sources not listed below can be considered by recommending the reference to the SwRI PM.



2. SECURITY STANDARDS AND BEST PRACTICES

The following sections summarize the standards and best practices in related industries. These resources can be leveraged in the development of cybersecurity guidance for transportation management agencies. Resources listed have been collected from a variety of sources and represent cybersecurity efforts in traffic systems and adjacent domains; automotive and critical infrastructure. Their content and recommendations will be reviewed for possible incorporation into the web guidance and other deliverables under this effort.

Standards

The following sections provide a summary of standards, both draft and released, that may be applicable to this effort.

2.1.1 ISO/IEC JTC 1/SC 27 – IT Security Techniques

The ISO/IEC JTC 1/SC 27 is a collection of standards, guidelines, and best practices developed to assist organizations in addressing security and privacy concerns. The SC 27 contains an extensive collection of artifacts covering a wide breadth of security topics. While it would be out of the scope of this document to summarize all artifacts in the set, a selection of potentially relevant ones are summarized below.

2.1.1.1 ISO/IEC 15408 - Common Criteria

The Common Criteria (CC) is short for the Common Criteria for Information Technology Security Evaluation, which is international standard ISO/IEC 15408 for computer security certification. [1] Version 3.1, Revision 4, is described in three (3) documents entitled:

• Part 1: Introduction and General Model [2],

• Part 2: Security Functional Components [3],

• Part 3: Security Assurance Components [4].

Part 1 describes basic concepts and describes the specification of protection profiles (PPs), security targets (STs) and evaluation results. The CC provides a methodology for developing a common set of security functionality requirements and security assurance requirements for classes of products that may be hardware, firmware, or software. The evaluation process is intended to determine whether assurance requirements are satisfied for a specific product undergoing evaluation.

The CC does not address operational or administrative security measures or the accreditation and approval process for using the evaluation results. Some of the other specific issues which are not covered include the following:

• Physical security

• Personnel security

• Cryptographic algorithms

• System integration issues such as the role of the integrator or how the device should work with other devices

• Device evaluation outside the laboratory in an operational environment

• The role of service organizations who run a system for users and provide operations and maintenance support

• How to address newly discovered vulnerabilities



The goal of the CC is to develop a standard methodology for specifying, designing, and evaluating IT products that perform security functions. It was to be a full life-cycle, consensus-based security engineering standard.

The CC is well established and recognized in the Information Technology (IT) cybersecurity domain. Though acceptance has not been as widespread as initially planned, it has acted as the basis for a variety of attempts to employ standardized testing to cybersecurity of embedded devices. The applicability of CC to this effort would be in reviewing CC’s process for evaluating equipment and investigating its potential applicability to TMS field equipment.

2.1.1.2 ISO/IEC 27000 Series - ISMS Family of Standards

The ISO/IEC 27000 Series of standards, also known as the Information Security Management System (ISMS) Family of Standards, provides best practices and recommended guidance for implementing organizational information security management and controls. [5] The goal of the ISO/IEC 27000 series of documents was to provide generic best practices applicable to a wide variety of organizations. The ISO/IEC 27000 series is comprised of approximately 45 publications and artifacts that provide guidance and recommendations from a broad range of topics relating to security. Some artifacts developed under the series are tailored to specific organization resources such as wireless networking, cloud computing, or intrusion detection. ISO/IEC 27001:2013, ISO/IEC 27002, and ISO/IEC 27005:2011 are the most frequently referenced.

ISO/IEC27001:2013 was developed to provide the requirements for establishing and maintaining an ISO/IEC 27000 compliant information security management system. It uses language and definitions defined in ISO Annex SL which provides commonality with ISO 9001 and ISO 140001, Quality Management and Environment Management standards respectively. This relationship makes incorporation of an ISO/IEC 27000 series security management system into an organization already practicing 9001 or 140001 require less effort.

The high-level processes and organizational guidance provided by ISO/IEC 27000 series could be directly leveraged by the guidance developed under this effort. The ISO/IEC set of standards is employed by a variety of organizations. Some tailoring of the methods and procedures may be required as the ISO/IEC 9001, 140001, and 27001 are intended for originations engaged in manufacturing. SwRI has employed 9001 since approximately 2008 and later SAE AS9100 to improve institutional quality control of engineering services. These processes required tailoring to SwRI’s unique business processes but SwRI ultimately achieved ISO, then SAE accreditation, for these standards.

2.1.1.3 ISO/IEC DIS 29147 Vulnerability disclosure and ISO/IEC 30111 Vulnerability Handling Process

ISO/IEC 29147 and ISO/IEC 30111 were developed to standardize the reporting of externally discovered vulnerabilities and how to handle a reported vulnerability respectively. The intent is to formalize the processes of receiving and handling vulnerabilities to the organization or its products. Prior to the practice of establishing a vulnerability reporting process, effective reporting was difficult or ineffective. If an outsider identified problems with a web service or product, often it was difficult to identify the appropriate contact or method for reporting. This resulted in public disclosures going unnoticed or stagnation and unresponsiveness from the affected company. ISO/IEC 29147 establishes the “way” to report, while ISO/IEC 30111 establishes the “what.” Figure 1 illustrates the interaction between 29147 and 30111.



Figure 1. Mapping of ISO/IEC 29147 and ISO/IEC 30111 [6]

Examples of the ISO/IEC 29147 and 30111 processes can easily be found online. For example, Microsoft maintains their Common Vulnerabilities and Exposures (CVE) that documents findings against their products. More generically, MITRE maintains the Common Vulnerabilities and Exposures page and independent CVE Details also report 29147 type submissions among others. [7] [8]

The goals of these standards are to produce business processes and methods when receiving vulnerabilities to ensure:

• Identified vulnerabilities are addressed

• Minimize risk to stakeholders

• Users are provided with the information to evaluate their systems risk and act if necessary

• Positive communication between reporting parties and product stakeholders

When a report is initiated, a 29147/30111 organization should be able to receive and appropriately react to the report. Activities include:

• Capturing relevant configuration data

• Reproducing the vulnerability in house to verify findings

• Notify users and third parties that may be affected

• Kick-start addressing the issue and dissemination of fixes



Additionally, the affected vendor may need to work with third party vulnerability coordinators that aggregate reports from a variety of sources for many vendors. Identified vulnerabilities may not come directly from the initial reporter and therefore it is critical that pertinent and clear information regarding the report is collected. Figure 2, illustrates the information flow in a vulnerability report.

Figure 2. Vulnerability Information Exchange [6]

Standardized vulnerability reporting is relevant to any TMS security effort in a variety of ways. While reports may not come from the public at large, they will come from suppliers, security teams at other TMSs, researchers, and developers. Establishing inter-agency procedures within each organization will make responding to vulnerabilities more efficient.

Additionally, this effort will use ISO/IEC 29147 style reporting for vulnerabilities discovered during the red team review of critical TMS equipment.

2.1.1.4 ISO/IEC 29100:2011 Privacy Framework

The ISO/IEC 29100:2011 privacy framework was developed to help organizations safeguard personally identifiable information (PII). ISO/IEC 29100:2011 covers defining roles for different members within the organization, incorporating privacy controls for third parties, risk assessments, and engineering specifications. It’s possible that the recommendations made by ISO/IEC 29100:2011 could be useful in helping establish processes and safeguards with respect to collected information from travelers.

2.1.2 IEC 61508 Functional Safety of Electrical/Electronic/Programmable Electronic Safety-related Systems

IEC 61508, Functional Safety of Electrical/Electronic/Programmable Electronic Safety-related Systems, was developed to provide basic functional safety methods and processes for electronic assemblies. It was developed to be industry independent and provide guidance and processes that could be applied to anywhere safety critical electronic equipment is used. IEC 61508 provides the base document for a wide variety of supplemental standards that describe processes specific to industry applications designed to work within the IEC 61508 framework.



Figure 3. IEC 61508 and Related Standards

While IEC 61508 provides the high-level safety framework that eventual ISO security standards will operate within, ISO 26262 is mature and employed by many major vehicle manufacturers and suppliers. IEC 61508 guidance could possibly be leveraged for application on TMS equipment where safety is a concern. Several standards for nuclear power, railway system, or process industry may provide relevant guidance as these systems, like a TMS, are composed of large networks of embedded systems from a variety of manufacturers.

2.1.3 SAE J3061 Cybersecurity Guidebook for Cyber-Physical Vehicle Systems

SAE J3061, Cybersecurity Guidebook for Cyber-Physical Vehicle Systems, is a Work in Progress standard currently under development by the Vehicle Electrical System Security (Cybersecurity) Committee. This standard has released an official draft release as recently as January 2016. The working group is currently collecting comments to the draft standard.

SAE J3061 is intended to describe a Cybersecurity Process Framework that works in conjunction with ISO 26262 Safety process. The draft standard describes the scope, terms and definitions, relationship with safety, process, and lifecycle of cybersecurity as it applies to road vehicles.

Capability Models and Frameworks

The following sections describe Capability Maturity Models (CMM) and Cybersecurity Frameworks. These models and frameworks will be assessed for possible incorporation into the web based guidance developed under this effort. The scope for these resources have not been limited to traffic management, but instead expanded to encompass additional industries with similarities to TMSs and their network structure.

2.2.1 NIST Cyber Physical Systems Framework

Developed through the Cyber Physical Systems working group, the Cyber Physical Systems (CPS) Framework was developed to introduce aspects of cybersecurity to Internet of Things (IoT) and “Smart” devices as various industries begin adopting and incorporating these devices. [9] The Framework describes the construction of a variety of processes for securing cyber-physical systems.

IEC 61508

Functional Safety of Electrical/Electronic/Programmable Electronic Safety-related Systems

IEC 61513

Nuclear Power

IEC 62061

Machinery

IEC 62279

Rail SW

ISO 26262

Automotive

IEC 61511

Process Ind.



Figure 4. CPS Framework Domains

Specifically, the framework is built to address Systems of Systems (SOS) and implementing security features and controls at a variety of levels. The framework recommends construction of processes based on understanding the various layers and interactions between equipment and users of a particular domain.

Figure 5. CPS Conceptual Model

The CPS Framework may be particularly useful to this effort since it puts emphasis on understanding an organization size and connectivity may vary from site to site. This SoS model may offer useful guidance for TMSs since they are constructed using a variety of embedded systems using many diverse types of communication.

2.2.2 DHS Cybersecurity Capability Maturity Model (C2M2)

The Department of Homeland Security (DHS) Cybersecurity Capability Maturity Model (C2M2) was developed to provide a framework for improving the cybersecurity posture of infrastructure organizations of all sizes. The C2M2 focuses on information technology and operational technology assets and the environments in which they operate. [10] While the core principles in the C2M2 are intended to be industry agnostic, the program has released three (3) models consisting of:

• The Cybersecurity Capability Maturity Model;

• The Electricity Subsector Cybersecurity Capability Maturity Model (ES-C2M2); and

• The Oil and Natural Gas Subsector Cybersecurity Capability Maturity Model (ONG-C2M2).



The models are freely available and are supported with a variety of other publications including guidelines, roadmap models, and journal articles.

2.2.3 Center for Internet Security's (CIS) Critical Security Controls (CSC)

Through a committee of international experts, CIS has developed a list of the 20 security controls that can most effectively limit an organization's risk. An organization implementing all 20 controls and their sub controls would be extremely well protected from most realistic threat scenarios. The suggested 20 controls are oriented to the enterprise level, and run the gamut from inventorying, to email and malware protections, and incident response.

The CSCs can provide a useful tool for municipal organizations operating TMS equipment to determine missing controls, and thereby begin to address them. Several of the control categories are directly relevant to operating a secure TMS ecosystem. These include:

1. Inventory of authorized and unauthorized devices 2. Inventory of authorized and unauthorized software 3. Secure configurations for hardware and software 4. Continuous vulnerability assessment and remediation 5. Controlled use of administrative privileges 6. Maintenance monitoring and analysis of audit logs 7. Limitations and control of network ports 8. Data recovery capability 9. Secure configurations for network devices 10. Boundary defense 11. Wireless access and control 12. Incident response and management

While intended for application to a traditional organizational environment, these controls can be tailored to provide a robust list of best practices for an organization operating a TMS system.

2.2.4 OWASP Application Security Verification Standard (ASVS)

Open Web Application Security Project (OWASP) Application Security Verification Standard (ASVS) provides a standardized way to discuss the layers of security controls present and the depth of penetration testing. Originally developed with controls focused on web and mobile applications, Version 3.1 (currently in development) adds controls for embedded devices. [11] ASVS establishes four (4) tiers of security controls, with higher tiers being a superset of lower tiers' security controls. The verification levels are:

Level 0: Cursory - The target has undergone cursory testing, not tied to a particular set of controls. Level 1: Opportunistic - The target adequately defends against vulnerabilities that are easy to

discover. Level 2: Standard - The target adequately defends against most risks. Level 3: Advanced - The target defends against advanced attacks and demonstrates principles of

good security design. This highest level is typically reserved for applications in high risk/threat environments and requires significant security assurance.

ASVS can provide a framework for municipalities deploying TMS systems to verify that their deployments meet a baseline of security controls. It can be used in procurement as a means of verifying a procured system meets reasonable controls, or as means to structure discussions of testing depth with penetration testing vendors. Additional guidance for determining and applying OWASP verification levels an agency should seek is included in Appendix A.



2.2.5 NIST Cybersecurity Framework (CSF)

The NIST CSF provides a structure for organizations to assess their current risk and determine what level of security maturity (and investment) is appropriate for them based on that risk. The framework conceptualizes security as five (5) functions of Identify, Protect, Detect, Respond, and Recover. Each function can then be evaluated according to its maturity, or implementation tier, as 1) partial, 2) risk informed, 3) repeatable, or 4) adaptive. The framework provides a means for an organization to evaluate their current tier for each function, their target tiers, and then make informed business decisions about where to make further investment and improvement.

The NIST CSF is predominantly targeted at the enterprise level, and as such is not directly relevant to the deployment of specific TMS equipment. That said, it is relevant to municipal organizations operating TMS equipment as they seek to provide holistic security for their ecosystems.

2.2.5.1 Federal Information Processing Standards (FIPS) Publication 200

In the United States in 2002, Title III of the E-Government Act, entitled the Federal Information Security Management Act (FISMA), directed the promulgation of federal standards for:

1. The security categorization of federal information and information systems. 2. Minimum security requirements for information and information systems. Private sector

organizations that compose the critical infrastructure of the United States are encouraged to consider the use of FIPS PUB 200 (Minimum Security Requirements for Federal Information and Information Systems), as appropriate [12].

The Federal Information Processing Standards (FIPS) Publication Series of NIST is the official series of publications relating to standards and guidelines adopted and promulgated under the provisions of FISMA. FISMA tasked NIST with the responsibility of developing security standards and guidelines for the US federal government. FIPS PUB 200 serves as an example of existing open source minimum security requirements for federal information and information systems that could serve as a useful, high-level reference.

2.2.5.2 Framework for Improving Critical Infrastructure Cybersecurity

NIST has released the Framework for Improving Critical Infrastructure Cybersecurity in response to Executive Order (EO) 13636. [13] This executive order calls for the open development of a cybersecurity framework structured to protect critical infrastructure systems, individual privacy, and civil liberties. It recognizes that increased dependence on aging critical infrastructure has created vulnerabilities that could pose risks to national security interests. The EO calls for voluntary information sharing program for eligible critical infrastructure providers. It also calls for development of a framework and standards consistent with international standards.

The framework aims to enable critical infrastructure organizations, regardless of size, risk, or cybersecurity maturity, to identify and apply industry best practices to improve infrastructure resilience. The framework is composed of the following:

• Framework Core: Cybersecurity activities and references common across many critical infrastructure sectors

• Framework Implementation Tiers: Defined levels aimed at helping the critical infrastructure organization understand it’s current state and approach to managing cybersecurity risk

• Framework Profiles: Example profiles designed to help the critical infrastructure organization align itself with cybersecurity goals



The NIST Framework for Improving Critical Infrastructure Cybersecurity is a risk based framework built on industry standards, best practices, and experience in similar industry. The framework core is composed of guidance broken into five functions and shown in the figure below:

Figure 6. Framework Core Functions [13]

• Identify: Develop the organizational understanding to manage cybersecurity risk to systems, assets, data, and capabilities.

• Protect: Develop and implement the appropriate safeguards to ensure delivery of critical infrastructure services.

• Detect: Develop and implement the appropriate activities to identify the occurrence of a cybersecurity event.

• Respond: Develop and implement the appropriate activities to act regarding a detected cybersecurity event.

• Recover: Develop and implement the appropriate activities to maintain plans for resilience and to restore any capabilities or services that were impaired due to a cybersecurity event.

The Framework Implementation Tiers, also Tiers, is comprised of four (4) tiers ranging from Partial (Tier 1) to Adaptive (Tier 4). Each Tier describes an increasing degree of rigor and sophistication in cybersecurity risk management practices that an organization integrates into its business operations. The tier definitions are summarized as follows [13]:

Figure 7. Framework Implementation Tiers



• Tier 1 - Partial: o Risk Management Process: Risk management practices are formalized, and risk is managed

in an ad hoc and sometimes reactive manner. o Integrated Risk Management Program: Limited awareness of cybersecurity risk at the

organization level. Risk management occurs on an irregular, case-by-case basis. o External Participation: The organization does not understand its role in larger ecosystem and

does not collaborate with, share, or receive information from other entities, such as suppliers and researchers.

• Tier 2 - Risk Informed: o Risk Management Process: Risk management practices are approved by management

however may not be part of an established organization-wide policy. o Integrated Risk Management Program: Awareness of cybersecurity risk is at an organization

level however organization-wide cybersecurity risk management has not been established. Risk management and risk assessments occur on an informal basis that is not typically repeatable or reoccurring.

o External Participation: The organization understands its role in larger ecosystem and partially collaborates with or receives information from other entities, such as suppliers and researchers but may not share information.

• Tier 3 - Repeatable: o Risk Management Process: Risk management practices are formally approved and

considered policy, and organizational cybersecurity practices are regularly updated based on business requirements and a changing threat and technology landscape.

o Integrated Risk Management Program: Organization-wide cybersecurity risk management has been established and consistent methods are in place using risk-informed policies, processes, and procedures. The policies, processes, and procedures are defined, implemented, and reviewed.

o External Participation: The organization understands its role in larger ecosystem and may contribute to the community in understanding risks. The organization also collaborates with, shares, and receives information regularly from other entities, such as suppliers and researchers.

• Tier 4 - Adaptive: o Risk Management Process: Risk management practices are adaptive through a process of

continuous improvement using advanced cybersecurity technologies and are based on previous and current cybersecurity activities, including lessons learned and predictive analytics.

o Integrated Risk Management Program: Organization-wide cybersecurity risk management has been established and consistent methods are in place using risk-informed policies, processes, and procedures. The policies, processes, and procedures are defined, implemented, and reviewed. The relationship between organizational objectives and cybersecurity risk is understood and senior executive monitor cybersecurity risk like financial risk.

o External Participation: The organization understands its role in larger ecosystem and contributes to the community in understanding risks. The organization also collaborates with, shares, and receives information regularly from other entities, such as suppliers and researchers.



The Tiers to do not represent maturity levels, instead they are meant to support organization decision making, including which parts of the organization are of a higher priority and should receive additional resource. The Tiers also provide guidance how to coordinate between cybersecurity risk management and operational risk management.

The Framework Profile, also Profile, allows organizations to create a roadmap to reduce cybersecurity risk that align business requirements, risk tolerance, and resources of the organization with industry best practices, legal and regulatory requirements, and reflects risk management priorities.

The NIST Framework for Improving Critical Infrastructure Cybersecurity addresses many of the challenges a TMS is likely to encounter when undertaking a similar cybersecurity risk management and implementation efforts. Aside from administrative update, the latest 2017 draft of the Framework enhanced guidance for applying the framework, summarized the relevance and utility of the Frameworks’ measurement for self-assessments, and provided additional accounts for authorization, authentication, and identity proofing. It’s likely that many of the best practices and guidance provided by the framework could be leveraged for this effort.

Past Studies, Research Efforts, and Reports

The following sections summarize research efforts or reports that may be applicable to development of cybersecurity processes for TMSs.

2.3.1 Issues in Autonomous Vehicle Deployment

This report issued by the Congressional Research Service briefly summarizes cybersecurity and its relationship to autonomous vehicle development. It provides some general information and references community driven information sharing such as the Automotive Information Sharing and Analysis Center (Auto-ISAC). The Driver Privacy Act of 2015, is also briefly mentioned about the owner of information collected by the vehicle.

2.3.2 Cyber security challenges in Smart Cities: Safety, security and privacy

This paper discusses a variety of security and privacy aspects as they relate to PII in an increasingly connected society. It discusses some of the concerns and challenges of using, as well as protecting information gathered through an Intelligent Transportation System (ITS). As ITS incorporate more data collection and analysis, decisions will need to be made regarding how the information is shared. It discusses some of the compromises that will need to be considered when sharing information about driving habits collected from vehicles. Additionally, this paper poses some possible manipulation of these systems by motivated offenders. [14]

2.3.3 US-CERT Critical Infrastructure Cyber Community (C3) Voluntary Program

The US-CERT Critical Infrastructure Cyber Community (C3) Voluntary Program was created to encourage adoption of the NIST Cybersecurity Framework. C3 connects users of the NIST Cybersecurity Framework with other critical infrastructure adopters, as well as providing resources from DHS, NIST, and others. [15]

The C³ Voluntary Program focuses on three primary activities:

• Use: Understanding the Cybersecurity Framework and application of guidance.

• Outreach and Communications: Connect new users with organizations already employing the Framework. Collect and disseminate useful materials.

• Feedback: Collect feedback and improve the C3 and Framework.



2.3.4 DHS Study on Mobile Device Security

In response to the Cybersecurity Act of 2015 and the Consolidated Appropriations Act, DHS in consultation with NIST, conducted a study on threats related to the security related to the mobile devices of the federal government. The study performed a threat model of the mobile ecosystem and categorized logical function that followed industry roles. The threat model categories included [16] [17]:

• Mobile device technology stack, including mobile operating systems and lower level device components

• Mobile applications

• Network Protocols, Technologies, and Infrastructure (e.g., cellular, Wi-Fi, Bluetooth) and services provided by network operators

• Device physical access

• Supply Chain

• Enterprise mobile services and infrastructure, including mobile device management, enterprise mobile app stores and mobile application management

The study provided a summary of the greatest threats to the mobile ecosystem along mitigations and defenses. The study found that there were threats across all elements of the ecosystem and that security approaches typically applied to desktop applications were not sufficient to protect mobile systems. NIST produced a report that further detailed the threat catalogue and included descriptions of the attack surfaces, entitled Assessing Threats to Mobile Technologies (NISTIR 8144) [17]. Incorporating this information when considering the threat modeling of TMS applications will assist in assuring a breadth and depth coverage as guidance development progresses.

Best Practices and Guidance

The following sections provide summaries of best practices and guidance that could be leveraged in creating cybersecurity guidance for TMSs. Often, cybersecurity tools like policies and maturity models tend to be highly abstract and difficult to reap immediate benefits. Articles in this section tend to provide solutions to real world experiences in cybersecurity. The incorporation of applicable tools from this section organized under an appropriate maturity model or framework is key to the successful development of TMS cybersecurity guidance.

2.4.1 DHS Roadmap to Secure Control Systems in the Transportation Sector

The purpose of the DHS roadmap is to produce guidance for securing Industrial Control Systems (ICS) installed in five (5) key CI domains:

• Aviation

• Highway

• Maritime

• Pipeline

• Surface Transportation

Of interest is the guidance provided for Highway ICS networks as illustrated in Figure 8. This figure was originally developed as part of the National ITS Architecture Subsystems and Communications publication via the Federal Transit Administration.



Figure 8. Highway/Roadway Network System [18]

The roadmap covers cybersecurity guidance focusing on four (4) primary technologies:

• Supervisory Control and Data Acquisition (SCADA)

• Distributed Control System (DCS)

• Programmable Logic Controller (PLC)

• General Purpose Controller (GPC)

The roadmap claims to outline the activities and benchmarks an organization can use to identify the cybersecurity features currently in place and to determine the next activities for consideration to improve cybersecurity performance. [19] The DHS National Cybersecurity Division (NCSD), Control Systems Security Program (CSSP) sponsored the development of the Roadmap to Secure Control Systems in the Transportation Sector.

2.4.2 Transportation Industrial Control Systems (ICS) Cybersecurity Standards Strategy

The Transportation Industrial Control Systems (ICS) Cybersecurity Standards Strategy is a cooperative effort to improve ICS security across multiple domains. Specifically, they hope to roadmap security efforts for highway, maritime, aviation, surface transportation, and pipeline. [20]

2.4.3 TSS Cybersecurity Framework Implementation Guidance

The Transportation Systems Sector (TSS) Cybersecurity Framework Implementation Guidance is a collection of resources and direction for assisting TSS organizations in adopting the NIST Cybersecurity Framework. This guidance was created by the Transportation Security Administration, Department of Transportation, United States Coast Guard, and TSS to create implementation NIST Framework guidance specific to the transportation sector.



2.4.4 TRB Guidebook on Best Practices for Airport Cybersecurity

The TRB Guidebook on Best Practices for Airport Cybersecurity is a report generated for the Airport Cooperative Research Program under the ACRP Project 05-02 Panel review by Grafton Technologies, Inc., SoftKrypt, and Grafton Information Services, Inc. [21] The report summarizes the research and findings of cybersecurity investigations of several airport organizations. It attempts to identify the state of the art for airport cybersecurity, best practices, and provide resources of improving the cybersecurity stance of an adopting agency. It leverages the NIST CSF and makes recommendations specific to airport cybersecurity.

The recommendations and best practices the report makes could be applied to many organizations that incorporate distributed embedded devices, TMSs included. This report explains topics well and does so in a way that is oriented to non-security professionals. Many of the recommendations could be leveraged for incorporation into the final guidance.

2.4.5 National Infrastructure Protection Plan (NIPP)

The purpose of the National Infrastructure Protection Plan (NIPP) is to unify cybersecurity efforts for United States critical infrastructure. There have been several revisions of the NIPP since its initial conception in 1998. The goals of the NIPP is to facilitate information exchange between government, private, and other stakeholders involved with critical infrastructure operations and support. Specifically, the NIPP lists their goals as: [22]

• Assess and analyze threats to, vulnerabilities of, and consequences to critical infrastructure to inform risk management activities;

• Secure critical infrastructure against human, physical, and cyber threats through sustainable efforts to reduce risk, while accounting for the costs and benefits of security investments;

• Enhance critical infrastructure resilience by minimizing the adverse consequences of incidents through advanced planning and mitigation efforts, and employing effective responses to save lives and ensure the rapid recovery of essential services;

• Share actionable and relevant information across the critical infrastructure community to build awareness and enable risk informed decision making; and

• Promote learning and adaptation during and after exercises and incidents

The NIPP describes recommended Risk Management Framework that has heavy emphasis on information exchange between CI members to build a robust, interdependent network. The framework was developed to be flexible to work for all DHS selected CI modes, but well defined enough to permit sharing of risks, threats, and countermeasures between members to be productive.

Figure 9. NIPP Risk Management Framework and Data Flow



The NIPP and associated cybersecurity framework could provide significant value to this effort as it offers several strong benefits. The NIPP is:

• Driven by Presidential Policy Directive • Established and mature through several revisions • TMSs and CIs identified share many network and process similarities • Has an active community

2.4.6 APTA Cybersecurity Considerations for Public Transit

The American Public Transportation Agency (APTA) released the Cybersecurity Considerations for Public Transit to inform public transportation organizations about possible methods of implementing cybersecurity controls to public transportation systems. [23] The report covers a variety of resources and standards the organization can refer to including ISO, NIST, and others. The ATPA has released several related documents that may offer additional information including “Securing Control and Communications Systems in Transit Environments” and “Securing Control and Communications Systems in Rail Transit Environments.”

2.4.7 Surface Transportation Cybersecurity Toolkit

The TSA Surface Transportation Cybersecurity Toolkit (TCT) is a collection of guidance drawn from three (3) primary sources; the NIST Technology Framework for Improving Critical Infrastructure Security, “Stop.Think.Connect.”, and US-CERT. The intent is to create a collection of useful guidance for surface transportation organizations with fewer than 1000 employees. [24] The TCT is a purchased set of guidance aggregating several sources.

2.4.8 NHTSA Cybersecurity Best Practices for Modern Vehicles

The NHTSA Cybersecurity Best Practices for Modern Vehicles is a document released by NHTSA encouraging industry to adopt risk based approach for cybersecurity of on road motor vehicles. [25] The document encourages a voluntary incorporation of the best practices described within the document for all motor vehicles manufacturers and suppliers.

NHTSA encourages a layered approach to vehicle cybersecurity including the NIST Cybersecurity Framework. It encourages incorporation of cybersecurity integration into the design process, as well as considering SAE J30161. It also recommends information sharing including vulnerability, exploit, and incident response sharing using methods, such as the US-CERT Federal Incident Notification Guidelines. It puts emphasis on penetration testing and documentation done by members outside the development team. The document provides several good recommendations for embedded systems security. The policies it recommends could be applied to TMS systems policy.

2.4.9 Protection of Transportation Infrastructure from Cyber Attacks: A Primer

The NCHRP and Transit Cooperative Research Program produced the Protection of Transportation Infrastructure from Cyber Attacks: A Primer which provides sound cybersecurity principles and how they apply to modern intelligent transportation systems. [26] The document appears to target the non-security initiated personnel and attempts to provide explanations on foundational cybersecurity principles. The Primer appears to be an excellent resource as a starting point for applying security best practices to intelligent transportation systems.



2.4.10 Airport Cooperative Research Program Guidebook on Best Practices for Airport Cybersecurity

The Airport Cooperative Research Program (ACRP) published the ACRP Guidebook on Best Practices for Airport Cybersecurity as a result of the studies conducted as part of the TRB Project ACRP 05-02. [27] The guidebook summarizes findings from the research effort which investigated airport cybersecurity efforts and provides guidance for airports looking to start or improve their own programs. Findings and recommendations from this effort are likely applicable to TMSs as they both share a large, complex IT infrastructure composed of devices from a variety of manufacturers. Both systems manage a variety of systems that exhibit varying levels of data collection, traffic control, and information. Both Airports and traffic management systems are high profile targets that vary greatly in size and budget. The report is freely available from the TRB program site.

Working Groups

The following working groups may provide relevant information from discussions or publications. These groups are a mix of public and private. They may provide a platform for engaging industry resources or contacting other groups with experience in cybersecurity that may have experiences or recommendations for implementing security within a TMS.

2.5.1 Automotive Information Sharing and Analysis Center (Auto-ISAC)

The Automotive Information Sharing and Analysis Center (Auto-ISAC) is a privately-run consortium managed by Booz Allen Hamilton. [28] They host monthly calls in two (2) forums, Manufacturer/Supplier, and community. The OEM/Supplier call requires attendees be part of an automotive OEM or of an approved automotive tier supplier. The calls discuss topics related to automotive security. The community call is a free to join teleconference held monthly. A guest speaker is usually invited to give a presentation on security aspects relating to automotive, autonomous, or connected vehicle security. The Auto-ISAC encourages submissions of automotive security related findings to the organizers. The group has also produced a series of best practices guidance, most of which are publicly available. Guidance available and in-process include:

• Incident Response (available to industry stakeholders)

• Collaboration & Engagement (available to industry stakeholders)

• Governance (in progress)

• Risk Management (upcoming)

• Security by Design (upcoming)

• Threat Detection & Protection (upcoming)

• Training & Awareness (upcoming)

2.5.2 United States Computer Emergency Readiness Team (US-CERT)

Originally created by congress as the Federal Computer Incident Response Center, the United States Computer Emergency Readiness team (US-CERT) was created to coordinate and improve US critical infrastructure cybersecurity. US-CERT is funded as part of the DHS and was established as a centralized hub for information exchange relating to federal agencies relating to computer security. US-CERT has produced a variety of publications from personal device threats, ransomware, forensics and others. The publications are typically freely available and provide high-level guidance. The US-CERT website maintains a list of reported alerts, bulletins, and reported vulnerabilities. They also accept incident report via their website.



The publications from US-CERT are typically offer easily digestible and actionable guidance. Much of the best practice guidance contained within the publications could be incorporated into the state and local agency web guidance tool.

2.5.3 Industrial Control Systems Computer Emergency Readiness Team (ICS-CERT)

Operating within the National Cybersecurity and Integration Center (NCCIC), a division of the DHS's Office of Cybersecurity and Communications (DHS CS&C), the Industrial Control Systems Cyber Emergency Response Team (ICS-CERT) mission is to guide a cohesive effort between government and industry to improve the cyber security posture of control systems within the nation's critical infrastructure [30]. ICS-CERT coordinates control systems related security incidents and information sharing with Federal, State, and local agencies and organizations, the intelligence community, and private sector constituents, including suppliers, owners, and operators. ICS-CERT undertakes several efforts to coordinate sharing and build effective risk management strategies that include [30]:

• Responding to and analyzing control systems-related incidents.

• Conducting vulnerability, malware, and digital media analysis on samples of infected systems at the Advanced Analytic Lab (AAL).

• Providing onsite incident response services in partnership with NCCIC’s Hunt and Incident Response Team (HIRT).

• Providing situational awareness in the form of actionable intelligence.

• Coordinating responsible disclosure of vulnerabilities and associated mitigations.

• Sharing vulnerability information and threat analysis through information products and alerts.

Additionally, ICS-CERT partners with US-CERT in support of critical infrastructure stakeholders, providing control systems and cybersecurity technical expertise and incident response capabilities. ICS-CERT offers the Cyber Security Evaluation Tool (CSET), a desktop software tool that enables users to self-assess their network and ICS security practices against recognized industry and government standards, guidelines, and recommended practices. CSET could be incorporated into the state and local agency web guidance tool given the similar challenges TMS and ICS face regarding the design, development, and deployment of secure field equipment.

2.5.4 Critical Infrastructure Partnership Advisory Council (CIPAC)

The Critical Infrastructure Partnership Advisory Council (CIPAC) is a collection of 16 Sectors that span a variety of US infrastructure systems identified by the DHS as Critical Infrastructure. Each Sector consists of several working groups that compose the CI. Each working group may have additional sub-groups. The CIPAC consists of 16 CI Sectors including:

• Chemical

• Commercial Facilities

• Communications

• Critical Manufacturing

• Dams

• Defense Industrial Base

• Emergency Services

• Energy Sector

• Financial Services

• Food and Agriculture

• Government Facilities

• Healthcare and Public Health



• Nuclear Reactors, Materials, and Waste

• Transportation Systems

• Water and Wastewater Systems

The Transportation Systems Sector, is composed of:

• Aviation

• Highway Motor Carrier

• Maritime

• Mass Transit

• Postal and Shipping

• Rail

• Transportation Systems o Cybersecurity Working Group o Research and Development Working Group o Surface Transpiration Security Priority Basement Working

The Cybersecurity working group is listed as occurring Ad Hoc and has not hosted a meeting since 2014, with no additional meetings on the schedule.

2.5.5 SAE Automotive Systems Security Committee

The SAE Vehicle Electrical System Security Committee intends to cultivate recommended practices and guidance of vehicle electrical systems’ security. The committee’s goals are to:

• Identify and recommend strategies and techniques related to preventing and detecting adversarial breaches, and

• Mitigating undesirable effects if a breach is achieved.

The SAE Vehicle Electrical System Security Committee plans to classify attack methods, propose preventative strategies, define levels of security by criticality of system type, and identify architecture-level strategies for mitigating attacks. While this group is centered on vehicle systems attacks, incorporation of misuse cases generated by the committee may be useful in considering their affects to TMS systems.

2.5.6 Transportation System Cybersecurity Framework (TSCF) Partnership

The Transportation Systems Cybersecurity Framework (TSCF) partnership is a collaboration between the Institute of Transportation Engineers (ITE), American Association of State Highway and Transportation Officials (AASHTO), ITS America, the National Association of Electrical Equipment and Medical Imaging Manufacturers (NEMA), and the National Association of City Transportation Officials (NACTO) working with USDOT. The TSCF partnership plans to develop dimensions of threats to transportation systems and guidance. To develop content, the TSCF consists of the following working groups [31]:

• WG1: Public Sector Workgroup (represents AASHTO, ITS America, NEMA, NACTO and ITE)

• WG2: Vendor/Supplier/Industry Workgroup (represents ITS America, NEMA, and ITE)

• WG3: Local/Regional Cybercrime/Law Enforcement/Legal WG

• WG4: Red Team SME (Testing)

2.5.7 CTIA Cybersecurity Working Group

The Cybersecurity Working Group (CSWG), developed by the Cellular Telecommunications Industry Association (CTIA)-The Wireless Association, promotes recommended best practices and standards for data transparency, data integrity and security of mobile technologies. These mobile technologies,



including machine to machine (M2M) communication used to provide the connectivity in Internet of Things (IoT) technologies [32]. The CSWG members include service providers, manufacturers and wireless data, and internet and applications companies.

CTIA-The Wireless Association supports the US wireless communications industry and the companies throughout the mobile ecosystem by hosting educational events to promote the industry and coordinate.

As TMS’ network architectures across the nation are incorporating either DSRC or Cellular-V2X(C-V2X), or a combination of these technologies, leveraging the CSWG’s risk management strategies, lessons learned, initiatives for security features and updates that will be used in future wireless technologies can provide perspective on security risks and recommendations when considering a more connected TMS environment.

2.5.8 Harmonization Task Groups (HTGs)

The USDOT collaborates with other governments, industry associations, experts, and standards development organizations (SDOs) when in the public interest to enable [33]:

• Shared research, a larger and more detailed set of results, and leveraged/reduced research costs;

• Common hardware and software across regions;

• Improved interoperability across borders;

• Facilitation of a global marketplace.

In 2009, the USDOT Research and Innovative Technology Administration (now OST-R) and the European Commission's Directorate General for Information Society and Media (now the Directorate General for Communications Networks, Content & Technology, or DG Connect) signed an Implementing Arrangement to develop coordinated research programs. This is known as the EU-US Joint Declaration of Intent on Research Cooperation in Cooperative Systems. Under the effort, a Coordinating Group operates several programs through working groups, of which the Standards Harmonization Working Group (HWG) is one.

Most of the HWG activities take place through Harmonization Task Groups (HTGs). The HTGs are a means for focused analysis to lead to harmonization and/or joint development of specific standards, protocols, and policies [33]. These HTG are focused on performing work related to security standards related to ITS and CV.

2.5.8.1 HTG1 & HTG3: ITS Security and Communication Protocols

Completed in 2013, these two (2) HTGs worked in parallel on analyses of security standards (HTG1) and communications standards (HTG3) for CV systems to provide recommendations to SDOs. Both HTG’s reports are available online and include [33]:

• Overview of Harmonization Task Groups 1&3 • Stakeholder Engagement and Comment Resolution • Observations on GeoNetworking • Summary of Lessons Learned • Status of ITS Security Standards • Testing for ITS Security • Feedback to Standards Development Organizations—Security • Status of ITS Communication Standards • Testing for ITS Communications

http://ntl.bts.gov/lib/48000/48500/48524/4487DD4C.pdf

http://ntl.bts.gov/lib/48000/48500/48525/5292327.pdf

http://ntl.bts.gov/lib/48000/48500/48532/899FC6AA.pdf

http://ntl.bts.gov/lib/48000/48500/48534/9814BDCD.pdf

http://ntl.bts.gov/lib/48000/48500/48529/1CB8483E.pdf

http://ntl.bts.gov/lib/48000/48500/48533/4099A268.pdf

http://ntl.bts.gov/lib/48000/48500/48528/1B6F6230.pdf

http://ntl.bts.gov/lib/48000/48500/48530/4CD758FD.pdf

http://ntl.bts.gov/lib/48000/48500/48535/C8040E25.pdf



• Feedback to Standards Development Organizations—Communications

2.5.8.2 HTG2: Harmonization of US Basic Safety Message (BSM) and EU Cooperative Awareness Message (CAM)

HTG2 sought to harmonize the vehicle-to-vehicle (V2V) safety messages that had been developed separately within the EU and the US. HTG2 completed in 2012 and showcased at 2012 ITS World Congress, demonstrating that the HTG was able to evolve the two (2) message sets in a manner such that simple software translation is sufficient to allow cross-compatibility [33].

2.5.8.3 HTG4/5: Infrastructure Messages

Currently in progress, HTG4/5 intends to address the need for standardized Vehicle-to-Infrastructure message sets and interfaces, including [33]:

• Signalized intersections applications such as Signal Phase and Timing, Signal Request, Signal Status (ISO 19091)

• In-vehicle data message sets (ISO 19321)

2.5.8.4 HTG6: Cooperative ITS Security Policy

The work of HTG6 substantially completed in late 2015, with publication of documents supporting an end-to-end security policy framework that facilitates harmonization of Connected Vehicle systems. In 2015, the initial set of draft final reports were published [34], and additional reports anticipated to be published soon [33].

2.5.8.5 HTG7: Standards Selection, Gap Analysis, and Identifiers for Connected Vehicle (CV) architectures

HTG7 will specify standards in detail throughout CV architectures, identify standards gaps for future cooperative development activity, and facilitate Standards Development Organization (SDO) cooperation on globally unique ITS identifiers. The US, Europe, and Australia are conducting this effort cooperatively [33].

http://ntl.bts.gov/lib/48000/48500/48537/F369945B.pdf

https://www.iso.org/standard/69897.html

https://www.iso.org/standard/64606.html



3. UNITED STATES DEPARTMENT OF TRANSPORTATION (USDOT) RELATED PILOT PROGRAMS AND ARTIFACTS

The U.S. Department of Transportation (USDOT) has issued a departmental Cybersecurity Policy, DOT Order 1351.37 as guidance to the USDOT organization itself and not as recommended guidance for state level DOTs. The policy is utilized as guidance of all USDOT information systems, information technology, networks, and data that support USDOT.

USDOT posted that they intend to improve cybersecurity, privacy, and Information Assurance Technology operations and infrastructure as a priority moving forward. The Office of the Chief Information Officer (OCIO) lists the following priorities:

• Standards, Policies and Directives o Ensure DOT implementation of federal cybersecurity initiatives o Ensure DOT implementation of National Security Presidential Directive 54/Homeland

Security Presidential Directive 23 (NSPD-54/HSPD-23) • Situational Awareness and Incident Response

o Enhance support of the DOT Cyber Security Management Center (CSMC) and cyber incident response.

o Enhance situational awareness of the DOT cyber infrastructure o Improve information sharing with DHS

• Independent Verification and Validation o Verification and validation (V & V) functions as required by statute o Expand the use of Office of Management and Budget-authorized reporting tools o Increase the use of automation tools to reduce the V & V burden

• Certification and Accreditation (C & A) o Modernizes the DOT C & A program and processes o Expand the use of Cyber Security Assessment and Management (CSAM) tool o Enhance data quality reviews to identify and correct performance gaps

The USDOT page for the OCIO was last updated in March of 2015. Progress on these initiatives has not been investigated at the time of writing this document.

National Highway Traffic Safety Administration (NHTSA)

On behalf of the USDOT, the NHTSA has been investigating solutions to protect and harden vehicle’s electronic systems against cyber-attacks to reduce the probability of a successful attack and ensuring the vehicle systems respond appropriately to mitigate potential loss in the event of a successful cyber-attack. [35]

3.1.1 Security Credential Management System (SCMS)

Partnering with the automotive industry and industry security experts through the Crash Avoidance Metrics Partnership (CAMP), the Intelligent Transportation Systems (ITS) Joint Program Office (JPO) and National Highway Traffic Safety Administration (NHTSA) are working to design and develop a communications security solution for the CV environment, called the Security Credential Management System (SCMS). The SCMS is a Public Key Infrastructure (PKI) that provisions certificates to ensure trusted communications between vehicles and between vehicles and infrastructure such that received messages have:

• Integrity: The message was not modified between sender and receiver.

• Authenticity: The message originates from a trustworthy and legitimate source.

• Privacy: The message appropriately protects the privacy of the sender



The SCMS, extends on IEEE1609.2, forming the basis of trust for V2V and V2I communication by providing the security infrastructure to create, distribute, and revoke the security certificates. First connected vehicle devices enroll into the SCMS by submitting an enrollment request to the USDOT, then they obtain security certificates from certificate authorities (CAs), and attach those certificates to their messages as part of a digital signature. The certificates form a chain of trust and prove the device is a trusted actor in the system, while also maintaining privacy. The SCMS makes use of several certificate types depending on CV application installation type, such that onboard equipment (OBE) versus roadside unit (RSU), each CA representing an individual link along the chain. Additionally, misbehavior detection and reporting allow the system to identify bad actors and revoke message privileges, when necessary. A simplified architecture design diagram of the SCMS is shown in the figure below.

Figure 10. Simplified SCMS Architecture Design [36]

Development of a proof-of-concept (POC) version of the SCMS has ongoing since 2015, and will be available to early deployment sites, such as the USDOT’s three (3) CV pilot test beds in Tampa, Wyoming, and New York City, by the end of 2017. [36] The goal of the SCMS POC is to provide security credential materials to deployments of CV technology to address unanswered questions regarding the exchange of information among vehicles, roadway infrastructures, traffic management centers, and wireless mobile devices. [35] CAMP released an end entity (EE) requirements and specifications supporting SCMS software release document in 2016 as part of the effort. A roadmap of the SCMS POC is shown in the figure below.


January 12,2018 of 48

Figure 11. SCMS Roadmap [37]



As the SCMS POC progressed, the Certification Operating Council (COC) and OmniAir launched a formal certification program October 2017 and hosted a PlugFest in October 2017, covering CV policy and V2V mobile interoperability.

Additionally, the Ann Arbor Connect Vehicle Test Environment (AACVTE, www.aacvte.org), operated by the University of Michigan Transportation Research Institute (UMTRI) have chosen to use a commercial SCMS as the AACVTE will not be federally funded starting in 2018, and the use of CAMP’s SCMS POC may no longer be available. One of the main goals of the AACVTE is to transition this test bed from research to operational [38]. The AACVTE will use the SCMS being set up by Green Hills, who were involved in the development of the SCSM POC. The certificates from the Green Hills SCMS are anticipated to have the same root as used in the SCMS POC, and as such should be compatible and provide a good operational test of how the CV SCMS will eventually operate.

Federal Highway Administration (FHWA)

The FHWA is working through multiple areas, including outreach and awareness programs in cooperation with the National Highway Institute (NHI), engineering organizations, and transportation agencies to improve cybersecurity resilience of transportation infrastructures. FHWA is currently working with NIST to generate customized risk management and mitigation information using NIST existing works for operating engineers in the highway transportation sector. [35] Also, USDOT is promoting the use and adoption of the NIST Cybersecurity Framework (http://www.nist.gov/cyberframework/) within the transportation sector.

CV Safety Pilot Model Deployment Program (SPMD)

Sponsored by the USDOT NHTSA, ITS JPO, Federal Highway Administration (FHA), Federal Motor Carrier Safety Administration (FMCSA), and Federal Transit Administration (FTA), the SPMD program demonstrated the readiness of DSRC-based CV applications nationwide deployment. [39] The program focused on effectively assessing a real-world deployment of V2V technology and collecting data to support: [40]

1. The functional evaluation of V2V safety applications 2. The assessment of the operational aspects of messages that support V2I safety applications 3. Comprehension of the operational and implementation characteristics of a prototype security

operating concept.

Deploying CV technology in over 2,800 vehicles (including cars and trucks) and at 25 infrastructure sites this program tested CV safety applications in real-world driving scenarios, and determined the effectiveness of the CV crash avoidance systems. [39] As part of this program University of Michigan Transportation Research Institute (UMTRI) and the USDOT established test environment in the northeast quadrant of the city of Ann Arbor, Michigan.

During the development of the SPMD program, a Security Management System Concept of Operation Plan was developed which took into consideration how DSRC-based devices and the SCMS server should be implemented and operated to prevent malicious and unintentional attacks. Consideration was given to the security of over-the-air (OTA) DSRC messages and DSRC units and of the SCMS’ server, security policies, physical security, and secure life-cycle. For OTA communication between DSRC devices, IEEE1609.2 provides authentication and encryption mechanisms and the SCMS specification helps to extend IEEE1609.2 through security certificate issuing and management in vehicle-based DSRC devices.

CV Safety Pilot Sites

The following three (3) CV pilot sites were selected as part of USDOT-funded Connected Vehicle (CV) Pilot Deployment Program and initiated in September 2016. Additionally, in 2016 each CV pilot program was required to develop a Security Concept of Operations (ConOps) [41] and reported on their

http://www.aacvte.org/

http://www.nist.gov/cyberframework/



respective security assessments. These sites will be beneficial when developing typical TMS architectures as the industry adjusts to the addition of V2X technologies and the potential cybersecurity implications the technologies impose.

3.4.1 New York City (NYC) DOT Pilot Site

As one (1) of the three (3) USDOT funded CV pilot deployment programs, the NYCDOT pilot site encompasses three distinct areas in the boroughs of Manhattan and Brooklyn. NYC pilot program aligns with the city’s objective of the Vision Zero program to reduce the number of traffic crash-related fatalities and injuries. During the initial planning, the pilot program prepared a deployment concept around NYC’s tightly-spaced intersections typical in a dense urban transportation system and is anticipated to be the largest connected vehicle technology deployment to date. [42]

Moving forward, the next 20-month phase will see the integrated deployment of wireless in-vehicle, mobile device and roadside technologies. Approximately 5,800 cabs, 1,250 MTA buses, 400 commercial fleet delivery trucks, and 500 city vehicles that frequent the deployment area will be fitted with CV technology. The deployment will include approximately 310 signalized intersections using DSRC for V2I technology and deploy approximately 8 RSUs along the higher-speed Franklin D. Roosevelt (FDR) Drive to address challenges such as short-radius curves, a weight limit and a minimum bridge clearance and 36 RSUs at other strategic locations throughout the city to support system management functions. This pilot will also focus on reducing vehicle-pedestrian conflicts through in-vehicle pedestrian warnings and an additional V2I and I2V project component that will equip approximately 100 pedestrians with personal devices that assist them in safely crossing the street. [42]

3.4.2 Tampa-Hillsborough Expressway Authority (THEA) Pilot Site

On September 2016, the THEA CV pilot was selected as one of three USDOT-funded pilot deployment sites. The THEA pilot site encompasses the downtown Tampa area, including the Selmon Reversible Express Lanes (REL) which is a major route into and out of downtown Tampa. As the REL features reversible lanes, wrong way driver entry is possible. As part of initial planning, THEA pilot program prepared a deployment concept on variety of V2V and V2I applications to relieve congestion, reduce collisions, and prevent wrong way entry. [43]

Over the next 20-month phase of the pilot program, the THEA pilot will employ DSRC to enable transmissions among approximately 1,600 cars, 10 buses, 10 trolleys, 500 pedestrians with smartphone applications, and approximately 40 roadside units along city streets. As part of this program, THEA created a region-wide Connected Vehicle Task Force and its primary partners include The City of Tampa (COT), Florida Department of Transportation (FDOT) and Hillsborough Area Regional Transit (HART). This Task Force will support the uniform deployment of CV infrastructure in the region to ensure interoperability and interagency coordination as these deployments transition from concept to planning to operations. [43]

3.4.3 Wyoming (WY) DOT Pilot Site

As one (1) of the three (3) USDOT funded CV pilot deployment programs, the WYDOT pilot site encompasses 402 miles of I-80 corridor in Wyoming. WYDOT pilot site sees heavy east/west freight movement, moving 32 million tons of freight per year and correspondingly, has seen a number blow over incidents and weather-related incidents. During the initial planning, the pilot effort prepared a CV infrastructure and connectivity deployment concept that would support a range of services from advisories including roadside alerts, parking notifications and dynamic travel guidance. This plan is expected to improve safety and reduce incident-related delays. [44]

As the pilot program continues, WYDOT will deploy approximately 75 RSUs that can receive and broadcast message using DSRC along various sections of the I-80 corridor. At the end of 2017, the



WYDOT pilot program anticipates installing on-board units (OBUs) into approximately 400 vehicles. These vehicles will be a combination of fleet vehicles and commercial trucks with at least 150 being heavy trucks that are expected to be regular users of I-80. In addition to the 400 vehicles, 100 WYDOT fleet vehicles, snowplows, and highway patrol vehicles, will be also equipped with OBUs and mobile weather sensors. [44]



4. STATE AND LOCAL RELATED PROGRAMS AND ARTIFACTS

The following sections will summarize efforts and activities that have been performed in State and Local agencies with respect to cybersecurity guidance and resilience programs. At the time of writing this document, SwRI is aware of some of the effort performed by a select few agencies, but will need to seek approval and additional information from those sources.



5. OTHER RELATED TECHNOLOGIES AND DATA SOURCES

This section will serve as a placeholder for other potentially related items that should be reviewed and briefly summarized. There are technologies that exist that may not be standardized but should be considered from a future looking perspective (e.g., 5G).

NIST National Vulnerability Database (NVD)

The NIST National Vulnerability Database (NVD) uses the Secure Content Protocol (SCAP) to inventory and rank security flaws, misconfigurations, vulnerabilities and statistics. The NVD is a public database and is accessible through a variety of language agnostic methods including JSON, XML, and RSS. Vulnerability information can be obtained via real-time “feeds” or via daily batches. The NVD is popular with researchers for generating vulnerability statistics. The NIST NVD is available at https://nvd.nist.gov/.

NISTIR 8138 Vulnerability Description Ontology (VDO)

NISTIR 8138 Vulnerability Description Ontology (VDO) was developed to provide a machine consumable format for describing vulnerabilities. [45] The VDO describes the high-level requirements for formatting vulnerability information and metadata, as well as defining a common vernacular. The intent was to create vulnerability datasets that can be used across a variety of systems and languages.

CybOXTM, STIXTM, and TAXIITM

US-CERT has developed the Trusted Automated eXchange of Indicator Information (TAXII), Structured Threat Information eXpression (STIX) and Cyber Observable eXpression (CybOX) as community driven technical specifications for capturing, standardizing threat reporting language, and specifying a set of messages for exchanging vulnerabilities. All three (3) specifications are freely available including their source documentation. STIX and TAXII have officially transitioned to the Organization for the Advancement of Structured Information Standards (OASIS) open project but the source and documentation of STIX and TAXII are still available.

Cyber Security Assessment & Management (CSAM)

The Cyber Security Assessment & Management (CSAM) was created as a web-based secure network capability tool to assess, document, manage, and report on the status of IT security risk assessments and implementation of Federal and DOC mandated IT security control standards and policies. The intent was to provide a standardized way for organizations to meet and report their compliance with federal cybersecurity policy.

https://nvd.nist.gov/



6. CONCLUSION

This document’s objective is to capture summary information regarding current Transportation and CAV security standards and the various efforts in which these standards are being used. Also included in this document are efforts that relate to the cybersecurity of TMS and CAV technologies.

This document is intended to be a living document throughout the duration of this program effort and will be occasionally revisited as the dynamic field of cybersecurity in traffic management systems is expanded upon. With each revision, new sources will be added in order to provide summaries of cybersecurity efforts for the development of the web based guidance tool. The security standards and best practices collected in this report will form the basis of recommendations for future development in this domain.



7. REFERENCES

[1] Common Criteria Recognition Arrangement, "Common Critera Portal," 3 11 2017. [Online]. Available: http://www.commoncriteriaportal.org/cc/.

[2] "Part 1: Introduction and General Model V3.1R4," Common Criteria Recognition Arrangement (CCRA), 2012.

[3] "Part 2: Security Functional Components V3.1R4," Common Criteria Recognition Arrangement (CCRA), 2012.

[4] "Part 3: Security Assurance Components V3.1R4," Common Criteria Recognition Arrangement (CCRA), 2012.

[5] International Organization for Standardization, "ISO/IEC 27000 - Information Secuity," ISO/IEC, 2013. [Online]. Available: https://www.iso.org/isoiec-27001-information-security.html. [Accessed 3 11 2017].

[6] ISO/IEC, Information Technology - Security Techniques - Vulnerability Disclosure, Switzerland: ISO/IEC, 2014.

[7] MITRE Corporation, "Common Vulnerabilities and Exposures," MITRE Corporation, 17 11 2017. [Online]. Available: https://cve.mitre.org/. [Accessed 17 11 2017].

[8] S. Özkan, "CVE Details," 17 11 2017. [Online]. Available: https://www.cvedetails.com/. [Accessed 17 11 2017].

[9] Cyber Physical Systems Public Working Group, "Framework for Cyber-Physical Systems," National Institute of Science and Technology, 2016.

[10] United States Department of Homeland Security, "Cybersecurity Capability Maturity Model (C2M2) Program," United States Department of Homeland Security, 22 November 2017. [Online]. Available: https://energy.gov/oe/cybersecurity-critical-energy-infrastructure/cybersecurity-capability-maturity-model-c2m2-program. [Accessed 22 November 2017].

[11] Open Web Application Security Project, "Category:OWASP Application Security Verification Standard Project," Open Web Application Security Project, 5 June 2017. [Online]. Available: https://www.owasp.org/index.php/Category:OWASP_Application_Security_Verification_Standard_Project. [Accessed 14 November 2017].

[12] William Jeffrey, "Minimum Security Requirements for Federal Information and Information Systems - FIPS PUB 200," NIST, Gaithersburg, 2006.

[13] National Institute of Standards and Technology, "Framework for Improving Critical Infrastructure Cybersecurity version 1.1 (Draft)," 5 December 2017. [Online]. Available: https://www.nist.gov/cyberframework. [Accessed 5 December 2017].

[14] A. S. Elmaghraby and M. M. Losavio, "Cyber security challenges in Smart Cities: Safety, security, and privacy," Cairo University Journal of Advanced Research, vol. 5, no. 4, pp. 491-497, 2014.

[15] United States Department of Homeland Security, "C3 Voluntary Program FAQs," United States Department of Homeland Security, 2015.



[16] Department of Homeland Security, "Study on Mobil Device Security," 4 May 2017. [Online]. Available: https://www.dhs.gov/publication/csd-mobile-device-security-study. [Accessed 19 December 2017].

[17] National Institute of Standards and Technology, "Assessing Threats to Mobile Devices & Infrastructure, The Mobile Threat Catalogue," NISTIR8144, 12 September 2016. [Online]. Available: https://csrc.nist.gov/CSRC/media/Publications/nistir/8144/draft/documents/nistir8144_draft.pdf. [Accessed 19 December 2017].

[18] F. T. Adminisration, "National ITS Architecture Subsystems and Communications," Federal Transit Adminisration.

[19] The Roadmap to Secure Control Systems in the Transportation Sector Working Group, "Roadmap to Secure Control Systems in the Transportation Sector," United States Department of Homeland Security, 2012.

[20] U.S. Department of Homeland Security, "Transportation Industrial Control System (ICS) Cybersecurity Standards Strategy," 2013.

[21] The National Academies of Sciences Engineering and Medicine, "Guidebook on Best Practicies for Airport Security," The National Academies Press, Washington, D.C., 2015.

[22] United States Department of Homeland Security, "NIPP 2013, Partnering for Ctitical Infrastructure Security Resilience," United States Department of Homeland Security, 2013.

[23] APTA Standards Development Program, "Cybersecurity Considerations for Public Transit," APTA Standards Development Program, Washington, D.C., 2013.

[24] Transportation Security Administration, "Surface Transportation Cybersecurity Toolkit," Department of Homeland Security, 17 11 2017. [Online]. Available: https://www.tsa.gov/for-industry/surface-transportation-cybersecurity-toolkit. [Accessed 17 11 2017].

[25] NHTSA | National Highway Traffic Safety Administration, "Cybersecurity Best Practices for Modern Vehicles," U.S. Department of Transportation, Washington, DC, 2016.

[26] E. a. M. National Academies of Sciences, Protection of Transportation Infrastructure from Cyber, Washington, DC: The National Academies Press., 2016.

[27] R. J. Murphy, M. Sukkarieh, J. Haass and P. Hriljac, "Guidebook on Best Practices for Airport Cybersecurity," Transportation Research Board, 2015.

[28] Booz Allen Hamilton, "Automoive ISAC," Booz Allen Hamilton, 23 11 2017. [Online]. Available: https://www.automotiveisac.com/. [Accessed 23 11 2017].

[29] US Computer Emergency Readiness Team, "US Computer Emergency Readiness Team," Department of Homeland Security, 17 11 2017. [Online]. Available: https://www.us-cert.gov/about-us. [Accessed 17 11 2017].

[30] Industrial Control Systems Cyber Emergency Response Team, "Industrial Control Systems Cyber Emergency Response Team (ICS-CERT) Mission," April 2017. [Online]. Available: https://ics-cert.us-cert.gov/About-Industrial-Control-Systems-Cyber-Emergency-Response-Team. [Accessed 3 January 2018].

[31] AASHTO, "AASHTO's Special Committee on Transportation Security and Emergency Management - Transportation System Cybersecurity Framework," 24 August 2016. [Online]. Available: http://sp.scotsem.transportation.org/Documents/Tues%20-%20Cybersecurity%20-%20AASHTO.pdf. [Accessed 4 January 2018].



[32] CTIA, "Cybersecurity Working Group," 2017. [Online]. Available: https://ctia.org/about/benefits/cybersecurity-working-group. [Accessed 01 2018].

[33] ITS JPO, "Development Activities - International Standards Harmonization," 2017. [Online]. Available: https://standards.its.dot.gov/DevelopmentActivities/IntlHarmonization. [Accessed 4 January 2018].

[34] HTG6, "Harmonized security policies for cooperative Intelligent Transport Systems create international benefits," [Online]. Available: https://ec.europa.eu/digital-single-market/news/harmonized-security-policies-cooperative-intelligent-transport-systems-create-international. [Accessed 5 January 2018].

[35] T. L. I. P. a. K. T. I. J. Kevin Gay, "How the U.S. Department of Transportation is Protecting the Connected Transportation System from Cyber Threats," [Online]. Available: https://www.its.dot.gov/factsheets/pdf/cybersecurity_factsheet.pdf. [Accessed 10 2017].

[36] N. Bob Kreeb and I. J. Kevin Gay, "SCMS POC," 2017. [Online]. Available: https://www.its.dot.gov/factsheets/pdf/CV_SCMS.pdf. [Accessed October 2017].

[37] P. I. J. Jonathan Walker, "Fundamental Principles and Research of the SCMS POC," September 2017. [Online]. Available: https://www.its.dot.gov/presentations/2017/SCMS_September2017Webinar.pdf. [Accessed October 2017].

[38] M. Chowdhury, Ph.D., P.E., F. ASCE, M. Rahman, A. Rayamajhi, S. Khan, M. Islam, Z. Khan and J. Martin, Ph.D., "Lessons Learned from the Real-world Deployment of a Connected Vehicle Testbed," Clemson University, Clemson, SC, 2017.

[39] V. K. Kevin Gay, "Safety Pilot Model Deployment: Lessons Learned and Recommendations for Future Connected," September 2015. [Online]. Available: https://ntl.bts.gov/lib/59000/59300/59361/FHWA-JPO-16-363.pdf. [Accessed October 2017].

[40] J. S. Debby Bezzina, "Safety Pilot Model Deployment: Test Conductor Team Report," June 2015. [Online]. Available: https://www.nhtsa.gov/sites/nhtsa.dot.gov/files/812171-safetypilotmodeldeploydeltestcondrtmrep.pdf. [Accessed October 2017].

[41] USDOT, "USDOT Guidance Summary for Connected Vehicle Deployments," USDOT, 2016.

[42] ITS JPO, "CV Pilot Deployment Program: New York City (NYC) DOT Pilot," [Online]. Available: https://www.its.dot.gov/pilots/pilots_nycdot.htm. [Accessed September 2017].

[43] ITS JPO, "CV Pilot Deployment Program: Tampa (THEA) Pilot," [Online]. Available: ttps://www.its.dot.gov/pilots/pilots_thea.htm. [Accessed September 2017].

[44] ITS JPO, "CV Pilot Deployment Program: Wyoming (WY) DOT Pilot," [Online]. Available: https://www.its.dot.gov/pilots/pilots_wydot.htm. [Accessed September 2017].

[45] National Institute of Standards and Technology, "NISTIR 8138 Vulnerability Description Ontology (VDO)," National Institute of Standards and Technology, McLean, VA, 2016.

[46] P. Ponticel, "SAE committee busy developing standards to confront the cybersecurity threat," 5 January 2015. [Online]. Available: http://articles.sae.org/13809/.

[47] H. Tipton and M. Krause, Information Security Management Handbook, Boca Raton: Auerbach, 2006.


Utilizing OWASP Application Security Verification Standard (ASVS)



Utilizing OWASP Application Security Verification Standard (ASVS)OWASP Security Verification Levels

OWASP Security Verification Levels

What level of review is appropriate for the application in question?

The budget and evaluation rigor allocated for an application should be directly proportional to the application’s exposure and its importance. Answer the following questions to help ascertain the appropriate level of for a security review.

Is the application revenue generating?

Is the application an externally facing asset?

Is the application storing/processing/transmitting sensitive information?

Is the application governed by regulatory compliance requirements?



OWASP ASVS Classification Definitions

The OWASP ASVS defines four (4) levels of verification, with each level increasing in depth as the verification moves up the levels.

Level 0 (or Cursory) is an optional certification, indicating that the application has passed some type of verification.

The detailed verification requirements are not provided by ASVS. Instead, organizations

can define their own minimum criteria (such as automated runtime scan, or strong

authentication mechanism). This level is most appropriate for organizations that have a

large number of applications, and where a low cost point of entry may be required.

Level 1 (or Opportunistic) certified applications adequately defend against security vulnerabilities that are easy to discover.

The specific set of vulnerabilities against which Level 1 verification is measured typically includes

vulnerabilities that Praetorian can identify with minimal-to- low effort. As such, this level cannot

be considered a thorough inspection or verification of the application, but more of a quick

inspection. Level 1 is typically appropriate for applications where some confidence in the correct

use of security controls is required, or to provide a quick sweep of a fleet of enterprise

applications, to assist in developing a roadmap for more thorough inspections at a later date.

Level 2 (or Standard) verified applications adequately defend against prevalent security vulnerabilities whose existence poses moderate-to-serious risk.

The specific set of vulnerabilities against which Level 2 verification is measured includes OWASP

Top 10 vulnerabilities and business logic vulnerabilities. Level 2 ensures that evaluated security

controls are in place, effective, and used as needed within the application to enforce application

specific policies. Level 2 represents an industry standard for which the majority of an

organization’s sensitive applications would strive. Level 2 is typically appropriate for applications

that handle significant business-to-business transactions, including those that process healthcare

information, implement business-critical or sensitive functions, or process other sensitive assets.

Level 3 (or Advanced) certified applications adequately defend against advanced security vulnerabilities, and demonstrate principles of good security design.

The specific set of vulnerabilities against which Level 3 verification is measured includes more

difficult to exploit vulnerabilities, which would most likely be exploited by determined attackers.

Level 3 is the only ASVS level which also requires an inspection of the application’s design.

Level 3 verification is typically appropriate for critical applications that protect life and safety,

critical infrastructure, or defense functions or have the potential of facilitating substantial damage

to the organization. Level 3 may also be appropriate for applications that process sensitive assets.

Threats to security will be from determined attackers (skilled and motivated attackers focusing on

specific targets using tools including purpose-built scanning tools).



OWASP ASVS 3.0.2 Coverage Matrix

Security Control Group Level 1:

Opportunistic Level 2: Standard Level 3: Advanced

Architecture, Design, Threat Modeling 1 / 10 6 / 10 10 / 10

Authentication Controls 17 / 26 24 / 26 26 / 26

Session Management Controls 11 / 13 12 / 13 13 / 13

Access Control 9 / 12 11 / 12 12 / 12

Malicious Input Handling 14 / 21 20 / 21 21 / 21

Cryptography at Rest Controls 2 / 10 7 / 10 10 / 10

Error Handling & Logging Controls 1 / 12 7 / 12 12 / 12

Data Protection Controls 4 / 11 8 / 11 11 / 11

Communications Security Controls 7 / 13 8 / 13 13 / 13

HTTP Security Controls 6 / 8 8 / 8 8 / 8

Malicious Controls 0 / 2 0 / 2 2 / 2

Business Logic Controls 0 / 2 2 / 2 2 / 2

Files and Resources Controls 0 / 9 9 / 9 9 / 9

Mobile Controls 6 / 11 9 / 11 11 / 11

Web Service Controls 7 / 10 10 / 10 10 / 10

Configuration Controls 1 / 10 5 / 10 10 / 10

Internet of Things Controls 10 / 28 20 / 28 28 / 28



The depth is defined in each level by a set of security verification requirements that must be addressed (these are included in the requirements tables towards the end of this document). It is a verifier’s responsibility to determine if a target of verification (TOV) meets all of the requirements at the level targeted by a review. If the application meets all of the requirements for that level, then it can be considered an OWASP ASVS Level N application, where N is the verification level that application complied with. If the application does not meet all the requirements for a particular level, but does meet all the requirements for a lower level of this standard, then it can be considered to have passed the lower level of verification.

The breadth of the verification is defined by what parts of the application are reviewed for each security requirement. For example, the scope of the review may go beyond the application’s custom-built code and include external components. Achieving a verification level under such scrutiny can be represented by annotating a “+” symbol to the verification level.

Coverage Key

Excellent

Good

Fair

Inadequate



Level 0: Cursory

Level 0 (or Cursory) is an optional certification, indicating that the application has passed some type of verification.

Level 0 is designed to be a flexible point of entry into the verification hierarchy; it indicates that some type of review has been done on the application. The detailed verification requirements are not provided by ASVS. Instead, organizations can define their own minimum criteria (such as automated runtime scan, or strong authentication mechanism).

This level is most appropriate for organizations that have a large number of applications, and where a low-cost point of entry may be required. One (1) organization may use Level 0 to require a cursory automated scan of all of their external facing applications using the organization’s commercial tool of choice; whereas another organization may define L0 requirements using data from a recent breach.

Unlike the other ASVS levels, Level 0 is not a prerequisite for other levels - an application can jump straight to Level 1 without achieving Level 0 certification (if L0 is not defined by the organization).

When defining Level 0 requirements, it is advised that each requirement be documented in a similar manner to the Detailed Verification Requirements in this document – clear, distinct, realistic, and verifiable.

Overview of Verification Requirements



Level 1: Opportunistic

An application achieves Level 1 (or Opportunistic) certification if it adequately defends against application security

vulnerabilities that are easy to discover.

The specific set of vulnerabilities against which Level 1 verification is measured is detailed in the Detailed

Verification Requirements, but typically includes vulnerabilities that a verifier can identify with minimal-to-low

effort. As such, this level cannot be considered a thorough inspection or verification of the application, but more of

a quick inspection.

Level 1 is typically appropriate for applications where some confidence in the correct use of security controls is

required, or to provide a quick sweep of a fleet of enterprise applications, to assist in developing a roadmap for

more thorough inspections at a later date.

Threats to the application will most likely be from attackers who are using simple techniques to identify easy-to-

find and easy-to-exploit vulnerabilities. This is in contrast to a determined attacker who will spend focused energy

to specifically target the application.




Level 2: Standard

An application achieves Level 2 (or Standard) verification if it also adequately defends against prevalent application security vulnerabilities whose existence poses moderate-to-serious risk.

The specific set of vulnerabilities against which Level 2 verification is measured is detailed in the Detailed Verification Requirements, but would include OWASP Top 10 vulnerabilities and business logic vulnerabilities.

Level 2 ensures that evaluated security controls are in place, effective, and used as needed within the application to enforce application-specific policies.

Level 2 represents an industry standard for which the majority of an organization’s sensitive applications would strive. Level 2 is typically appropriate for applications that handle significant business-to-business transactions, including those that process healthcare information, implement business-critical or sensitive functions, or process other sensitive assets.

Threats to security will typically be opportunists and possibly determined attackers (skilled and motivated attackers focusing on specific targets using purpose-built scanning tools as well as manual testing techniques).




Level 3: Advanced

An application achieves Level 3 (or Advanced) certification if it also adequately defends against all advanced application security vulnerabilities, and also demonstrates principles of good security design.

The specific set of vulnerabilities against which Level 3 verification is measured is detailed in the Detailed Verification Requirements, but would include more difficult to exploit vulnerabilities, which would most likely be exploited by determined attackers.

Level 3 is the only ASVS level which also requires an inspection of the application’s design.

Level 3 verification is typically appropriate for critical applications that protect life and safety, critical infrastructure, or defense functions or have the potential of facilitating substantial damage to the organization. Level 3 may also be appropriate for applications that process sensitive assets.

Threats to security will be from determined attackers (skilled and motivated attackers focusing on specific targets using tools including purpose-built scanning tools).
