Security for Low-End IoT Devices: When Energy is Not Enough, What is

One to Do?

Wade Trappe

WINLAB

Talk Overview

Wireless Ecosystems and The Internet of Things– What do we think of when we hear the IoT?– What is the point behind the IoT?

Lets talk architecture… Security and Privacy: Its actually about the point behind IoT!

– The risks and challenges– But not everyone can join the crypto party!!! The disenfranchised

The fallacy of Green…

What we can do for the disenfranchised? Three plane approach to security Recycle functions! And analyze data… all data!

Wrapping up…– Great opportunity for FORENSICS research!

WINLAB[3]

Vehicles with Sensors & Wireless

Hospital with Embedded Monitoring

Robotics Application

Smart Public Space

Autonomous Wireless Clusters(“ecosystems”)

Physical World with Embedded Wireless

Network Connectivity& Computation

Autonomous software agents

Application Management & Control Software

Control Module

Control Module“Human in the Loop”

From Sensors

Virtualized physicalworld object

Content & LocationAware Routers

Computation& Storage

Protocolmodule

Ambient interfaces

Cognitive Intelligence Module

Global Pervasive Network(Future Internet)

Multiple radio standards, Cognitive radios

To Actuators

The Internet of Things is the “Wireless Ecosystem” the next generation of pervasive computing systems

WINLAB

WHAT DO YOU THINK OF WHEN YOU HEAR “INTERNET OF THINGS”?

WINLAB

Fitbit

WINLAB

Zeo – sleep manager

WINLAB

Smart home – Nest, WallyHome, Dropcam, Ivee, Rachio

WINLAB

Smart meters in smart grid

WINLAB

UAV

WINLAB

Google glass and its apps

WINLAB

Smartphone, laptop, tablet

WINLAB

Low-end devices: RFID tags, small sensors …

WINLAB

Smart vehicle & Self-driving cars

WINLAB

Recap: IoT Motivational Scenarios Lead to New Challenges

Popular scenarios : Diverse Requirements– Smart Homes

Policy based seamless interaction between heterogeneous control systems (climate/security/health/entertainment etc.); service composition ; mobility.

– Smart Grid Reliability, Real-time Control, Secure Communication to achieve energy

efficiency– Smart Transportation

Very short Response time Ad-hoc + Infrastructure communication with mobility, secure data collection and exchange

– Smart Healthcare Security/Privacy/Trust, High Reliability, short-communication latency

pScale + Energy + Variable-Context + Open-API:

Service Realization/User Experience

WINLAB

The IoT is really about “DATA”

SMART is about the DATA and closing the loop!!!

+

Needs…

We need security to protect the loop!

WINLAB

Beyond Data, there are Several other IoT Architectural Requirements

• Naming Application Centric (Secure or not), Persistent considering Mobility,

Context Changes.• Scalability

Scale to billions on devices (passive/active), name/locator split, local/global services, resolution infrastructure, efficient context update.

• Resource Constraints Compute/Storage/Bandwidth constrains, Protocols being

application/context aware, Infrastructure support (edge computing, polling on demand)

• Traffic Characteristics Separate Local versus Wide Area traffic based on Application logic ;

Many-to-Many (Multicasting/Anycasting)• Contextual Communication

Key to create several meaningful IoT services• Handling Mobility

Fundamental Design Criteria

WINLAB

Legacy and Current IoT System Architectures have had drawbacks

Legacy approach can be characterized as “Silo” or vertically integrated:– Fragmented, Proprietary

solutions:DF-1, MelsecNet, Honeywell SDS, BACnet, etc

– Fundamental Issues : Co-existence, Inter-operability, Service level interaction

Vertically Integrated

More recent architectures are overlay-based and attempt to unify IoT Solutions– Coupled control/data functions– Centralized and limits innovation

InternetSmart Homes

Publishing

Subscribing

Sensors

Routers

IoTServer

IoT ApplicationsIoTGateway

Publishing

Smart Grid

Sensors

IoTGateway

Smart Healthcare

Sensors

IoTGateway

API

API

API

Publishing

Weaknesses of the Overlay-based Approach•Scalability: Merges control + forwarding path in central servers (bottleneck)•SPF: Central servers create a point of attack

WINLAB

IoT Architecture

IoT Middleware

Application Plane

Network Plane

Physical Plane

Devices Apps

