Securing a Smart Vehicle in IoT World

2018 Securing a Smart Vehicle in IoT World

Debshikhar Das B. Tech CSE Amity University Kolkata A91005215094 8/31/2018

Contents

1. IntroducIon .............................................................................................................................................2 1.1 Document Purpose ............................................................................................................................2 1.2 Project Outline ...................................................................................................................................2 2. Project detail ............................................................................................................................................3 2.1 ObjecIves ..........................................................................................................................................3 3. Overall Architecture.................................................................................................................................5 3.1 Architecture Principles.......................................................................................................................5 4. Overall Architecture Overview .................................................................................................................6 5. Conceptual Architecture of Manufacturer’s cloud ..................................................................................8 6. Logical Architecture ...............................................................................................................................10 7. Traffic flow ............................................................................................................................................. 10 7.1 3rd party vendor / supplier accessing the car ..................................................................................11 7.2 Manufacturer wants to access the car .............................................................................................11 7.3 Car service centre accessing the car ................................................................................................. 12 7.4 Owner accessing the car ...................................................................................................................12 8. Security components .............................................................................................................................13 Appendix - A ...............................................................................................................................................14 Appendix - B ...............................................................................................................................................14

1

1. IntroducIon 1.1 Document Purpose This document represents the detail work done for the project explained in secIon 1.2.

It outlines each aspect of the project and the outcome. This also describes how the outcome is achieved using various resources like hardware, so\ware, cloud and development pla]orms. I have used relevant diagrams and tables throughout this document to capture informaIon which is supplemented by appendix at the end of the document.

1.2 Project Outline The advanced fi\h-generaIon (5G) infrastructure will not only be a sheer evoluIon of the current network generaIons but, more significantly, a revoluIon in the informaIon and communicaIon technology (ICT) field. The 5G technology will efficiently enable new secure, dependable, ultra reliable, and delay-criIcal services to everyone and everything, such as cogniIve objects, IoT supported devices and connected vehicular systems.The number of connected vehicles and IoT enabled systems is rapidly growing and will conInue to do so over the coming years. CommunicaIon of vehicles and roadside sensors with a roadside unit is intended to increase the safety, efficiency, and convenience of the transportaIon system, by the exchange of criIcal safety and operaIonal data. The communicaIon can also be used to provide value added services, such as car finder, parking locaIon and to support entertainment services (e.g. video distribuIon) through a cloud based Radio Access Network(RAN). LTE can significantly accelerate the deployment of connected vehicle communicaIons. LTE cells can provide “beyond the line of sight” visibility i.e. beyond the range of direct communicaIon between vehicles of 300 – 500m. It can also saIsfy the Ight latency requirement of connected vehicle communicaIons, below 100ms in some use cases. Messages could be distributed in real Ime over LTE, eliminaIng the need to build a countrywide Digital Short-Range CommunicaIons (DSRC) network. Cars can leverage their increasingly inbuilt LTE connecIvity; in deployments where DSRC exists, LTE would be able complement it.

Because of the nature of some of the devices being connected, a real Ime capability is required and a grouping of sensors and devices is needed for efficient service. As the number of connected vehicles and IoT enabled devices increases and use cases evolve, the volume of data will conInue to increase along with the need to minimise latency.

Whilst data stored and processed centrally may be adequate for some use cases, it can be unreliable and slow for others.On the other side, vehicles themselves are now controlled by hundreds of Electrical Control Units (ECUs) that form an internal network of devices within the vehicle. While increasing autonomy and connecIvity in vehicles and IoT devices bring many improvements in terms of funcIonality and convenience, it also brings a new cyber threat plane into life where such connected systems become a new target for aiackers/hackers.With advancement in technology and communicaIon systems, hackers are coming up with innovaIve methods and vectors to penetrate into the network architectures of connected vehicles and IoT devices to steal, destroy or mutate data. Hence in order to restrict and prevent such incidents, an analysis of probable threat vectors for connected vehicles and a cloud based soluIon to these issues to ensure End-to-End security is explained in the next secIon in detail.

2

2. Project detail This chapter provides informaIon on the objecIves that this project tends to accomplish in secIon 2.1.

