Servers , the Web PCs - UCSD Jacobs School of Engineering · Short-range wireless: Bluetooth, tire...

20

Transcript of Servers , the Web PCs - UCSD Jacobs School of Engineering · Short-range wireless: Bluetooth, tire...

Servers , the Web

PCs

November 17, 2015 3

Very common pattern Add computers (efficiency, safety, cost) Add communications (mgmt, integration, etc) Security consequences of these choices are under-considered

Exhaust

Engine Control Unit

TCU

Transmission

Brake Line ABS

Airbag Control Unit

Body Controller Locks/Lights/Etc

Radio

Telematics _

Internet/ PSTN

HVAC

Keyless Entry

Anti-Theft

4

A car is just a big distributed system Large attack surface Internal: all units connected via bus External: ▪ Indirect physical: shop tools, CDs ▪ Short-range wireless: Bluetooth, tire pressure, RKE ▪ Long-range wireless: RDS, cellular

Not on radar of car industry in 2010

5

6

In 2010, our group (UW/UCSD) demonstrated how internal network access in a car sufficient for arbitrary control

7

In 2011, we showed remote takeover without physical access and at arbitraty distance

8

9

Standard configuration SoC embedded system (typically Linux) OBD-II interface Local senors (GPS, accelerometer) External networking (BT, Cellular)

In 2015, showed remote takeover via popular aftermarket dongles (Uber & Metromile)

10

Major impacts OEMs: transformation in security process in auto

industry; 10x increase in security staffing SAE: Standards effort on auto cyber security DoT: new regulatory effort for cyber-auto issues DoD: $70M HACMS project for new technology;

DHS CyberCPS program for transportation sec

We’ve also looked at embedded security in: X-ray scanners Computer periphers (e.g., mice, keyboards) Voting machines Power transport SCADA And currently, passenger transport aircraft

Different issues in each…

12

13

Insulin pump, McAfee

Smart meters, IOActive

AVC voting machine, UCSD/Princeton

Paleari & Speziale, Solar SCADA

Nike+iPod, UW

Telephones, Columbia

Televisions, Codenomicon/ReVuln

ICDs, UW/UMass

DGPS, CMU

14

Why is the situation so bad?

What challenges need to be overcome to

make it better?

15

No adversarial pressure Absent attackers; no darwinian sieve to force

improvements in development practice

Very complex environment Heterogeneous, loosely coupled, systems of

systems Very complex supply chain No platform economies; IP issues; cost structure

16

Modest margins and low per-device revenue Many embedded verticals super price sensitive ▪ 1.5-2.5x indirect costing (plus retail markup) ▪ 8051 part cost is down around $0.001

How to recover costs for post-sale vulnerability and incident response, let alone more expensive development?

Low-power (battery or ambient) Can’t afford cycles or Hz for security

17

Fixed/limited function devices

Implications No administration Huge heterogeneity in hardware, software, tools No conception of alternate use ▪ May have no channel/procedure for patches, detection,

incident response

Overall environment is system of systems, but no one is in charge (how to reason about IFTTT?)

18

Common to outsource components (cost & TTM) Software components, IP cores, subassemblies

IP held by suppliers (source code too frequently) Suppliers and OEMs in conflict

Contractors sell into multiple markets (reuse is good business, so generalize)

Exacerbates heterogeneity Security problems at interface boundaries Supply chain integrity issues

But… security is a holistic property

19

IoT security is not going to be addressed on a per-device basis Responsible parties will need visibility, context

and enforcement authority and the business clout to establish that position

Most likely model: hub-centric security Interconnection points to monitor and enforce

security policy Large confluence of of technical and business

challenges to get there 20