Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Uniform IoT security using NFV-based policy enforcement gateways

Uniform IoT security using NFV-based policy enforcement gateways

As telecoms move towards cloud-based models to affordably handle the wave of newly connected devices, thanks to 5G and the Internet of Things (IoT) trend, security of such critical infrastructure has never been more important in order to meet government regulations. In particular, network security services are gaining momentum as a key use case for Network Function Virtualization (NFV), giving operators the opportunity to offer universal security protection for heterogeneous clients. However, outsourcing security to the edge of the network raises a number of security and privacy concerns requiring a great deal of faith and trust from the tenant as they must rely on the edge to perform correct enforcement of security policies. This talk will report on the progress of the SECURED project for leveraging NFV as a security gateway for the IoT, and will describe the trust architecture used to deliver assurance to end tenants of its proper operation.

Adrian L. Shaw

May 11, 2016
Tweet

More Decks by Adrian L. Shaw

Other Decks in Research

Transcript

  1. Uniform IoT security using NFV based policy enforcement gateways Adrian

    L. Shaw [email protected] 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 – 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
  3. 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…
  4. Introducing SECURED: From heterogeneous to uniform security security applications independent

    from user terminals security protection independent from user location
  5. Outline of this talk – The SECURED architecture – Deployment in virtualized

    infrastructure – Policy definition, analysis and enforcement – Results – Standardisation activities 7
  6. 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)
  7. 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”
  8. 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 . . .
  9. 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
  10. 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
  11. 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?
  12. 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
  13. 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
  14. 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
  15. 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)
  16. 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)
  17. 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
  18. 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.
  19. 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
  20. 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)
  21. Special thanks 30 https://www.secured-fp7.eu Consortium contact: Prof. Antonio Lioy: [email protected]

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