Building Blocks Towards a Trustworthy NFV Infrastructure

A number of large open-source projects are being surgically tied together to bring the Network Functions Virtualization stack to the carrier environment. The sheer scale of software components and the interplay of APIs will bring the inevitable - a frightening number of attack surfaces embedded in critical infrastructure. A security architect's mileage may vary when trying to secure such large stacks without compromising on core functionality. We must accept that security will fail at some point and provide robust ways for detecting such failures. This talk describes a proactive approach to systematically manage the complexity from the ground up in spite of many different attack vectors. In particular, we introduce two ongoing research projects based on Trusted computing technology to dynamically monitor and attest the underlying configurations of virtual network and compute nodes.

Transcript

1. Building Blocks Towards a Trustworthy NFV Infrastructure IRTF NFVRG Adrian L. Shaw <adrian.shaw@hp.com> Hewlett-Packard Laboratories / July 22nd, 2015 1
2. Why security and trust? •  Big requirement for critical infrastructures •  Security is not just about ACLs and crypto •  Workflows and service lifecycles •  Need for continual compliance monitoring •  Quick remediation •  Assurance requires strong visibility and infrastructure transparency
3. Where were we before? Cloud •  General purpose •  Difficult to generally automate •  Compute and storage centric •  Administrators •  Multiple owners and tenants •  Generally broad and difficult NFV •  Very specific purpose •  Controlled software •  Focused orchestration •  I/O centric •  Operator + some customers •  Opportunity for focused security
4. Trusted Computing and Remote Attestation •  Trusted computing: checking if platform executes expected SW •  Enforced through a component isolated from the software •  Measurement log signed by secure identity and verified remotely •  Remote verifier must have measurements of all expected software and configurations •  Different roots of trust: Measurement, storage, recovery, etc •  General requirement for a root of trust: –  Secure storage –  Protected memory –  Shielded execution –  Cryptographic engine
5. Hardware-based Roots of Trust • Minimum piece to be trusted in order to achieve security property • Why hardware? –  Identity in hardware helps prevent ID forgery and SW-based attacks –  Small functionality and immutability give high assurance –  A small chip is often more reliable than someone else’s Python script • Bind identity to platform • Standards –  Trusted Platform Module (TPM) and Trusted Computing Group (TCG) • Other HW roots of trust: Intel TXT, AMD SVM, ARM TrustZone + PUFs –  Provisioning & authentication: IEEE 802.1AR Secure Device Identity
6. Building blocks • Platform boot time integrity –  Verified boot – only allow signed software components –  Trusted boot – reports the version of each software in boot chain • Load time inspection –  Linux IMA – measure each program and report to TPM before executing • Measures high integrity files e.g. readable by root user –  Linux EVM – measures integrity of file-system permissions • Network integrity –  Bind platform certificates to root of trust –  Configuration measurement (e.g. SDN VLANs, MACSEC context)
7. IMA: Host-level attestation • Measures and reports to the TPM every time the kernel loads: –  Executable programs –  Shared libraries –  Files readable by high integrity (e.g. Root user) • Flexible appraisal strategy –  SHA-1/SHA-256 measurements –  Signature-based verification • Overheads – Speed of verification –  Integrity report size: “Virtualized security at the network edge” – Montero et al
8. Trusted channel establishment Host1 strongSwan (initiator) 1: start trusted channel Host2 hypervisor privileged OS hardware TPM strongSwan (responder) PSCM MEAS. MODULE (IMA) RA AGENT -> 4: request integrity and verify cert 0: measure hw/sw components during the boot 6: retrieve measurements and create TPM quote -> 5: request integrity report <- 7: send integrity report 8: evaluate measurements <- 9: verification result Trusted Third Party OpenAttestation -> 2: start handshake <- 3: get cert 10: if verification is ok: establish channel 11: exchange data
9. Compliance monitoring of SDN SDN verifier SDN controller Sync Hardware Switch vSwitch VMM VNF VNF VNF vSwitch VMM VNF VNF VNF Outboun d traffic Hardware Switch Attest switch configurations TrustedFW TrustedFW Inbound traffic Dataplane Monitoring plane Control plane not visualised
10. Remote Attestation of a Network Element Network Element Trusted Computing Base (TCB) RTM RTR SDN switch SDN contex t Report RA agent SDN verifier SDN controller Sync Introspect Trusted Device Store Measure Get RA proof Get SDN conf.
11. SDN attestation report •  Attestation requests context •  TCB includes reporting agent •  Report covers –  Header matches for L1, L2, L3, L4 –  Action –  Priority –  Surrounding DP configuration •  Report signed by the TPM •  Prototyped on HW –  SNMP-based, thinking of appropriate monitoring protocol Digest: 9335860991caa2c169732facea5704624ea8a311 Digest: b6a716e7f86fc2489800d99e805bb2e712ed6def TPM sign operation
12. Compliance monitoring for NFV SDN verifier NFV orchestrator OSS/BSS VNF manager SDN controller Sync NFV software stack Hardware Switch vSwitch VMM VNF VNF VNF vSwitch VMM VNF VNF VNF Outbound traffic Hardware Switch Attest switch configurations TrustedFW TrustedFW Inbound traffic VIM Errors Compute verifier
13. Takeaways • Great opportunity for TC to work for NFV –  Operator more likely to know expected software images and configurations –  Different building blocks can be applied for varying levels of integrity • Ethemeral configurations (e.g. SDN) need monitoring –  Data plane security – alert on unauthorised change • Other needs: –  Control plane security – separation of concerns between SDN applications • Stateless infrastructure deployment –  Better for attestation of compute nodes without too many ringing alarm bells
14. Thank you adrian.shaw@hp.com 14