Patent Publication Number: US-8984620-B2

Title: Identity and policy-based network security and management system and method

Description:
CROSS REFERENCE TO RELATED APPLICATIONS 
     This application is a U.S. National Stage Application of PCT International Application No. PCT/IN2007/00359, titled “Identity and Policy-Based Network Security System and Method”, filed Aug. 21, 2007, which in turn claims the benefit of Indian Patent Application Number 1299/Mum/2007, filed Jul. 6, 2007. PCT International Application No. PCT/IN2007/00359 and Indian Patent Application Number 1299/Mum/2007 are hereby incorporated herein by reference. 
     FIELD OF THE INVENTION 
     The present invention relates generally to a method and system for managing a network connection, and specifically for conducting an identity-based and policy/rules-based analysis of one or more packets sent over a connection in the network to provide increased security and optimize computing resources. 
     BACKGROUND OF THE INVENTION 
     In conventional network environments, firewalls have played an increasingly important role in protecting resources residing on a private network, while allowing communication with and access to systems located on an unprotected network, such as, for example, the Internet. The firewall acts as a gatekeeper, configured to prevent attacks on a private network deriving from the unprotected network by providing a single connection with limited services. 
     In this regard, the firewall is able to secure a private network by allowing the network administrator to develop and implement a particular security policy. Some conventional firewalls are configured to implement access rules which are based on the association of the source IP address and the destination IP address. While this approach is effective for a static network environment, it is not effective for systems including conventional dynamic addressing, such as, for example, a Dynamic Host Configuration Protocol (DHCP) or a wi-fi network environment. In a typical dynamic IP environment, the user&#39;s information is not available on the LAN side, and, as such, no user-specific rules or decisions can be implemented. 
     Network Address Translation (NAT) firewalls have been developed to provide for the mapping of port numbers to allow multiple machines to share a single IP address. NAT is also used to provide mapping of private and public IP addresses. One can not have a pool of public IP addresses to be used for NAT whereby a single user or a group of users can be NATed by a specific IP address so as to identify themselves uniquely to an external server. 
     Furthermore, a conventional firewall is not able to identify a user. Even those firewalls which are adapted to include an authentication of the user are limited in that they are unable to apply user-specific rules to perform NATing. According to these systems, the user&#39;s identity is not part of the rule matching criteria considered by the firewall. 
     Accordingly, there is a need in the art for a method and system for a more robust network security system capable of considering a user&#39;s identity as part of the firewall rule matching criteria. 
     SUMMARY OF THE INVENTION 
     The above-described problems are addressed and a technical solution is achieved in the art by a system and a method for managing and securing a network. According to an embodiment of the present invention, the network security system and method comprise a firewall wherein the user&#39;s identity and user-specific policies are combined to provide enhanced network security and resource optimization. 
     According to an embodiment of the present invention, a method and system is provided for managing a network connection between a source and a destination for the transmission of at least one data packet. According to the present invention, a login request comprising a user IP address, and login credentials is received from a user. Based on the login credentials, the user is authenticated. Following authentication, a profile associated with the authenticated user is identified. The profile is specific to the user and comprises user data and one or more user-specific security and management policies. 
     According to an embodiment of the present invention, the system determines if the user is authorized to login. To determine whether the login request is authorized, the system applies the at least one user-specific policy of the identified profile. For example, to determine if the login request is authorized, the system may apply an access time policy and/or quota policy. If the login request is in compliance with the at least one user-specific policy, then the login request is authorized. 
     Next, a record including identity information related to the authorized user is created and stored, wherein the identity information comprises the profile and the user IP address. The identity information creates an association between the user and the one or more user IP addresses associated with that user. 
     The system is configured to receive a data communication from a source intended for a destination. The data communication includes one or more data packet, with each packet comprising a source IP address and a destination IP address. The system is configured to identify and apply the user-specific policy associated with the user. 
     According to an embodiment of the present invention, the system creates a connection object associated with the connection based at least on the source IP address and a destination IP address. The connection object is then associated with the at least one packet. 
     Based on the source IP address, the system identifies the identity information associated with the authorized user. Next, the connection object is updated with the identified identity information and a connection is established based on the information and policies included in the updated connection object. In this regard, the connection is secured and managed according to the user-specific policy associated with the user. 
    
    
     
       BRIEF DESCRIPTION OP THE DRAWINGS 
       The present invention will be more readily understood from the detailed description of preferred embodiments presented below considered in conjunction with the attached drawings, of which: 
         FIG. 1  illustrates an exemplary Network Management System, according to an embodiment of the present invention; 
         FIG. 2  illustrates an exemplary process flow of the operation of a User Creation Module of a Network Management System, according to an embodiment of the present invention; 
         FIG. 3  illustrates a process flow of an exemplary Network Management System, according to an embodiment of the present invention; 
         FIG. 4  illustrates an exemplary Firewall Module, according to an embodiment of the present invention; and 
         FIG. 5  illustrates a process flow of an exemplary Management Module, according to an embodiment of the present invention. 
     
    
    
     It is to be understood that these figures are for purposes of illustrating the concepts of the invention and may not be to scale. 
     DETAILED DESCRIPTION OF THE INVENTION 
       FIG. 1  depicts a Network Management System  10  according to embodiments of the present invention. It is to be understood that the schematic representation of the Network Management System  10  provided in  FIG. 1  is exemplary in nature and alternative arrangements are within the scope of the present invention. 
     According to an embodiment of the present invention, the Network Management System  10  is a computer-based security system, accessible by one or more communicatively connected user computers or “sources” seeking to establish a connection and transmit and/or receive data to and from a computer-based resource, herein referred to as a “destination”. The term “computer” is intended to include any data processing device, such as a desktop computer, a laptop computer, a mainframe computer, a personal digital assistant, a server, or any other device able to process data. The term “communicatively connected” is intended to include any type of connection, whether wired or wireless, in which data may be communicated. The term “communicatively connected” is intended to include a connection between devices and/or programs within a single computer or between devices and/or programs on separate computers. 
     According to an embodiment of the present invention, the Network Management System  10  and related methods described herein comprises a User Creation Module  20 , a User Database  25 , a Login Module  30 , a User IP Map  40 , a Connection Tracker  50 , a Firewall Module  60 , and a Management Module  70 , configured to manage and secure the connection between the User Computer  1 , or source, and a destination (identified as Destination  80  in  FIG. 1 ), wherein information specific to an identity of the user sending the one or more packets to the Destination  80  is used as part of the network and firewall traversal criteria. Furthermore, the Network Management System  10  is configured to consider and implement a number of additional user-specific policies governing the use and traversal of the connection. 
     One having ordinary skill in the art will appreciate that the components of the Network Management System  10  may be located on a single computer, as schematically illustrated in  FIG. 1 , or on more than one communicatively connected computers. The Network Management System  10  and the components thereof perform a number of functions, as described in detail below, which may be executed, implemented, supervised, monitored, and/or managed by a computer (i.e., hardware and/or software), one or more persons, or a combination of both. 
     A user or source may access the Network Management System  10  using a computer, herein referred to as a User Computer  1 . According to an embodiment of the present invention, the User Computer  1  may include, but is not limited to, a Web browser that provides a portal to one or more Web-based networks (e.g., the Internet) or an executable or binary program that provides an interface to the user and is connectable to a remote Authentication Server  35  and/or the Login Module  30 . One having ordinary skill in the art will appreciate that any suitable Web browser may be used in accordance with the present invention, including but not limited to FireFox, Microsoft® Internet Explorer, Netscape, Opera, WebTV®, and Mozilla™. 
     For each user that is permitted to interact with and traverse the Network Management System  10  a “profile” is created and stored, thereby registering the user with the system. According to an embodiment of the present invention, one or more persons responsible for managing, updating, editing, or controlling the Network Management System  10 , herein referred to as an Administrator  5 , creates the profile for each user using the User Creation Module  20 , according to the user creation processes illustrated in  FIG. 2 . 
     As shown in  FIG. 2 , the Administrator  5  may create the “profile” for the user via an interface to the User Creation Module  20  by entering information that identifies the user, herein referred to as “user data.” The user data may comprise any information that is suitable to identify a user, including, but not limited to, the user&#39;s name, username, and password. The profile further comprises one or more pre-set rules, policies, limitations, permissions, parameters, authorizations, or restrictions which are specific to the user, herein collectively referred to as a “user-specific policy.” The term “user-specific policy” may include any number of policies (e.g., restrictions, rules, permissions, authorizations, limitations, and/or parameters) related to the user&#39;s use of the network. The user-specific policy may include, but is not limited to, login restrictions, access time policies/restrictions, group identification information, upload data transfer limits/parameters, download data limits/parameters, an Application Security Policy such as an Internet access Policy, quota policy, access time policy, anti-virus scanning policy, logging policy, bandwidth classes, Intrusion Detection and Prevention (IDP) Policy, route information or policy, upload and download data transfer limits, etc. 
     As used herein, the term “Application Security Policy” is intended to include, but is not limited to, a rule or policy related to the control of application layer capabilities based on information related to one or more application protocols. 
     As used herein, the term “Internet access policy” is intended to include, but is not limited to, a rule or policy related to the control of access to a Wide Area Network (WAN) from a Local Area Network (LAN). 
     As used herein, the term “quota policy” is intended to include, but is not limited to, a rule or policy that governs the amount of time (i.e., the limit or quota) that a user is permitted to access and/or surf the WAN or the Internet. 
     As used herein, the term “access time policy” is intended to include, but is not limited to, a rule or policy that governs the amount of time and timing of when a user is permitted to access and/or surf the WAN or the Internet. 
     As used herein, the term “anti-virus scanning policy” is intended to include, but is not limited to, a policy that governs whether the specific traffic should be scanned for a virus or not. 
     As used herein, the term “routing policy” is intended to include, but is not limited to, a policy that governs the manner in which a packet should be routed. 
     As used herein, the term “logging policy” is intended to include, but is not limited to, a policy that governs whether a packet, connection and/or relevant policy/rule information should be logged or not. 
     The profile (or user profile) comprising the user data and the user-specific policy is created and stored in the User Database  25 . 
     According to an embodiment of the present invention, the Administrator  5  may employ an automated utility configured to extract and copy user data from an existing legacy systems or conventional user databases and store such user data in the User Database  25 . Exemplary legacy systems and/or user databases from which the automated utility may extract user data include, but are not limited to, a Lightweight Directory Access Protocol (LDAP) server, a Radius server, a Windows Active Directory, and a Windows Domain Controller. 
     Prior to interacting with the network, the user logs on to the Network Management System  10 , as illustrated in  FIG. 3 . As shown in  FIG. 3 , the User Computer  1  communicatively connects to the Login Module  30 , a computer-based module configured to receive all login requests and authenticate the users, and is prompted to provide login credentials in order to gain access to the Network Management System  10 . The login credentials may include any information suitable for identifying the user, including, but not limited to one or more of the following: a username, password, IP address, and hardware address. The logon process may be conducted in accordance with any suitable sign on protocol known in the art, including, but not limited to a HTTP protocol, Single Sign-On (SSO) protocol, or other proprietary protocol. 
     According to an embodiment of the present invention, the Login Module  30  is configured to authenticate the User Computer  1  by checking the login credentials against the one or more user profiles stored in the User Database  25 . In this regard, the Login Module  30  searches the User Database  25  to determine if there is a profile stored therein that includes user data which corresponds to the login credentials presented by the User Computer  1 . 
     Optionally, the Login Module  30  may be communicatively connected to an Authentication Server  35 . According to this option, the Login Module  30  is configured to send an authentication request to the Authentication Server  35  for processing, and, in response, the Authentication Server  35  returns an authentication reply indicating whether the user has been authenticated. The Authentication Server  35  is a computer-based module configured to perform authentication services, and may be any suitable authentication means known to those having ordinary skill in the art, such as, for example, an Active Directory, a Windows Domain Controller, a LDAP Server, or a Radius Server. One having ordinary skill in the art will appreciate that the Authentication Server  35  may reside within the Network Management System  10  or may be a separate component accessible by the Network Management System  10 , as denoted by the dashed line in  FIG. 1 . 
     If the user is not authenticated (i.e., the authentication is not successful), the Login Module  30  sends a message indicating same to the User Computer  1 . 
     If the user is authenticated, the Login Module  30  next determines if the user is authorized to perform the login request by comparing the login credentials with the user-specific policy associated with the particular user&#39;s profile stored in the User Database  25 . To determine if the login request is authorized, the system may apply the appropriate user-specific policy, such as, for example, the access time policy and/or the quota policy. If the login request is compliant with and conforms to all of the applied user-specific policies, the user is authorized, and the Login Module  30  sends the profile (i.e., the user data and user-specific policy) and the user&#39;s IP address to the communicatively connected User IP Map  40 . The profile data (i.e., the user data and user-specific policy) and the user&#39;s IP address are associated with one another and stored as the user&#39;s “identity information” in the User IP Map  40 . The identity information comprises the profile data (i.e., the user data and user-specific policy) and the user IP address. 
     Once the user is authenticated and the associated login request is authorized, the Network Management System  10  may process one or more packets via a connection between a source (User Computer  1 ) and a Destination  80 . As shown in  FIGS. 1 and 3 , the Network Management System  10  receives a packet from a source and submits the packet to the Connection Tracker  50 . One having ordinary skill in the art will appreciate that any suitable input driver may be used to receive the packet, in accordance with the present invention. For illustration purposes, the process flow depicted in  FIG. 3  shows a packet as is it processed by the Network Management System  10 . As shown in  FIG. 3 , the packet includes the source IP address, the destination IP address, transport layer information, and may optionally include application layer data. 
     The Connection Tracker  50 , a computer-based module configures to track each connection between a user and a destination, checks each packet received from the source to determine if the packet belongs to an existing connection. To do so, the Connection Tracker  50  checks the communicatively connected Connection Database  55 , a database configured to store information related to each connection. According to an embodiment of the present invention, the connection information, herein referred to as a “connection object” includes, but is not limited to a request tuple (i.e., information related to the source and destination available to the source) and a reply tuple (i.e., information related to the source and destination available to the destination), and is stored in the Connection Database  55 , preferably when the first packet (i.e., the synchronizing packet) of the connection between the source and destination arrives. Each connection object stored in the Connection Database  55  is represented by an address, herein referred to as the “connection reference.” 
     As each packet enters, the Connection Tracker  50  reviews the source and destination address data, and based on this data, retrieves the associated connection object from the Connection Database  55 . If the packet belongs to an existing connection (i.e., there is an existing connection reference and object related to the source address and destination address associated with the packet), the Connection Tracker  50  retrieves the connection object and updates the packet data structure with connection reference associated with the connection object. As such, each connection managed by the Connection Tracker  50  is assigned a unique connection reference which may be added to packets related to that particular connection. 
     If the packet does not belong to an existing connection, the Connection Tracker  50  creates a connection object (including the request tuple and reply tuple). In addition, the Connection Tracker  50  creates an associated connection reference related to the connection object, and stores the connection reference in the Connection Database  55 . As shown in  FIG. 3 , the packet, as updated with the connection reference, includes, but is not limited to, the source IP address, the destination IP address, the transport layer information and the connection reference. 
     Next, using the source IP address, the Connection Tracker  50  accesses the communicatively connected User IP Map  40  to look up and identify the appropriate identity information. To do so, the Connection Tracker  50  locates the IP address in the plurality of identity information records that matches the source IP address, and retrieves the associated identity information. As described above, at the time the user is authenticated, the user and source IP address have been associated or mapped to one another in the User IP Map  40 . As such, using the source IP address, the Connection Tracker  50  is able to identify the appropriate identity information. 
     The Connection Tracker  50  then updates the connection object with the portion of the user-specific policy which relates to the connection (e.g., an application security policy, IDP, the upload data transfer limit, and route information/policy). Further, the Connection Tracker  50  updates the packet with the portion of the user-specific policy which relates to the packet (e.g., the bandwidth class information). Accordingly, as the source (e.g., User Computer  1 ) transmits packets of data to the Destination  80  via the Network Management System  10 , each packet is associated with and governed by the particular user&#39;s user-specific policy. 
     The Connection Tracker  50  comprises a zone lookup sub-module is configured to use the inbound interface (interface with the source) and outbound interface (interface with the destination) to determine the appropriate source and destination zones. According to an embodiment of the present invention, the zone lookup sub-module uses the interfaces to zone mapping information provided by the administrator during creation of the user. 
     Advantageously, the packet and connection may be managed by the user-specific policy comprised within the identity information. In addition, the user identity information may further be used as part of the firewall traversal criteria, as described in detail below with reference to  FIG. 4 . 
     According to an embodiment of the present invention, the Connection Tracker  50  passes the updated connection object including the request tuple, reply tuple, user-specific policy, and source and destination zone information to the communicatively connected Firewall Module  60 . 
       FIG. 4  illustrates an exemplary process flow of the operation and function of the Firewall Module  60 , according to an embodiment of the present invention. First, the Firewall Module  60  retrieves the firewall rule and updates the connection object with the firewall rule information. The firewall rule may include, but is not limited to, the firewall rule identifying information, the related firewall action (e.g., drop/reject or accept), a logging policy, and a scanning policy. According to an embodiment of the present invention, the firewall rules may be stored in a database which is communicatively connected to the Firewall Module  60 . Optionally, policy information associated with the firewall rule may be maintained in the firewall store. This policy information is herein referred to as the “override policy information” because it may be used to override or overwrite one or more of the user-specific policies. 
     The Firewall Module  60  determines the appropriate firewall rule to associate with the connection object by applying the “rule matching criteria,” according to any suitable search method known to those having ordinary skill in the art, such as, for example, a sequential searching method. As used herein, the term “rule matching criteria” is intended to include, but is not limited to, the Mac address, the source zone, the destination zone, source IP address, destination IP address, user identity, service data, Transport layer information, and schedule information. 
     The Firewall Module  60  examines the connection object (and information contained therein) received from the Connection Tracker  50  and applies the rules matching criteria to determine the applicable firewall rule. Next, the Firewall Module  60  updates the connection object with at least a portion of the firewall rule which relates to the connection. As noted above, optionally, the Firewall Module  60  may update the connection object with policy information retrieved from the firewall store, wherein the policy information is applied to override or overwrite one or more of the user-specific policies. In the example shown in  FIG. 4 , the connection object is updated to include the firewall rule identifying information, the firewall action, the override policy information, the logging policy and the scanning policy. 
     According to an embodiment of the present invention, the Firewall Module  60  also updates the packet data structure with route information which it retrieves from the connection object. Next, the Firewall Module  60  retrieves the firewall action (i.e., drop/reject or accept) from the connection object. If the firewall action is ‘drop/reject,’ the Firewall Module  60  then determines if the action is ‘drop.’ If so, the Firewall Module  60  determines if the packet drop is to be logged. If so, the Firewall Module  60  logs the packet, and then drops it. If logging is not to be performed, the packet is dropped. 
     If the firewall action is ‘accept,’ the Firewall Module  60  passes the packet to the Management Module  70 . The Management Module  70  is a computer-based module configured to perform the steps illustrated in  FIG. 5  for all packets having an ‘accept’ firewall action, according to an embodiment of the present invention. According to an embodiment of the present invention, the Management Module  70  is configured to implement the one or more management policies associated with the connection object and packet. As used herein, the term management policy or policies is intended to include, but is not limited to the user-specific policy and the firewall rule related to the associated with a given connection object and the one or more packets governed by the connection object. The one or more management policies may include, but are not limited to, any suitable policy concerning the management and/or security of the connection, such as an application security policy (e.g., the IAP), the IDP, Network Address Translation policies (e.g., DNAT and SNAT), routing policies, and bandwidth classes or allocation policies. Accordingly, one having ordinary skill in the art will appreciate that the management policy relates to both the security and the management or handling of the connection and related packets. 
     As illustrated in  FIGS. 1 and 5 , the Management Module  70  may comprise one or more sub-modules configured to implement the one or more management policies. In the example shown in  FIGS. 1 and 5 , the Management Module  70  comprises an Application Filter  71 , a NAT Module  72 , a Routing Module  73 , an IDP Module  74 , and a Bandwidth Module  75 . One having ordinary skill in the art will appreciate that the Management Module  70  may have any number of suitable sub-modules, including any combination of the example sub-modules shown in  FIG. 1 . In addition, one having ordinary skill in the art will appreciate that additional sub-modules (not shown) configured to performed functions and tasks related to the management of a connection and packets may be included in the Management Module  70 . 
     With reference to  FIGS. 1 and 5 , the Firewall Module  60  provides the connection object and packet to the first sub-module of the Management Module  70 , here the Application Filter  71 . The Application Filter  71  is a computer-based module configured to apply the one or more application security policies associated with the connection object. Exemplary application security policies which the Application Filter may execute include, but are not limited to, a IAP, an anti-virus policy, and an anti-spam policy. 
     Upon receipt of the connection object and packet, the Application Filter  71  submits the packet to the appropriate application filter (e.g., HTTP, FTP, SMTP, POP3, IMAP, etc.). In addition, the Application Filter  71  fetches any application security policies associated with the connection object, applies the policies at the application layer, and submits the packet to the next sub-module (if applicable). 
     According to an exemplary embodiment of the present invention, as shown in  FIG. 5 , the NAT Module  72  receives the packet and connection object, retrieves the Destination NAT (DNAT) policy from the Firewall Module  60  using the firewall rule identifying information stored in the connection object, changes the destination as per the defined DNAT policy, and updates the reply tuple and DNAT information in the connection object. 
     According to an exemplary embodiment of the present invention, the NAT Module  72  passes the packet to the Routing Module  73 . The Routing Module  73  is a computer-based module configured to route the packet according to the one or more defined routing policies. 
     For example, if there are more than one defined routing policies, the Routing Module  73  may route the packet according to any suitable sequence or application of the policies. As shown in  FIG. 5 , the packet may be routed according to the following exemplary sequence: 1) per the destination routing policy, 2) per the routing policy in the packet data structure, 3) per source-defined routing rules, 4) per default routes set forth in a routing table. One having ordinary skill in the art will appreciate that the routing polices set forth in  FIG. 5  and described above, and the suggested sequence, are exemplary in nature, and that other routing rules/policies and sequences may be applied in accordance with the present invention. 
     Next, the packet is submitted to the IDP Module  74 . The IDP Module  74  is a computer-based module configured to retrieve the IDP policy from the connection object and scan the packet pursuant to the IDP policy. If the IDP Module  74  determines that there is no network traffic pattern signature match, the packet is submitted or passed to the next sub-module of the Management Module  70  (i.e., the NAT Module  72  in  FIG. 5 ). 
     If the IDP Module  74  determines that the packet matches a network traffic pattern signature, the IDP Module  74  executes the appropriate IDP policy action (i.e., drop or detect). If the IDP policy action is ‘drop,’ the packet is dropped. Optionally, the packet may be logged prior to being dropped. If the IDP policy is ‘detect,’ the IDP Module  74  generates an alert and submits the packet to the next sub-module. 
     According to the exemplary embodiment illustrated in  FIG. 5 , the packet is received by the NAT Module  72 , which is configured to retrieve the Source NAT (SNAT) policy, if applicable, from the Firewall Module  60  using the firewall rule identifier stored in the connection object. Next, the NAT Module  72  changes the source IP address as defined by the SNAT policy and updates the reply tuple and SNAT information of the connection object. 
     Next, in the example shown in  FIG. 5 , the Bandwidth Module  75  retrieves the bandwidth class information from the packet data structure and controls the transmission/flow rate of the packet based on the bandwidth class information. 
     Finally, once the packet has been reviewed by each of the sub-modules of the Management Module  70 , it is passed back to the Firewall Module  60 , where the packet is submitted to an output device driver for transmission to Destination  80 . 
     It is to be understood that the exemplary embodiments and the above example are merely illustrative of the present invention and that many variations of the above-described embodiments and example can be devised by one skilled in the art without departing from the scope of the invention. It is therefore intended that all such variations be included within the scope of the invention.