Future Internet Infrastructure

Context Search

Aggregator

World Model

Computational PlaneSolver

Edge Router/Gateway Info.

Context-aware Middleware

WINLAB

IoT Architecture Four-plane Context

– Physical (Device) Plane Context determined by devices physical attribute such as:

Device Name, Device Type, Device Value, Device Location, etc.– Networking Plane

Context determined by the network attribute such as: Network Service Type (Stream, Linked-data), Bandwidth,

Connectivity, etc.– Computational/Middleware Plane

Filtering, processing, grouping, presentation, etc. Lives to serve the Application Plane

– Application Plane Context determined by attributes mentioned above and

application requirement such as : “Find the nearest cap”, “Find all the WINLAB rooms with temperature above 25 ° C”’

WINLAB

Example Middleware: OWL Architecture Three abstraction layers (OWL)

– Aggregator Collect raw data Filter out the redundant data

– Solver Distributed across the Internet. Subscribe to raw sensor data from the

aggregator Push higher-level information to the

world model May search or subscribe to world model

information– World model

All data in the world model is associated with objects (name & attributes)

For more information: http://www.owlplatform.com/

WINLAB

BEING EVIL IS GOODLET US LOOK AT SECURITY

WINLAB

It is useful to start with a basic security analysis

Identification of potential security threats and risks– The methods of such intrusions/subversions– The risks that may result from a successful attack

Identification of potential services that could address threats and mitigate risks– Centered around core security goals

Categorize security mechanisms and specific architectural and protocols/algorithms that can yield security gains

[22]

WINLAB� 23 �

(Some) Potential Security Threats

Unauthorized Access – An intruder gains access or gathers information from a resource it is not entitled to– Confidential information can be examined, removed, modified from system

Eavesdropping Intruder able to interact with the channel (e.g. wireless) to listen on communications/waveforms In wireless setting, eavesdropping is untraceable (aka, can’t identify where observer is)

Masquerading– Occurs when an intruder is able to mimic an authorized user/process– System resource/protocol believes the intruder is authorized user/process (e.g.

impersonating source address, forging signatures, etc).

Modification of Information

Unauthorized information is injected into the IoT system, network or its resources Modification can involve injection of false data from sensors to servers and applications Control and actuation systems may run instructions contained in falsified control messages

Repudiation Verification that a service was performed, messages were received Either sender or receiver could try to deny that a service was provided Could potentially lead to disputes/instabilities related to internal states within separate process (e.g. A

thinks B received an instruction, while B denies receiving instruction)

Replay, Misroute, Delete Messages

Replay: Intruder copies valid messages and attempts to reuse it for nefarious purposes Misrouting: Intruder sends messages to a wrong destination, perhaps to support traffic analysis Deletion: Intruder prevents messages from arriving to destination

Network Flooding Intruder sends an abundance of bogus messages Wastes network/system resources, leads to denial of service to schedule requests, etc.

WINLAB� 24 �

(Some) Potential Security Risks

Information Loss of Confidentiality

– Adversary has gained access to restricted information– Can be accomplished either at a host or on a network link– Occurs as a result of:

– Unauthorized access– Masquerading– Eavesdropping

Illegitimate Resource Consumption

Intruder forces the usage of resources that it is not entitled to Occurs as a result of

Unauthorized access Masquerading Modification of Information Replay, Misroute Messages

Stealing Services

– Adversary has obtained use of a service (e.g. forced a control system to do something without proper privileges)

– Occurs as a result of:– Unauthorized access– Masquerading– Modification of Information– Repudiation– Replay, Misroute, Deletion of Messages

Denial of Service

Adversary prevents an entity/process from providing service as expected Occurs as a result of:

Unauthorized access Masquerade Misrouting and Deletion of Messages Network Flooding

WINLAB

It is important to examine the security problem according to the information flows and potential adversarial points of control

InternetSmart Homes

Publishing

Subscribing

Sensors

Routers

IoTServer

IoT ApplicationsIoT Gateway

Publishing

Smart Grid

Sensors

IoTGateway

Smart Healthcare

Sensors

IoTGateway

API

API

API

Publishing

Adversary altersa sensor to reportfalse readings

Adversary attackscommunication conduitbetween server andapplications

Adversary acts as a falseapplication attemptingto access information not intended for it

Adversary creates a spoofingsensor to the system