2.1 ObjecIves TradiIonal security architectures focus on protecIon of voice and data, and they all have the following security features in common: ● User idenIty management based on (U)SIM ● Mutual authenIcaIon between networks and users ● Securing the path between communicaIng parIes hop-by-hop As the 5G era is drawing near, the volume of data traffic and variety of services will increase to unseen-before levels. IoT service is just one of the many. When it comes to 5G, it is not simply about being a medium for communicaIon. It can be seen as a catalyst for minimising the boundary between the digital world and physical world. 5G security design is an all-encompassing one that provides security protecIon for the everything-connected world. Diversified system level protecIon of IT-aware infrastructure a\er IT technologies (e.g. NFV and SDN) are put into use, a vast array of system-level protecIons is in place to defend against distributed denial of service (DDoS) and other acIve aiacks that may increase. 5G security design may need to consider issues of how to isolate, deploy, and manage virtual network slices securely. The main objecIve is to : ● Analyse and idenIfy various cyber threat vectors against IoT devices and connected vehicles. ● Implement End-to-End security to provide privacy protecIon and flexibility by integraIng cloud services to make it scalable easily.

Table 1: Threat Model Characteriza3on of probable surface implementa3ons

Vulnerability Class Direct Physical

Channel

Implemented Capability

Visible to user

Scale

Full Control

OBD port

yes

small

yes

Indirect Physical

CD

Plug attack hardware directly into car OBD port.

CD based Firmware Update

yes

small

yes

CD

Special song (WMA)

yes*

medium

yes

Pass-Thru Devices Hotspot

wireless or wired control connecIon to pass-thru devices Wifi or wired shell injecIon

yes

medium

yes

No

viral

yes

Bluetooth

Buffer overflow with paired phone and trojan app Sniff MAC address, brute force PIN, Buffer overflow

No

large

yes

No

large

yes

Short_Range Wireless

Bluetooth

3

Long_Range wireless

Cellular

Cellular

Call car, authenIcaIon exploit,Buffer overflow (using laptop ) Call car, authenIcaIon exploit,buffer overflow (using iPod with exploit audio file, earphones, and a telephone)

No

large

yes

No

large

yes

The Table 1 classifies the vulnerabiliIes, their respecIve channels of threat vectors and surface implementaIon capabiliIes. The Visible to User column indicates whether the compromise process is visible to the user (the driver or the technician); we discuss social engineering aiacks for navigaIng user detecIon in the body. For (∗), users will perceive a malfuncIoning CD. The Scale column captures the approximate scale of the aiack, e.g., the CD firmware update aiack is small-scale because it requires distribuIng a CD to each target car. The Full Control column indicates whether this exploit yields full control over the component’s connected CAN bus (and, by transiIvity, all the ECUs in the car).

Any network interface, physical or wireless, could be exploited by malware to infect a vehicle. The likelihood for a malware to enter a vehicle and run on it depends on many factors. Several of these factors are: 1) VulnerabiliIes in the design and implementaIon of hard- ware, so\ware, applicaIons, and communicaIon systems on the vehicle; 2) Users’ insufficient ability to safeguard file downloads into the vehicle when users access Websites and download applicaIons from external sources; 3) VulnerabiliIes in the external data that enters a vehicle (e.g., likelihood that a so\ware update package is infected with malware before it is loaded onto a vehicle); 4) VulnerabiliIes in the operaIng systems used on the vehicles.

Next, we discuss several scenarios where malware could exploit these vulnerabiliIes to infect a vehicle: • Aiackers installing malware on ECUs via Onboard DiagnosIc Port (OBD).

• Via remote OTA ECU firmware and So\ware updates.

• Via Embedded Wifi Hotspots.

• Via A\ermarket Equipments that provide network connecIvity and host third party applicaIons.

• Via embedded music Systems.

• Via removable media ports.

The onboard malware defence funcIons protect the vehicle against malware that have reached the vehicle from any aiack surface such as from local and remote network connecIons, physical and wireless network connecIons, V2I and V2V communicaIons, removable media, and replacement ECUs. The vehicle maintains local threat informaIon databases (e.g., threat signatures and whitelists) to assist onboard malware detecIon. However, the total size of such databases will be capped and needs not increase even as the number of malware grows over Ime. This framework eliminates the problems of having to install large malware informaIon databases on a vehicle and to add addiIonal 4

