Steven R Gomez Samuel Jero Richard Skowyra Jason Martin Patrick Sullivan David Bigelow Zachary Ellenbogen Bryan C Ward Hamed Okhravi James W Landry DISTRIBUTION STATEMENT A Approved for public release distribution unlimited This material is based upon work suppo ID: 793643
Download The PPT/PDF document "Controller-Oblivious Dynamic Access Cont..." is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Slide1
Controller-Oblivious Dynamic Access Control in Software-Defined Networks
Steven R. Gomez, Samuel Jero, Richard Skowyra, Jason Martin, Patrick Sullivan, David Bigelow, Zachary Ellenbogen, Bryan C. Ward, Hamed Okhravi, James W. Landry
DISTRIBUTION STATEMENT A. Approved for public release: distribution unlimited. This material is based upon work supported by the Department of Defense under Air Force Contract No. FA8721-05-C-0002 and/or FA8702-15-D-0001. Any opinions, findings, conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the Department of Defense.© 2019 Massachusetts Institute of Technology.Delivered to the U.S. Government with Unlimited Rights, as defined in DFARS Part 252.227-7013 or 7014 (Feb 2014). Notwithstanding any copyright notice, U.S. Government rights in this work are defined by DFARS 252.227-7013 or DFARS 252.227-7014 as detailed above. Use of this work other than as specifically authorized by the U.S. Government may violate any copyrights that exist in this work.
DSN 2019 – June 27, 2019
Network Security session – 9:00-10:30
Slide2Recent High-Impact Cyber Campaigns
Common FeaturesVulnerability ExploitationAdversarial Lateral MovementApproaches target by hopping from one device to another, potentially using credential theft or other techniquesMakes up ~80% of any sophisticated attack12
1 Detecting Lateral Movement With Deception, Smokescreen, March 2017.2013
2014
2015
2016
2017
2018
NotPetya
Slide3Recent High-Impact Cyber Campaigns
3
20132014
2015
2016
2017
2018
NotPetya
Can we make lateral movement harder by removing unnecessary network connectivity?
Common Features
Vulnerability Exploitation
Adversarial Lateral Movement
Slide42017 Equifax Attack
Equifax observed suspicious traffic on July 29, 2017
Attacker had been in place since at least May 13, 2017
Used Apache Struts vulnerability to establish foothold
Spread laterally via privilege escalation and credential theftEstimated cost: $1B+Attack duration: at least three months
4
xploits
CVE-2017-5638
Initial entry
via web portal
compromise
Install
web shell
Privilege Escalation
Pivot
Credential Theft
Pivot
Exfiltrate
PII
Records
Can we make lateral movement harder by removing unnecessary network connectivity?
Internet
Slide5https://www.wired.com/story/
notpetya-cyberattack-ukraine-russia-code-crashed-the-world
https://arstechnica.com/information-technology/2019/06/new-bluekeep-exploit-shows-the-wormable-danger-is-very-very-real/5
Slide6ContributionsNeed for systems that help enforce the principle of least privilege in the network itself
Potential to make it much harder for lateral-movement attacks to succeedMain contributions of this work:Design of a system called Dynamic Flow Isolation (DFI) to add and remove connectivity in real time as needs changeDemonstration of feasibility through a quantitative performance evaluation and security case study6
Slide7Roadmap
BackgroundDesign GoalsOverview of Dynamic Flow IsolationEvaluationSecurity ImpactPerformanceConclusion7
Slide8Access-Control Options
8
Internet
User Role Restrictions
Time/Event Restrictions
Upon user log-off
Outside approved time windows
During events where users are known to be away
While a device is potentially compromised
For example,
Background
– Design – DFI – Evaluation – Conclusion
Slide9Access-Control Options
9Background – Design – DFI – Evaluation – Conclusion
Software-Defined Networking (SDN) provides a paradigm and mechanisms for timely installation and revocation of access control rules, driven by a flexible, automated control plane.
Slide10Traditional versus SDN Switching
10H
HHHH
H
H
H
S
S
H
H
H
H
H
H
H
H
S
S
C
H
S
C
= end host
= switch
= controller
Distributed versus centralized logic, or
“How many brains does it take to forward a packet?”
Traditional L2/L3
SDN
Connectivity determined by static rules and distributed algorithms
Connectivity determined by control plane dynamically
Background
– Design – DFI – Evaluation – Conclusion
Slide11SDN Control Plane Overview
11Ujcich et al., “Cross-App Poisoning in Software-Defined Networks” (CCS 2018)
http://ujcich2.web.engr.illinois.edu/papers/18_CCS_slides.pdf
Centralized, software-driven decision system that handles flows (“controller”)
Apps extend functionality to core functions like forwarding
Considerations
Compatibility
: How apps plug into the controller may be vendor-specific
App security
: Cross-app poisoning is a security concern (
Ujcich
et al. 2018)
Background
– Design – DFI – Evaluation – Conclusion
Slide12Design Goals
12Background – Design – DFI – Evaluation – Conclusion
What are the goals for an SDN access control system that is both: (a) fine-grained and event-driven, and (b) independent of the controller?
Slide13Design Goals
Adapt flow rules in response to events according to event-driven access control policiesSupport high-level identifiers in policiesPeople think in hostnames, not IP addressesWant to gracefully handle changes, like new IP leasesWant to instantiate rules that are specific to the traffic even if derived from wildcarded policies
13Background – Design – DFI – Evaluation – Conclusion
f (
“user log-on”)
Slide14Design Goals
Adapt flow rules in response to events according to event-driven access control policiesSupport high-level identifiers in policiesPeople think in hostnames, not IP addressesWant to gracefully handle changes, like new IP leases
Want to instantiate rules that are specific to the traffic even if derived from wildcarded policies14Background – Design – DFI – Evaluation – Conclusion
f
(“user log-on”
)
Slide15Design Goals
Maintain policy-switch consistencyWant events that change current policies to also flush from switches any flows that are now disallowedHard flow time-outs hurt performance, and soft time-outs have edge cases that could enable inconsistent enforcement for ongoing flowsPrevent a compromised controller or app from interferingWant to place new firewall-like rules in SDN switch tablesController or its apps should not be able to remove these flow rules or handle any traffic that is dropped by the rules
15Background – Design – DFI – Evaluation – Conclusion
Slide16Design Goals
Maintain policy-switch consistencyWant events that change current policies to also flush from switches any flows that are now disallowedHard flow time-outs hurt performance, and soft time-outs have edge cases that could enable inconsistent enforcement for ongoing flowsPrevent a compromised controller or app from interferingWant to place new firewall-like rules in SDN switch tablesController or its apps should not be able to remove these flow rules or handle any traffic that is dropped by the rules
16Background – Design – DFI – Evaluation – Conclusion
Slide17Design Goals
Maintain policy-switch consistencyWant events that change current policies to also flush from switches any flows that are now disallowedHard flow time-outs hurt performance, and soft time-outs have edge cases that could enable inconsistent enforcement for ongoing flowsPrevent a compromised controller or app from interferingWant to place new firewall-like rules in SDN switch tablesController or its apps should not be able to remove these flow rules or handle any traffic that is dropped by the rules
17Background – Design – DFI – Evaluation – Conclusion
Data Plane
Untrusted Control Plane
Independent
Access Decision Plane
Slide18Dynamic Flow Isolation (DFI)DFI uses software-defined networking to adapt network-level access over time as neededHandles OpenFlow and provides platform for new sensors and dynamic policies
Enables policies that apply the principle of least privilege in the network18Background – Design – DFI
– Evaluation – Conclusion
Slide19DFI Overview
19Background – Design – DFI – Evaluation – Conclusion
Policy ManagementPolicy Enforcement
Slide20DFI Overview
Policy Manager maintains the current policy for the networkPolicy Decision Points (PDPs) listen for events then notify the Policy Manager about how high-level policies are currently instantiated20
Background – Design – DFI – Evaluation – Conclusion Policy Management
Policy
Enforcement
Slide21DFI Overview
21Background – Design – DFI – Evaluation – Conclusion
Policy Management
Policy
Enforcement
Switches
connect to the DFI Proxy
in place of the SDN controller
Proxy ensures that a
DFI has total control over a flow table
in each switch
Packets from switches are routed into the DFI Policy Compilation Point (PCP) that
checks the current policy and creates DFI “fire wall” flow rules
Controller installs
forwarding rules
for allowed flows
Slide22SDN
Controller
DFI
Controller Proxy
Policy Compilation Point
Sensors
DFI Policy Decision Point
Events
“Log-on enables user’s
access control list”
Policy
Database
Alice
ip
: 1.2.3.4
DFI Architecture in Action
22
Bob
ip
: 5.6.7.8
Policy Management
Policy Enforcement
Background – Design –
DFI
– Evaluation – Conclusion
Slide23SDN
Controller
DFI
Controller Proxy
Policy Compilation Point
Sensors
DFI Policy Decision Point
Events
“Log-on enables user’s
access control list”
Policy
Database
Event: Log-On
Alice@AliceDesktop
Allow: Alice
Bob
Limit: Alice
Internet
Alice
ip
: 1.2.3.4
Bob
ip
: 5.6.7.8
DFI Architecture in Action
23
Policy Management
Policy Enforcement
Background – Design –
DFI
– Evaluation – Conclusion
Slide24SDN
Controller
DFI
Controller Proxy
Policy Compilation Point
Sensors
DFI Policy Decision Point
Events
“Log-on enables user’s
access control list”
Policy
Database
Event: Log-On
Alice@AliceDesktop
Allow: Alice
Bob
Limit: Alice
Internet
Alice
ip
: 1.2.3.4
Bob
ip
: 5.6.7.8
Match
Src:1.2.3.4
Dst:5.6.7.8
Action
ALLOW
Policy Management
Policy Enforcement
DFI Architecture in Action
24
Background – Design –
DFI
– Evaluation – Conclusion
Slide25Event-Driven Policy
25Background – Design – DFI – Evaluation – Conclusion
Goal: Adapt flow rules in response to events according to event-driven access control policies
Slide26Event-Driven Policy
26Background – Design – DFI – Evaluation – Conclusion
Alice logs onto Host X
DFI Policy Manager and DB
DFI PDP for
“Auth-triggered RBAC”
User-Host
Log-on sensor
Allow Host X to access all Alice’s role-based list with PDP’s priority and cookie Z
Alice logs off X
Revoke policies with cookie Z from Manager
Flush any flows in data plane with cookie Z
Time
Async. query and response from PCP for enforcement
Slide27Closer Look at Controller Isolation Approach
27Background – Design – DFI – Evaluation – Conclusion
Goal: Prevent a compromised controller or app from interfering with DFI access control
Slide28OpenFlow 1.3+ Switch
Closer Look at Controller Isolation ApproachProxy shifts the Table ID of controller requests/configs to the switch
Increment northbound, decrement southboundPrevents controller from addressing anything to Table 0DFI’s “allow” rule for a flow is an instruction to look for a match in the subsequent tables, where the controller will have installed a forwarding rule28Background – Design – DFI – Evaluation – Conclusion
Data Plane
Untrusted Control Plane
Proxy
DFI PCP
0
1
2
n-2
…
n-1
Controller owned
DFI owned
Slide29Evaluation
29Background – Design – DFI – Evaluation – Conclusion
Attack Scenario – How does an event-driven policy with DFI slow down a threat?Performance Evaluation – How does it impact normal flows (e.g., latency, time-to-first-byte)?
Slide30Attack Scenario Evaluation
Goal: Evaluate impact of DFI on realistic threatLeverage a testbed to simulate malware attackDeploy ransomware surrogate on a typical enterprise workday scenario Vary access-control conditions via DFI (static or event-driven RBAC)Measure infection rate over timeTestbed Configuration100 Windows hosts and servers, 15 Open vSwitch VMs (OF 1.3)Logical enclaves correspond to notional enterprise workgroups
ONOS controller30
Background – Design – DFI –
Evaluation
– Conclusion
Adapt
NotPetya
propagation logic
Slide31Attack Scenario Evaluation
31
Comparison of infection rates using:No access controlStatic role-based policy (S-RBAC)Event-driven role-based policy (AT-RBAC) enabled by DFIBackground – Design – DFI – Evaluation – Conclusion
“What if the infection begins when fewer users are on their devices?”
Slide32Performance Evaluation
32Latency per flow (no load)
5.73msstd. dev.: 3.39msThroughput (saturated)
1350 flows/sstd. dev.: 39 flows/s
Queueing new flows
Background – Design – DFI –
Evaluation
– Conclusion
Slide33Conclusion
Modern network threats utilize needless connectivityWe built a system to test the feasibility of dynamic access controlEnforced in the network itselfIndependent of the controllerWe found that our system, DFI, is a practical solution for these threats in a small enterprise network, usingAn attack scenario in which the threat was slowed by the systemPerformance benchmarks with reasonable latency and time-to-first-byte
33Background – Design – DFI – Evaluation – Conclusion Contact: steven.gomez@ll.mit.edu