Adversary monitors sensorreadings to track customer usage

WINLAB

Case Study: TPMS — From the Public Domain

Components of TPMS:– Tire pressure sensors– TPMS electric control unit

(ECU)– Receiving antenna(s)

Four or one antenna– Dashboard

Communication protocols– Link Sensor IDs with TPMS ECU– Sensors ECU 315/433Mhz

ASK/FSK ECU filters packets based on IDs

– Sensors can be waken up by ECU sensors 125kHz Travel at high speeds(>40 km/h)

26See Usenix paper

WINLAB

Case Study TPMS — To Be Discovered

The details of communication protocols are proprietary– How difficulty to reverse engineering?– Messages encrypted?– Messages authenticated?

How likely to eavesdrop TPMS communication?– High speed, car’s Metal body, message rate,

transmission power

• How likely to spoof TPMS communication?– ECU filters/rejects suspicious packets?– How much damage can spoofing accomplish?

27

WINLAB

Case Study: Spoofing validation

Tested on two equipments:– ATEQ VT55 validates packet structure.– A car using TPS-A validates ECU’s logic.

40 packets per minute

Observations– No authentication; – No input validation and weak filtering– Warning lights only depend on the alarm flag, not the real pressure– Large range: 38 meters with a cheap antenna without any amplifier– Inter-Vehicle Spoofing is feasible; travel speed 55 km/h and 110 km/h

28

•TPMS-LPW Light •Vehicle's warning light

WINLAB

Case Study 2: Smart Meter Privacy and Security

Analyzed existing meters with USRP software radio

Meters broadcast every 30s Able to spoof readings and

eavesdrop on hundreds of meters

WINLAB

Can’t we just call TLS and go home?

Unfortunately no…– Many devices won’t have the resources needed to support cryptographic

mechanisms (I’m sorry, you want an X.509 what?) We’re not too worried about securing your well-resourced Tablet, etc!

– Many communication flows will be one-directional (how can you complete TLS Handshake without a hand to shake?)

– Many of the attacks exist “outside” the network (Here is an encrypted 10000 degree Kelvin reading…)

Perhaps you can use IPSEC/TLS between the gateway and the server, but what about the sensor to the gateway?

TCP

IP/IPSEC

HTTP FTP SMTP

TCP

IP

HTTP FTP SMTP

SSL/TLS

TCP

IP

S/MIME PGP

UDP

Kerberos SMTP

SET

HTTP

At the Network LevelAt the Transport Level At the Application Level

WINLAB

More IoT Security Challenges New security challenges brought by IoT

– Extending the virtual network to the real world brings many legal and security/privacy issues. Ubiquitous devices monitor everything causing privacy concerns. Data is everywhere, acting upon that data is dangerous since you don’t

know its source! – Highly distributed nature:

It is difficult to management the large number of distributed devices. Sensors and devices may be distributed in public areas unprotected, thus

are vulnerable to physical attacks. – Limited-function embedded devices

Constraints: power, computation capability, storage etc. Most of the communications are wireless, which makes attacks (e.g.

eavesdropping, jamming) simple. Some types of devices (e.g. passive RFID tags) are unable to provide

authentication or data integrity.

[31]

WINLAB

There is a low-end to the IoT… it will be hard to secure! Let’s compare a Samsung S5

– 2.5GHz quadcore processor– 2 GB of RAM– 128GB SD card– 38kJ battery that is recharged

daily– Can run 10 hours of web

browsing before being recharged

With a low-end IoT Tag– 16-bit processor– Running at 6MHz– 512 bytes storage– 16KB flash for program– Must run for about 10000

hours on a coin cell battery with less than 1/15th the energy of the phone

gTake-away: Don’t worry about (some aspects) the

high-end of the IoT…

WINLAB

But I don’t believe you, what about the Green Whatever movement… pg 1. Let’s take a minute and talk energy, technology advancement

and the green movement… – Our devices have limitations…– Much better batteries are not coming

(Aka, bond energy is not a Moore’s Law phenomena!)– Energy harvesting is being touted as a solution to our energy problems…

but how much can they really harvest?– Lightweight crypto is either questionable or not light enough…

Next few slides, I’ll attempt to make the case…

Take-away: Please don’t believe the hype…

WINLAB

There’s plenty of energy and computing available… not true!