storage and processing capaciIes to keep up with the growing number of malware over Ime. The limited size of the onboard malware informaIon databases may constrain the vehicle’s ability to detect malware locally. Therefore, the onboard malware defence capability will be compensated by the malware detecIon and defence capabiliIes in the car manufacture’s cloud as explained in secIon 3 and illustrated in Figure 1.

3. Overall Architecture This chapter provides informaIon on the principles that guided the creaIon of the overall vehicle security architecture and the design of the various blocks involved in the same.

3.1 Architecture Principles A number of principles has been considered when developing the overall vehicle security architecture, while focusing on the communicaIon security aspects of the architecture. The objecIve of formalising the following principles is to provide relevant guidance on designing the security controls model of the various architectural blocks described in the next secIon. Table 2: Architecture Principles

Sl. No. 1

2 3

Principles

Remarks

The proposed architecture considers all possible Wired protocols – Ethernet, TCP/ communicaIon protocols e.g. wired and wireless which shall IP etc. be used between all the blocks Wireless – 802.11a/b/d/g/n, 3G/ 4G/5G etc.

The security requirement of each architectural block depends on type and value of data sent/received.

Data from Manufacturer to car is more secure.

All communicaIon which is meant for the car has to travel to Owner can send instrucIon the manufacturer’s cloud for authenIcaIon, compaIbility directly to the car, however, no and security check before sent to the car. so\ware changes are possible by the owner.

4

3rd party vendors shall develop the manufacturer’s cloud pla]orm to develop, test and deliver the so\ware

Manufacturer will check the compaIbility and security of the so\ware before pushing it to the car

5

All communicaIon channels should be encrypted end-toend to ensure man-in-the-middle aiack including other forms of aiack which may compromise integrity of the data.

Technologies like Firewall, VPN, EncrypIon, AuthenIcaIon, and AuthorizaIon are placed in relevant places.

6

The architecture is considered to be protecIng the system from DDoS aiacks at all levels from Cloud to Car

DDoS could challenge availability of the system which will impair Imely update of the car so\ware. This control is included at the base layer as an integrated system.

5

4. Overall Architecture Overview Figure 1 depicts the overall architecture of the secure vehicle. This is based on the architecture principles described in Table 2. Each block is described in Table 3.

Figure 1: Overall architecture of the secure vehicle

Table 3: Summary of Blocks

Sl. No.

Block Name

DescripGon

1

Car Manufacturer’s Cloud

The car manufacturer uses cloud technologies to host all the so\ware deliverables and ensure 24x7 availability of resources from anywhere anyIme using internet facility. Major resources would be – a. Hardened OS b. OS patch files c. Firewall so\ware and updates d. AnI-Malware so\ware and updates e. Threat Intelligence database f. Car Equipment drivers and APIs g. Car Sensor update The car manufacturer uses mulI-factor authenIcaIon technology to ensure that specific resources are used by specific car and the owner is engaged in the authenIcaIon process. This enIre communicaIon between car and cloud would be encrypted to ensure integrity and confidenIality and avoid aiacks like Man-in-the-Middle.

6

2

3rd Party Suppliers

Every car manufacturer uses 3rd party equipment in their cars. The role of 3rd party vendors are becoming more important than ever due to increase in compliance and compaIbility requirements at the so\ware domain. To ensure end-to-end security and safety of the smart car, both the OEM and 3rd party must ensure that all the hardware and so\ware must work in tandem. The development, tesIng and delivery of the hardware and so\ware happens jointly to avoid gaps at the endproduct. This is where 3rd parIes need to access OEM’s cloud to test and deliver their so\ware which is eventually delivered to the car. No 3rd party can upload their so\ware directly to the car without gesng it tested/verified by the OEM and it is OEM’s responsibility to cerIfy the so\ware and upload the same to the car.

3

Insurers / Auditors

For smart car pla]orm, the role of the Insurer is to collect specific data points from the car to perform following funcIons – • • • •

Set the insurance premium based on driver’s driving skills Assess / Audit the damage remotely Seile the claim Remotely check the car documents and alert the owner about renewals etc.

