Research in Cloud and Data Center Security€¦ · Research in Cloud and Data Center Security...

Research in Cloud and Data Center Security

Matthew Elder, Ph.D.

Director, Symantec Research Labs

Symantec Research Labs (SRL)

• SRL: Symantec’s core research organization – United States (California, Virginia) and Europe (Ireland, France)

• Charter – Develop key technologies and explore uncharted territories

– Provide thought leadership

• Operational model – Work closely with existing and emerging businesses

– Identify and work on relevant hard technical challenges

– Collaborate with academia

• Success factors – Invent new protection technology

– Transfer technology to existing or new product offerings

– Develop new intellectual property

– Forge research collaborations and publish innovative work

Countermeasure 2015 - Copyright © 2015 Symantec Corporation

2

Symantec Research Labs (SRL)

3

f (risk, time_horizon, impact)

Pro

po

rtio

n o

f ti

me

sp

en

t

Product Development

Advanced Development

SRL Academic Research


SRL Research Areas

• Security and risk – Malware research, intrusion detection, “traditional” security research…

– Security analytics, risk assessment

– Publications: IEEE S&P’15, Usenix Security’15, ACM CCS’15, NDSS’15, Financial Crypto’15, DIMVA’15, IMC’14, SIGKDD’14, RAID’14, ASIA CCS’14…

• Cloud security – Cloud platform security

– Cloud application security

• Other – Trust, certificates, identity management

– Data protection, data loss prevention, asset protection

– Mobile and IoT


4

Overview – Cloud and Data Center Security in SRL

• Security-as-a-Service for OpenStack Clouds

• Policy Enforcement for Docker Containers

• Data Center Service Obfuscation


5

Security-as-a-Service for OpenStack Clouds Yuqiong Sun (Penn State/SRL), Susanta Nanda (SRL), Trent Jaeger (Penn State)

Countermeasure 2015 - Copyright © 2015 Symantec Corporation 6

(A detailed version of this research to appear in IEEE CloudCom 2015, 12/1/15)

Virtualized Networks in the Cloud

• Software-defined data center enables virtualized networks

– Customer’s view of network is decoupled from cloud provider’s physical network topology

– Logical switches/routers emulated in software

• Impact for tenants/customers:

– Enables topology creation via software, quickly

– Recreates on-premise infrastructure in cloud, deploy enterprise apps quickly

– Does not require adapting network policies

• Impact for cloud operators/providers:

– Enables better multi-tenancy

– Maximizes utilization of the network infrastructure

– Provides opportunities for value added services (e.g., security)


7

Monitoring in Virtualized Networks

• Security applications (e.g., IDS, DLP) require network monitoring

• Network monitoring challenges

– No SPAN port (in the logical switches) to connect to, no way to tap

– How do we monitor a logical network that is distributed and dynamic?

– Cloud applications are moving towards microservices architecture

• Architectural support for tapping

– Needs to sniff traffic in all logical network elements

– Need to address multi-tenancy, monitor VM-to-VM traffic, and isolate impact due to one tenant from another in shared security infrastructure

– Needs to dynamically scale with dynamic and elastic workloads, as compute and network elements are added and removed on the fly

– Needs to support a variety of deployment strategies…


8

Flexible Tapping: Dedicated Host for Security VMs


9

• One security appliance per tenant/L2-L3 domain/etc.

Hypervisor

Application VM

Application VM

Hypervisor

Application VM

Application VM

Hypervisor

Security VM

Security VM

IP fabric

L2-in-L3 Tunnel

Application VM

Application VM

Security VM

Application VM

Application VM

Security VM

Physical View

Logical View

Flexible Tapping: Distributed Security VMs


10

• One security appliance per physical host

Hypervisor

Application VM

Application VM

IP fabric

L2-in-L3 Tunnel

Physical View

Security VM

Hypervisor

Application VM

Application VM

Security VM

Logical View

Application VM

Application VM

Security VM

Application VM

Application VM

Security VM

Flexible Tapping: Application-Specific Security VMs


11

• Custom security appliances for different apps/protocols/etc.

– Example: Web app firewall for HTTP

IP fabric

Hypervisor

Web Server Database

L2-in-L3 Tunnel

Physical View

Email Server

Hypervisor

WAF DLP Email

Security

SMTP Port:3306 HTTP(S)

Traffic Tapping/Sniffing in OpenStack: FlowTap

• Flexibility is the key – Port to port (tapping on ports, i.e., vNIC of VM)

– Selective tapping (tapping based on flow)

• Flow-based matching – OpenStack uses Open vSwitch (OVS) that supports OpenFlow

– OpenFlow allows matching against a wide variety of L2-L4 parameters

• FlowTap (src, dst, flow_syntax, action): flow-based tapping primitive – src: port being monitored; such ports often belong to the application VM and

are assigned IP addresses.

– dst: tap port that sniffs traffic on the monitored ports; such ports often belong to the security VM and may not have IP addresses.