Lifecycle of a typical IoT device– Sense and read data from memory– Frame data into a packet– Move packet from processor to radio– Power up radio– Stabilize and calibrate radio to meet

frequency regulations – Transmit!

TI MSP430 16-bit microcontroller, CC1150 Radio

– The MSP430 requires 1mA to operate– The radio requires 23mA to broadcast at

6dBm– Example: 14byte packet at 250kbps requires

448 sec, requires 32.3 J– Coin cell battery has about 2-3 kJ of stored

energy– Allows only about 20000 operations to

perform non-essential (security) operationsLightweight TLS needs 16M operations

WINLAB

Batteries are a mature technology with centuries of engineering behind them. Over past several decades, improvement at about 7% per year There are only a limited number of elements in the periodic table and their

potentials have long been known We are already using some of the highest energy density materials available

Green Batteries? Not going to happen… this ain’t your typical Moore’s Law phenomena, pg 3.

WINLAB

Harvest energy from the environment– manmade or natural RF energy harvesting (e.g. passive RFID)

– Tag collects the energy, converts it to DC to power microprocessor and RF– Fundamental constraint: radio energy decreases in density by– Example: 4Watts of power emitted by a basestation can support distances of

3meters for an IoT tag in a environment 100W gives 10 meters… far in excess of safe and legal exposure!

Photovoltaics– At high noon on a clear (summer) day, 100 mW/cm2 provided by the sun– Photovoltaic cells have an efficiency of (roughly) 1% to 25%– Practical limitations: shadows, clouds, nighttime, dust accumulation, etc…– Example: NYC average solar energy in winter is 12 mW/cm2 for a cell

aimed at sun– Reality check: IoT devices will experience shadows, will not be kept clean,

will have rechargeable battery leakage, etc…

Green Harvesting? Maybe in an ideal world, but the world is not ideal!, pg 4.

2

1r

3/1 r

WINLAB

OK, no Green Panacea… so where can we secure the IoT? Three Plane Approach

Things IoT Middleware

Future Internet

Applications

Device-level Security

IoT Middleware Security

Network Security

We can introduce security here… and here… and here…

WINLAB

Three Planes for Security Device-level:

– To prevent data modification (while it is stored in the device), memory is protected in most RFID tags, such as EPCglobal Class-1 Generation-2 and ISO/IEC 18000–3 tags

– Lightweight cryptography between devices and the aggregator: CLEFIA (ISO/IEC 29192) is a 128-bit blockcipher or SIMON/SPECK: NSA recent recommendation for

lightweight crypto Caveat Emptor!!!

– Reuse functionality and other information for security (anomaly detection) purposes: Physical layer, traffic statistics, etc.

Network:– Between gateways and servers, utilize conventional network security protocols (TLS!)– Future Internet semantic/content-centric networking can provide privacy– In-network caching can ride out DoS.

Middleware, or “the data computation layer”:– Analyze the data you get, look for outliers and suspicious data, send warnings!

For the sake of the discussion, I won’t worry about where you put these modes… some will be at device to gateway, some will be in the backend cloud

ypNew forms of security can exist outside of the

crypto!!! This is Forensics!

WINLAB

Authentication: A Cartoon Version Authentication in the PHY-sense is about verifying a transmission came from

a particular transmitter– useful for spoofing detection!!! Wireless devices can authenticate themselves based upon

– Ability to produce an appropriate received signal/channel estimate at the recipient

– Location information can be extracted to authenticate a transmitter relative to its previous location

Alice

Bob

Eve

Probe Pulseu(t)

Bandwidth W of Probe Pulseis critical! 1/W must be small compared to channel temporal width

1. Estimates channelhAB (t,)

2. Compares againsthAB (t-1,)

3. Accepts transmission if match

Spoof Alice:Probe Pulse

u(t)1. Estimates channel

hEB (t,)2. Verification fails!!! 3. Does not accept Eve

as Alice!

WINLAB

Channel Probing Types

The probing signal u(t) can take many forms:– Pulse-type probing: The signal u(t) is a pulse

Usually very short in duration by time-bandwidth product, implies broad bandwidth

– Multi-tone probing: The signal u(t) is several simultaneous carrier waves Usually, carrier frequencies are separated by the channel

coherence bandwidth Can be realized with OFDM-style receivers

For all essential purposes, they are functionally the same– The bandwidth W should be small relative to the temporal width

