onboard security presentation title - its-nyconnected vehicle significant reduction in deaths may be...
TRANSCRIPT
2017 ITS-NY TWENTY-FOURTH ANNUAL MEETING “ITS Mobility – A New World”
June 15-16, 2017; Saratoga Springs, NY
AGENDA -continued-
Friday, June 16, 2017 7:30 a.m. ITS-NY Board of Directors Meeting, Garden Room 7:30 Registration Desk and Exhibit Hall Open; Full Breakfast in Exhibit Hall 9:00 Panel 4: Using ITS for Performance Assessment
Panel Moderator: Dr. Camille Kamga, UTRC2 “Analyze This: Using NPMRDS for Multi-Geographic-Resolution (MGR) Performance
Assessment,” Dr. Catherine Lawson, SUNY “Artificial Intelligence Saving Lives on Highways (with Existing Infrastructure)," Branko Glad, Telegra “ITS and Performance Assessment for Freight Transportation,” Shobna Varma, StarIsis Corp.
10:15 Break in Exhibit Hall (Exhibit Hall Closes at 10:45 a.m.) 10:45 Panel 5: ITS Security Panel Moderator: John Bassett, NYSDOT
“Considering Cybersecurity,” Roderick Link, FBI Cyber Task Force Unit/Albany “Cybersecurity,” Siva Narla, ITE “Security for Connected Vehicles: Successes and Challenges,” Dr. Virendra Kumar,
Security Innovation Inc. Noon ITS-NY Closing Luncheon
ITS-NY Officers and Board of Directors Election Results; Free Weekend and CITE Course Drawings
1:15 p.m. Adjourn
Security for Connected
Vehicle: Successes and
Challenges
Dr. Virendra Kumar
Principal Scientist, OnBoard Security
Outline
Connected vehicle security: what and why?
Successes
– SCMS: developed and ready for use
– CIA analysis: a framework for device security
Challenges
– Provisioning of certificates into devices
– Misbehavior detection and revocation
Traffic Safety
32k US road deaths, and 3.8M injuries annually
Fatalities and injuries = $300B/year
Congestion = $230B/year
Leading cause of death for ages 15-34 in US
Technology Evolution
Passive Active
Proactive
Connected Vehicle
Significant reduction in deaths may be possible from vehicle-to-vehicle (V2V) wireless
communications for 360o warning applications.
– 300 m range, 802.11-derived medium access
– Basic Safety Message (BSM)
Contains location, velocity, steering angle…
Transmitted up to 10x second
Allows receiving unit to predict collisions and warn driver
– “Prevent 80% of unimpaired 2-vehicle accidents”
Availability of wireless communications may also enable other applications
– Signal phase and timing
– Point of interest notification
Security Considerations
Risk of false messages
– Reduce users’ faith in system and cause warnings to be ignored
– (not safety-related): Messages may affect choice of route or have other mobility/efficiency
impacts
– Requirement: must be able to detect untrustworthy senders or messages and let receivers
know not to trust them
Impact on privacy
– Don’t want the system to be used as a tracking system
Tracking is always possible, don’t want this option to be the cheapest
– Prevent eavesdroppers or insiders from collecting Personally Identifiable Information (PII)
– Conflict with requirement to detect and remove untrustworthy senders
Protection Against False Messages
Protect against false messages:
– Messages are signed and not encrypted
Signed using ECDSA over the NISTp256 curve with ECQV certs
– Message signing certificate specifies permissions (not identity) of holder
– Misbehaving units can have their certificates identified and revoked
Use different certs for different types of operation
– Security management, application A, application B
Protection of Privacy
Don’t directly reveal information: No personal information included in broadcast
messages
Prevent tracking: “Identifiers” at application, network and other levels should be
transient
Vehicles have a number of simultaneously valid BSM certificates, can choose which
certificate to use to sign each message
– Baseline number of certs = 20 per week
– When cert changes, all other identifiers change too: currently no standardized
algorithm for cert change
Successes in CV Security
SCMS Design
Secure Credential Management System
(SCMS – think PKI-on-steroids) for V2V
includes privacy-preserving mechanisms
Shuffle at RA to protect against CA learning
certificates
Linkage authorities to allow tracing
misbehaving devices without revealing their
identity, and revoking in a way that only
allows them to be tracked after revocation
Organization separation ensures no single
insider / no single database breach can
track any car
SCMS Development
SCMS Proof-of-Concept Implementation
– EE requirements and specifications available since May 04, 2016 (https://www.its.dot.gov/pilots/pdf/SCMS_POC_EE_Requirements.pdf)
– SCMS QA environment available since May 19, 2017. (https://cvcs.samanage.com/catalog_items.portal?category=SCMS+-+POC)
Support for Connected Vehicle Pilot Deployment Program
– New York City DOT Pilot (https://www.its.dot.gov/pilots/pilots_nycdot.htm)
– Tampa-Hillsborough Expressway Authority Pilot (https://www.its.dot.gov/pilots/pilots_thea.htm)
– Wyoming DOT Pilot (https://www.its.dot.gov/pilots/pilots_wydot.htm)
Device Security
Certificates should be issued to a device only when it is considered to be secure enough.
– Where do security requirements come from?
– What are they?
– How can one make conformance statements about device security?
– Whose responsibility is it to check those conformance statements?
– …
Threat model is application specific
Connected Vehicle applications –not just vehicles!
– Traffic signals, signs, gates, toll plazas, back-end systems, …
– Signal preemption, border crossing, pedestrian in signalized intersection warning...
Many devices playing many different roles in different applications
Deriving security requirements
False positives
– Unlikely to cause physical harm
– “Something bad round the corner!swerve now!”
– But invalid alerts reducedriver faith in system
– Appropriate security approach: Authentication + misbehavior detection
False negatives
– Need to warn about denial of service once system is widely deployed
Threat model for crash avoidance
!!!
General Approach
FIPS-199 Confidentiality, Integrity, Availability (C-I-A) low/medium/high (little/significant/catastrophic)
Focus on the flow of information/data in and out of the device
Analyze a representative subset of projected applications from the CVRIA
Use the devices data C-I-A requirements to derive the device’s requirements
See which C-I-A combinations turn up most frequently
Define a “minimal useful” set of device classes that cover all the identified C-I-A combinations
Specify security controls for each device class based on NIST SP 800-53
Goals of SCMS Device Requirements for CV Pilots
Enable Privileged applications to securely use different cryptographic keys
– Privileged vs. unprivileged applications
– Privileged application crypto key access
Prohibit read access to key material!
Public key (signature verification) protected from unauthorized replacement
Control access to data by application
Secure software/firmware update
https://wiki.campllc.org/display/SCP/Hardware%2C+Software+and+OS+Security+Requirements
Enforcement
Vendors self-certify for Pilot Deployments
There are interoperability tests but no platform security tests yet
Note, FIPS 140-2 level 2 or 3 hardware *equivalent*
Challenges in CV Security
Device Credentials
Device enrollment
– Enrollment interfaces are not standardized, and may differ from one manufacturer to another.
– How can small manufacturers participate without being overburdened with understanding and designing these interfaces?
– How can special vehicles like police, emergency, etc. get regional authorization? How can their authorization be changed?
Once enrolled, how can devices get authorization credentials in the absence of frequent connectivity?
Misbehavior Detection and Revocation
Privacy vs. misbehavior detection
– How can one restrict Misbehavior Authority (MA) to maintain honest users’ privacy, yet keep it powerful enough to detect misbehaving users?
– How can one prevent MA from colluding with rest of the SCMS to undermine honest users’ privacy?
– …
Revocation
– How to enforce revocation in the absence of frequent connectivity?
– How to “unrevoke” someone who was revoked by mistake or whose malfunction has now been fixed?
– …
Thank you!
Cyberattacks on the Public
Sector
Trends and Perspectives CS Roderick Link > FBI Albany
//GCFA, GPEN, GREM, GCIH, GCIA
//In the Battle for New Cybertron…
//The Good
FireEyeSymantecCisco CarbonBlack
NSA
The Bad >
Hactivists
Ransomware
Russian APT
Chinese APT
Account Compromise
//The Ugly
Former Employees
Insider Threat
NSA
Reality is a Little Less Hollywood
The adversary is not always sophisticated.
An actual sophisticated adversary does not always equal
sophisticated attack or require sophisticated response.
//Know the Enemy
75%
25%
POINT OF ORIGIN
Outsiders Insiders
51%
18%
31%
OUTSIDERS
Organize Crime Nation State Other
73%
21%
6%
MOTIVATION
Financial Espionage / Intel Other
Source: 2017 Verizon Data Breach Investigations Report 10th Ed.
Know the Enemy > Points
Insiders on average are a way larger threat than most organizations
expect
Outsiders are overwhelmingly not nation-state
Mostly, cyber attacks come down to money
//Know the Weapon
62%
38%
METHOD
Hacking Other
51%43%
6%
TACTIC
Malware Social Other
66%
34%
VECTOR
Email Attachment Other
Source: 2017 Verizon Data Breach Investigations Report 10th Ed.
//Know the Weapon
Emails contain malware
1
141 Phishing attempts per email
1
2329
Source: Internet Security Threat Report – Vol 22, April 2017 - Symantec
Attack Rates for Public Sector
Trends > Malware
New ransomware family discoveries increased nearly 600% from 2015 to 2016, despite overall malware families decreasing ~8%
Magnitude (purple), Angler (black), Rig (red), Neutrino (white), Sundown (pink) all deteriorated by the beginning of 2017.
Source: F-Secure State of Cyber Security 2017
Know the Weapon > Points
Hacking is often not required because of poor configurations
Social attacks are almost as frequent as malware.
The overwhelming majority of malware is delivered by email.
Despite shrinking field, large shift to ransomware
Public Sector > Perspective
36%
23%
18%
23%
SECTOR
Finance Healthcare Public Other
Source: 2017 Verizon Data Breach Investigations Report 10th Ed.
Public Sector > Perspective
75%
25%
OVERALL
Outsiders Insiders
Source: 2017 Verizon Data Breach Investigations Report 10th Ed.
60%
40%
PUBLIC SECTOR
Outsiders Insiders
POINT OF ORIGIN
Public Sector > Perspective
Source: 2017 Verizon Data Breach Investigations Report 10th Ed.
73%
21%
6%
OVERALL
Financial Espionage / Intel Other
20%
64%
16%
PUBLIC SECTOR
Financial Espionage / Intel Other
MOTIVATION
Public Sector > Points
Insider threat is far outsized compared to Private Sector
The motivations are much more destructive
Trends > Mobile
Source: Internet Security Threat Report – Vol 22, April 2017 - Symantec
Trends >
Internet of
Things
Source: Internet Security Threat Report – Vol 22, April 2017 - Symantec
Trends > Malware for Breaking Things
Shamoon reappeared in Saudi Arabia in November of 2016. This malware
compiles a list of files from targeted directories, uploads them to the attacker,
then erases the victims MBR. Shamoon has been targeted at the Middle East Energy sector and bares similarity to Flame.
Campaigns in late 2015 and early 2016 that initially used BlackEnergy malware
targeting the Ukranian Energy sector transitioned to using KillDisk malware,
triggering blackouts across the country.
Planning a Defense > Outsiders
Source: 2017 Verizon Data Breach Investigations Report 10th Ed.
If half of all compromises are a result of malware, what resources can you spend
on endpoint AV services, OS upgrades?
If (nearly) the other half of compromises are a result of social engineering, what amount of time are you dedicating to user training?
Do you have the resources available to identify phishing attempts against your
domain and can you revoke messages?
Do you have the rapport between IT and end users to encourage compromise
reporting and to reactively change credentials?
Planning a Defense > Insiders
In what ways are access privileges limited by group role?
How are actions by administrators audited?
What happens to credentials when a user changes roles or separates from the
organization?
//Planning a Defense
Are your access points secured against simple packet captures?
Do you have the ability to alert on foreign IP addresses attempting
authentication at a gateway?
Can field devices be accessed without credentials or with default credentials?
Are you building partnerships with intelligence value?
“Our obligation is to refuse to let bad win, to refuse to let
evil hold the field.”
< James Comey
Roadway Transportation System
Cyber Security Framework (RTCSF)
Update on Stakeholder driven effort in US
Supported by US DOT
Siva R. K. Narla
Senior Director
Institute of Transportation Engineers (ITE)
Email: [email protected]
2
Topics
• Need - Improving Critical Infrastructure
Cybersecurity
• Transportation System Cyber-Security
Framework (TSCSF)
• TSCSF Services – Products and Tools
• TSCSF Stakeholder Partnership
3
Need - Improving Critical Infrastructure
Cybersecurity
• Driver - Executive Order (EO) 13636 “Improving
Critical Infrastructure Cybersecurity”
• NIST Framework for Improving Critical
Infrastructure Cybersecurity
• USDOT Framework for Improving Critical
Infrastructure Cybersecurity
4
Transportation System Cyber-Security
Framework (TSCSF) - WHY
Source: Edward Fok
USDOT/Resource Centers
5
TSCSF – What are We Trying to
Protect
Source: Edward Fok
USDOT/Resource Centers
6
TSCSF Services – Phase I (Q4 2016)
• US DOT funded effort to create the TSCSF
• Objectives of the task order is to develop a
TSCSF Partnership
• Develop a BETA NoCOE Cyber Security website
as a prototype for transportation owners and
operators to identify needs and develop detailed
requirements and testing
• Define additional needs such as implementation
guidance, affiliated resources, training materials
and outreach to stakeholders nationwide
7
TSCSF Services – Phase I (Q4 2016)
• Define Mission, vision and goals for TSCSF
• Invite stakeholders from all five associations
representing transportation infrastructure and
form groups representing
Owner/operators
Industry
Practioners
State, and local governments
• Define tools and services needed for the TSCSF
8
Transportation System Cyber-Security
Framework (TSCSF) Partnership
Establishment of the TSCSF Partnership with a MOU
between transportation industry’s associations
• American Association of State Highway and
Transportation Officials (AASHTO)
• ITS America
• National Electrical Manufacturers Association
• (NEMA) and
• Institute of Transportation Engineers (ITE)
• National Association of City Transportation Officials
(NACTO)
9
Transportation System Cyber-Security
Framework (TSCSF) Partnership
MOU helps establish a cooperative partnership with each
association’s membership uniquely has a voice and stake
in the success.
• Invite Experts in the field of cybersecurity, industrial
cybersecurity standards, as well as other domains such
as National Institute of Standards (NIST), Department of
Homeland Security (DHS) and others as advised by US
DOT
10
Proposed Phase II
Needs Assessment and ConOps
Objectives: To create an initial needs assessment
outline, create a Concept of Operations and hold a
Concept of Operations Walkthrough.
Deliverables:
• Stakeholder Interview List and Questionnaire
• Stakeholder Interview Summary Document
• Needs Assessment and Operational Scenarios
presentation
• Final Concept of Operations Document
11
Proposed Phase II
Research Dimensions of Threat
Objectives: Identify gaps, redundancies, and
unknowns on comparing to the NIST Framework.
Build (Functional) requirements from the Concept
of Operations.
Deliverables:
Contract Summary/Report of TSC Framework and
additional research needs
12
Proposed Phase II
NoCOE Outreach Site
Objectives: Build outreach site facilitating:
Discussion Forum,
Outreach/Informational, and
Site characteristics.
Information sharing with ISAC, ICS-CERT alerts
Outreach and Training material
Deliverables:
• NOCoE outreach site for Transportation System Cyber-
Security Framework with security features
13
Proposed Phase II
Monitor/Alert/Advisory System
Objectives:
• Develop a TSCF specification
• Develop the TSCF Monitor/Alert/Advisory prototype
• Implement a fully functional TSCF
Monitor/Alert/Advisory system
• Operate the TSCF Monitor/Alert/Advisory system
• Maintain a database for input and a comment
resolution plan
14
Proposed Phase II
Monitor/Alert/Advisory System
Deliverables:
• TSCF specification
• TSCF Monitor/Alert/Advisory prototype
• TSCF Monitor/Alert/Advisory system
• Comment Resolution Database
15
Proposed Phase II
Self-Assessment Tool
Objectives: Build self-assessment tool facilitating:
Self assessment by agencies
Requirements Verification
Testing and Validation Reports
Deliverables:
• Self Assessment Tool with secure access and
confidential reporting features
16
Contact
To get more involved with US Transportation
System Cyber-Security Framework (TSCSF) effort,
please contact:
Siva Narla, Institute of Transportation Engineers (ITE)
Phone: 202-785-0060 x119
Fax: 202 785 0609
Email: [email protected]