4

Car Owner

The car owner has fewer control over the car except changing the OS, Drivers, So\ware, and basic Firewall configuraIon. This also ensures that even the owner doesn’t have rights to misconfigure the car to the extent that it becomes unsafe to drive (knowingly or unknowingly).

However the owner has the privilege to set his/her preferred music channel or operate the AC or sesng ambient mood etc.

5

Car

The car OperaIng System is the key brain behind running the operaIons of the car. It controls pracIcally all aspects of the car e.g. engine, gear, brakes, AC, audio, security system etc. Being a smart car, the OS of the car is capable of interacIng with all the other components and perform necessary checks and balances to ensure car’s operability, safety and security. The Car OS has certain level of intelligence to take few decisions on its own on case-to-case basis. Below are the basic funcIons which the car does by default• Collect data from all the sensors in real Ime • Correlate input parameters with normal/standard operaIng procedures • Interact with the driver • Manage the overall OS patches

7

6

Car Service Center

Car service center has access to individual car database which has detail about the ser vices done since the car has been manufactured. It collects fault/warning/error database from each car and determines it’s service requirement accordingly informs the owner.

5. Conceptual Architecture of Manufacturer’s cloud Manufacturer’s cloud infrastructure plays a pivotal role in securing the enIre environment. This cloud is the single point of truth which hosts all so\ware and pla]orms which is required to build, test and deliver the right and secure so\ware for the cars. All relevant stakeholders connect to this cloud and deliver their respecIve so\ware from Ime-to-Ime. The conceptual cloud architecture of the manufacturer is showing how the security of the same is addressed using layered approach and what all services are included in this infrastructure. Please refer Appendix A for detail of each services menIoned in the Figure 2.

Figure 2: Conceptual architecture of Manufacturer’s cloud infrastructure

8

Table 4: Component of the Cloud Infrastructure

Component

Description

Internet routers

The Internet routers are hosted in the untrusted zone and connect the Internet edge block with Internet service providers and the manufacturer.

Internet firewalls

The firewalls provide stateful access control and secure connecIvity between segments hosted in the untrusted, semi-trusted and trusted zone.

Traffic between zones and segments shall be authorized by an access-list configured on the Internet firewalls.

Intrusion prevenIon

The intrusion prevenIon components detect and prevent aiacks based on signatures, threat intelligence informaIon, malware detecIon and applicaIon visibility and control. The architecture provides flexible policybased traffic control such that traffic from/to any segments can be inspected by the intrusion prevenIon components adding any complexity.

Site-to-site VPN

The site-to-site VPN provides the ability to build secure IPsec tunnels between 3rd ParIes and Manufacturer. The components shall authenIcate and authorize the establishment of VPN tunnels based on strong authenIcaIon mechanisms.

Web applicaIon firewalls

The web applicaIon firewalls protect Manufacturer’s web servers from web-based aiacks iniIated from the Internet.

Security Zone

Security zone hosts all the security components which will work in tandem to secure the overall cloud infrastructure

Business ApplicaIon Zone

This is the zone where the car manufacturer hosts all the business applicaIons which shall be accessed by 3rd parIes, customers, service centers and internal employees.

Public Web Zone

This is the external facing web portal where all external enIIes land when they access manufacturer’s services.

Infrastructure Zone

This zone hosts all the hardware infrastructure which builds the cloud data center

3rd Party UAT Zone

This zone hosts all the so\ware, pla]orms accessed by 3rd parIes to test their so\ware by the manufacturer

3rd Party Infra Zone

This zone hosts 3rd party hardware / so\ware for so\ware development and tesIng

9

6. Logical Architecture The logical architecture gives a layered view of all the blocks and their inter-connecIon in terms of how these blocks are logically connected to each other, depicted in Figure 3 . This architecture will lead to physical architecture which is more detail view of the physical connecIvity. As depicted in the figure, all communicaIon from any source shall converge in the manufacturer’s cloud followed by scanning, filtering and authorising. Once the so\ware is “Passed” it can be deployed in the car through another layer of security controls which is built in the car before it is integrated with Vehicle AutomaIon and Control System.

Figure 3: Logical Architecture of End-to-End security of the secure car