of the impulse response in order to resolve multipaths

WINLAB

Authentication can be achieved by exploiting unique properties of the wireless physical layer

Validation of physical layer authentication has been performed using both ray-tracing methods and through experiments using ORBIT and USRPs

A change point detector based on the amplitude response of three carriers (pilots) was used to detect spoofing

WINLAB

Sybil Detection: Another form of PHY channel authentication

The Sybil Attack: A node claims multiple identities The channel response serves as a fingerprint to detect multiple claimed identities Clever Adversary: Adapt power across subcarriers for each identity (but don’t change

“shape” or else decoding failure!) Issues to consider: System bandwidth, Number of APs and their synchronization

Sybil node

Ns clients

Client Ns+1

Client N

Client Ns+2

WINLAB

Channel-based Sybil Detection Channel sample obtained by the n-th client:

Pair-wise Sybil detection between the m-th and n-th clients – Constant power allocation by the Sybil node

– Adaptive power allocation by the Sybil node

,

Sybil detection with multiple clients: – Claim a Sybil client, if it has similar channel samples to at least one other

client.

– The decision function

2 2 2( , ) 2|| || /(1 | | )m nL m n H wH w 2/ || ||H

m n nw H H H

( ) 2 2( , ) || || /H

m njArg H Hm nL m n H e H

,1njn n n nH H a e N n N

1, ,1 , . . ( , )( )

0, . . n m n N s t L m n K

I mo w

WINLAB

Sybil: Wideband Performance

0 1 2 3 4 5 6

x 10-3

0.9

0.91

0.92

0.93

0.94

0.95

0.96

0.97

0.98

0.99

1

False alarm rate

Det

ectio

n ra

te

(6,2)(8,4)(10,6)(12,8)

(N, N-4) systems, with N clients, including 4 legal clientsM = 5 tones, W = 50 MHz, PT = 50 mW, and b = 0.25 MHz.

WINLAB

Rather than use the channel, we may use channel estimation (piloting) for message authentication

WINLAB

By embedding an authenticator in the CSI estimation phase, the communication is validated rapidly

WINLAB

There are several strategies for embedding authenticator messages into pilot symbols

RelativeFrequencyCodebook

BinaryFrequencyCodebook

Joint Frequency-Power

Codebook

WINLAB

Prior experimental validation using current SDRs illustrates feasibility of CSI authentication in rejecting false communications

RFC Experiment

FPC ExperimentBFC Experiment

Experimental Setup

WINLAB

Strategy: Divide authentication into two parts Inter-burst part

– Authentication of the first frame in each data burst– Use channel response of some frames in previous burst as the basis for authentication

in current burst – Alternative: Use an embedded cryptographic authenticator (e.g. hash chaining,

analogous to TESLA)– Legal transmitter obtains the key either by feedback from the receiver or channel

measurement

Intra-burst part– Authentication of the following frames in each data burst– Assuming the previous frame has been authenticated, compare the channel responses

of the previous frames and the current frame– Alternative: Use an embedded cryptographic authenticator– Two possible methods for channel-based authentication: Neyman-Pearson Test based

vs. Least-Square Adaptive Filter based

But I have a mobile IoT environment: An enhancement for continuous authentication of vehicular communications

WINLAB

If you can’t get at the PHY, then perhaps you can at least use relationship-based anomaly detection

The basic scenario:– Suppose we have two devices A and B

claiming the same identity– Let X be a separate monitoring device

There should be “relationships” present within the stream of packets coming from this identity

These relationships and the rules by which they are verified should be difficult for an adversary to forge

There are two types of relationships:– Relationships introduced into packets

through auxiliary fields– Relationships associated with inherent

properties of packet transmission/reception

A

B

Monitor X

•Normal Case: Only one device using an identity, then X will see packets following a particular pattern•Anomalous case: Two or more devices using the identity, then X will see a mix of different packets

WINLAB

Strategy: Sequence Number Monotonicity Wireless NICs typically

have MAC-layer packet sequencing in firmware

As an example, in 802.11 Sequence Numbers increase monotonically

During a spoofing attack, the observed sequence numbers for a particular MAC address will not behave monotonically

OK, but can’t I change the sequence numbers? Yes, use Software MACs Won’t help you that much! A sends #101, #102… B can now send #103… But A will eventually send #103 Assume Retransmission Disabled