– flow_syntax: describes particular flows; traffic from/to src port that comply with flow_syntax will be sent to dst port for security monitoring.

– action: sends a copy of traffic to dst port.


12

FlowTap: Example Usage

• Dedicated security VM (per tenant)

– (P1, P3, P5 | *) -> S1; (P2, P4, P6 | *) -> S2

• Distributed security VM (same physical host)

– (P1, P2, P3 | *) -> S1; (P4, P5, P6 | *) -> S2

• Application-specific security VM (e.g. WAF)

– (P1-P6 | HTTP(S)) -> S1; (P1-P6 | SMTP) -> S2


13

VM1 VM2 VM3 VM4 VM5 VM6

Security VM1

Security VM2

Hypervisor Hypervisor P1 P2 P3 P4 P5 P6

S1 S2

Implementation in OpenStack Neutron

• New neutron client command (neutron appliance-create)

• New neutron-server plugin and neutron-plugin agent

• Components in gray were modified


14

Bro Network Security Monitor

• A proof-of-concept “IDS as a Service” using Bro

– Open source network monitor designed for physical networks.

– Bro’s domain-specific scripting language enables application-specific monitoring policies.

– Bro is not restricted to any particular detection approach and does not rely on traditional signatures.

• Example use cases:

– Enforce connection policy in security VMs, protecting services in app VMs.

– Check and enforce request-specific connection policies in security VMs

– Check integrity of requests in security VMs, enforcing application-specific logic and invariants.


15

FlowTap Summary

• Network virtualization enables software defined data centers but complicates network security monitoring

• Goal: enable tenants/operators to configure and deploy security monitoring in virtualized networks

• FlowTap enables an architecture to deploy network monitoring-based security services that is

– Flexible and scalable

– Deploys and manages security services based on policies

• Prototype developed within OpenStack and proof-of-concept security monitor built using Bro network monitor


16

Policy Enforcement for Docker Containers Mingwei Zhang (Stony Brook/SRL), Daniel Marino (SRL), Petros Efstathopoulos (SRL)


(A detailed version of this research to appear in IEEE CloudCom 2015, 12/3/15)

Background

• Trend toward container-based application deployment

– Packages an application with all its dependencies into a container

– Portability eases transition from development to QA to deployment

– Employs lightweight (OS-level) virtualization

• Much lower overhead than VMs

• Shared resources with underlying OS and other containers

• Docker has lots of momentum

– Growing, active community

– Supported by major cloud infrastructure providers: Google Cloud, AWS, Microsoft Azure, OpenStack Nova

– Early adopters include Yelp, Spotify, eBay, Gilt

– Images for many common open source applications available on public Docker registry


18

Example Docker Architecture


19

Container Management Process (Docker Daemon)

Application Owner Application Image Repository

App Images

Deployment Commands

App Images

App Containers

pull apache-image

run apache-image MyApache “httpd –d /home/www”

stop MyApache

Co

nta

iner

Ser

ver

Problem

• Docker does not provide the same degree of isolation that traditional virtual machine (VM) infrastructure provides – Parameters passed to the run command launching a Docker container control

the degree of isolation from the underlying operating system

– --privileged option gives the application running within the container nearly the same access to the host as an uncontained process running as root

– Non-default entry points can be specified when starting containers

• Good security practice dictates that administrators should adhere to the principle of least privilege, granting users only the privileges needed to accomplish their job – Unfortunately, once a user is able to issue commands to a Docker daemon,

they are free to download and launch any container (potentially from an untrusted source) with arbitrarily high privileges

– Administrators should be able to constrain these commands and enforce enterprise-specific security policies for Docker


20

Solution: Policy Enforcement Proxy

• Harbormaster: protects container hosts by enforcing fine-grained policies on container commands issued by users

– Intercepts commands with proxy and evaluates for compliance

– Transparent to users and orchestration tools


21

Harbormaster Policies

• Image operation policies

– Control which registries from which images can be pulled down

– Restrict which users can push modified images

• Container operation policies

– Ensure that a user is not able to launch a container with more privileges than the user is granted by the operating system, by default

– Restrict run command policies around host access and default entry points

– Control the starting and stopping of containers launched by other users


22

Proof-of-Concept Prototype and Experimentation

• Designed and implemented policy language

• Developed proxy for intercepting Docker commands and interpreter for evaluating against policy

• Conducted initial experimentation:

– Runtime overhead of proxy for startup commands: 11.2% on average

– Policy evaluation time less than .5 seconds for up to 10,000 rules

– Tested with commands coming from Docker client and Kubernetes container management system


23

Harbormaster Summary

• Docker containers are a promising new cloud application development and deployment mechanism

• Isolation and privileges are potentially unrestricted for users running Docker commands

• Harbormaster enables policy specification and enforcement to enable principle of least privileges for Docker administration

– Proxy intercepts Docker commands and evaluates policy compliance

