Our novel SDN agent approach provides scalable flow-based monitoring for enterprise networks. With it, organizations can reuse their existing network infrastructure and incrementally deploy the approach. With logically-centralized access controllers, operators can understand the context of the network request, such as the application being used and the username of the user. This enables richer and more powerful organizational network policy.
We created a prototype implementation and evaluated it in a real physical network with systems that lacked support for host-based SDN. We evaluated the approach at a higher scale using a virtual
Metric Open vSwitch Modified Open vSwitch
Median Elevation (ms) 1.98 2.739
Median RTT (ms) 6.25 7.390
New Flows/sec 103.19 86.80
Table 3.3: Table showing the performance characteristics of host-based SDN using Open vSwitch. Modifying Open vSwitch to support appending context results in approximately 16% reduction in flows per second. These results are incorporated from Najd et al. [135].
network. In doing so, we found that our approach incurred minimal overheads. We also briefly explore the possibility of integrating our approach into existing OpenFlow technologies. Leveraging Open vSwitch shows an improvement in performance over our clean slate approach.
Our work provides a foundation for potential future work. Future work includes exploring proxy solutions for legacy devices or assets not owned by the organization. Additionally, we will also examine how virtualization and trusted computing technology can be leveraged to relax some requirements in our trust model. Finally, we will explore building more advanced policies for enterprise network systems.
Chapter 4
Extending Host Context into the GUI
4.1
Introduction
In Chapter 3, we discuss our enterprise solution to securing networks using host-based SDN. By maintaining a presence on the end-host, we are able to better understand and attribute network interactions from a systems perspective. However, computing devices are designed to serve an end-user by allowing a user to complete tasks. To complete tasks, a user interacts with a machine using inputs to the graphical user interface (GUI). In this chapter, we seek to leverage not only system information when making policy decisions but also incorporate a user’s interaction with an application’s GUI to act as an endorsement for network activity.
Interactions with a GUI and the context generated from interactions determine how an ap- plication should behave. Accordingly, context and interactions may act as user endorsements for low-level operations such as network communication or disk access. With few exceptions, appli- cations without an on-screen presence are not user-oriented. These applications may either be well-known daemons, such as clock-synchronization systems, or may be an indicator of unautho- rized software that is attempting to evade detection.
For malware, it is advantageous to remain hidden in order to avoid detection. One way to remain undetected is to have no, or very little, on-screen presence. Indeed, the majority of malware never has an onscreen presence, and those that do, briefly present an error to avoid raising suspicion and lack subsequent interaction with the user [63]. As such, applications that have an on-screen presence should bring some legitimacy to an application and its behavior. User interactions with GUI objects, such as buttons, can either result in internal changes in the process’s memory or could result in system specific operations such as opening a descriptor to a file on disk or creating a network connection. Importantly, these operations result from discrete steps taken by the user when navigating through the GUI interface.
Our goal is to leverage the inherent GUI structure, along with a user’s input, to understand what underlying system interactions should occur as a user interacts with an application. Specifically, we aim to detect when applications perform network operations without a user’s endorsement. We detect unexpected network connections by building GUI signatures of applications. The signatures are comprised of paths and paths are composed of GUI objects and the related interaction that must occur to transition to the next node in the path. For example, a mail client may have
Text: Compose Type: Button Parent: Mail
Mail Client Signature
Path1
Text: NULL Type: Textbox Parent: Compose
Action: Left-click Action: Keystroke Text: Send
Type: Button Parent: Compose Action: Left-click Network access Text: File Type: Menu Parent: Mail Path2
Action: Left-click Text: Compose
Type: Menu Item Parent: File Menu
Action: Left-click
...
Pathn
...
Figure 4.1: A GUI signature is composed of all valid interaction paths that result in network access.
multiple paths for sending an email. One path could be clicking on a “compose” button to create a new email, writing the email and providing the intended recipient’s context information, and then clicking a “send” button. The collection of these paths creates a signature for a particular application as shown in Figure 4.1.
GUI signatures can be used to detect when applications attempt network access without an en- dorsement. Such unexpected access may be the result of something benign including asynchronous background traffic, such as application updates, which tend to happen infrequently and can be quickly ruled out as malicious. On the other hand, the traffic could potentially be the result of an attack resulting from a buffer overflow or backdoor in an application. Without understanding the user’s interactions, the state of GUI, and the relationship between the two (i.e., the paths in a signature), it can be difficult to catch such attacks. It may be unclear to security applications, such as network-based intrusion detection systems, whether the network communication was so- licited or not. With GUI signatures and an appropriate detection system, security operators can detect applications operating without the user’s involvement or outside of a known path. GUI signatures also have the flexibility to allow operators to add more verbose signature paths based on information specific to an organization. Such extensions may include specific servers should be contacted when a user, for example, sends an email.
In this Chapter, we make the the following novel contributions:
• Introduction, motivation, and definition of GUI signatures and interaction paths.
• Discussion on how to build GUI signatures and an enforcement system on top of a modern operating system.
• A case study evaluation by detecting a ransomware application without a GUI and detecting a well-known text editor that has been compromised.
Figure 4.2: Our approach hooks into the Windows message passing system to determine what application objects exist and are being interacted with by the user and what network traffic the application generates in response. This information is sent to a local collector and stored at a collection server.