ORBIT DATA

WINLAB

Example: Sequence Number Anomaly Detector Can we turn these observations into a fast MAC-layer detection

mechanism? Yes. Suppose s(n) and s(n+1) are two consecutive observed sequence numbers Basic rule:

– s(n+1) - s(n) = 1 mod 4096 is an automatic test: if we see s(n+1) < s(n) or s(n+1) = s(n) then declare anomaly!

More generally, there is packetloss and we want the rule to be robust lost packets– s(n+1) should not be too much bigger than s(n)

If s(n+1) - s(n) > K mod 4096 then declare anomaly This allows for up to K-1 lost packets

We may determine thresholds based on target Probability of False Alarm and Probability of Missed Detection according to packetloss rate p.

We have conducted experiments on ORBIT to validate the feasibility of this method for detecting anomalous traffic.

WINLAB

Strategy: Signal Strength Discrimination Signal strength can be used as a discriminator to identify the presence of

two or more sources using the same MAC address Idea: (Requires Stationary Sources)

– A talks to X or B talks to X then there is a particular distribution.– When A and B talk to X (alternating) then we see two types of

distributions Bimodal: The two distributions are “added” together Unimodal: Automatic gain control performs smoothing between

readings– Key point: Neither distribution looks like the original distribution!

RSSI

A

B

Monitor X

The Mixed Distributions

WINLAB

Signal Strength Discrimination

Suppose the monitor X has a distribution for the signal strength readings from A.

Later, we may test observed signal strength readings against this distribution.

– Assuming devices have not changed their configuration

Suppose our initial distribution is fA(r), and we have broken the dynamic range into k histogram bins pj.

Later, we conduct n RSSI readings. If we observe Nj RSSI readings in bin j, then the Chi-Squared Test Statistic

is

If the test statistic is greater than a threshold, we declare that the new, observed distribution is not a good fit for the original distribution

k

j j

jj

npnpN

1

22 )(

WINLAB

Strategy: Traffic Statistics Discrimination In this strategy, we assume that

all devices must follow a specified traffic pattern.

For example, the network policy might be that all wireless devices transmit at a constant bit rate (CBR) source with a fixed interarrival time.

Idea: – When A talks to X there is a particular

observed inter-arrival distribution at X.– When A and B talk to X then the extra

source adds extra traffic claiming to come from this network identity

– The interarrival statistics will change significantly.

InterarrivalGap

A X

B X

A & B X

A X

B X

A & B X

WINLAB

So lets put it together in a story/case-study Call it the “Indiana Jones Attack!”

NETWORK`

TAGGED ASSETS

BASE-STATION

BACK-END

Hard problem, case study: Thwarting an Indiana Jones Attack… still research to be done!

WINLAB

0.00

1.00

2.00

3.00

4.00

5.00

6.00

7.00

8.00

0 20 40 60 80 100 120 140 160

Mob

ility Score

Seconds

Tag 8e Mobile

Tag 77 Stationary

Tag 3B Mobile

Threshold

Thwarting an Indiana Jones Attack: Mobility Detection Using Active IOT Tags

Localization turned out to be hard, but detecting movement was not!

WINLAB

Putting it all together case study: Thwarting an Indiana Jones Attack, it doesn’t quite work (yet!!!)

Let’s return to the Indiana Jones Attack…– Even if item is immobile, a quick

imposter can replicate its radio signals

Problem: – Replacement events (“Indiana Jones”

attacks) cause variations in signal strength that are similar to those seen from immobile transmitters when people are moving close by.

– Replacement events would only rarely be detected as mobility events.

We need better “forensics” tools!

WINLAB

Placing security in the middleware: study the actual data to find anomalous activity

We have (lots of) data and physical phenomena on our side…– Data analytics can allow us to look for

and use correlations to validate the Process of Measurement (POM): Identify anomalous data Tag data with quality assessments

using historical or physical phenomena

– Temporal Consistency Checking

– Multimodal Consistency Checking Use physics and correlations

Data analytics needed for forensics and analysis can get fancy (and fun!) very fast!

1: nnn XXX

WINLAB

Will Allow…

Wrapping it up… Securing the IoT will involve a lot of data analysis– at different locations within the system

Standard security protects only some aspects Data analysis and forensics will flag anomalous events and

protect the applications being built upon IoT

DATA

ForensicsAlgorithms