Patent Publication Number: US-10778722-B2

Title: Dynamic flow system

Description:
FEDERALLY SPONSORED RESEARCH 
     This invention was made with Government support under Contract No. FA8721-05-C-0002 awarded by the U.S. Air Force. The Government has certain rights in the invention. 
    
    
     FIELD 
     This disclosure relates to network communication and security and, more particularly, to dynamically controlling network communication and security. 
     BACKGROUND 
     OpenFlow is a communication protocol that provides access to the forwarding plane of a network switch or router over a network. It enables network controllers to determine the path of network packets across a network of switches. The controllers are distinct from the switches. This separation of the control from the forwarding allows for more sophisticated traffic management than is feasible using access control lists (ACLs) and routing protocols. Also, OpenFlow allows switches from different vendors—often each with their own proprietary interfaces and scripting languages—to be managed remotely using a single, open protocol. The protocol&#39;s inventors consider OpenFlow an enabler of software defined networking (SDN). 
     OpenFlow allows remote administration of a layer  2  switch&#39;s packet forwarding tables, by adding, modifying and removing packet matching rules and actions. This way, routing decisions can be made periodically or ad hoc by the controller and translated into rules and actions with a configurable lifespan, which are then deployed to a switch&#39;s flow table, leaving the actual forwarding of matched packets to the switch at wire speed for the duration of those rules. Packets which are unmatched by the switch can be forwarded to the controller. The controller can then decide to modify existing flow table rules on one or more switches or to deploy new rules, to prevent a structural flow of traffic between switch and controller. It could even decide to forward the traffic itself, provided that it has told the switch to forward entire packets instead of just their header. 
     The OpenFlow protocol is layered on top of the Transmission Control Protocol (TCP), and prescribes the use of Transport Layer Security (TLS). Controllers should listen on TCP port 6653 for switches that want to set up a connection. Earlier versions of the OpenFlow protocol unofficially used port 6633. 
     SUMMARY 
     In an embodiment, a system for communicating across a network comprises: a database containing one or more high level security rules for the network; a plurality of computing devices communicating on the network; a security rule translation module; a plurality of event sensors configured to monitor and detect one or more events occurring on or relating to the network, and in response thereto, provide to the security rule translation module an indication of occurrence for each of the one or more security events. In response to the security rule translation module receiving the indication of occurrence for each of the one or more security events from the event sensors, the security rule translation module may associate one or more of the security rules with the security events corresponding to the received indication, and produces a low-level security rule based on data from the high-level security rule and the received indication of occurrence of the security events. 
     The system may also include one or more switches coupled to receive the low-level security rules from the security rule translation module and enforce the low-level security rules on the network. 
     In another embodiment, a method for communicating across a network comprises: receiving one or more security network events by one or more network security sensors; translating, by one or more sensor event handler modules, the one or more security network events into network security statements, wherein the network security statements are high level security statements having a common format; receiving, by a policy resolver, the one or more security network statements and a current security state of the network that includes at least one identifier of a network device; translating, by the policy resolver, the one or more network security statements into low level security rule that incorporate the identifier of the network device; and modifying, by a policy enforcement kernel, one or more firewall tables of one or more network switches to include the low level security rules 
     In another embodiment, a system for communicating across a network comprises: a plurality of computing devices communicating on the network; a plurality of event sensors configured to monitor and detect security events occurring on the network; a database containing high level security rules for the network; a binding database containing data representing a current state of the network; a security rule translation module configured to receive the security events from the event sensors, associate one or more of the security rules with the received security events, receive a state of a network entity associated with the security rule from the binding database, and produce a low level security rule based on data from the high level security rule, the received security events, and the state of the network entity; and one or more switches coupled to receive the low level security rules from the security rule translation module and enforce the low level security rules on the network 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       The foregoing features may be more fully understood from the following description of the drawings. The drawings aid in explaining and understanding the disclosed technology. Since it is often impractical or impossible to illustrate and describe every possible embodiment, the provided figures depict one or more exemplary embodiments. Accordingly, the figures are not intended to limit the scope of the invention. Like reference numbers in the figures denote like elements. 
         FIG. 1  is a network diagram of a communication network. 
         FIG. 2  is an architecture diagram of a system for dynamically configuring network security. 
         FIG. 3  is a flow diagram of a process for transforming data. 
         FIG. 4  is a flow diagram of a process for transforming data. 
         FIG. 5  is a block diagram of a computing device. 
     
    
    
     DETAILED DESCRIPTION 
     Referring now to  FIG. 1 , a communication system  100  includes network devices  102   a - 102   f  that may communicate over a network provided from a plurality of signal paths such as communication link  104 . Network devices  102   a - 102   f  may be any type of device capable of communication over a computer network. Examples of network devices include, but are not limited to, computers, tablets, smart phones, printers, servers, wearable computing devices, etc. 
     Network devices  102   a - 102   f  may communicate with each other through communication links (such as communication link  104 , for example) to network switches  106  and  108 . Communication links (e.g. communication link  104 ) that allow network devices  102   a - 102   f  to communicate on the network may be wired or wireless connections, or any other type of communication link known in the art that allows for communication between computing devices. 
     In embodiments, network devices  102   a - 102   f  may communicate on a local-area network, a wide-area network, a cellular network, an internet, or on any scale of network appropriate for communication between computing devices. 
     System  100  may also include one or more servers  110  that may also communicate on the network. Although shown as a single server for ease of illustration, server  110  may comprise multiple servers in the same or different geographical locations. Server  110  may be any type of server including, but not limited to, a file server, a domain controller, a DHCP server, a print server, a database server, etc. 
     In an embodiment, system  100  also includes a so-called dynamic flow isolation (DFI) server  112 . Although shown and described as a single server for ease of illustration, DFI server  112  may also comprise multiple servers in the same or different geographical locations. Thus, in some embodiments, DFI server may be implemented as a distributed server. 
     DFI server  112  may be configured to create and implement security policies across the network. In an embodiment, DFI server  112  may implement the security policies by generating low-level security rules that can be programmed into switch  106  and/or  108 . 
     Network  100  also includes a binding database  114  to store a current security state of the network. The security state may be a snapshot of the current state of the network that can assist DFI server  112  in generating the low level rules. Data within binding database  114  may include, but is not limited to: logon events, logon status of users, MAC addresses, network addresses, host names, usernames, and network location (e.g. switch ID and port number). 
     The data within binding database  114  is dynamically updated as events on the network take place. For example, if server  110  records an event of a particular user logging into computing device  102   d , server  110  may transmit an indication of the event to binding database  114  such that the occurrence of the event can be recorded in the database. Binding database  114  may then store data describing the event and associate the particular user, their username, and their logon event with computing device  102   d . Binding database  114  may also associate the IP address of computing device  102   d , the MAC address of computing device  102   d , the type of network connection being used by computing device  102   d , the network location (e.g. the switch  108  and port number) to which computing device  102   d  is attached, the host name of computing device  102   d , the domain that the user logged into, or any other network information associated with the logon event. 
     One skilled in the art will recognize similar information can be recorded in binding database  114  for other types of events, including but not limited to, logoff events, communication events, printing events, etc. (Communication events may include any event where a computing device attempts to communicate with another computing device. These can include, but are not limited to: instant messages, email, logon/logoff validation, file sharing, printing, database queries, or any type of network communication.) Binding database  114  may be, for example, a relational database implemented by DFI server  112 , or any other type of database implemented by DFI server  112  or any computing device capable of providing database services. 
     In an embodiment, one or more of computing devices  102   a  may function as network sensors (e.g. execute program code such that the device may operate as one or more network sensors  116 ) and server  110  may execute program code to provide network sensors  118 . Network sensors  116  and  118  may be software modules (e.g. drivers, services, applications, or other executable software elements) that detect network security events, such as logon/logoff events, communication events, etc. 
     In an embodiment, DFI server  112  may execute sensor event handlers  120 , policy resolver  122 , and/or policy enforcement kernel  124 . Sensor event handlers  120 , policy resolver  122 , and policy enforcement kernel  124  may also be software modules. Sensor event handlers  120  may be configured to receive security events from network sensors  116  and  118  and convert the security events into high-level security statements. Policy resolver  122  may receive the security statements from sensor event handlers  120  and generate a low-level security rule that can be applied to switch  106  and/or  108 . And policy enforcement kernel  124  may be configured to receive the low-level security rules from policy resolver  122  and apply them to switch  106  and/or  108 . 
     One skilled in the art will recognize that system  100 , as depicted in  FIG. 1 , is provided as an example of a system that can implement a dynamic flow isolation. The system  100  depicted in  FIG. 1  shall not be construed as limiting—other network architectures can also implement a dynamic flow isolation. 
     Referring now to  FIG. 2 , a software architecture  200  for implementing a dynamic flow security scheme may be implemented by a system such as system  100 . Architecture  200  includes sensors  202 , which may be the same as or similar to sensors  116  and/or  118 . Sensor event handlers  204 , policy resolver  206 , and policy enforcement kernel  208  may be the same as or similar to sensor event handlers  120 , policy resolver  122 , and policy enforcement kernel  124 , respectively. 
     Sensors  202  may include one or more software-based sensor modules to detect network security events. An authentication event sensor  212 , an intrusion detection event sensor  214 , and an anti-virus event sensor  216  are shown, however other event sensors may also be included. 
     Sensors  202  may also include other sensors including, but not limited to: a physical location event sensor (e.g. network security may be controlled based upon the physical location of a user, which can be tracked with RFID cards, location off a computing device accessed by the user, or other types of personal identification associated with the user), a host-based monitoring system sensor (that may check compliance, etc.), a time of day sensor (to enable day/night shifts, etc.), a multi-factor authentication sensor (phone, SMS, etc.), a physical security sensor (fire alarm, etc.), an imaging sensor (e.g. video cameras), an audio sensor (e.g. microphones), or any other sensor that can collect information from network traffic or access to centrally managed systems. 
     Authentication event sensor  212  may include software that detects user domain logins, logouts, a user&#39;s use of a password-protected resource on the network, and other user authentication events. For example, authentication event sensor  212  may use a pulling scheme to poll the domain server to determine which users have logged in since the last polling event. Additionally or alternatively, use a push scheme to receive messages from, for example, the domain server when a logon event occurs. In this case, the domain server may be equipped with a service that sends logon events to authentication event sensor  212  as they occur. In yet another embodiment, logon events may be stored in binding database  210 . Authentication event sensor  212  may query binding database  210  to identify and process the logon events. In other instances, authentication event sensor  212  may populate binding database  210  with logon event data after authentication event sensor  212  detects a logon event on the network. 
     Intrusion detection sensor  214  may include software that detects attempts to access restricted system resources. These may include multiple login attempts with invalid passwords, access to a restricted file share, etc. As an example, intrusion detection sensor  214  may identify an intrusion if a user attempts, for instance, three or more logons with a different password each time. 
     In some embodiments, an intrusion detection sensor may report intrusion events to DFI server  112 . DFI server  112  can adjust network access based upon these intrusion events. For instance, it may adjust network connectivity on systems identified as infected by the intrusion detection sensor events. In embodiments, the emphasis of the DFI server may be less on the intrusion detection sensor itself and more on the fact that network security is dynamically adjusted in response to events received by an intrusion detection sensor. An example of an intrusion detection sensor is a system that inspects network packets and generates an event when the packet data contains a known malicious signature. 
     For example, intrusion detection sensor  214  may use a pulling scheme to poll one or more network servers to identify failed login attempts that match a network intrusion profile. Additionally or alternatively, use a push scheme to receive messages from, for example, the one or more servers when a potential intrusion is detected by the server. In this case, the server may be equipped with a service that identifies intrusion logon attempts and send information about the intrusion to intrusion detection sensor  214  as they occur. In yet another embodiment, logon events may be stored in binding database  210  and intrusion detection sensor  214  may query binding database  210  looking for logon events or resource accesses that match an intrusion profile. In other instances, intrusion detection sensor  214  may populate binding database  210  with detected intrusion data after intrusion detection sensor  214  detects an intrusion or an attempted intrusion on the network. 
     Antivirus sensor  216  may include software that detects antivirus events, such as a virus infiltrating the network, an email with an attached virus entering the network, or a computer that identifies and cleans or blocks a virus. For example, antivirus sensor  216  may use a pulling scheme to poll any computing device on the network to determine which, if any, computing devices have a virus or have detected a virus. Additionally or alternatively, antivirus sensor  216  may use a push scheme to receive messages from, for example, another computing device when a virus is detected by the computing device. In this case, the domain server may be equipped with a service that sends virus event information to antivirus sensor  216  as they occur. In yet another embodiment, virus events may be stored in binding database  210 . Antivirus sensor  216  may query binding database  210  to identify and process any virus events that have been recorded in the database. In other instances, antivirus sensor  216  may populate binding database  210  with antivirus event data after antivirus sensor  216  detects or receives information about a virus event on the network. 
     The sensor event handlers  204  may include an authentication policy handler  218 , an intrusion policy handler  220 , and an antivirus policy handler  222 . Each policy handler  218 - 222  may receive data from a respective sensor  212 - 216  according to a data format or Application Programming Interface (API) specific to its type. For example, authentication event sensor  212  may communicate with authentication policy sensor  218  with a different data format or API than that used by intrusion detection sensor  214  and intrusion detection policy handler  220 . 
     Each of the sensor event handlers may contain a set of high level security rules, and may produce one or more high-level security statements that dictate, based on the high-level security rules, whether the event should be allowed, denied, limited, etc., and whether network connectivity should be adjusted. For example, one security rule may specify that user A is allowed to communicate with computing devices  102   a ,  102   b , or  102   c , but not communicate with computing devices  102   d - 102   f  (see  FIG. 1 ). If user A logs into computing device  102   a , authentication event sensor  212  may detect the login attempt and forward data describing the login attempt to authentication policy handler  218 . Authentication policy handler  218  may then apply the rule regarding user A, determine that user A on device  102   a  may communicate with devices  102   b  and  102   c , and provide a high-level security statement stating that these communication paths are allowed. 
     In embodiments, high-level rules may encompass entities (users, devices, etc.) that do not yet exist. A simple policy could be, for example, that user A may communicate (via the network) with user B and server  110 . When user A logs into a device such as  102   a , the authentication sensor event handler might issue a high-level rule that user A on device  102   a  may communicate (ALLOW) with user B (who may not yet be in the network) and server  110 . The specific communication paths need not be specified at this level. 
     Suppose device  102   c  reports a virus infection to the anti-virus sensor  216 . An example high level rule issued by an anti-virus sensor event handler may specify that device  102   c  may not communicate (DENY) with devices  102   a - f  (excepting itself). In addition, device  102   c  may communicate with servers  110  no faster than 0.5 Mbps (LIMIT). 
     An example of a high-level rule using a particular API syntax (but not limited to that syntax) is as follows: ((“device”: “ 102   c ”), (“device”: “ 102   a ”), (“action”: “deny”)). This rule denies all communication from device  102   c  to  102   a . Rules may also be defined over users instead of devices, as well as any other high-level identifier that can be linked to low-level network identifiers. 
     Many such rules may be implemented or supported by the system  200 . The above examples do not limit the types of high-level rules nor do they limit the uses of any types of high level rules. 
     The high-level security rules implemented by system  200  may be stored in a policy database (not shown). The database may be dynamically updated as rules are removed and added by sensor event handlers  204 . 
     The policy handlers  218 - 222  may also access information from binding database  210  in order to produce high level security statements. For example, a security rule may specify that user B can log into only one computing device  102   a - 102   f  at a time. Assume that user B is logged into computing device  102   a  and attempts to also log into computing device  102   b . Binding database  210  may include a record indicating that user B is logged into computing device  102   a . When authentication policy handler  218  receives notification from authentication event sensor  212  that user B is attempting to log into computing device  102   b , authentication policy handler  218  may access binding database  210  to determine if user B is already logged into another computing device. In this example, authentication policy handler  218  may determine, based on the record in binding database  210 , that user B is already logged into computing device  102   a  and issue a high level security statement indicating that user B&#39;s login attempt to computing device  102   b  should be denied. 
     One example may arise when an intrusion detection sensor detects an intrusion but at a low confidence level. In this case the bandwidth for the suspicious systems could be limited until the systems are further investigated. More generally, bandwidth may be limited in any circumstance in which the evidence is insufficient to justify a full block, or in which a full block could impede mission-critical functionality, and yet is suspicious. It can also be restricted when it is known that bandwidth will not exceed a certain amount if used only in the authorized manner. 
     As an example of an intrusion detection policy, intrusion detection policy handler  220  may contain a rule that, if three or more login attempts fail from a particular external Internet Protocol (IP) address, that the external IP address should be blocked from further access. In the event that intrusion detection sensor  214  detects three failed login attempts from IP address 168.192.1.2, intrusion detection policy handler  220  may issue a high-level security statement that login attempts from that IP address should be blocked. Other rules may include preventing or allowing login attempts from certain geographical areas, preventing or allowing login attempts at certain times of day, etc. 
     As another example, an intrusion detection sensor may generate an event indicating that an intrusion has been detected on a network segment. The intrusion detection policy handler may issue a high-level security statement indicating that the connectivity for this network segment should be adjusted such that systems on the suspicious segment may only reach honeypot systems, or that full network packet capture should be enabled on the triggered systems. 
     As an example of an antivirus policy, antivirus policy handler  222  may contain a rule that emails originating from external sources and containing a certain type of attachment (e.g. a zip file) should be blocked. Assume that antivirus sensor  216  detects that a mail server has received an external email with a zip attachment and sends information about the event to antivirus policy handler  222 . Antivirus policy handler  222  may issue a high-level security statement that the email should be blocked. Other rules may include preventing or allowing transmissions from certain geographical areas, preventing or allowing execution of certain file types, etc. 
     In some embodiments, an antivirus sensor may detect that a system has executed a known malicious program and may send an event to the antivirus policy handler indicating that the system is compromised. The antivirus policy handler may subsequently issue a high-level security statement indicating that the network connectivity be adjusted such that this system can only access limited number of systems required for remediation. 
     In an embodiment, one or more of the policy handlers  218 - 222  may be given a priority value. The priority may specify which high level rules should be implemented first, or take precedence over potentially conflicting rules. As an example, antivirus policy handler  222  and the high level rules it produces may be given a higher priority than authentication policy handler  218  and the high level rules it produces. 
     System  200  may also include policy resolver  206 , which may receive the high level rules from policy handlers  218 - 222  and produce a low level rule that can be implemented in a router or firewall table. Policy resolver  206  may parse the high level rule and translate it into low level code that can be executed by a firewall. For example, a high level rule that states that logon attempts from a particular geographical area should be blocked may be translated into: DENY XXX.XXX.XXX, where XXX.XXX.XXX.XXX is an IP subnet corresponding to the geographical area. One skilled in the art will recognize that IP is used as an example and other network protocols may be used. 
     Policy resolver may also use the priorities associated with the high level rules to resolve conflicting high level rules received from policy handlers  218 - 222 . Building upon the antivirus/authentication examples from above, a higher priority antivirus policy may be applied before the lower priority authentication policy but the authentication policy may be applied once the conflicting antivirus policy is removed (e.g. the antivirus scan reported no infections on the system). Rules may be applied in blocks of priority level, such that all rules of priority  1  appear before all rules of priority  2 . As such, a conflict may be resolved by using the first matching rule. This example scheme allows a lower priority rule to be triggered if all conflicting rules of higher priority are removed. 
     One example of a rule conflict could arise in the following scenario. User B is logged into device  102   b . User A logs into device  102   a , which is infected with a virus. The authentication policy  218  may issue a rule at low priority that allows user A to communicate with user B. However, the anti-virus policy  222  may issue a rule at high priority that blocks device  102   a  from all communications. When user A on device  102   a  tries to communicate with user B on device  102   b , the higher priority rule is used to block that communication. At some later time, device  102   a  is cleaned, and the anti-virus handler  222  now revokes the previous rule. Now the lower priority rule allows user A on device  102   a  to communicate with user B on device  102   b.    
     One skilled in the art will recognize that other priority resolution schemes exist and may be used in place of, or in addition to, the exemplified scheme. 
     The low level rules from policy resolver  206  may be received by policy enforcement kernel  208 , which may program the rules into firewall table  224 , where they can be implemented by a firewall. 
     In an embodiment, system  200  may include an OpenFlow controller system  226  having one or more OpenFlow applications  228 . One skilled in the art will recognize that OpenFlow controller system  226  may comprise one or more controllers that determine the path of data packets through the network. The OpenFlow controllers may comprise (or receive data from) OpenFlow applications  228  and subsequently program router tables or firewall tables in response to the determined path of data packets. In certain instances, OpenFlow controller system  226  may attempt to program firewall table  224  with instructions that conflict with those generated by dynamic flow system  200 . In this case, policy enforcement kernel  208  may determine which instructions should be programmed into firewall table  224 . 
     In one embodiment, policy enforcement kernel  208  may program firewall table  224  so that any instructions provided by policy resolver  206  override or take precedence over any instructions provided by OpenFlow controller  226 . Those instructions provided by OpenFlow controller  226  may be programmed into forwarding table  226  by policy enforcement kernel  208 , for example. In another embodiment, policy enforcement kernel  208  may program firewall table  224  with instructions provided by both OpenFlow controller  226  and policy resolver  206 , but may check the instructions for any conflicting instructions. In this case, policy enforcement kernel  208  may drop any conflicting instructions provided by OpenFlow controller  226  and instead program firewall table  224  with the instruction provided by policy resolver  206 . In yet another embodiment, policy enforcement kernel  208  may drop some or all instructions provided by OpenFlow controller  226  and program only instructions from policy resolver  206  into firewall table  224 . One skilled in the art will recognize that policy enforcement kernel  208  may be configured to enforce any policy regarding conflicting instructions provided by OpenFlow controller  226  and policy resolver  206 . However, in certain embodiments, it may be preferable for policy enforcement kernel  208  to enforce a policy that gives precedence to the instructions provided by policy resolver  206 . 
     Once firewall table  224  (and/or forwarding table  226 ) is programmed with instructions from policy resolver  206 , system  200  may route traffic through the network according to the instructions generated by dynamic flow system  200 . As noted above, the instructions generated by dynamic flow system  200  may include instructions dynamically generated in response to events that are detected by sensors  202  and/or by the current state of the network as captured in binding database  210 . 
     Dynamic flow system  200  may also include a control interface  228 , which may comprise a user interface through which a user may monitor and/or change events, rule generation, routing policies, and other elements described above. 
     Referring to  FIG. 3 , a flowchart illustrates a process  301  for generating security rules in a dynamic flow system, such as dynamic flow system  200 . In box  300 , sensors  202  may wait for (or poll for) a sensor event, such as an authentication event, an intrusion event, an anti-virus event, etc. If a sensor event is received in decision box  302 , sensor event handlers  204  may determine the type of event (such as an authentication event, an intrusion event, an anti-virus event, etc.) in box  304 . If no event is received in decision box  302 , the system may continue to wait for a sensor event in box  304 . 
     In box  306 , sensor event handlers  204  may generate a policy update (e.g. generate high level commands) based on the received event and any relevant information stored in a policy database  308 . The policy database  308  may be a database storing all currently implemented high level commands produced by sensor event handlers  204 . 
     In embodiments, sensor-specific policy database  308  may store all possible policies that this event handler may generate. For example, an authentication sensor policy database may include a list of all users and their access control lists (ACL) that defines which entities that user may communicate with. The following pseudo-code provides an example of one such policy database:
         Entity→ACL [(entity, rule), . . . ]   User A→[(user B, allow), (user C, block)]   Device  102   a →[(server  110 , limit 1 Mbps)]       

     One skilled in the art will recognize that this database format may take many different forms based on the type of sensor, the type of sensed event, etc. 
     In decision box  310 , system  310  may determine if any previously existing rules (i.e. high-level commands) conflict with the newly created high-level commands in box  306  and need to be removed from the current rule set. If so, system  312  may retrieve the rule ID (which may be a unique identifier) in box  312 , and send a drop message to policy resolver  206  in box  314 . The drop message may instruct policy resolver  314  to drop the rule (e.g. the high level command and/or low level instruction) from the current rule set. The drop message may be issued by combining the DROP function with the previously received rule ID, as shown in box  316 . 
     If an existing rule does not need to be removed in decision box  310 , process  301  may advance to decision box  318  to determine if a new rule should be added. If the rule is the same as another rule that is already implemented, the system does not need to add a new rule and can advance to box  330  to wait for the next sensor event. However, if the current rule is not already implemented, the system may proceed to box  320  where the sensor event handlers may send the rule (e.g. the high level command) to policy resolver  206 . The new rule may be issued to policy resolver  206  by issuing an ALLOW, DENY, and/or RATE LIMIT rule according to box  322 . Other high-level rules may be supported by the system. 
     In box  324 , policy resolver  206  may produce an ID for the newly created rule. The system may retrieve the ID and, in box  326 , record the rule ID in the current rule database  328 . 
     The system may then proceed to box  330  where it waits for the next event from sensors  202 . When the next event is received, the system may again proceed to box  304 . 
     Referring now to  FIG. 4 , a flowchart illustrates a process  400  for updating a global policy table with rules generated by a dynamic flow system, such as system  200 . In box  402 , policy resolver  206  waits for a message (e.g. a high level command) received from one or more of the sensor event handlers  204 . In decision box  408 , policy resolver  206  determines if the high level command corresponds to a DROP message. If so, in box  404 , policy resolver  206  issues an OpenFlow OFPFC_DELETE command to policy enforcement kernel  208 , which in turn deletes the low level rule from the global policy table (e.g. from firewall table  224 ) in box  406 . Policy resolver  206  then waits for the next message from event handlers  204  in box  440  and begins the process  400  again. 
     In decision box  408 , if policy resolver  206  determines the high level command does not correspond to a DROP message, the process generates a new rule ID (which may be a unique identifier) in box  410 , and adds the rule and the newly created ID to the global policy table (not shown) in box  412  that is accessible by sensor event handlers  204 . 
     In box  416 , policy resolver  206  identifies any high-level principals associated with the rule. These principals may be hostnames, usernames, MAC addresses, IP addresses, or any other identifier. Policy resolver  206  may query binding database  210  for any existing principals that may be stored there. For example, if the high-level rule being processed states that User A can only communicate with computing device  102   a , then policy resolver may identify principals such as User A&#39;s username and/or computing device  102   a &#39;s IP address, MAC address, hostname, etc. 
     In box  420 , the system may generate an action list for flow rules. In general, each rule may be a multi-part that comprises one or more actions such as ALLOW, DENY, RATE, etc. The action list is a list or array of such actions that may be associated with the high level rule. For example, consider a high level rule that says port 22 on server X can be accessed from LAN addresses only, but User A can access port 22 from any location. Such a high level rule may be implemented by a series of rules. The first in the series may be an ALLOW rule that allows traffic from the machine on which User A is logged on to access port 22, and the second in the series may be a DENY rule that denies access to port 22 from any location outside the LAN. 
     In decision box  422 , if the high level rule comprises an ALLOW message, policy resolver may set an action to output in box  424 . 
     In box  424 , the action field of the OpenFlow message may be set to ‘output.’ In other words, an OpenFlow action may be set, where “output” indicates that the switch should output the matching packet as instructed by the action. In embodiments, a table ID or switch port to which the packet is to be output may be included. 
     In decision box  426 , if the high-level rule comprises a DROP message, policy resolver may set an action to drop in box  428 . And in decision box  430 , if the high level rule comprises a RATE message, policy resolver may set an action to (output, meter) in box  432 . 
     After setting the action in boxes  424 ,  428 , and/or  432 , policy resolver  206  may use low-level identifiers to generate an OpenFlow header with matching fields in box  434 . For example, if the high level rule being processed states that User A can only log in to computing device  102   a , then policy resolver  206  may identify low-level identifiers (e.g. from binding database  210 ) such as User A&#39;s username and/or computing device  102   a &#39;s IP address, MAC address, hostname, etc. These low-level identifiers may be combined into a low level rule along with the actions identified in boxes  424 ,  428 , and  432 . 
     In box  436 , policy resolver  206  may issue (e.g. emit) the low level rule to policy enforcement kernel  208  via an emit statement in box  438 . Policy enforcement kernel  208  may subsequently program the low level rule into firewall table  224  as described above. The process may then proceed to box  440  where it waits for another message from event handlers  204  to begin the process anew. 
     Some or all of the features and processes described above may be implemented by programmable code (such as software, firmware, scripts, etc.) executed by a computing device.  FIG. 5  shows an exemplary computing system  500  that can execute software. System  500  includes a processor  502  (which may be the same as or similar to processor  110 ), a random access memory (RAM)  504 , and a storage device  506 , which may be a hard drive, a CD, a DVD, a flash drive, or any other type of non-volatile memory. Software instructions may be stored in RAM  504  and/or storage device  506 . Processor  502  may be coupled to storage device  506  and/or RAM  504  so that processor  502  can read the software instructions. As processor  502  reads the software instructions, the software instructions may cause processor  502  to perform operations, as described above, for computing the position of a magnetic target. Although not shown, processor  502  and/or system  500  may include other inputs and outputs, such as inputs for receiving the signals from the sensing elements, GPIO, power inputs, or other interfaces such as USB, SATA, HDMI, and the like. 
     Having described preferred embodiments, which serve to illustrate various concepts, structures and techniques, which are the subject of this patent, it will now become apparent to those of ordinary skill in the art that other embodiments incorporating these concepts, structures and techniques may be used. Accordingly, it is submitted that that scope of the patent should not be limited to the described embodiments but rather should be limited only by the spirit and scope of the following claims. All references cited herein are hereby incorporated herein by reference in their entirety.