– Image operation and container operation policies can be specified for user and groups


24

Data Center Service Obfuscation Nathan Evans (SRL), Azzedine Benameur (SRL)


Context

• DARPA Mission-oriented Resilient Clouds (MRC) program

• MEERKATS project

– In collaboration with Columbia University and George Mason University

– Leverage unused resources in the cloud for added security

– Create replica hosts, decoys, honeypots, etc.

– Migrate data, create fake data

• Data center service obfuscation makes an attacker’s job more difficult after they’re in…


26

Problem Statement

• Once an attacker has breached an internal network, finding other hosts/services to attack is trivial

– Nmap (IP/port scans)

– Local application settings

– Broadcast traffic

– Netstat, ARP cache, browser logs, etc.

• Once the “application layer topology” is discovered, attacker can use custom or specific attacks on services and hosts that are most vulnerable

• How can we stop this step of targeted attacks, data center breaches, and APTs (reconnaissance)?


27

Current Solutions

• Firewall/PIX – limit access between networks, block traffic by port/IP/application

• IDS/IPS – detect scan behavior and malicious packets

• Isolation – separate networks (subnets, VLANs) by organizational unit, data center vs. employee networks, etc.

• Honeypots – deploy decoy systems to lure attackers

• Obfuscation – run services on non-standard ports


28

The ShadowNet Solution

• Prevent service discovery (port scanning) – Bind all services to localhost (127.0.0.1) only interface

– Expose only a _single_ port on “live” network

– Network scans reveal homogenous network

Nothing to detect, nothing to attack!

• Prevent service location discovery – Each ShadowNode acts as proxy/relay for other ShadowNodes

– Client can connect to any ShadowNode with unique service UUID

– Entry ShadowNode routes request through network to where actual service is running

– Client doesn’t know which host is actually running service

– Any attack must go through proxy


29

ShadowNet Example


30

Proof-of-Concept Implementation

• Tor – Open Source Onion routing software

• Onion Routing

– Multiple hops through network

– Added layer of encryption at each step

– Provides client anonymity (which we don’t care about)

• Tor Hidden Services

– Onion route to public “rendezvous point”

– Provides server anonymity

– Leverage the hidden services concept to hide data center services

• Tested with some common data center services


31

Technical Details

• Number of relay hops can be varied – Services are “better” hidden with more hops

– More hops mean more bandwidth/latency

• All connections to relays/proxies encrypted – Access to one server does not give away services on other servers

– Traffic analysis, tracking connections more difficult

• Strict firewall rules – Only a single public facing port

– No outgoing connections to non-ShadowNet services

• Leverage spare bandwidth/CPU in cloud/data center to provide increased security


32

Docker Integration

• Docker: fast and easy deployment of lightweight containers

• Docker images integrated with ShadowNet

– Eases overhead of deployment

– Reduces complexity in setting up ShadowNetified services

– One-time cost joining docker server to ShadowNet

• Data center containers which can be deployed in seconds

– Database servers (mysql, mongodb)

– Web services (apache, wordpress)

– Code repositories (git, svn)


33

Honeypot Integration

• We assume the worst – At some point attackers will breach ShadowNet protected services

– What happens then?

• Second line of defense – Once an attacker gains foothold, give them targets for lateral movement

– Reveal network/services that are in fact honeypots

• Back to Docker – Create lightweight honeypots as containers

– “Link” honeypots to ShadowNet containers: when attacked, honeypots appear to be on the same network

– Any movement from ShadowNet->honeypot flags an incursion

• Implemented leveraging modern honeynet project backend


34

ShadowNet Issues and Summary

• Issues

– Deployment costly in terms of CPU/bandwidth

– Non-trivial to bootstrap/integrate in existing data center

– Some services are not amenable to proxying

• Summary

– Data center service obfuscation prevents network reconnaissance

– ShadowNet hides services from attacker discovery

– Docker integration enables easier deployment

– Honeypot integration adds second layer of defense

– Performance and usability challenges remain before transitioning research


35

Conclusion


Summary

• New cloud technologies (e.g., SDN, containers) enable new functionality as well as new security threats

• Research is being done in industrial research labs such as SRL and academia to invent new solutions and solve new problems

• Technology based on research will transition into solutions down the road…


37

Thank you!

Copyright © 2015 Symantec Corporation. All rights reserved. Symantec and the Symantec Logo are trademarks or registered trademarks of Symantec Corporation or its affiliates in the U.S. and other countries. Other names may be trademarks of their respective owners.

This document is provided for informational purposes only and is not intended as advertising. All warranties relating to the information in this document, either express or implied, are disclaimed to the maximum extent allowed by law. The information in this document is subject to change without notice.

Matthew Elder

[email protected]

Date post:	28-May-2020
Category:	Documents
Upload:	others
View:	7 times
Download:	0 times

Research in Cloud and Data Center Security€¦ · Research in Cloud and Data Center Security...

Documents