Uniform IoT security using NFV based policy enforcement gateways

Transcription

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

2 # 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 2015 split Interests Platform security in distributed systems Practical/exploratory applications of trusted computing Runtime integrity protection Integrity models and scalable verification Infrastructure Servers Networking Storage Security Software Cloud and telecom Services PCs Printers Wearables 2

3 You probably have one of these 3

4 And had to learn one of these 4

5 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

6 Introducing SECURED: From heterogeneous to uniform security security applications independent from user terminals security protection independent from user location

7 Outline of this talk The SECURED architecture Deployment in virtualized infrastructure Policy definition, analysis and enforcement Results Standardisation activities 7

8 Introducing SECURED (FP7) SECURity at the network EDge 8

9 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)

10 The SECURED framework architecture authn 3. get policies Policy repository E.g., No internet connection after 10.00pm 2. authenticate 1. trust 4. get apps Application repository user terminal NED 5. protect! personal execution environment

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

12 NED components at work (2) User A TVD User B TVD authn TVD Manager MGMT & CTRL EE1 Personal Controller... PSA 1 EE2 User A Trusted Channel Endpoint User B TPM NED Control Plane and Management Network User A Data Plane Network Internet

13 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

14 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 DPI BRAS Firewall CG-NAT PE Router GGSN/ SGSN VIRTUAL NETWORK FUNCTIONS FUNCTION COMMON HW (Servers & Switches) CAPACITY

15 Building trust 15

16 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?

17 The current SECURED trust architecture Measurements are repeated periodically to guarantee that the NED is not compromised device secure & trusted channel NED (Network Edge Device policy app(s) TPM certification of good state (cryptographically bound to the secure channel) measures Trusted verifier

18 Remote attestation: current limitations TPM is slow Supports a limited number of measurement per second Short (malicious) tasks may be discovered too late Execution environment (e.g., Virtual machine, Linux container, etc.) 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 Other applications Softswitch OpenFlow rules 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 Trusted Platform Module Operating system + hypervisor NED

19 Going distributed: other challenges arise Need to setup a transitive chain of trust Execution environment PSA2 Cloud controller Execution environment PSA3 Execution environment PSA1 Compute node1 Compute node2 User s network traffic NED Trust rela*onship

20 What about the network paths? Future! The Vision: automated and trustworthy monitoring for SDN Introducing the SDN verifier Assess that SDN configurations of switches match the controller expectation SDN controller sync SDN verifier VM VM vswitch Out-of-band challenge/response: meant for continual attestation Challenge: Build a trusted reporting mechanism for each network device (physical and virtual) Towards Trustworthy Software-defined Networks using a hardware-based integrity measurement architecture - L. Jacquin, A. L. Shaw, C. I. Dalton (NetSoft 2015) control plane not shown monitoring plane

21 Policy-driven security Definition, analysis and enforcement 21

22 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 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)

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

24 MSPL capabilities Project SECURED ( 24

25 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 government ISP parent user (child) government ISP corporation department user (employee) 25

26 Policy definition and enforcement Translation and analysis engines prototyped on the OpenDaylight SDN controller

27 Results 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. 27

28 Test PSAs with MSPL plugins 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 28

29 Conclusion 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 ) 29

30 Special thanks Consortium contact: Prof. Antonio Lioy: 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 ) 30

31 Thanks for your attention!