The present invention relates to network policies, and more particularly to policy enforcement.
The recent explosion of distributed computing systems and their attendant problems have led to many innovative solutions to ensure commonality, interoperability, and standardization. In order to both provide authorized access and prevent unwanted access, administrators establish policies for distributed computing systems under their control. These policies include firewall policies, file access policies, application-related policies, encryption policies, audit trail policies, activity logging policies, etc.
Unfortunately, if any particular computer in the aforementioned distributed computing system is not compliant with any particular desired policy, the remaining computers in the system may be detrimentally affected. Such affects may range from security-related problems to more benign issues such as performance reduction, inconvenience, etc.
There is thus a need for overcoming these and/or other problems associated with the prior art.
A policy management system, method and computer program product are provided. In use, information is received over a network relating to at least one subset of computers that are at least potentially out of compliance with a policy. Further, such information is sent to a plurality of the computers, utilizing the network. To this end, network communication involving the at least one subset of computers is capable of being controlled utilizing the information.
Coupled to the networks 102 are server computers 104 which are capable of communicating over the networks 102. Also coupled to the networks 102 and the server computers 104 is a plurality of client computers 106. Such server computers 104 and/or client computers 106 may each include a desktop computer, lap-top computer, hand-held computer, mobile phone, hand-held computer, peripheral (e.g. printer, etc.), any component of a computer, and/or any other type of logic. In order to facilitate communication among the networks 102, at least one gateway or router 108 is optionally coupled therebetween.
It should be noted that any of the foregoing computers in the present network architecture 100 may be equipped with a policy management system, method and/or computer program product. In use, information is received over one or more of the networks 102. Such information may include any data that relates to at least one subset of computers 104 and/or 106 that are at least potentially out of compliance with a policy. In the context of the present description, such policy may include one or more firewall policies, file access policies, application-related policies, encryption policies, audit trail policies, activity logging policies, and/or any other plan and/or course of action intended to influence and/or determine decisions, actions, and/or other matters associated with the computers 104 and/or 106, and/or one or more of the networks 102.
Such information is then, in turn, sent to a plurality of the computers 104 and/or 106 utilizing the one or more of the networks 102. Of course, the term “information” in the context of the send operation may include the entire set of information received, a portion thereof, a processed form of the received information, and/or any other data that again relates to the at least one subset of computers 104 and/or 106 that are at least potentially out of compliance with a policy. Further, the computers 104 and/or 106 to which the information is sent may or may not include some or all of the computers 104 and/or 106 including or excluding the out of compliance computers 104 and/or 106.
To this end, network communication involving the at least one subset of computers 104 and/or 106 is capable of being controlled utilizing the information. More illustrative information will now be set forth regarding various optional architectures and features with which the foregoing technique may or may not be implemented, per the desires of the user. It should be strongly noted that the following information is set forth for illustrative purposes and should not be construed as limiting in any manner. Any of the following features may be optionally incorporated with or without the exclusion of other features described.
The workstation shown in
The workstation may have resident thereon any desired operating system. It will be appreciated that an embodiment may also be implemented on platforms and operating systems other than those mentioned. One embodiment may be written using JAVA, C, and/or C++ language, or other programming languages, along with an object oriented programming methodology. Object oriented programming (OOP) has become increasingly used to develop complex applications.
Our course, the various embodiments set forth herein may be implemented utilizing hardware, software, or any desired combination thereof. For that matter, any type of logic may be utilized which is capable of implementing the various functionality set forth herein.
As shown, one or more client computers 301 (e.g. see, for example, the client computers 106 of
Of course, while the policy scanner 302 and the firewall 304 are shown to be included with the client computer 301 as separate modules, it should be noted that they may be combined in any capacity as well as be external to the client computer 301, as desired. Still yet, in various embodiments, one policy scanner 302 and/or firewall 304 may be allocated to more than one client computer 301.
Further provided is a server 308 (e.g. see, for example, the server computers 104 of
In use, the policy scanner 302 is adapted to provide the server 308 with information relating to any aspect of the associated client computer 301 that is found to be at least potentially out of compliance. Still yet, the policy seamier 302 may, upon detecting such out of compliance status, communicate with the firewall 304 for immediately controlling network communication involving the client computer 301 on which it is installed.
Thereafter, the server 308 may store and/or process such information received from the policy scanner 302. Armed with such information, the server 308 is further adapted to communicate with other computers for the purpose controlling network communication involving such other computers with respect to the client computer 301 utilizing respective firewalls 304. Thus, not only is an out of compliance client computer 301 controlled in the manner it communicates with other computers, but such other computers are also controlled in the manner in which they communicate with the out of compliance client computer 301. To this end, two-way dynamic quarantining may optionally be established in order to optimally isolate out of compliance computers.
It should be noted that the receipt and sending of information may be carried out utilizing any desired push and/or pull techniques on a periodic or other basis. For example, instead of a periodic sharing of information, the information may be received and/or sent only upon it being determined that a compliance status of at least one of the computers has changed.
In one embodiment, the aforementioned network communication control may be carried out utilizing the aforementioned white and/or black list(s) stored in the database 310. More exemplary information regarding such functionality, according to various embodiments, will be set forth in greater detail during reference to subsequent figures.
As shown, compliancy is periodically assessed using a scanner (e.g. see, for example, the policy scanner 302 of
Then, in decision 404, it is determined whether the one or more computers managed by the scanner are in compliance under one or more policies. For example, such decision may be made based on a particular setting, whether an update has been installed, whether a particular application (e.g. virus scanner, intrusion detector, etc.) is installed and/or running, whether a particular behavior has been recognized (e.g. utilizing a pattern detection technique, heuristics, etc.), etc. Of course, such determination may be made in any desired manner that detects any sort of manifestation that at least potentially indicates at least a potential violation of a policy.
If it is determined in decision 404, that the one or more computers is out of compliance under one or more policies, information relating to such policy violating computer may be reported to a server (e.g. see, for example, the server 308 of
For example, such information may include an identification of the out of compliance computer(s) in the form of an Internet Protocol (IP) address, user name, etc. Further, for reasons that will soon become apparent, the information may also describe a nature (e.g. severity, urgency, which policies where violated, etc.) of the policy violation, and/or a description of the activities, behavior, etc. that prompted the violation, etc. As will soon become apparent, such information may be used in the compilation of black and/or white list(s).
Next, the initiation of the firewall may prompt black list processing in operation 408 and/or white list processing in operation 412, based on a mode in which the present method 400 is operating per decisions 406 and 410, respectively. Of course, such modes may be predetermined or dynamic based on user input and/or any automated logic, etc. More information regarding the white list processing in operation 412 will be set forth in greater detail during reference to
Referring back to decision 404, if it is determined that the one or more computers managed by the scanner is indeed compliant under one or more policies, information relating to such policy compliance may be reported to a server, and any previously enabled firewall black or white list-based blocking may be disabled with respect to the particular computer that is now found to be compliant. Of course, such action may be conditioned on whether the computer was out of compliance in the first place, in order to preserve bandwidth, processing resources, etc.
Thus, the compliancy status of each computer equipped with the present functionality is constantly updated so as to 1) adjust the onboard blocking functionality of such computer, as well as 2) update the server so that the blocking functionality of any remaining computers may be similarly adjusted.
While not shown, before the method 500 proceeds with the operations shown, the associated white list may be “reset,” by denying communication with all computers. Thereafter, a white list update may be carried out in operation 501 for receiving an updated current white list reflecting all computers currently found to be compliant with relevant policies.
In addition to such computers, various other computers may be added which meet certain criteria. For example, in operation 502, the white list is amended to include at least one domain name server (DNS) so a computer is capable of converting hostnames to IP addresses for remediation and/or other purposes. Further, in operation 504, the white list is amended to include a Windows Internet name server (WINS) so the computer is capable of converting NetBIOS names to IP addresses, again for remediation and/or other purposes. Even still, in operation 506, the white list is amended to include a remediation server which is adapted for providing updates to various computers, some of which may be necessary for staying in compliance.
In operation 508, additional servers may be added per an administrator. Such additional servers may be defined on a local and/or global basis. Thus, the white list may be configurable by an administrator. Further, while not shown, the white list may be updated to add the server (e.g. see, for example, the server 308 of
Once the white list is established per operations 501-508, operation may continue by monitoring network communications. Specifically, each portion (e.g. packet, frame, byte, etc.) of such network communications may be compared against the white list. See decision 510. For example, a source of each network communication portion may be compared against the white list. If there is a match, such network communication portion may be allowed, per operation 512. On the other hand, if there is not a match, such network communication portion may be blocked, per operation 511.
It should be noted that the foregoing example of white list usage is non-limiting. For example, multiple white lists may be utilized in other embodiments. To this end, in operation 501, one of many white list updates may be received based on any desired criteria including, but not limited to a particular computer group of which the instant computer is a member, etc. Further, as mentioned previously, the white list may include information relating to a nature (e.g. severity, urgency, which policies where violated, etc.) of the policy violation, and/or a description of the activities, behavior, etc. that prompted the violation, etc. To this end, the white list update may be a function of such information. Just by way of example, a more serious or urgent policy violation/behavior may prompt a more stringent white list, etc.
Thus, in one embodiment, a plurality of different subsets of computers may be quarantined from remaining computers and/or subsets on the network, as a function of the computers themselves (e.g. groups associated therewith, etc.) and/or any aspect associated with the corresponding policy violation. Further, the nature of any resultant blocking may further vary based on the foregoing information. For example, a user may be given an option to nevertheless allow a blocked communication, based on any of the above information.
To this end, multiple quarantine zones may be employed. Specifically, one may have a zone defined by subnet, domain name, etc. A computer may then be firewalled from all other computers and, if the computer is communicating with a member of a particular domain, communications may be denied. On the other hand, if the computer with which the aforementioned machine is communicating is a member of a different domain, it may communicate. Therefore, one can create quarantine zones by location, etc., thus providing a “roving” laptop or the like.
Still yet, in various embodiments, the present white list processing of method 500 may be carried out on any computer involved in a particular system. On the other hand, in various other embodiments, the method 500 may be carried out only on out of compliance computers.
While not shown, similar to the method 500 of
Once the black list is established per operations 608, operation may continue by monitoring network communications. Specifically, each portion (e.g. packet, frame, byte, etc.) of such network communications may be compared against the black list. See decision 610. For example, a source of each network communication portion may be compared against the black list. If there is a match, such network communication portion may be blocked, per operation 611. On the other hand, if there is not a match, such network communication portion may be allowed, per operation 612.
Similar to the white list processing described in the context of
Still yet, in various embodiments, the present black list processing of method 600 may be carried out on any computer involved in a particular system. Specifically, in various embodiments, the method 600 may be carried out both on out of compliance computers as well as compliant computers. Thus, not only may the out of compliance computers be prevented from communicating with other computers, but such other computers may also thwart any network communications with the out of compliance computer. This may be of particular benefit, if a user of the out of compliance computer (or the computer itself) is capable of circumventing the associated firewall.
While various embodiments have been described above, it should be understood that they have been presented by way of example only, and not limitation. For example, any of the network elements may employ any of the desired functionality set forth hereinabove. Thus, the breadth and scope of a preferred embodiment should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.
This Application is a continuation (and claims the benefit of priority under 35 U.S.C. §120) of U.S. application Ser. No. 11/313,605, filed Dec. 21, 2005, entitled “SYSTEM, METHOD AND COMPUTER PROGRAM PRODUCT FOR CONTROLLING NETWORK COMMUNICATIONS BASED ON POLICY COMPLIANCE,” Inventor(s) Michael Anthony Davis, et al. The disclosure of the prior application is considered part of (and is incorporated by reference in) the disclosure of this application.
| Number | Name | Date | Kind |
|---|---|---|---|
| 5550976 | Henderson et al. | Aug 1996 | A |
| 5832208 | Chen et al. | Nov 1998 | A |
| 5937160 | Davis et al. | Aug 1999 | A |
| 5987610 | Franczek et al. | Nov 1999 | A |
| 5987611 | Freund | Nov 1999 | A |
| 6044402 | Jacobson et al. | Mar 2000 | A |
| 6070244 | Orchier et al. | May 2000 | A |
| 6073142 | Geiger et al. | Jun 2000 | A |
| 6075863 | Krishnan et al. | Jun 2000 | A |
| 6088803 | Tso et al. | Jul 2000 | A |
| 6119165 | Li et al. | Sep 2000 | A |
| 6205551 | Grosse | Mar 2001 | B1 |
| 6266704 | Reed et al. | Jul 2001 | B1 |
| 6269447 | Maloney et al. | Jul 2001 | B1 |
| 6327579 | Crawford | Dec 2001 | B1 |
| 6460050 | Pace et al. | Oct 2002 | B1 |
| 6622150 | Kouznetsov et al. | Sep 2003 | B1 |
| 6622230 | Yano et al. | Sep 2003 | B1 |
| 6718469 | Pak et al. | Apr 2004 | B2 |
| 6725377 | Kouznetsov | Apr 2004 | B1 |
| 6832321 | Barrett | Dec 2004 | B1 |
| 6839850 | Campbell et al. | Jan 2005 | B1 |
| 6892241 | Kouznetsov et al. | May 2005 | B2 |
| 6920558 | Sames et al. | Jul 2005 | B2 |
| 7003562 | Mayer | Feb 2006 | B2 |
| 7249187 | Sobel et al. | Jul 2007 | B2 |
| 7293099 | Kalajan | Nov 2007 | B1 |
| 7350203 | Jahn | Mar 2008 | B2 |
| 7436783 | Cheshire et al. | Oct 2008 | B2 |
| 7454488 | Wechter et al. | Nov 2008 | B2 |
| 7506155 | Stewart et al. | Mar 2009 | B1 |
| 7610624 | Brothers et al. | Oct 2009 | B1 |
| 7725558 | Dickenson | May 2010 | B2 |
| 7792994 | Hernacki | Sep 2010 | B1 |
| 7836506 | Liu | Nov 2010 | B2 |
| 7996841 | Smith et al. | Aug 2011 | B2 |
| 20030037094 | Douceur et al. | Feb 2003 | A1 |
| 20030158929 | McNerney | Aug 2003 | A1 |
| 20040019807 | Freund | Jan 2004 | A1 |
| 20040088581 | Brawn et al. | May 2004 | A1 |
| 20040103310 | Sobel et al. | May 2004 | A1 |
| 20040221126 | Peinado et al. | Nov 2004 | A1 |
| 20040226019 | Tucker et al. | Nov 2004 | A1 |
| 20040258044 | Girouard et al. | Dec 2004 | A1 |
| 20050006466 | Overhultz et al. | Jan 2005 | A1 |
| 20050007091 | Makeig et al. | Jan 2005 | A1 |
| 20050055242 | Bello et al. | Mar 2005 | A1 |
| 20050060417 | Rose | Mar 2005 | A1 |
| 20050081045 | Nicodemus et al. | Apr 2005 | A1 |
| 20050086537 | Johnson | Apr 2005 | A1 |
| 20050144279 | Wexelblat | Jun 2005 | A1 |
| 20050165834 | Nadeau et al. | Jul 2005 | A1 |
| 20050172142 | Shelest et al. | Aug 2005 | A1 |
| 20050182949 | Phillips et al. | Aug 2005 | A1 |
| 20050209876 | Kennis et al. | Sep 2005 | A1 |
| 20050246767 | Fazal et al. | Nov 2005 | A1 |
| 20050273850 | Freund | Dec 2005 | A1 |
| 20060075103 | Cromer et al. | Apr 2006 | A1 |
| 20060080656 | Cain et al. | Apr 2006 | A1 |
| 20070073874 | Moghaddam et al. | Mar 2007 | A1 |
| 20070101405 | Engle et al. | May 2007 | A1 |
| 20110078795 | Liu | Mar 2011 | A1 |
| Number | Date | Country |
|---|---|---|
| 06070448 | Oct 1995 | JP |
| 9905814 | Feb 1999 | WO |
| 03030001 | Apr 2003 | WO |
| Entry |
|---|
| “SonicWALL Network Anti-Virus: The Problem”, copyright 2001 SonicWALL, retrieved and printed on Jun. 17, 2003 from website://C:/Documents%20and%20Settings/Dom%20Kotab/Local%20Settings/Temporaty%2. . . , 1 page. |
| “SonicWALL Network Anti-Virus: The Solution”, copyright 2001 SonicWALL, retrieved and printed on Jun. 17, 2003 from website://C:/Documents%20and%20Settings/Dom%20Kotab/Local%20Settings/Temporaty%2 . . . , 2 pages. |
| “SonicWALL Network Anti-Virus Benefits”, copyright 2001 SonicWALL, retrieved and printed on Jun. 17, 2003 from website://C:/Documents%20and%20Settings/Dom%20Kotab/Local%20Settings/Temporaty%2 . . . , 2 pages. |
| “Sonic WALL Network Anti-Virus-Details”, copyright 2001 SonicWALL, retrieved and printed on Jun. 17, 2003 from website://C:/Documents%20and%20Settings/Dom%20Kotab/Local%20Settings/Temporaty%2 . . . , 1 page. |
| Jansen et al., Applying Mobile Agents to Intrusion Detection and Response; www.iti.nist.gov/div893/staff/melllmaresponse.pdf, NIST Interim Report (IR)-6416, Oct. 1999, 49 pages. |
| Gordon, Real World Anti-Virus Products Reviews and Evaluations (1996); csrc.nist.gov/nissc/1996/papers/NISSC96/final.pdf, 10 pages. |
| Using Mobile Agent Results to Create Hard-to-Detect Computer Viruses—Yongge Wang; www.cs.uwm.edu/.about.wang/papers/virus.ps.gz, 9 pages, Information Security—SEC, 2000, 9 pages. |
| Java and Internet Security—Viljamaa, Viljamaa (1998); www.sc.helsinki.fi/group/fred/reports/JavaSecurityReportFinal.ps.gz, Helsinki, May 1998, University of Helsinki, 33 pages. |
| Keizer, Gregg-ZoneAlarm Product Firewalls Spyware—Network Computing's desktoppipeline, Oct. 19, 2005, retrieved and printed Dec. 20, 2005 from file://T:/patent/N/NAI1—Network Asso,Inc./NAI1P511/prior art/DesktopPipelineZoneA . . . , 3 pages. |
| Symantec-Sygate Secure Enterprise, Sygate Technologies, Inc., retrieved and printed from file://T:/patent/N/NA11-NetworkAsso,Inc./NAI1P511/prior art/SygateSecure Enterprise . . . on Dec. 20, 2005, 4 pages. |
| Sygate Secure Enterprise—The Problem, Sygate Technologies, Inc., copyright 2004 Sygate Technologies, Inc., 4 pages. |
| Office Action from U.S. Appl. No. 09/968,106 mailed May 24, 2004. |
| Written Opinion from PCTƒUS02/29302 mailed May 19, 2003. |
| International Search Report from PCTƒUS02/29302 mailed Dec. 18, 2002. |
| International Preliminary Examination Report from PCTƒUS02/29302 mailed Jul. 21, 2004. |
| Notice of Allowance from U.S. Appl. No. 09/968,106 mailed on Jul. 24, 2004. |
| Supplemental Notice of Allowance from U.S. Appl. No. 09/968,106. |
| USPTO Oct. 1, 2005 Non-Final Office Action from U.S. Appl. No. 11/313,605. |
| USPTO Feb. 2, 2009 Response to Oct. 1, 2005 Non-Final Office Action from U.S. Appl. No. 11/313,605. |
| USPTO May 14, 2009 Final Office Action from U.S. Appl. No. 11/313,605. |
| USPTO Jul. 14, 2009 After Response to May 14, 2009 Final Office Action from U.S. Appl. No. 11/313,605. |
| USPTO Jul. 28, 2009 Advisory Action from U.S. Appl. No. 11/313,605. |
| USPTO Nov. 16, 2009 Request for Continued Examination Response to Jul. 28, 2009 Advisory Action from U.S. Appl. No. 11/313,605. |
| USPTO Dec. 11, 2009 Non-Final Office Action from U.S. Appl. No. 11/313,605. |
| USPTO Apr. 12, 2010 Response to Dec. 11, 2009 Non-Final Office Action from U.S. Appl. No. 11/313,605. |
| USPTO Jul. 9, 2010 Final Office Action from U.S. Appl. No. 11/313,605. |
| USPTO Nov. 9, 2010 Request for Continued Examination Response to Final Office Action from U.S. Appl. No. 11/313,605. |
| USPTO Feb. 1, 2012 Non-Final Office Action from U.S. Appl. No. 11/313,605. |
| USPTO May 1, 2012 Response to Feb. 1, 2012 Non-Final Office Action from U.S. Appl. No. 11/313,605. |
| USPTO Jun. 26, 2012 Notice of Allowance from U.S. Appl. No. 11/313,605. |
| Number | Date | Country | |
|---|---|---|---|
| 20130060943 A1 | Mar 2013 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 11313605 | Dec 2005 | US |
| Child | 13647987 | US |