Uniform IoT security using NFV based policy enforcement gateways Adrian L. Shaw Hewlett Packard Labs (Bristol, UK) SICS Security Day 2016

# whoami

– Senior Researcher, Hewlett Packard Labs – HPE’s advanced research arm –  Security & Manageability Laboratory, (Bristol, UK) –  Long history in platform security –  Personal experience in OS and FW security

– Interests –  Platform security in distributed systems –  Practical/exploratory applications of trusted computing – Runtime integrity protection –  Integrity models and scalable verification

2

2015 split

•  PCs •  Printers •  Wearables

•  Infrastructure •  Servers •  Networking •  Storage

•  Security •  Software •  Cloud and telecom •  Services

You probably have one of these

3

And had to learn one of these…

4

Let’s define some of the issues

– Each device can have very different security levels – Complex management of security controls for so many platforms with so different characteristics –  Lack of uniform capabilities (accelerated encryption, limitations in performance, energy and memory)

– With changing network connections – May not necessarily consistently rely on consistent network border protection –  Physical media: wireless, wired, mesh

– With different policy requirements –  Stationary and mobile – Multi-tenancy

– Finally, someone has to (correctly!) learn all the heterogeneous security controls…

Introducing SECURED: From heterogeneous to uniform security

security applications independent from

user terminals

security protection independent from user

location

Outline of this talk

– The SECURED architecture – Deployment in virtualized infrastructure

– Policy definition, analysis and enforcement – Results

– Standardisation activities

7

Introducing SECURED (FP7) “SECURity at the network EDge”

8

The SECURED components

•  NED (Network Edge Device) •  Trusted node (with Trusted Computing techniques) •  E.g. home gateway, corporate router, wireless AP, GGSN •  Sets up a Trusted Virtual Domain per user

•  Personal Security Applications (PSA)

•  Security applications as virtual network functions, executed on a NED •  Specific tasks (packet filter, parental control, anti-phishing, content inspection, …) •  Several PSA can be chained according to security policies

•  Security policies

•  Simplify configuration of PSAs and share “best practices” •  (e.g., block inconvenient content)

•  Flexibility (devices owners care about policy, not implementation)

The SECURED framework architecture

user terminal

Application repository

Policy repository authN

1. trust

2. authenticate

3. get policies

4. get apps

personal execution

environment 5. protect!

NED

E.g., “No internet connection after 10.00pm”

NED components at work (1) – the Trusted Virtual Domain

NED components at work (2)

EE2

EE1 MGMT & CTRL

PSA 1

Trusted Channel Endpoint

User A TVD

authN

Internet

User A

TVD Manager

Control Plane and Management Network User A Data Plane Network

Personal Controller

User B TPM NED

User B TVD

. . .

Main challenges addressed

Performance and scalability •  The NED may have to support hundred of users, each one with his policies •  In principle, this means hundreds (or even more) Trusted Virtual Domains

Building the trust

•  Is the NED trusted? Are really my policies enforced there? •  High level, human friendly security policies, with conflict analysis in multi-device environment

DPI BRAS GGSN/

SGSN Firewall

CG-NAT

PE Router

VIRTUAL NETWORK FUNCTIONS

COMMON HW (Servers & Switches)

FUNCTION

CAPACITY

Performance and Scalability

•  In essence, the NED is equivalent to an NFV “compute” platform. •  A lot of work is currently ongoing with respect to performance and scalability of NFV platforms. •  Not much work in the security use cases

Building trust

15

Building trust

•  Is the NED trusted? •  E.g., is the base software (OS, software switch, etc.) the one we expect?

•  Are only my PSA running in the NED and inspecting my traffic? •  I.e., can I be sure that no other PSA are handling my data?

•  Are network devices trusted? •  Network devices can be compromised as well

•  Are network paths trusted? •  I.e., is my traffic crossing some additional (malicious) device that manipulates my data?

secure & trusted channel

