1	"Intelligent Transportation Systems (ITS" Intelligent Transportation Systems (ITS) Policy Program: Safety Policy Review and Discussion
2	Presentation Topics 2010-2011 Safety Policy Review Policy Program in Support to V2V/V2I Program Roadmaps Accomplishments since last workshop (August 2010) Stakeholder Engagement Discussion Governance Approach to Communications Security/Security Infrastructure Break Out Session Instructions Key Takeaways, Summary, and Next Steps
3	The Policy Program: Support of the Connected Vehicle Research Program
4	Identified Challenges
5
6	Where Are We Now? Roadmaps Developed roadmaps: Global, cross-cutting roadmap New version now available based on common issues between safety and mobility Safety Policy Roadmap Well vetted through Safety team and stakeholders Key activities in support of NHTSA 2013-2014 agency decision have been prioritized Roadmaps under development: Truck policy roadmap Draft roadmap vetted with trucking stakeholders Focus is on value propositions Mobility policy roadmap Draft Roadmap under internal review. AERIS policy roadmap Working draft Focus is on crosscutting issues (across the TCs) Transit policy roadmap Under development
7
8	V2V/V2I Safety Policy Roadmap
9	Safety Policy Roadmap: Communications Security & Infrastructure Objective: Develop the institutional options in support of a technical communications security solution. Steps/Milestones: Develop Certificate Management Organizational/Operational Models: Options due in winter 2011 Approach for Safety Pilot testing: March 2012 Test Results and Evaluation of Approach: August 2013 Final Report: October 2013 Analyze Infrastructure Options: Requirements Definition: Fall 2011 Analysis of Communications Options: Winter 2011/12 Implementation Requirements and Business Models: Spring 2012 Progress/Accomplishments: Analyzed technical approach and identified policy issues and trade-offs Chose DSRC for Safety Pilot
10	Safety Policy Roadmap: Certification Objective: Develop the institutional options that assure interoperability. Steps/Milestones: Policy Framework /Policies on interface access/control points: Draft a policy framework that identifies Core System interface points for certification/standards: Winter 2011/2012 Finalize policy framework: October 2013 Develop/Analyze Institutional Models and Market Impacts: Using technical process/metrics (beginning 2012), define institutional model options, including draft policies in support of technical process: Summer 2012 Analyze market impacts: Fall 2012 Final recommendation: October 2013 Progress/Accomplishments: Analyzing policy issues with core system Reviewing technical certification process Planning for development of policy framework
11	Safety Policy Roadmap: Spectrum Analysis Objective: Establish policies to transition the Dedicated Short Range Communications (DSRC) 5.9 GHz spectrum from research use to commercial use. Steps/Milestones: Needs Analysis for Spectrum Management: Identify potential need and institutional processes for spectrum management: Spring 2012 Ongoing Communications with NTIA and FCC as Needed present – October 2013 Progress/Accomplishments: Met with FCC in Fall 2010 to provide program update Met with FCC in April 2011 to clarify use of channels based on test results
12	Safety Policy Roadmap: Governance Objective: Develop a governance framework and policy options to support national implementation
13	Safety Policy Roadmap: Risk/Liability Objective: Address relevant legal issues Steps/Milestones: Identify new risks and legal issues: Scope issues / develop risk inventory: now – Spring 2012 Conduct research and develop options for mitigation/new policies/policy modifications: Spring 2013 Final report on potential mitigation strategies: October 2013 Progress/Accomplishments: Have identified legal issues and will be working with a DOT legal task force to scope policy research plan
14	Safety Policy Roadmap: Cost-Benefit Analysis and Regulatory Support Objective: Develop comprehensive analysis of total benefits and costs of implementing a connected vehicle environment. Develop a rigorous benefits-cost framework for making a NHTSA agency decision.
15
16	Additional Activities, 2010-2011 V2V/V2I Senior Policy Task Force: Internal multi-modal executive working group in DOT Formed in March 2011, meets regularly Stakeholder Engagement: Implementation scenarios workshop–June 2010 Safety workshop–July 2010 Mobility workshop—December 2010 Truck Policy webinar—February 2011 Governance roundtable –June 2011 Safety workshop – August 2011
17	Today’s Discussions Governance – Terry Regan, US DOT/Volpe Center, Presenter Review expert knowledge about how to structure Governance and lessons learned from other industries Gather stakeholder input in break-out sessions Approach to Communications Security and Security Infrastructure – Suzanne Sloan, US DOT/Volpe Center, Presenter Review approach developed using expert input Discuss options for turning approach into prototype for testing Discuss next steps
18	"Governance" Governance
19
20	Relevant Industry Governance Models Healthcare Industry / Health IT – Framework for policy and technology practices while protecting privacy; offers insights into standards setting, governance Public Safety / Emergency Response Communications – Highlights the issue of interoperability as well as issues dealing with spectrum sharing. National Standards of Standards and Technology (NIST) – Provides government-wide examples of challenges with technology adoption and insights into analysis of private sector and the cost/value proposition. Internet / ICANN (Internet Corporation for Assigned Names and Numbers) – Provides an example of governance structures already being in place (implemented by the US Department of Commerce) but then dismantled and reconstructed to transition management to the global community. Smart Grid – Highlights how governance issues related to consumer data, security issues and data ownership can have innovation implications. Telecommunications / Cell phone industry: The governance of the cell phone industry is relevant as a parallel to a transportation communications system. Cognitive radio – Example of governance structure that used to be a federal government function, but is now in a private sector laboratory which has been delegated a government role. Also deals with issues concerning wireless governance, spectrum sharing and white space.
21	Best Practices: Stakeholder Involvement Multi-stakeholder engagement is critical. Identify “veto or dispute points” early in the process. Make use of the innovative techniques/technologies for engaging the public and give voice to a wide range of groups during the governance-setting process. Consider horizontal and vertical perspective when evaluating stakeholder impacts: Horizontal–inter-agency ties within one level of government. Vertical–different levels of government, for example, between state and local. Typically, local and state entities are responsible for implementation, which could have a large effect on governance.
22
23	Best Practices: Privacy Implement “privacy by design” early in the process—note that all information can or should not have to be treated equally. Note that privacy is more than anonymity—it is also a set of clear, transparent, enforceable principles for how data will be collected, used, accessed, and/or stored. Fair Information Practice Principles (FIPPs): A solid example of how to best deal with information from both a privacy and information management perspective. FIPPs is a process for identifying the purpose of information collection and to determine if the correct information is being collected. Good examples include: Department of Homeland Security (DHS), Health and Human Services (HHS), and the Organization for Economic Cooperation and Development (OECD). The 2007 Privacy Principles for VII were based on the OECD principles.
24	Developing Governance We asked the experts: “What does the program need to do to define a governance structure for new technologies/systems?” The response was 3 steps: Step 1: Define Why Governance is Needed/Who is Involved Define Mission and Goals Define Good Governance Principles, based on the Mission Identify Trade-offs and Downstream disputes Step 2: Map Governance – Who else has defined governance/authority in this space? What is the legal landscape in this space? Step 3: Develop Governance Options Develop Approach(es) Develop a Policy Framework for use of Tools such as rules, standards, certification, etc. Develop Privacy Strategy – turn principles into policy/design
25	Step 1: Determine Mission and Goals Determine a mission and goals for the program Establish appropriate good governance principles for the program. Examples include: Participation / Voice – Those who will be impacted by the system will be part of the decision making process Accountability – Clearly defined process for how to address disputes Representation – Recognized stakeholder participation and interests Transparency – Clarity on how and why decisions were made Efficiency – Recognize that there are trade-offs with participation Flexibility – Don’t lock into decisions that may lead to stalled innovation Evaluate and prioritize the list of defined principles and identify potential trade-offs Identify areas where market failures may impact the governance model – how much will failure be tolerated? Answer will help identify where the Federal government is needed most. Note that the less tolerant of failure, the less tolerant of innovation and the more centralized control and limited access is required. Evaluating failure will determine levels of tolerance and drive the regulatory structure.
26	An Important Highlight Safety vs. Mobility/Environment–Experts noted that we have mission/goals that might be in some conflict with one another. They asked: Is it about enhancing safety or improving mobility or mitigating environmental degradation? Or all? It is about establishing trust and interoperability? Others? Which are the priorities? They noted that there are potentially different roles for government in each: A safety goal will require a different governance process and a different Federal role as opposed to goals for enabling mobility and environmental applications. Goals will help to determine which stakeholders will be at the table. Use of regulatory tools, standards, and other rules differ, but so does access and enforcement. Privacy issues in safety seem to be far less of a privacy concern than for mobility.
27	Step 2: Map Governance Process of identifying what other agencies or organizations having existing governance structures or authority that might overlap with the V2V/V2I governance needs. Mapping describes both: The current situation The entities that coordinate governance versus the entities with the authority that are needed to enforce interagency coordination. Experts suggested mapping the following elements: Stakeholders – who is central to the network and what relationships are present between stakeholders? Roles of Federal, state, and local government Roles of public institutions Existing private sector involvement Operational network – who is in charge of each particular aspect, who has authority to make decisions? Budget categories and public spending trends
28	Step 3: Develop Governance Options Analyze strengths, weaknesses, and relevance of different approaches for meeting V2V/V2I needs: Holistic vs. Organic: Holistic: A total systems or systems engineering approach—May be valuable to inform the 2013 process and other processes Organic: An evolutionary approach to incrementally implementing the system and running early on and learning by doing—Builds confidence with the things that work early on, a way of “growing” a system. Centralized vs. Decentralized Hybrid Others Identify what different types of governances are needed for V2V/V2I. Governances typically exists at different levels: Regulatory governance – involves typical decisions on price setting, anti-trust issues Public policy governance & values – involves moral / social values, issues surrounding privacy International governance – involves international affairs, national security and defense Others Examine the different processes or functions of governance. Functions help work towards certain goals, such as trust and interoperability. Mechanisms will need to be developed to perform each function.
29	Governance may be Governances! It is possible to have many “governances” for the V2V/V2I system
30	Governance Tools and Lessons in Application Standards: Do not ‘over-develop’ standards. Consider the use of ‘soft law’ where standards are set and then benchmarking is established to determine if people are meeting benchmarks voluntarily. Regulation: Look at the model of Rulemaking Workshops and Negotiated Regulations (RegNeg) in various case studies. RegNegs are used to identify critical issues, create consensus, or help mitigate disputes. The decisions are not binding on the agency or stakeholders. This has typically been used in the EPA and OSHA in developing industry standards. Certification: Certification can be a great enforcement tool and establishes trust – an essential element in a cooperative safety system. Certification can have unintended consequences by locking in a certain type of technology and inhibiting innovation. Certification represents an example where a wholly government function can be transitioned to the private sector. It is better to have multiple certifiers. This keeps standards high and encourages competition.
31	Governance Tools (continued) Enforcement: Consider to what extent enforcement can be privatized if a public good (such as safety) is involved. Funding: Funding can be a valuable and powerful governance tool depending on who is transferring funds and what the criteria is for funding transfers. This could affect the technology governance and help to understand what will prevail and how technology will be implemented. Consumer protection is important and the end user must be represented in the processes of governance. Information -governance frameworks identify important factors in protecting privacy: For what purposes is the data or information collected? When collected, is that enough data or information to deal with that purpose? Collecting data that is not necessary? What is done with the collected data? Who has access? How long is it stored? What if there is a change in the information being collected? Who is impacted? What are processes for facilitating the change? How do you resolve disputes? Who is involved in the resolution? What are the remedies?
32	Key Lesson: **Fully understand your governance tools and their potential cost implications as well as the consequences of not having them. Recognize that there are costs even with self-governance.
33
34	Break — 10:45-11:00am Next: Discussion of Communications Security Instructions for Break Out Sessions
35	Communications Security – Approach Implementing V2V/V2I will require communications security Key part of the prototype system for which experts were engaged to develop an approach V2V/V2I has unique characteristics that differ from traditional systems. Major difference is that mission-critical systems typically do not use wireless. Key communications security requirements are: Provide trusted messages between vehicles – trust is established through a user authentication process. These messages are not encrypted Secure messages between vehicles and certifying authority – messages are encrypted to prevent eavesdropping and tampering over the communication channel Ensure Anonymity - no personally identifiable information is contained in messages Allow for Scalability – needed to support over 250 million vehicles in the system
36	Important Distinction in Development Path Approach vs. Design vs. Model vs. System Approach = first step in identifying industry best practices and tailoring them to meet the requirements of a V2V/V2I environment for preventing, detecting, and mitigating security risks. Deliverable due in Fall of 2011. Design = second step that structures the technical elements into a representative prototype. Deliverable due in Spring 2012. Model = third step that combines the technical prototype with organizational and operational elements the results in a representative system to test and evaluate in real world environment. Deliverable due in Summer 2013. System = last and final step is to combine test results with prototype model to understand the requirements/specifications for an operational system. Deliverable due in Fall 2013.
37	Description of Security Approach (continued)
38	Description of Security Approach Three key elements: Public Key Infrastructure (PKI) Vehicle and other security elements Policies PKI is an umbrella term used to describe the hardware, software, people, policies, and procedures needed to create, manage, store, distribute, and revoke digital certificates. For V2V/V2I, the PKI establishes trusted messages: Provides authorization credentials to vehicles for participation in the network Facilitates the revocation of credentials if an administrating authority decides to do so. Vehicle and other security elements at the local (vehicle) level are incorporated to prevent misbehavior and detect misbehavior already occurring within the system. These include: Hardware: standard controller on the vehicle + tamper-proof encasements Software: functionality checks and misbehavior detection processes
39	Description of Security Approach (continued) Policies, in combination with technical solutions, assist in preventing and addressing misbehavior. Such policies can include: Legal deterrence for physical tampering with vehicle’s on-board equipment User access policies Split certificate management entity
40	Description of Security Approach (continued) Risks: Analysis suggests minimal risk to safety in event of a successful attack. Greatest risk appears to be in reducing acceptance (and use) of an operational system if users do not trust it and ignore it. The identified privacy attacks would require a significant level of effort and investment to implement. Risk of these types of attacks is thus lower than utilizing existing methods for tracking (cell phone or physically following a vehicle). The identified privacy or system attacks would require insider knowledge of the system or physical access to a vehicle.
41	Advantages and Limitations of the Approach Advantages: Meets objectives of providing trusted, anonymous messages using random identifiers that are changed every five minutes Is scalable to 250+ million users Supports crash avoidance safety applications Many attacks are only feasible with a significant amount of investment and expertise about the system Approach prevents/mitigates against harm to the system Limitations: No instantaneous identification of misbehaving actors; delay in identification and delay in removing misbehaving actors from system Splitting the certificate management entity may have cost implications Need frequent updates of certificates; as of now, our approach limits updates to driving by a roadside unit (RSE) as other options have significant challenges Approach does not address system backhaul (RSE) connections
42	Technical - Policy Balance Balanced Approach: Privacy versus Safety versus Security Safety versus Security Security versus Cost Technical Requirements: Enable trusted communication between vehicles and secure communication between vehicles and the infrastructure Provide reasonable defense against attacks Protect privacy and personal information of users Reasonably balance privacy needs against security requirements
43	Example: Decision about Communications media Which communications media can support both the technical and the policy requirements? Viable choices include: Existing Cellular Networks Dedicated Short Range Communications (DSRC) WiFi What are advantages and limitations of each? Business Model Questions: – How much will it cost? Who will fund deployment, operations and maintenance? Ownership? Can commercial networks be used or leveraged? Can multiple networks be used or combined?
44
45
46
47	Next Steps for Communications Security Conclusion: Approach provides us with a solid basis for moving to next step–prototyping and analyzing business models. Next Steps: Refine security approach Interoperability and scalability tests Fall 2011 Engage privacy advocates Privacy Roundtable – Outreach to privacy advocacy groups in Winter 2011 Identify options for organizational and operational scenarios (see Roadmap for Safety Policy) Certificate Management Entities – Organizational and Operational Interim Models Spring 2012 Costs – Interim security cost estimates Spring 2012 Governance – Develop options and guidance for understanding roles and responsibilities – Spring 2012 Develop technical design (if appropriate) – Spring 2012 Test prototype during Safety Pilot Model Deployment
48	Questions? Questions?
49	Break Out Session Instructions Four Rooms – Same session in each room Facilitator and Notetaker will be present; ask that the group appoint a representative to report out San Francisco (Green): Facilitator is Suzanne Sloan; notetaker is Andrea Van Easton New Orleans (Red): Facilitator is Terry Regan; notetaker is Jamie Weil Hong Kong (Blue): Facilitator is Gary Ritter; notetaker is Julie Nixon Regency A (Yellow): Facilitator is Valerie Briggs: notetaker is Kevin Gay
50
51	Summary Report Out from Groups Summary of what we heard Discussion of next steps