7. Traffic flow As per the logical architecture, there are four possible ways to connect to the car for so\ware/firmware upgrade or to make changes in parameters.

A. 3rd party vendor / supplier accessing the car B. Manufacturer wants to access the car C. Car Service centre accessing the car D. Owner accessing the car

10

7.1

3rd party vendor / supplier accessing the car 3rd party vendors are responsible for developing so\ware and firmware to release newer version or changing some exisIng bug in their equipment installed in the car. To ensure end-to-end security, all 3rd party vendor/supplier need to connect to the manufacturer’s cloud using VPN technology. Once authenIcated through encrypted tunnel, vendors can upload, develop, release new/modified so\ware ready to be deployed in the car.

Manufacturer will check the compaIbility, compliance and security controls at their test environment before it is scheduled for download. The Figure 4 shows the complete data flow along with checks in the way.

Figure 4: data traffic between 3rd par3es to car

7.2

Manufacturer wants to access the car Manufacturer need to access the car to install/modify so\ware from Ime to Ime. The Figure 5 below depicts how data between manufacturer and the car is screened at car’s security control system before being adopted.

Figure 5: data flow between manufacturer and the car

11

7.3

Car service centre accessing the car Car service centre someIme may need to change parameters or install new version in the car. The following Figure 6 shows how the traďŹƒc between service centre and car is handled to ensure end-to-end security.

Figure 6: traďŹƒc between service centre and car

7.4

Owner accessing the car The owners should enjoy maximum privilege by virtue but due to security and safety reasons, owners are restricted to change any parameters which may compromise the safety and security of the car as depicted in Figure 7. By default owner is not supposed to install/upgrade any so\ware for the same reason. However, owners can certainly change parameters which are purely related to sesng the AC temp., Music staIons, Ambiance light, seaIng preference etc.

Figure 7: data ow between Owner and car

12

8. Security components To achieve a desired state of secure and safe vehicle and based on the basic principle of secure architecture, following components will help achieve a reasonably secure pla]orm for the car.

a. Firewall: The firewall plays a pivotal role in the all the layers in terms of securing, segmenIng and providing visibility into the traffic. The proposed firewall design has following integrated capabiliIes: ๏ Intrusion prevenGon – Protects the network infrastructure and data resources from Internet-based threats such as worms, viruses, and targeted aiacks by performing applicaIon and user-aware security inspecIon of Layer 4-7 traffic coordinated with global threat prevenIon informaIon. ๏ AnG-malware protecGon – Files are securely analysed and correlated against hundreds of millions of other analysed malware artefacts to provide a global view of malware aiacks, campaigns, and their distribuIon on current and historical malware artefacts, indicators, and samples. ๏ Threat intelligence – Threat intelligence is evidence-based knowledge, including context, mechanisms, indicators, implicaIons, and acIonable advice about an exisIng or emerging menace or hazard to assets that can be used to inform decisions regarding the subject’s response to that menace or hazard. ๏ ApplicaGon visibility and Control – ApplicaIon-specific aiacks that take advantage of poor applicaIon-development techniques and insecure modules. Advanced, specialised web applicaIon inspecIon and monitoring for inbound and outbound service calls meeIng a specifically tuned and configured policy. ๏ Event correlaGon – security/threat event correlaIon is effecIve to isolate the problem areas and focus on them quickly.

The intrusion prevenIon service is integrated within the same firewall hardware. The firewalls would be configured such that all traffic allowed by the firewall is forwarded to the integrated IPS service.

13

Appendix - A

Appendix - B Description

Capabilities

Advance Malware Protection

Client-based Advanced Malware Protection. Files are analyzed and correlated against hundreds of millions of other analyzed malware artifacts to provide a global view of malware attacks, campaigns, and the distribution on current and historical malware artifacts, indicators, and samples. Additional capabilities include retrospective view of malicious activity, mitigation techniques, and sandboxing.

802.1x

Selective restriction of access, based on contextual information and identity, to a place or other resource. Restriction can occur through the use of Security Group Tags (SGT), VLAN Assignment, and Access Control Lists.

14

Description

Capabilities

Administrative Policy

Policies identified by leadership with the intention of guiding employee action and behavior. Administrative policy may be influenced by regulatory compliance requirements and will drive technical policy.