NED (Network Edge Device

The current SECURED trust architecture

TPM

measures

Trusted verifier

device

certification of “good” state

(cryptographically bound to the secure channel)

policy app(s)

Measurements are repeated periodically to guarantee that the NED is not compromised

Remote attestation: current limitations

•  TPM is slow •  Supports a limited number of

measurement per second •  Short (malicious) tasks may be discovered too late

•  We can guarantee only the code of

applications running on the bare hardware •  We can guarantee that the VM image is correct,

but we cannot guarantee it is not changed at run-time

•  No guarantees on ephemeral state of applications •  E.g., OpenFlow rules •  We made progress in last year’s talk:

enabled TPMs in ProVision for dynamic OpenFlow integrity reporting

Operating system + hypervisor

Execution environment (e.g., Virtual machine, Linux

container, etc.)

NED

Trusted Platform Module

Softswitch Other

applications

OpenFlow rules

Going distributed: other challenges arise

NED

Execution environment

PSA1

Cloud controller

Compute node1

Execution environment

PSA2

Compute node2

Execution environment

PSA3

Need to setup a transitive chain of

trust

Trust  rela*onship

User’s  network  traffic

What about the network paths?

The Vision: automated and trustworthy monitoring for SDN Introducing the SDN verifier

Assess that SDN configurations of switches match the controller expectation

Out-of-band challenge/response: meant for continual attestation

Challenge: Build a trusted reporting mechanism for each network device (physical and virtual)

SDN controller

monitoring plane

VM VM

vSwitch

SDN verifier

sync

control plane not shown

Future!

“Towards Trustworthy Software-defined Networks using a hardware-based integrity measurement architecture”

- L. Jacquin, A. L. Shaw, C. I. Dalton (NetSoft 2015)

Policy-driven security Definition, analysis and enforcement

21

High level, human friendly security policies

• HSPL: high-level security policy language •  Specifies the end-user security requirements •  Formally, a language with the following syntax:

•  [ subject ] action object [ (field_type,value) ... (field_type,value) ] •  In practice, HSPL looks very similar to natural language and its constructs

can be easily created through a graphical interface •  Examples

•  “Toaster is not authorized to get access to illegal content” •  “Owner enables email scanning for antimalware for sensors”

•  Translated down to common MSPL: medium-level security policy language

•  Like machine-readable XML, similar to XACML •  MSPL fields are essentially a list of abstract capabilities (e.g. filter, block, transform, etc) •  Developer writes translation plugin from MSPL to the low-level app-specific syntax •  These plugins are known as Medium to Low-level (M2L)

Policy-driven security made easy (codenamed: the Grandmother GUI)

24

MSPL capabilities

Project SECURED (www.secured-fp7.eu)

Stackable multi-tenanted security policies

•  The same Internet access may be subject to constraints from different tenants, depending on the network environment

•  Policies are applied hierarchically according to the user and connection profiles

•  User is informed of the overall policy applied to her connection and may refuse to connect to the network

25

user (child)

parent

ISP

government

user (employee)

department

ISP

government

corporation

Policy definition and enforcement

Translation and analysis engines prototyped on the OpenDaylight SDN controller

Results

27

In order to cut down the time to verify remote attestations, a centralised verifier is used to cache results. We perform differential logging such that: -  Previous analyses are not repeated -  Integrity report size reduces network chatter

Validation in Summer of 2015 shows average fresh remote attestation protocol takes ~3 seconds. If already cached, can be nearly instantaneous.

The MSPL policy representation was applied at scale to handle thousands of IPtables and Squid transparent proxy configurations.

Test PSAs with MSPL plugins

28

•  Intrusion Detection (Bro NSM)

•  Re-encryption (MITMproxy)

•  Anti-phishing (DansGuardian)

•  Transparent VPN (StrongSwan)

•  L4 Firewall (IPtables)

•  L7 Firewall (Squid)

•  Anonymity (OpenVPN)

•  Bandwidth Control (TC)

Got encrypted traffic? Re-encryption VNF

Conclusion

29

•  SECURED selected as a flagship security project by the European Commission •  Strong interest around Europe (5G and NFV communities) •  Contributions to standardisation:

•  IETF I2NSF vNSF attestation •  ETSI NFV-SEC-007 report on attestation technologies •  TCG Network Element subgroup

•  Due for another test pilot in the summer of 2016 •  Early results are promising, although our integrity verification research continues •  Ongoing work: move prototype to an NFV platform: UNIFY UN, OPNFV, etc •  Open-source (if all goes to plan)

The research described in this presentation is part of the SECURED project, co-funded by the European Commission under the ICT theme of FP7 (grant agreement no. 611458)

Special thanks

30

https://www.secured-fp7.eu Consortium contact: Prof. Antonio Lioy: lioy@polito.it §  Politecnico di Torino §  Hewlett Packard Labs §  Telefonica I+D §  Universitat Politècnica de Catalunya §  Barcelona Supercomputing Center §  VTT Technical Research Center of Finland §  UNICRI §  PRIMETEL

The research described in this presentation is part of the SECURED project, co-funded by the European Commission under the ICT theme of FP7 (grant agreement no. 611458)

Thanks for your attention!