Network Anti-Malware

Network-based Advanced Malware Protection. Files are analyzed and correlated against hundreds of millions of other analyzed malware artifacts to provide a global view of malware attacks, campaigns, and the distribution on current and historical malware artifacts, indicators, and samples. Additional capabilities include retrospective view of malicious activity, mitigation techniques, and sandboxing.

Application Visibility Control

Also known as AVC or Application Control. This is the ability to report on, or act on, applications that are running on the network without reliance on TCP/UDP port numbers.

Cloud Access Security Broker On-premise or cloud-based security policy enforcement points, (CASB) placed between cloud service consumers and cloud service providers to combine and interject enterprise security policies as the cloud-based resources are accessed.

Data Loss Prevention

Products which look at data and files being transmitted to restrict their mobility based on a Data Classification Policy. It can be tag based for a file, can look at messaging for "Regular Expressions" or RegEx to stop data strings such as phone numbers, social security numbers or account numbers, among others.

Posture

Typically done during Authentication to the network, a device is assessed for patch level, certain applications (AV, anti-Malware, etc.) and others to determine if it is within policy and can be allowed on the network, denied or quarantined for remediation.

Device Profiling

Identifying they type of device accessing the network based on characteristics including Operation System, MAC address, protocols being transmitted, and other unique identifiers.

DDoS Protection

Protection on premises, via the cloud or both from an interruption in an authorized user's access to a computer network or device, typically one caused with malicious intent.

DNS Security

Ability to seamlessly insert host security using Domain Name Services. This is very useful for prevention of malware, including Ransomware.

15

Description

Capabilities

Micro Segmentation

A security technique that enables fine-grained security policies to be assigned to data center applications, down to the workload level.

Firewall Segmentation

Protects the network infrastructure and data resources through stateful packet filtering, protocol inspection, and network address translation.

Flow Analytics

Ability to monitor NetFlow (and other flow types) to identify application information, as well as malicious traffic, data loss, and malicious behavior.

Host Based Security

Security software to protect the host consisting of anti-virus, antimalware, host firewall and VPN encryption.

Identity Authorization

Ability to Identify Users and Devices by a combination of methods, including certificates, username and password, and more.

Intrusion Detection and Prevention (IDS/IPS)

Protects the network infrastructure and data resources from Internet-based threats such as worms, viruses, and targeted attacks by performing application and user-aware security inspection of Layer 4-7 traffic coordinated with global threat prevention information.

Malware Sandbox

Network-based Advanced Malware Protection, with the same capabilities as Host-based protection, but utilizing network security devices for the file inspection.

NG-IPS

Next-Generation Intrusion Prevention System. Self-tuning IPS service with ability to use contextual information, such as: user info, operating system, services running, TrustSec group, etc.

Technical Policy

Policies and configurations, Standards and Baselines for how devices are imaged, configured and managed. This will include things like firewall rules, web site blacklists and gold standard images for systems, etc.

Threat and Event Monitoring

Round the clock monitoring of events and threats triggering alerts in your environment to improve response and mitigation time.

Supported by context and a security knowledge base/repository.

16

Description

Capabilities

Threat intelligence

Threat intelligence is evidence-based knowledge, including context, mechanisms, indicators, implications, and actionable advice about an existing or emerging menace or hazard to assets that can be used to inform decisions regarding the subject's response to that menace or hazard.

VPN-Clientless

Web portal VPN access. Clientless VPN utilizes the user’s web browser to build a proxy connection with restricted access to internal resources.

VPN – remote access

Provides secure encrypted access to resources inside the organization from remote locations and mobile devices.

VPN tunnel

Termination of an IPsec or SSL/TLS Tunnel for IP access to network.

Web Application Firewalling

Advanced, specialized web application inspection and monitoring for inbound and outbound service calls meeting a specifically tuned and configured policy.

Web Content Filtering

Web traffic inspection to control where users navigate and restrict access to categories or specific sites, known malicious and reputationally challenged sites.

Web Security

Provides inspection and filtering for web reputation, anti-malware, anti-virus. Protects against data loss and data exfiltration. Enforces acceptable-use controls and user monitoring. Can be on-premise or cloud.

17