US20040181690A1 - Managing multiple network security devices from a manager device - Google Patents
Managing multiple network security devices from a manager device Download PDFInfo
- Publication number
- US20040181690A1 US20040181690A1 US10/712,313 US71231303A US2004181690A1 US 20040181690 A1 US20040181690 A1 US 20040181690A1 US 71231303 A US71231303 A US 71231303A US 2004181690 A1 US2004181690 A1 US 2004181690A1
- Authority
- US
- United States
- Prior art keywords
- security
- information
- devices
- network
- supervisor
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/28—Restricting access to network management systems or functions, e.g. using authorisation function to access network configuration
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/22—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks comprising specially adapted graphical user interfaces [GUI]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/0803—Configuration setting
- H04L41/0813—Configuration setting characterised by the conditions triggering a change of settings
- H04L41/082—Configuration setting characterised by the conditions triggering a change of settings the condition being updates or upgrades of network functionality
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
- H04L41/08—Configuration management of networks or network elements
- H04L41/0803—Configuration setting
- H04L41/084—Configuration by using pre-existing information, e.g. using templates or copying from other elements
- H04L41/0843—Configuration by using pre-existing information, e.g. using templates or copying from other elements based on generic templates
Definitions
- the present invention relates generally to communicating information between computers, and more particularly to using a manager device to remotely manage multiple network security devices.
- NSDs network security devices
- Some types of NSDs such as firewalls and security appliances, have a group of one or more trusted network devices (or networks consisting of trusted network devices) which the NSD attempts to protect from unauthorized external access.
- These NSDs monitor network information passing between external network devices and the devices in their group of trusted or internal devices.
- these NSDs typically implement a specified security policy by preventing the passage of unauthorized network information between the external and the trusted devices.
- network information can be transmitted in a variety of formats.
- network information is often transmitted as a series of individual packets of information, such as TCP/IP (Transfer Control Protocol/Internet Protocol) packets. While such packets will typically include the network address (e.g., IP address) of the device to receive the information, other data about the network information (e.g., the specific type of information being requested or sent) may be difficult to ascertain.
- IP Transfer Control Protocol/Internet Protocol
- NSD While a properly configured NSD can protect information stored on or accessible from trusted devices, it can be difficult to configure NSDs so that they correctly implement the desired security policies.
- One source of difficulty in configuring NSDs arises from the large number of types of network information which may be encountered. For example, there are a large number of network services and protocols which external devices may attempt to provide to trusted devices or access from trusted devices.
- Such network services and protocols include, but are not limited to, Archie, auth (ident), DCE-RPC (Distributed Computing Environment Remote Procedure Call), DHCP (Dynamic Host Configuration Protocol) Client and Server, DNS (Domain Name Service), finger, FTP (File Transfer Protocol), gopher, H.323, HTTP (HyperText Transfer Protocol), Filtered-HTTP, Proxied-HTTP, ICMP (Internet Control Message Protocol), NNTP (Network News Transfer Protocol), NTP (Network Time Protocol), ping, POP (Post Office Protocol) 2 and 3, RealNetworks, rlogin, rsh (Remote SHell), SMB (Simple Block Messaging), SMTP (Simple Mail Transfer Protocol), SNMP (Simple Network Management Protocol), syslog, ssh (Secure SHell), StreamWorks, TCP/IP, telnet, Time, traceroute, UDP (User Datagram Protocol), VDOLive, WAIS
- NSD network information of different types. For example, for each type of service or protocol, a NSD may wish to take different actions for (e.g., allow passage of, deny passage of, or otherwise manipulate) the corresponding network information of that service or protocol. The decision to take these different actions can also be based on additional factors such as the direction of information flow (i.e., whether the network information is passing from a trusted device or to a trusted device) or on the basis of the sender or the intended recipient of the information (e.g., whether the network information is passing from or to specific network devices or is passing from or to any network device of a specified class, such as any external device).
- the direction of information flow i.e., whether the network information is passing from a trusted device or to a trusted device
- the sender or the intended recipient of the information e.g., whether the network information is passing from or to specific network devices or is passing from or to any network device of a specified class, such as any external device.
- the types of actions to be taken for the monitored network information provide an initial incomplete security policy.
- Various device-specific information is necessary to configure a particular NSD with a specific security policy that can be implemented by the device.
- the device-specific information which must typically be specified to create a specific security policy includes, for example, the network address of the NSD and the network addresses of some or all of the trusted devices. If a particular network service is to be provided to external devices by a trusted device, such as FTP access, information about the trusted FTP server must also be available to the NSD.
- a user such as a system administrator typically defines the specific security policy for a NSD by determining the services and protocols of interest and then configuring the NSD to protect the trusted devices as appropriate.
- configuring an NSD can be time-consuming, and any mistakes in the configuration (e.g., failure to define how a particular service should be handled, or allowing default behaviors to allow passage of network information) can compromise the ability of the NSD to protect sensitive information.
- the need for system administrators to configure each NSD can cause various problems.
- NSDs In addition to implementing security policies which may restrict the passage of some network information, NSDs typically gather network security information about events of interest, including encountering types of network information that is encountered as well as various actions taken by the NSD. The network security information can be displayed to users such as system administrators so that they can verify that the security policy is correctly implemented, produce reports about the types and quantities of network information that is allowed to pass and that is blocked from passage, and identify when external activities of concern (e.g., a hacker attack on the NSD) are occurring. NSDs typically maintain a local storage, often referred to as a log, of the security information that they gather.
- a log often referred to as a log
- Some NSDs include computer software components executing on general-purpose or dedicated computer hardware.
- the executing software components assist in implementing the specific security policies defined for the NSD.
- Use of software components allows the operation of the NSD to be upgraded in an efficient manner by replacing some or all of the existing software components with new software components.
- Such new software is typically distributed via physical media such as CDs or optical disks, and is loaded onto the NSD by an individual such as a system administrator.
- Some embodiments of the present invention provide a facility for using a security policy manager device to remotely manage multiple network security devices (NSDs).
- the manager device uses one or more intermediate supervisor devices to assist in the management.
- Security for the communications between the manager device, supervisor devices, and NSDs can be provided in a variety of ways.
- the facility allows the manager device to create a consistent security policy for the multiple NSDs by distributing a copy of a security policy template to each of the NSDs and by then configuring each copy of the template with NSD-specific information.
- the manager device can distribute the template to multiple NSDs by sending a single copy of the template to a supervisor device associated with the NSDs and by then having the supervisor device update each of the NSDs with a copy of the template.
- Other information useful for implementing security policies for the NSDs such as software components to be executed by the NSDs, can also be distributed by the manager device to the NSDs in a similar manner.
- the facility also allows a manager device to retrieve, analyze and display the network security information gathered by the various NSDs while implementing security policies.
- Each NSD can forward its network security information to a supervisor device currently associated with the NSD, and can switch supervisor devices if the current supervisor device becomes unavailable.
- the manager device desires the network security information for an NSD, the manager device contacts the one or more supervisor devices which store portions of the network security information of interest, retrieves the various portions of the network security information, and then aggregates the retrieved information in an appropriate manner.
- FIG. 1 is a block diagram illustrating an embodiment of the Network Security Device Management (NSDM) system of the present invention.
- NSDM Network Security Device Management
- FIG. 2 is a block diagram illustrating the flow of network security information from a network security device (NSD) to the manager device.
- NSD network security device
- FIGS. 3A-3H are examples of security policy templates.
- FIGS. 4A-4H are an example of network security information generated by implementing a specific security policy.
- FIGS. 5A-5D are examples of a manager device's hierarchical view of multiple supervisor devices and NSDs and of corresponding configuration and network information.
- FIG. 6 is an example of one or more NSD software components which can be distributed by a manager device.
- FIG. 7 is an exemplary flow diagram of an embodiment of the Network Security Device routine.
- FIG. 8 is an exemplary flow diagram of an embodiment of the Filter Network Packets subroutine.
- FIG. 9 is an exemplary flow diagram of an embodiment of the Generate Network Security Information subroutine.
- FIG. 10 is an exemplary flow diagram of an embodiment of the Respond To Management Message subroutine.
- FIG. 11 is an exemplary flow diagram of an embodiment of the Supervisor Device routine.
- FIG. 12 is an exemplary flow diagram of an embodiment of the Process NSD Message subroutine.
- FIG. 13 is an exemplary flow diagram of an embodiment of the Process Manager Or Supervisor Device Message subroutine.
- FIGS. 14A and 14B are exemplary flow diagrams of an embodiment of the Manager Device routine.
- An embodiment of the present invention provides a method and system for using a manager device to remotely manage multiple network security devices.
- the Network Security Device Management (NSDM) system allows a security policy manager device to create a consistent security policy for multiple network security devices (NSDs) by distributing a copy of a security policy template to each of the NSDs and by then configuring each copy of the template with NSD-specific information.
- Other information useful for implementing security policies for the NSDs such as software components to be executed by the NSDs or lists of devices from whom information is to be blocked, can also be distributed by the manager device to the NSDs in a similar manner.
- the NSDM system also allows a manager device to retrieve, analyze and display the network security information gathered by the various NSDs while implementing security policies.
- the manager device uses one or more intermediate supervisor devices to assist in managing the multiple NSDs.
- Security policy templates can be defined by a user of the manager device and then used to implement consistent network security policies across multiple NSDs while reducing the risk of configuration error.
- Each template defines default network information filtering rules for various common services and protocols, and uses defined aliases to represent various specific devices of interest for a particular NSD.
- Security policy templates are discussed in greater detail below, as well as in the co-pending U.S. Patent Application entitled âGENERALIZED NETWORK SECURITY POLICY TEMPLATES FOR IMPLEMENTING SIMILAR NETWORK SECURITY POLICIES ACROSS MULTIPLE NETWORKS,â filed May 6, 1999, incorporated herein by reference.
- a manager device can use one or more intermediate supervisor devices. For example, after a security policy template is defined, the manager device can distribute the template to multiple NSDs by sending a single copy of the template to a supervisor device associated with the NSDs and by then having the supervisor device update each of the NSDs with a copy of the template. Each of the NSD template copies can then be configured with NSD-specific information from one or more of a variety of sources, such as by the manager device, by a local user such as a system administrator, or automatically such as with DNS information.
- aliases in the template copy on a particular NSD can be replaced with information about the specific corresponding devices that are protected by the NSD, and NSD-specific access information can also be specified.
- an alias for an HTTP server can be replaced with the specific network address and name of the actual HTTP server.
- Other information useful for implementing security policies for the NSDs such as software components to be executed by the NSDs, lists of devices to be blocked (i.e., to block information flowing from and/or to the device), or updates to existing templates in use, can also be distributed by the manager device to the NSDs in a similar manner via the supervisor devices. Such information can also be configured with NSD-specific information if necessary in the manner described above. Those skilled in the art will appreciate that configuration of an NSD can occur not only when the NSD is initially installed, but also at later times.
- the manager device can also provide various types of information to the supervisor devices (e.g., software updates for software executing on the supervisor devices).
- One or more intermediate supervisor devices can also assist the manager device in retrieving, analyzing and displaying the network security information gathered by the various NSDs.
- the NSD gathers network security information about its activities and about the network information that is monitored.
- Each NSD forwards its network security information to a host supervisor device currently associated with the NSD so that the supervisor device can host the network security information by storing and/or processing it. If the supervisor device currently associated with an NSD becomes unavailable, the NSD instead forwards its network security information to one or more alternate host supervisor devices. In this manner, even if one supervisor device becomes unavailable, the network security information for the NSDs that were associated with the supervisor device is not lost.
- the manager device wants to retrieve the network security information for an NSD, the manager device contacts the one or more supervisor devices which store portions of the network security information of interest, retrieves the various portions of the network security information, and then aggregates the retrieved information in an appropriate manner.
- the manager device and supervisor devices are external devices.
- Security for the communications between the manager device, supervisor devices, and NSDs can be provided in a variety of ways. For example, any of the information transmitted between the NSDs and the supervisor devices and between the supervisor devices and the manager device can be protected from unauthorized access by encrypting the information (e.g., using Data Encryption Standard (DES) in Cipher Block Chaining (CBC) mode).
- DES Data Encryption Standard
- CBC Cipher Block Chaining
- various schemes can be used to ensure that NSDs and supervisor devices provide information only to authorized devices or users, such as by using passwords, hashing passwords to produce keys, challenge/response, shared secrets, digital IDs, or a list of devices defined as being authorized to request and/or receive information.
- Part of the NSD-specific configuration of each NSD can include associating one or more supervisor devices authorized to communicate with the NSD, as well as providing specific information about how the communication is to occur.
- User authentication can be performed in a variety of ways, such as by using WINDOWS NTTM Domain Users and Groups RADIUS user authentication, or CRYPTOcard.
- an embodiment of the Network Security Device Management (NSDM) system 100 includes a security policy manager device 110 able to communicate with multiple supervisor devices 120 and 160 , also referred to as host devices or event processors.
- Each supervisor device is associated with multiple NSDs, with supervisor device 120 associated with NSDs 130 through 140 and with supervisor device 160 associated with NSDs 161 through 162 .
- Each NSD protects one or more trusted devices from external devices, such as NSDs 130 and 140 protecting devices (not shown) in internal networks 135 and 145 respectively from devices (not shown) in external network 190 .
- supervisor device 160 and NSDs 161 through 162 are not described in detail.
- additional classes of devices which the NSD will protect are defined, with different security policies defined for each class of devices.
- internal devices which are in direct communication with external devices (e.g., HTTP and FTP servers) may be specified in an optional class.
- Optional devices are typically afforded some level of trust greater than external devices but less than trusted devices, such as by monitoring some communications between optional and trusted devices.
- security policy templates and specific security policies can be viewed as defining levels of trust given to various specific devices or classes of devices.
- Each NSD has a supervisor device which is designated as the primary supervisor device for that NSD.
- supervisor device 120 is the primary supervisor for NSDs 130 through 140 , and those NSDs store information about supervisor device 120 (e.g., the device's network address) with their respective specific security policy information 133 and 143 on storage devices 131 and 141 .
- supervisor device 160 is the primary supervisor for NSDs 161 through 162 .
- NSDs 130 and 140 also store any required access information (e.g., one or more unique passwords which supervisor device 120 must provide in order to gain access to the NSDs) along with their respective device access information 134 and 144 .
- the NSD-specific access information and primary supervisor device information can also optionally be stored by the manager device along with its supervisor device and NSD access information 115 and specific security policy information 116 respectively.
- storage devices 131 and 141 can be implemented in a variety of ways, such as by using local or remote storage, and by using a variety of storage media (e.g., magnetic disk, flash RAM, etc.).
- the manager device has one or more input/output devices 118 (such as a display) to enable a user (not shown) to interact with the manager device.
- the manager device also stores a variety of information on storage device 111 , including one or more NSD software updates 112 , security policy templates 113 , and aggregated network security information 114 from one or more NSDs.
- the manager device also optionally stores supervisor device and NSD access information 115 (e.g., passwords and a decryption key for stored information) as well as specific security policy information 116 (including NSD-specific configuration information) for one or more NSDs.
- supervisor device and NSD access information 115 e.g., passwords and a decryption key for stored information
- specific security policy information 116 including NSD-specific configuration information
- a user of the manager device desires to establish or modify a security policy for one or more NSDs such as NSDs 130 and 140 , the user first selects one of the security policy templates 113 or creates a new security policy template. Security policy templates are discussed in greater detail below with respect to FIG. 3.
- the manager device determines the one or more primary supervisor devices for the NSDs of interest, such as by retrieving this information from its specific security policy information 116 . If this information is not stored by the manager device, the manager device can obtain the information in a variety of ways, such as by querying the NSDs of interest or by querying the various known supervisor devices.
- the manager device sends a single copy of the security policy template to each of the primary supervisor devices. For example, if the NSDs 130 and 140 are selected, a copy of the template is sent to supervisor device 120 . The primary supervisor devices then send a copy of the security policy template to each of the selected NSDs. Each NSD stores its copy of the security policy template with the NSD's specific security information.
- Each NSD's copy of the security policy template can then be configured with information specific to the NSD. For example, information about specific devices of interest from internal network 135 will be retrieved, and will be used to configure the security policy template for NSD 130 . This NSD-specific information will be used to configure the security policy template into a specific security policy for the NSD, and the information will be stored with the specific security policy information for the NSD.
- the NSD-specific configuration can be conducted by a user via the manager device, by a local user such as a system administrator for the NSD, or automatically via a device-identifying service such as DNS.
- a user of the manager device desires to initially load or modify the software to be executed by one or more NSDs such as NSDs 130 and 140
- the user first selects the software of interest, such as from NSD software updates information 112 .
- the user can update some or all of the software components used by the NSDs.
- the manager device then distributes the software components to the NSDs in the same manner as for the security policy templates, including configuring the copies of the software with NSD-specific information if necessary.
- Each NSD stores the software, such as NSDs 130 and 140 storing their software with their security device software 132 and 142 respectively.
- the NSDs will implement the defined specific security policy by executing the software and using the stored specific security policy information.
- Those skilled in the art will appreciate that other types of information other than security policy templates and software can be distributed from the manager device to the NSDs in a similar manner.
- each NSD forwards its network security information to its primary supervisor device for storage.
- the network security information can be forwarded to the supervisor device in a variety of ways, such as immediately upon generation, on a periodic basis, or when the supervisor device requests the information.
- NSDs 130 and 140 forward their network security information to supervisor device 120 for storage in the supervisor device's network security information log 125 . If supervisor device 120 becomes unavailable, NSDs 130 and 140 will forward their network security information to another supervisor device, such as supervisor device 160 .
- Supervisor device 160 stores the network security information it receives in network security information log 165 .
- each supervisor device maintains one or more logs containing network security information sent by NSDs associated with the supervisor device.
- the manager device retrieves the network security information from each supervisor device which stores any of the network security information (e.g., any security information generated between two specified times, or all security information that is available).
- the manager device can determine these one or more supervisor devices in a variety of ways. For example, each of the supervisor devices can periodically inform the manager device of the NSDs which are currently associated with the supervisor device, and the manager device can store this information with its specific security policy information 116 .
- the manager device can then aggregate the network security information that is retrieved from multiple supervisor devices in a variety of ways, such as chronologically, by event type, etc. This aggregated network security information can be stored by the manager device in the aggregated network security information 114 of the manager device, either individually or with the security information of other NSDs.
- each device of the NSDM system may be composed of various components such as a CPU, memory, input/output devices (e.g., a display and a keyboard), and storage (e.g., a hard disk or non-volatile flash RAM).
- a CPU central processing unit
- memory e.g., a central processing unit
- input/output devices e.g., a display and a keyboard
- storage e.g., a hard disk or non-volatile flash RAM
- the described embodiment of the NSDM system is merely illustrative and is not intended to limit the scope of the present invention.
- the system may contain additional components or may lack some illustrated components.
- there may be multiple manager devices and/or multiple hierarchical layers of supervisor devices such that some supervisor devices supervise other supervisor devices.
- the manager device and one or more supervisor devices may be implemented as a single computer system such that the manager device communicates directly with NSDs.
- the devices which host network security information for the NSDs can be separate devices from those which supervise and send management information to the NSDs. Accordingly, the present invention may be practiced with other configurations.
- each NSD has not only a primary supervisor device which is associated with the NSD, but also one or more additional associated supervisor devices (e.g., secondary and tertiary devices, or multiple secondary devices).
- additional supervisor devices for an NSD can be specified in a variety of ways, such as by a user of the manager device during configuration of the NSD or automatically based on a variety of criteria (e.g., geographic proximity to the NSD, capacity of the supervisor device, etc.).
- Each NSD can store information about the additional supervisor devices with their specific security policy information, as well as any required access information for the additional supervisor devices along with their device access information.
- supervisor device 120 has been designated as the primary supervisor device for NSD 130 .
- two other supervisor devices have also been associated with NSD 130 .
- supervisor device 160 has been designated as a secondary supervisor device for NSD 130
- supervisor device 210 has been designated as a tertiary supervisor device.
- supervisor devices 160 and 210 maintain network security information logs 165 and 215 respectively, and supervisor devices 120 , 160 and 210 are all able to communicate with security policy manager device 110 .
- NSD 130 protects multiple trusted devices 220 through 230 in internal network 135 from external devices in external network 190 (not shown). As NSD 130 implements its specific security policy and notes events of interest, it gathers various network security information related to the events. When NSD 130 has network security information that is to be transmitted to a supervisor device for storage, NSD 130 first determines if primary supervisor device 120 is available to host the information (e.g., by sending a status query message to the device). If primary supervisor device 120 is able to receive network security information from NSD 130 and has the capacity to store the information, NSD 130 sends the network security information to supervisor device 120 for storage in the network security information log 125 .
- the NSD determines an alternate host supervisor device (referred to as a âfail-overâ). Since supervisor device 160 has been designated as the only secondary supervisor device, NSD 130 determines if that supervisor device is available to host the network security information. If so, supervisor device 160 becomes the supervisor device currently associated with NSD 130 , and the NSD forwards the information to the supervisor device. If supervisor device 160 is not available, the NSD determines a next supervisor device (e.g., supervisor device 210 ) to check for availability. In this manner, the network security information for a single NSD may be stored across multiple host supervisor devices. As discussed above, the manager device can be informed as to the NSDs currently associated with each supervisor device in a variety of ways, such as by the supervisor devices or the NSDs periodically sending status messages to the manager device.
- the manager device can be informed as to the NSDs currently associated with each supervisor device in a variety of ways, such as by the supervisor devices or the NSDs periodically sending status messages to the manager device.
- NSD 130 will continue to use that supervisor device as its host device until that supervisor device becomes unavailable.
- the NSD could instead continue to try to send network security information to its primary supervisor device even if the current supervisor device remains available, such as by periodically checking the availability of the primary supervisor device or by first attempting to send each portion of network security information to the primary supervisor device.
- an alternate supervisor device such as supervisor device 160 becomes unavailable, NSD 130 could first check the primary supervisor device for availability before checking other alternate supervisor devices, or could instead check the next supervisor device (supervisor device 210 ) that is associated with the NSD.
- Those skilled in the art will also appreciate that fail-over among multiple supervisor devices can occur in a variety of ways. For example, additional supervisor devices can be associated with an NSD only when needed, such as when the primary supervisor device becomes unavailable. In addition, the NSDs may use a currently associated host supervisor device for reasons other than storing network security information, such as for forwarding messages to the manager device or to other NSDs.
- FIG. 3A is a conceptual diagram illustrating the generation from a single security policy template of specific security policies for each of several NSDs and their respective internal networks.
- a security template 300 is first generated, such as by a user of the manager device. Then, for each of a number of different networks 315 , 325 , 335 , etc., the user generates a network profile containing NSD-specific information for implementation by the NSD protecting that network. These network profiles are shown as network profiles 310 , 320 , 330 , etc.
- the security policy template is combined with the network profile for that network. For example, in order to create security policy 315 for network 1 , the security policy template 300 is combined with network profile 310 for network 1 .
- FIG. 3B is a conceptual diagram illustrating the creation of a security policy in greater detail.
- FIG. 3B shows the creation of security policy 315 for network 1 shown in FIG. 3A.
- FIG. 3B shows that the security policy template 300 contains a number of security policy filter rules, including security policy rule 301 .
- Security policy rule 301 specifies that outgoing FTP connections are allowed only from network elements defined as being within the âInformationServicesâ alias. While only one security policy rule is shown in security policy template 300 to simplify this example, security policy templates often have a larger number of such security policy rules.
- the network profile 310 for network 1 contains a definition of the âInformationServicesâ alias 311 . It can be seen that this definition defines the âInformationServicesâ alias to include the network elements at the following IP addresses:
- a network profile contains an alias definition like alias definition 311 for each alias used in the security policy template.
- the facility replaces the âInformationServicesâ alias in rule 301 with the network addresses listed for the âInformationServicesâ alias in definition 311 . Doing so produces rule 316 in the security policy 315 for network 1 , which indicates that outgoing FTP connections are allowed only from the network elements having IP addresses 220.15.23.52, 220.15.23.53, and 220.15.23.97.
- each occurrence of an alias is replaced with the network addresses of the network elements defined to be within the alias in the network profile 310 for network 1 .
- the rules in security policy 315 for network 1 which are to be implemented in network 1 , specifically refer to network elements within network 1 . In this sense, they differ from the rules in security policies 325 and 335 , which specifically refer to network elements within networks 2 and 3 , respectively.
- FIGS. 3C-3H provide exemplary graphical user interface screens such as may be provided by a manager device to assist in defining security policy templates.
- aliases may be related to services and protocols (e.g., H323 and FTP) as well as to conceptual identifications of one or more network devices such as may be based on a particular NSD customer's network (e.g., Accounting, Marketing, Production, Sales, and TopMgmt). As is illustrated, filter rules have been defined for the H323 and FTP aliases. Referring now to FIG.
- Each filter rule can include associated information as to whether to generate network security information when the rule applies (e.g., via the Logging button).
- FIG. 3E an interface for defining aliases is shown along with a list of various defined exemplary aliases.
- FIG. 3F an example of a user interface for configuring a security policy template for a specific NSD of a particular customer is shown.
- a filter rule for the available service ping is shown.
- a WatchGuard service has also been defined to manage communications between the NSD and supervisor devices.
- Configuring the NSD can include specifying Contact Information for the customer (e.g., company name, contact person, customer ID, etc.), Identification and Access information (e.g., the NSD name and serial number, the NSD external IP address, a modem number that is used by the NSD, etc.), Network Configuration information (e.g., IP addresses for the default gateway and for the trusted, external and optional interfaces, as well as hosts and networks related to each of the interfaces), Out Of Band (OOB) information to specify how to communicate with the NSD in ways other than through the external network (e.g., via a modem or serial port), Route information (e.g., network routing information when the customer uses a router to connect one or more secondary networks to a network behind the NSD), Authentication information to specify how user and/or device authentication will be performed, Log Host information about the one or more supervisor devices associated with the NSD (e.g., a list of supervisor devices in order of precedence, with the primary supervisor device first, as well as password and other access
- FIGS. 3G and 3H provide exemplary information related to events of interest and the specifying of network security information of interest.
- various configuration information for an HTTP proxy service is shown, including types of information which may be denied passage (e.g., submissions, JAVATM or ACTIVEXTM applets, and various types of information such as audio, images, text, and video) as well as whether to log network security information about accesses of the service.
- FIG. 3G a GUI is shown for specifying how to generate network security information, such as for a filter rule or service, and how to notify indicated users or devices of the network security information.
- FIGS. 4A-4H provide an example of various network security information and NSD status information generated by implementing a specific security policy.
- network security information can include a variety of types of information about packets of interest, such as the direction, network interface, total length, protocol, header length, time to live, source IP address, destination IP address, source port, destination port, ICMP type and code, information about IP fragmentation, TCP flag bits, and IP options.
- the network security information can also include information about the logging itself, such as a time stamp, the action taken after applying filter rules, and information about the supervisor/host device such as the device name, corresponding process name, and corresponding process ID.
- FIGS. 5A-5D provide examples of a GUI displaying to a user of a manager device a hierarchical view of multiple supervisor devices and NSDs as well as corresponding configuration and network information.
- a manager device (âNetwork Operations Centerâ), two supervisor devices (âWEP_ 1 â and âWEP_ 2 â), and seven NSDs (âComputer_Enterprises,â âBilington_Insurance,â âGeneral_Automotive,â âFields_Bank,â âStarr_Manufacturing,â âVision_Cable,â and âGray_Design_Groupâ) are illustrated in the upper left pane of the GUI.
- the first three NSDs are currently associated with the WEP_ 1 supervisor device, and the next four NSDs are currently associated with the WEP_ 2 supervisor device.
- the hierarchical arrangement allows devices to be accessed in a variety of ways, such as by selecting all of the security devices associated with a supervisor device by merely selecting or indicating the supervisor device.
- supervisor devices and their associated security devices can be organized in a variety of ways, such as by geographical proximity or by conceptual similarity (e.g., grouping customers based on similar types of business).
- a variety of information about the devices can be displayed graphically (e.g., type of device and connection status).
- various information about the supervisor devices and NSDs can be displayed textually (e.g., the IP address, connection status, and phone number).
- the current contents of the right pane indicate that a variety of specific information can be displayed for a particular security device (in this example, âComputer_Enterprisesâ).
- other information accessible to the device executing the GUI can be displayed, such as the available security policy templates shown in the lower left pane.
- GUI graphical user interface
- other tools and information can also be accessed via the GUI (e.g., via the top-level menus, pop-up menus for particular displayed items, via the toolbar, etc.).
- GUI graphical user interface
- other available tools include the Security Management System (SMS) tool provides a GUI for viewing and modifying the existing security policy, as well as access to higher-level functions such as adjusting proxy settings, customizing web surfing rules and configuring a VPN.
- SMS Security Management System
- the SMS tool allows a user to specify access information for an NSD, examine or edit the configuration information of an NSD, save NSD configuration information either locally or on an NSD, add and delete services for the NSD, specify network-specific addresses for the NSD, set up logging and notification details about network security information, define default packet handling rules, block network information passing to or from certain IP addresses and port numbers, set up IP masquerading so that the NSD presents its IP address to the external network in lieu of any specific internal network addresses, set up port forwarding so that the NSD redirects incoming packets to a specific masqueraded device in the internal network based on the destination port numbers of the packets, determine the level of security for incoming and outgoing sessions using proxy services, and organize the internal network by defining aliases, defining groups of internal devices, and defining groups of users (e.g., with different levels of access privileges).
- Other tools also include the Status Viewer for retrieving specific status information about an NSD (e.g., version information, uptime, memory usage, active connections, etc.), the Log Viewer for displaying network security information, the Host Watch for providing a graphical view of real-time connections between an NSD's trusted and external networks, the Service Watch for graphing the number of connections of service, the Mazameter for displaying real-time bandwidth usage for a particular NSD interface, and the Historical Reporting to run NSD reports related to exceptions (such as denied packets), usage by supervisor device, service, or session, time series reports, masquerading information reports, and URL reports.
- exceptions such as denied packets
- FIG. 5B provides an example of a GUI for a Host Watch tool that provides a graphical view of real-time connections
- FIGS. 5C and 5D provide examples of GUIs for a Status Viewer tool.
- FIG. 5C indicates various users associated with specific IP addresses
- FIG. 5D includes information about IP addresses and ports which are currently blocked.
- FIG. 6 is an example of one or more NSD software components which can be distributed by a manager device to an NSD.
- the NSD is a security appliance device capable of executing the Linux operating system.
- the NSD can also perform additional tasks, such as providing support for Virtual Private Networks (VPNs).
- the NSD software components include a version of the Linux OS kernel 610 which is capable of executing on the NSD to provide various OS functionality (e.g., TCP/IP support, network drivers, etc.).
- the OS software component can also include an application programming interface (API) so that various other software components can interact with the OS kernel in a consistent manner.
- API application programming interface
- the packet filter engine 615 implements the specific security policy for the NSD, and interacts with various other software components including the firewall 630 , proxies for various network services 635 , and authentication software 640 .
- the firewall component can provide a variety of functions such as configuring security policy filter rules, providing an interface to implement communication and access security (e.g., via encryption), launching proxies for various network services, and communicating with management software of the NSD client (e.g., a business which owns the trusted devices protected by the NSD).
- the firewall component can provide a client API 645 which client computers can contact, or can instead communicate with such an API provided by the client.
- the various network service proxies can provide a variety of information about the activities and configuration of the proxies, and the authentication software can ensure that users or devices provide the necessary access information before gaining access to the NSD or being able to receive information (e.g., network security information) from the NSD.
- information e.g., network security information
- Other software components which interact directly with the OS include various functionality-specific drivers (e.g., VPN drivers) 620 , and various service and protocol drivers (e.g., TCP/IP driver) 625 .
- Most functionality-specific drivers will also have a corresponding software component which implements the functionality and which interacts with the driver, such as the VPN software 650 interacting with driver 620 .
- one or more software components may be associated with the service and protocol drivers to implement or provide support for those protocols and services, such as the initialization program 655 interacting with drivers 625 .
- the network security information logging component 660 provides network security information to supervisor devices. While the logging component could interact with other components such as the packet filter engine to retrieve the network security information of interest, the logging component could also retrieve the information from a temporary local storage without such direct interaction.
- the logging component can provide a supervisor device API 670 which supervisor devices can contact, or can instead communicate with such an API provided by the supervisor devices.
- the logging component can provide for the security of the information it provides in a variety of ways (e.g., encrypting the information before transmitting it).
- the software components 670 a variety of other optional software components can be provided to and executed by an NSD. These components may or may not interact with other displayed software components. Those skilled in the art will appreciate that various of the displayed software components may interact with each other even if such interaction is not graphically illustrated, that existing software components could be removed, and that various software components could alternately be grouped together into a single component or separated into separate sub-components. In addition, those skilled in the art will appreciate that various specific types of software (e.g., the Linux OS and the TCP/IP protocol) could be replaced with alternate types of software providing similar functionality.
- the Linux OS and the TCP/IP protocol could be replaced with alternate types of software providing similar functionality.
- the routine begins at step 705 where the NSD executes an initial boot program that loads the software to be executed by the NSD. After the software is loaded, the routine continues to step 710 to load various NSD-specific network packet filter rules that will be used to implement the specific security policy for the NSD, as well as any other NSD-specific configuration information.
- the software and NSD-specific configuration information will typically be stored in non-volatile memory (e.g., flash RAM or a magnetic disk) by the NSD, but can also be loaded from a remote device.
- step 810 If it is instead determined in step 810 that none of the filter rules apply, the subroutine continues to step 820 to determine a default action to be taken for the packets.
- a default action can be used, including denying passage of all packets that are not explicitly approved, blocking spoofing attacks, blocking port space probes, and blocking address space probes.
- step 825 the subroutine continues to step 825 to take the determined action on the packets.
- the possible actions include denying or allowing the passage of the packet to the intended recipient.
- step 825 the subroutine continues to step 895 and returns.
- a network information security policy can be implemented in ways other than using filter rules.
- default filtering rules can be used such that some filter rules will apply to any packet.
- a variety of actions can be taken on packets other than allowing or denying passage of the packets, including modifying the packets to add or remove information, or holding the packets until additional processing (e.g., manual review) can be performed on the packets.
- additional actions may be necessary for the subroutine based on the format of the packets. For example, determining whether a packet matches a filter rule may require first stripping various network transmission information from the packet, and this information may need to be added back to the packet if the determined action for the packet is to allow its passage to its intended recipient.
- FIG. 9 is an exemplary flow diagram of an embodiment of the Generate Network Security Information subroutine 725 .
- the subroutine determines whether an event of interest has occurred (e.g., the application of a filter rule of interest or the detection of a packet matching predefined characteristics of interest such as corresponding to a particular network service), logs network security information about the event if appropriate, and notifies one or more specified entities about the event if appropriate.
- the subroutine encrypts information before it is transmitted so that it can be transmitted over an external network without fear of the information of interest being intercepted.
- the subroutine begins at step 905 where information about the network information packets of interest are received.
- the subroutine continues to step 910 to determine if the packets indicate an event of interest for which network security information is to be logged.
- step 933 to encrypt the network security information in a manner accessible by the current supervisor device (e.g., with an asymmetric public key for the supervisor device, or with a symmetric key available to all supervisor devices).
- the subroutine then continues to step 935 to send the encrypted network security information to the current supervisor device. Any necessary access information (e.g., passwords) can also be included with the sent information.
- step 935 the subroutine continues to step 940 to determine if the packets are of a type that require immediate notification of one or more entities (e.g., users, devices, services, etc.). If so, the subroutine continues to step 945 to notify the designated entities in the appropriate manner, such as by using a predefined notification means (e.g., email, a pager, voice mail, a message containing predefined information, etc.). This communication can also be encrypted as appropriate.
- step 945 or if it is instead determined in step 940 that immediate notification of one or more entities is not required, the subroutine continues to step 995 and returns.
- events of interest which trigger the logging of network security information or the notification of some entity can be defined and identified in a variety of ways, such as any packets to or from a particular device or a device in a particular class of devices, any packets for which a specific action are taken (e.g., deny passage), any packets containing contents of interest (e.g., particular words or an attached file of a particular type), any packets corresponding to a particular type of network service (e.g., HTTP requests), etc.
- a variety of means for providing security to information being transmitted over a non-secure network can be utilized, including symmetric keys, asymmetric keys, passwords, etc.).
- FIG. 10 is an exemplary flow diagram of an embodiment of the Respond To Management Messages subroutine 730 .
- the subroutine determines whether the NSD has received a management-related message, determines whether the sender of the message is authorized to access management functions of the NSD, decrypts the message if necessary, and responds to the message when appropriate.
- the subroutine begins at step 1005 where information about the network information packets of interest are received.
- the subroutine continues to step 1010 to determine whether the packets contain a message that is directed to the NSD.
- step 1015 determines what access information (e.g., passwords, the sender being on a list of authorized devices, etc.) is required for the message, as well as any information needed to decrypt the message if it is encrypted (e.g., a password, or a public or private key).
- step sz 17 to decrypt the message if it is encrypted.
- step 1020 to verify whether the sender of the message has supplied any necessary access information and otherwise met any other access criteria.
- step 1025 determines if the message is a request for information (e.g., status of the NSD, NSD configuration information, or network security information), information being supplied (e.g., a security policy template, NSD-specific configuration information, or NSD software), or some other instruction (e.g., reboot the NSD so that new software is used). If it is determined in step 1025 that the message is a request for information, the subroutine continues to step 1030 to supply the requested information if possible, including encrypting the information before sending if appropriate (e.g., if the intended recipient is able to decrypt the information, and the information is sensitive or if all communications are encrypted) and including any necessary access information.
- information e.g., status of the NSD, NSD configuration information, or network security information
- information being supplied e.g., a security policy template, NSD-specific configuration information, or NSD software
- some other instruction e.g., reboot the NSD so that new software is used.
- step 1025 If it is determined in step 1025 that the message is information being supplied, the subroutine continues to step 1035 to store the information in the appropriate location. In addition, other actions may be taken automatically if appropriate, such as loading new software immediately if possible. If it is determined in step 1025 that the message is some other instruction, the subroutine continues to step 1040 to process the instruction if possible.
- step 1010 After steps 1030 , 1035 or 1040 , or if it was determined in step 1010 that the packets do not contain a message directed to the NSD or in step 1020 that the necessary access has not been verified, the subroutine continues to step 1095 and returns.
- a variety of types of messages can be supplied from a supervisor device, directly from a manager device, from another NSD, or from an internal device.
- management-related messages can include a variety of types of requests, information, and other instructions.
- FIG. 11 is an exemplary flow diagram of an embodiment of the Supervisor Device routine 1100 .
- the routine implements a host device for one or more NSDs by receiving network security information of interest and storing the information until requested by a manager device, as well as assisting the manager device in distributing various information to the NSDs which are currently associated with the supervisor device.
- the routine begins at step 1105 where the supervisor device executes an initial boot program that loads the software to be executed by the supervisor device.
- the software can be loaded from local or remote storage.
- the routine continues to step 1110 to wait for a message.
- the routine continues to step 1115 to decrypt the message if it is encrypted.
- the decryption can be done in a variety of ways, such as by retrieving decryption information based on the specific sender of the message or based on the type of sender (e.g., NSD or manager device).
- the routine then continues to step 1120 to determine if the message is from an NSD.
- routine processes the message by executing the Process NSD Message subroutine 1125 , and if not the routine processes the message by executing the Process Manager Or Supervisor Device Message subroutine 1130 .
- routine continues to step 1190 to determine whether to continue processing messages. If so, the routine returns to step 1110 , and if not the routine ends at step 1195 .
- a supervisor/host device can be implemented in a variety of ways, such as by using a general-purpose computer executing specialized software or by using a special-purpose computer.
- a general-purpose computer executing an operating system (e.g., SOLARISTM from Sun Microsystems) and executing software from WatchGuard Technologies, Inc., of Seattle, Wash., such as the WatchGuard Event Processor software, can be used to implement such aspects of a supervisor/host device.
- an operating system e.g., SOLARISTM from Sun Microsystems
- WatchGuard Technologies, Inc. of Seattle, Wash.
- each supervisor/host device may be able to support a large number (e.g., 500) of NSDs.
- FIG. 12 is an exemplary flow diagram of an embodiment of the Process NSD Message subroutine 1125 .
- the subroutine stores network security information sent by NSDs, notifies the manager device if an NSD not previously associated with the supervisor device begins sending information, and processes other NSD requests as appropriate.
- the subroutine begins at step 1205 where it receives a decrypted copy of the message sent from the NSD.
- the subroutine continues to step 1210 to determine if the sending NSD is on the list of NSDs that are currently associated with the supervisor device. If not, the subroutine continues to step 1215 to add the NSD to the current list.
- step 1215 or if it was instead determined that the sending NSD is on the list of NSDs that are currently associated with the supervisor device, the subroutine continues to step 1220 where any NSDs that are shown on the current list but which are not currently associated with the supervisor device are removed from the current list.
- Whether a listed NSD is still associated with the supervisor device can be determined in a variety of ways, such as by removing NSDs from whom no messages have been received for a certain amount of time or by removing NSDs indicated to be associated with other supervisor devices (e.g., by the NSD, the manager device, or the other supervisor device).
- step 1225 the manager device is notified of the changes in the current list of NSDs.
- this communication can be encrypted if appropriate and any necessary access information can be included in the message.
- step 1230 determines if the message from the NSD is composed of network security information. If so, the subroutine continues to step 1235 to store the information in the log maintained by the supervisor device. The information in the log is encrypted before it is stored so that any other device able to access the log cannot obtain access to the contents of the stored network security information. If it is determined in step 1230 that the message from the NSD is not composed of network security information, the subroutine instead continues to step 1240 to process the message from the NSD as appropriate. For example, the NSD may be using the supervisor device as an intermediary when sending a message to another device such as the manager device, another NSD, or another supervisor device. After steps 1235 or 1240 , the subroutine continues to step 1295 and returns.
- NSD messages can be processed in a variety of alternate ways.
- the list of NSDs may be purged on a periodic basis rather than when each new NSD message is received, and the manager device can be updated as to the changes in the list in a similar manner.
- each supervisor device can maintain a single log in which the network security information of multiple NSDs is stored, or can alternately maintain individual logs for each NSD.
- the supervisor device's log is not accessible to other devices, the information stored in the log file may not be encrypted, with the supervisor device instead encrypting the information before it is sent.
- FIG. 13 is an exemplary flow diagram of an embodiment of the Process Manager Or Supervisor Device Message subroutine 1130 .
- the subroutine receives a copy of a message from the manager device that is to be distributed to multiple NSDs, and distributes a copy of the message to each of those NSDs which are currently associated with the supervisor device.
- the subroutine also receives requests from the manager device or another supervisor device, such as requests from the manager device for the various (potentially distributed) network security information of an NSD, and responds to the request if possible.
- the subroutine begins at step 1305 where it receives a decrypted copy of the sent message.
- the subroutine then continues to step 1310 to determine if the intended recipients of the message include one or more NSDs. If so, the subroutine continues to step 1315 to send a copy of the message to each of the intended recipient NSDs which are on the list of NSDs currently associated with the supervisor device.
- the messages are sent in an encrypted manner if appropriate and any necessary access information is added to the message.
- step 1310 If it is instead determined in step 1310 that the received message is not intended for NSDs, the subroutine continues to step 1320 to determine if the message is a request from a manager device for the network security information of an NSD. If so, the subroutine continues to step 1325 to retrieve any portions of the requested information which are stored by the supervisor device in the log. The subroutine then continues to step 1330 to determine if any other supervisor devices store at least a portion of the requested information.
- the encryption of the network security information to be sent to the manager device can be handled in a variety of ways. If the other supervisor devices from which information is retrieved also encrypt the information stored in their logs, the information can be sent to the requesting supervisor device without decrypting the information. If the manager device is able to decrypt the various portions of the network security information encrypted by different supervisor devices (e.g., if all supervisor devices use the same key for encryption), then the requesting supervisor device can just forward the various encrypted portions of information to the manager device. Alternately, if the requesting supervisor device can decrypt the information from the various other supervisor devices, the requesting supervisor device can combine all of the network security information in a decrypted form and then encrypt the information before sending it to the manager device.
- each of the other supervisor devices to encrypt their network security information before sending it to the requesting supervisor device, with the encryption such that the requesting supervisor device can decrypt it (e.g., by using the public key of the requesting supervisor device).
- step 1320 If it was instead determined in step 1320 that the message received by the supervisor device is not a request from a manager device for the network security information of an NSD, the subroutine continues to step 1350 to process the message as appropriate.
- the message may be from another supervisor device that is gathering the network security information of an NSD in preparation for forwarding the information to the manager device. In this situation, the supervisor device forwards the requested network security information to the other supervisor device.
- steps 1315 , 1345 or 1350 the subroutine continues to step 1395 and returns.
- the routine begins at step 1405 where a graphical user interface (GUI) is displayed to the user.
- GUI graphical user interface
- This display provides a hierarchical tree view of the various supervisor devices and the NSDs which are associated with each supervisor device.
- a variety of other types of information can also be conveyed, such as the status of supervisor devices (e.g., available or unavailable), the status of NSDs, the flow of information that is occurring between devices, etc.
- the GUI also allows the user to easily enter management-related commands, and to display information of interest such as the aggregated network information of one or more NSDs.
- the routine continues to step 1410 to wait for a user command or for a message.
- step 1415 After receiving a user command or message, the routine continues to step 1415 to determine if a user command was received. If not, the routine continues to step 1420 to determine if the received message is an indication of a current association between an NSD and a supervisor device, such as after a fail-over when the indicated supervisor device became the current supervisor device for an NSD after the primary supervisor device for the NSD was unavailable. If it is determined in step 1420 that the received message is an indication of a current association between an NSD and a supervisor device, the routine continues to step 1425 to store the association information. If it is determined in step 1420 that the received message is not an indication of a current association between an NSD and a supervisor device, the routine continues to step 1430 to process the message as appropriate.
- step 1415 If it was instead determined in step 1415 that a user command was received, the routine continues to step 1435 to determine if the command is to create or modify a security policy template. If so, the routine continues to step 1440 to display a list of possible network services and protocols that may be of interest. The routine then continues to step 1445 where the user can indicate one or more services or protocols for which filter rules are to created. For each service or protocol, the user specifies the specific characteristics which network information packets must have to match the rule (e.g., from a specific sender to any recipient, or incoming messages from any device of a specified type or class). The user also specifies the appropriate action to be taken with network information packets that satisfy the rule.
- the user specifies the specific characteristics which network information packets must have to match the rule (e.g., from a specific sender to any recipient, or incoming messages from any device of a specified type or class). The user also specifies the appropriate action to be taken with network information packets that satisfy the rule.
- the user can also specify aliases which are to be customized with NSD-specific configuration information when the template is loaded on a particular NSD. For example, if the user defines one or more filter rules related to an internal HTTP server, an alias can be created that will eventually hold the NSD-specific information about the particular HTTP server. After the filter rules and other information of the security policy template are defined or modified, the security policy template is stored.
- step 1464 receives from the user an indication of the NSDs to receive either the template or the software components.
- the routine continues to step 1466 to determine the one or more supervisor devices currently associated with the indicated NSDs, and then continues to step 1468 to send a single copy of the information to be distributed to each of the determined supervisor devices.
- the copy of the information sent to the supervisor devices includes an indication of the NSDs that are to receive the information being distributed.
- step 1470 determines if the command is to configure an NSD by supplying NSD-specific information to customize a security policy template. If so, the routine continues to step 1472 to receive an indication of the NSD to be configured. The routine then continues to step 1474 to receive an indication from the user of the NSD-specific information which is to be used to configure the NSD. The routine then determines in step 1476 the supervisor device that is currently associated with the NSD, and in step 1478 sends the NSD-specific information to the supervisor device for forwarding to the NSD. Those skilled in the art will appreciate that rather than merely sending the information to the NSD, the supervisor device could send instructions to the NSD to load or modify the configuration of the NSD in an appropriate manner.
- step 1480 determines if the command is to retrieve aggregated network security information from an NSD. If so, the routine continues to step 1482 to receive an indication of the NSD. The routine then continues to step 1484 to determine the supervisor device that is currently associated with the NSD, and in step 1485 determines all supervisor devices which store network security information for the NSD. The routine then continues to step 1486 to notify the current supervisor device to retrieve the network security information of interest for the NSD, including indicating to the current supervisor device the other supervisor devices which may store portions of the network security information. The routine then continues to step 1487 to wait for the network security information. After receiving the network security information, the routine in step 1488 aggregates the network security information as appropriate. Those skilled in the art will appreciate that the network security information can be aggregated in a variety of ways, either automatically or in response to user indications.
- step 1490 the routine continues to step 1492 to determine whether to continue processing messages and commands. If so, the routine returns to step 1410 , and if not the routine ends at step 1495 .
- a manager device can be implemented in a variety of ways, such as by using a general-purpose computer executing specialized software or by using a special-purpose computer.
- a general-purpose computer executing an operating system (e.g., WINDOWS 95TM or WINDOWS NTTM from Microsoft Corp.) and executing software from WatchGuard Technologies, Inc., of Seattle, Wash., such as the Global Policy Manager, Graphical Monitor, Historical Reporting Module, Global Console, WebBlocker, Branch Office VPN, Network Configuration Wizard and Security Management System (SMS) Control Center software components, can be used to implement some aspects of a manager device.
- an operating system e.g., WINDOWS 95TM or WINDOWS NTTM from Microsoft Corp.
- software from WatchGuard Technologies, Inc. of Seattle, Wash.
- the Global Policy Manager Graphical Monitor, Historical Reporting Module, Global Console, WebBlocker, Branch Office VPN, Network Configuration Wizard and Security Management System (SMS) Control Center software components
- SMS Security Management System
Abstract
Description
- This is a continuation of and claims priority to U.S. patent application Ser. No. 09/307,332, filed on May 6, 1999, and which is hereby incorporated herein by reference.
- The present invention relates generally to communicating information between computers, and more particularly to using a manager device to remotely manage multiple network security devices.
- As computer systems and other network devices (e.g., printers, modems, and scanners) have become increasingly interconnected, it is increasingly important to protect sensitive information (e.g., confidential business data, access information such as passwords, or any type of data stored on certain devices) stored on one network device from unauthorized retrieval by other network devices. The prevalence of the Internet and the growth of the World Wide Web have only exacerbated this issue.
- One way to address this issue involves the use of network security devices (âNSDsâ) which attempt to control the spread of sensitive information so that only authorized users or devices can retrieve such information. Some types of NSDs, such as firewalls and security appliances, have a group of one or more trusted network devices (or networks consisting of trusted network devices) which the NSD attempts to protect from unauthorized external access. These NSDs monitor network information passing between external network devices and the devices in their group of trusted or internal devices. In addition, these NSDs typically implement a specified security policy by preventing the passage of unauthorized network information between the external and the trusted devices.
- Those skilled in the art will appreciate that network information can be transmitted in a variety of formats. For example, network information is often transmitted as a series of individual packets of information, such as TCP/IP (Transfer Control Protocol/Internet Protocol) packets. While such packets will typically include the network address (e.g., IP address) of the device to receive the information, other data about the network information (e.g., the specific type of information being requested or sent) may be difficult to ascertain.
- While a properly configured NSD can protect information stored on or accessible from trusted devices, it can be difficult to configure NSDs so that they correctly implement the desired security policies. One source of difficulty in configuring NSDs arises from the large number of types of network information which may be encountered. For example, there are a large number of network services and protocols which external devices may attempt to provide to trusted devices or access from trusted devices.
- Such network services and protocols include, but are not limited to, Archie, auth (ident), DCE-RPC (Distributed Computing Environment Remote Procedure Call), DHCP (Dynamic Host Configuration Protocol) Client and Server, DNS (Domain Name Service), finger, FTP (File Transfer Protocol), gopher, H.323, HTTP (HyperText Transfer Protocol), Filtered-HTTP, Proxied-HTTP, ICMP (Internet Control Message Protocol), NNTP (Network News Transfer Protocol), NTP (Network Time Protocol), ping, POP (Post Office Protocol) 2 and 3, RealNetworks, rlogin, rsh (Remote SHell), SMB (Simple Block Messaging), SMTP (Simple Mail Transfer Protocol), SNMP (Simple Network Management Protocol), syslog, ssh (Secure SHell), StreamWorks, TCP/IP, telnet, Time, traceroute, UDP (User Datagram Protocol), VDOLive, WAIS (Wide Area Information Services), whois, and other device-specific services. Those skilled in the art will appreciate the uses and details of these services and protocols, including the device ports typically used with the services and protocols and the specified format for such information (e.g., the TCP/IP packet definition).
- Another source of difficulty in configuring NSDs arises from the variety of ways to handle network information of different types. For example, for each type of service or protocol, a NSD may wish to take different actions for (e.g., allow passage of, deny passage of, or otherwise manipulate) the corresponding network information of that service or protocol. The decision to take these different actions can also be based on additional factors such as the direction of information flow (i.e., whether the network information is passing from a trusted device or to a trusted device) or on the basis of the sender or the intended recipient of the information (e.g., whether the network information is passing from or to specific network devices or is passing from or to any network device of a specified class, such as any external device).
- The types of actions to be taken for the monitored network information (based on the various factors such as the services and protocols being used, the direction of the information flow, and the classes of devices of the sender and the intended recipient) provide an initial incomplete security policy. Various device-specific information is necessary to configure a particular NSD with a specific security policy that can be implemented by the device. The device-specific information which must typically be specified to create a specific security policy includes, for example, the network address of the NSD and the network addresses of some or all of the trusted devices. If a particular network service is to be provided to external devices by a trusted device, such as FTP access, information about the trusted FTP server must also be available to the NSD.
- A user such as a system administrator typically defines the specific security policy for a NSD by determining the services and protocols of interest and then configuring the NSD to protect the trusted devices as appropriate. However, configuring an NSD can be time-consuming, and any mistakes in the configuration (e.g., failure to define how a particular service should be handled, or allowing default behaviors to allow passage of network information) can compromise the ability of the NSD to protect sensitive information. Thus, the need for system administrators to configure each NSD can cause various problems.
- When it is necessary to configure large numbers of NSDs, such problems are only exacerbated. If the security policies across some or all of the NSDs should be consistent (e.g., multiple devices in use by a single company), the likelihood of mistakes increases. If the system administrator merely copies the specific security policy from one NSD to another, mistakes may occur in re-specifying the various NSD-specific configuration information. Alternately, if the system administrator attempts to re-create the general security policy independently on each NSD, various mistakes may occur such as neglecting to configure a type of service or incorrectly configuring the actions for such a type.
- In addition to implementing security policies which may restrict the passage of some network information, NSDs typically gather network security information about events of interest, including encountering types of network information that is encountered as well as various actions taken by the NSD. The network security information can be displayed to users such as system administrators so that they can verify that the security policy is correctly implemented, produce reports about the types and quantities of network information that is allowed to pass and that is blocked from passage, and identify when external activities of concern (e.g., a hacker attack on the NSD) are occurring. NSDs typically maintain a local storage, often referred to as a log, of the security information that they gather.
- Some NSDs include computer software components executing on general-purpose or dedicated computer hardware. For such an NSD, the executing software components assist in implementing the specific security policies defined for the NSD. Use of software components allows the operation of the NSD to be upgraded in an efficient manner by replacing some or all of the existing software components with new software components. Such new software is typically distributed via physical media such as CDs or optical disks, and is loaded onto the NSD by an individual such as a system administrator.
- Some embodiments of the present invention provide a facility for using a security policy manager device to remotely manage multiple network security devices (NSDs). In some embodiments, the manager device uses one or more intermediate supervisor devices to assist in the management. Security for the communications between the manager device, supervisor devices, and NSDs can be provided in a variety of ways.
- The facility allows the manager device to create a consistent security policy for the multiple NSDs by distributing a copy of a security policy template to each of the NSDs and by then configuring each copy of the template with NSD-specific information. For example, the manager device can distribute the template to multiple NSDs by sending a single copy of the template to a supervisor device associated with the NSDs and by then having the supervisor device update each of the NSDs with a copy of the template. Other information useful for implementing security policies for the NSDs, such as software components to be executed by the NSDs, can also be distributed by the manager device to the NSDs in a similar manner.
- The facility also allows a manager device to retrieve, analyze and display the network security information gathered by the various NSDs while implementing security policies. Each NSD can forward its network security information to a supervisor device currently associated with the NSD, and can switch supervisor devices if the current supervisor device becomes unavailable. When the manager device desires the network security information for an NSD, the manager device contacts the one or more supervisor devices which store portions of the network security information of interest, retrieves the various portions of the network security information, and then aggregates the retrieved information in an appropriate manner.
- FIG. 1 is a block diagram illustrating an embodiment of the Network Security Device Management (NSDM) system of the present invention.
- FIG. 2 is a block diagram illustrating the flow of network security information from a network security device (NSD) to the manager device.
- FIGS. 3A-3H are examples of security policy templates.
- FIGS. 4A-4H are an example of network security information generated by implementing a specific security policy.
- FIGS. 5A-5D are examples of a manager device's hierarchical view of multiple supervisor devices and NSDs and of corresponding configuration and network information.
- FIG. 6 is an example of one or more NSD software components which can be distributed by a manager device.
- FIG. 7 is an exemplary flow diagram of an embodiment of the Network Security Device routine.
- FIG. 8 is an exemplary flow diagram of an embodiment of the Filter Network Packets subroutine.
- FIG. 9 is an exemplary flow diagram of an embodiment of the Generate Network Security Information subroutine.
- FIG. 10 is an exemplary flow diagram of an embodiment of the Respond To Management Message subroutine.
- FIG. 11 is an exemplary flow diagram of an embodiment of the Supervisor Device routine.
- FIG. 12 is an exemplary flow diagram of an embodiment of the Process NSD Message subroutine.
- FIG. 13 is an exemplary flow diagram of an embodiment of the Process Manager Or Supervisor Device Message subroutine.
- FIGS. 14A and 14B are exemplary flow diagrams of an embodiment of the Manager Device routine.
- An embodiment of the present invention provides a method and system for using a manager device to remotely manage multiple network security devices. In particular, the Network Security Device Management (NSDM) system allows a security policy manager device to create a consistent security policy for multiple network security devices (NSDs) by distributing a copy of a security policy template to each of the NSDs and by then configuring each copy of the template with NSD-specific information. Other information useful for implementing security policies for the NSDs, such as software components to be executed by the NSDs or lists of devices from whom information is to be blocked, can also be distributed by the manager device to the NSDs in a similar manner. The NSDM system also allows a manager device to retrieve, analyze and display the network security information gathered by the various NSDs while implementing security policies. In some embodiments, the manager device uses one or more intermediate supervisor devices to assist in managing the multiple NSDs.
- Security policy templates can be defined by a user of the manager device and then used to implement consistent network security policies across multiple NSDs while reducing the risk of configuration error. Each template defines default network information filtering rules for various common services and protocols, and uses defined aliases to represent various specific devices of interest for a particular NSD. Security policy templates are discussed in greater detail below, as well as in the co-pending U.S. Patent Application entitled âGENERALIZED NETWORK SECURITY POLICY TEMPLATES FOR IMPLEMENTING SIMILAR NETWORK SECURITY POLICIES ACROSS MULTIPLE NETWORKS,â filed May 6, 1999, incorporated herein by reference.
- In order to remotely manage multiple NSDs, a manager device can use one or more intermediate supervisor devices. For example, after a security policy template is defined, the manager device can distribute the template to multiple NSDs by sending a single copy of the template to a supervisor device associated with the NSDs and by then having the supervisor device update each of the NSDs with a copy of the template. Each of the NSD template copies can then be configured with NSD-specific information from one or more of a variety of sources, such as by the manager device, by a local user such as a system administrator, or automatically such as with DNS information. In particular, aliases in the template copy on a particular NSD can be replaced with information about the specific corresponding devices that are protected by the NSD, and NSD-specific access information can also be specified. For example, an alias for an HTTP server can be replaced with the specific network address and name of the actual HTTP server.
- Other information useful for implementing security policies for the NSDs, such as software components to be executed by the NSDs, lists of devices to be blocked (i.e., to block information flowing from and/or to the device), or updates to existing templates in use, can also be distributed by the manager device to the NSDs in a similar manner via the supervisor devices. Such information can also be configured with NSD-specific information if necessary in the manner described above. Those skilled in the art will appreciate that configuration of an NSD can occur not only when the NSD is initially installed, but also at later times. In addition to providing information to the NSDs, the manager device can also provide various types of information to the supervisor devices (e.g., software updates for software executing on the supervisor devices).
- One or more intermediate supervisor devices can also assist the manager device in retrieving, analyzing and displaying the network security information gathered by the various NSDs. As each NSD executes and implements its specific security policy, the NSD gathers network security information about its activities and about the network information that is monitored. Each NSD forwards its network security information to a host supervisor device currently associated with the NSD so that the supervisor device can host the network security information by storing and/or processing it. If the supervisor device currently associated with an NSD becomes unavailable, the NSD instead forwards its network security information to one or more alternate host supervisor devices. In this manner, even if one supervisor device becomes unavailable, the network security information for the NSDs that were associated with the supervisor device is not lost. When the manager device wants to retrieve the network security information for an NSD, the manager device contacts the one or more supervisor devices which store portions of the network security information of interest, retrieves the various portions of the network security information, and then aggregates the retrieved information in an appropriate manner.
- In some embodiments, the manager device and supervisor devices are external devices. Security for the communications between the manager device, supervisor devices, and NSDs can be provided in a variety of ways. For example, any of the information transmitted between the NSDs and the supervisor devices and between the supervisor devices and the manager device can be protected from unauthorized access by encrypting the information (e.g., using Data Encryption Standard (DES) in Cipher Block Chaining (CBC) mode). In addition, various schemes can be used to ensure that NSDs and supervisor devices provide information only to authorized devices or users, such as by using passwords, hashing passwords to produce keys, challenge/response, shared secrets, digital IDs, or a list of devices defined as being authorized to request and/or receive information. Part of the NSD-specific configuration of each NSD can include associating one or more supervisor devices authorized to communicate with the NSD, as well as providing specific information about how the communication is to occur. User authentication can be performed in a variety of ways, such as by using WINDOWS NTâą Domain Users and Groups RADIUS user authentication, or CRYPTOcard.
- Referring now to FIG. 1, an embodiment of the Network Security Device Management (NSDM)
system 100 includes a securitypolicy manager device 110 able to communicate withmultiple supervisor devices supervisor device 120 associated withNSDs 130 through 140 and withsupervisor device 160 associated withNSDs 161 through 162. Each NSD protects one or more trusted devices from external devices, such asNSDs internal networks external network 190. For the sake of brevity,supervisor device 160 andNSDs 161 through 162 are not described in detail. - In some embodiments, additional classes of devices which the NSD will protect are defined, with different security policies defined for each class of devices. For example, internal devices which are in direct communication with external devices (e.g., HTTP and FTP servers) may be specified in an optional class. Optional devices are typically afforded some level of trust greater than external devices but less than trusted devices, such as by monitoring some communications between optional and trusted devices. Thus, security policy templates and specific security policies can be viewed as defining levels of trust given to various specific devices or classes of devices.
- Each NSD has a supervisor device which is designated as the primary supervisor device for that NSD. For example,
supervisor device 120 is the primary supervisor forNSDs 130 through 140, and those NSDs store information about supervisor device 120 (e.g., the device's network address) with their respective specificsecurity policy information storage devices supervisor device 160 is the primary supervisor forNSDs 161 through 162.NSDs supervisor device 120 must provide in order to gain access to the NSDs) along with their respectivedevice access information NSD access information 115 and specificsecurity policy information 116 respectively. Those skilled in the art will appreciate thatstorage devices - The manager device has one or more input/output devices118 (such as a display) to enable a user (not shown) to interact with the manager device. The manager device also stores a variety of information on
storage device 111, including one or more NSD software updates 112,security policy templates 113, and aggregatednetwork security information 114 from one or more NSDs. The manager device also optionally stores supervisor device and NSD access information 115 (e.g., passwords and a decryption key for stored information) as well as specific security policy information 116 (including NSD-specific configuration information) for one or more NSDs. Those skilled in the art will appreciate thatstorage device 111 can be implemented in a variety of ways, such as by using local or remote storage, and by using a variety of storage media (e.g., magnetic disk, flash RAM, etc.). - When a user of the manager device desires to establish or modify a security policy for one or more NSDs such as
NSDs security policy templates 113 or creates a new security policy template. Security policy templates are discussed in greater detail below with respect to FIG. 3. The manager device then determines the one or more primary supervisor devices for the NSDs of interest, such as by retrieving this information from its specificsecurity policy information 116. If this information is not stored by the manager device, the manager device can obtain the information in a variety of ways, such as by querying the NSDs of interest or by querying the various known supervisor devices. - After the one or more primary supervisor devices are known, the manager device sends a single copy of the security policy template to each of the primary supervisor devices. For example, if the
NSDs supervisor device 120. The primary supervisor devices then send a copy of the security policy template to each of the selected NSDs. Each NSD stores its copy of the security policy template with the NSD's specific security information. - Each NSD's copy of the security policy template can then be configured with information specific to the NSD. For example, information about specific devices of interest from
internal network 135 will be retrieved, and will be used to configure the security policy template forNSD 130. This NSD-specific information will be used to configure the security policy template into a specific security policy for the NSD, and the information will be stored with the specific security policy information for the NSD. The NSD-specific configuration can be conducted by a user via the manager device, by a local user such as a system administrator for the NSD, or automatically via a device-identifying service such as DNS. - When a user of the manager device desires to initially load or modify the software to be executed by one or more NSDs such as
NSDs information 112. The user can update some or all of the software components used by the NSDs. The manager device then distributes the software components to the NSDs in the same manner as for the security policy templates, including configuring the copies of the software with NSD-specific information if necessary. Each NSD stores the software, such asNSDs security device software - As the NSDs execute their specific security policies, they gather various network security information of interest. Each NSD forwards its network security information to its primary supervisor device for storage. The network security information can be forwarded to the supervisor device in a variety of ways, such as immediately upon generation, on a periodic basis, or when the supervisor device requests the information. For example,
NSDs supervisor device 120 for storage in the supervisor device's network security information log 125. Ifsupervisor device 120 becomes unavailable,NSDs supervisor device 160.Supervisor device 160 stores the network security information it receives in network security information log 165. Thus, each supervisor device maintains one or more logs containing network security information sent by NSDs associated with the supervisor device. - When a user of the manager device desires to see the network security information of an NSD such as
NSD 120, the manager device retrieves the network security information from each supervisor device which stores any of the network security information (e.g., any security information generated between two specified times, or all security information that is available). The manager device can determine these one or more supervisor devices in a variety of ways. For example, each of the supervisor devices can periodically inform the manager device of the NSDs which are currently associated with the supervisor device, and the manager device can store this information with its specificsecurity policy information 116. The manager device can then aggregate the network security information that is retrieved from multiple supervisor devices in a variety of ways, such as chronologically, by event type, etc. This aggregated network security information can be stored by the manager device in the aggregatednetwork security information 114 of the manager device, either individually or with the security information of other NSDs. - Those skilled in the art will appreciate that each device of the NSDM system may be composed of various components such as a CPU, memory, input/output devices (e.g., a display and a keyboard), and storage (e.g., a hard disk or non-volatile flash RAM). In addition, those skilled in the art will appreciate that the described embodiment of the NSDM system is merely illustrative and is not intended to limit the scope of the present invention. The system may contain additional components or may lack some illustrated components. In particular, there may be multiple manager devices and/or multiple hierarchical layers of supervisor devices such that some supervisor devices supervise other supervisor devices. Alternately, the manager device and one or more supervisor devices may be implemented as a single computer system such that the manager device communicates directly with NSDs. Also, in some embodiments the devices which host network security information for the NSDs can be separate devices from those which supervise and send management information to the NSDs. Accordingly, the present invention may be practiced with other configurations.
- Referring now to FIG. 2, an embodiment of the NSDM system is used to illustrate how network security information from an NSD is stored by multiple supervisor devices. In some embodiments, each NSD has not only a primary supervisor device which is associated with the NSD, but also one or more additional associated supervisor devices (e.g., secondary and tertiary devices, or multiple secondary devices). As with the primary supervisor device, these additional supervisor devices for an NSD can be specified in a variety of ways, such as by a user of the manager device during configuration of the NSD or automatically based on a variety of criteria (e.g., geographic proximity to the NSD, capacity of the supervisor device, etc.). Each NSD can store information about the additional supervisor devices with their specific security policy information, as well as any required access information for the additional supervisor devices along with their device access information.
- As is discussed above with respect to FIG. 1,
supervisor device 120 has been designated as the primary supervisor device forNSD 130. As is illustrated in FIG. 2, two other supervisor devices have also been associated withNSD 130. In particular,supervisor device 160 has been designated as a secondary supervisor device forNSD 130, andsupervisor device 210 has been designated as a tertiary supervisor device. Those skilled in the art will appreciate that any number of supervisor devices could be associated with any given NSD, and that different NSDs can have different groups of associated supervisor devices.Supervisor devices supervisor devices policy manager device 110. - As is illustrated,
NSD 130 protects multiple trusteddevices 220 through 230 ininternal network 135 from external devices in external network 190 (not shown). AsNSD 130 implements its specific security policy and notes events of interest, it gathers various network security information related to the events. WhenNSD 130 has network security information that is to be transmitted to a supervisor device for storage,NSD 130 first determines ifprimary supervisor device 120 is available to host the information (e.g., by sending a status query message to the device). Ifprimary supervisor device 120 is able to receive network security information fromNSD 130 and has the capacity to store the information,NSD 130 sends the network security information tosupervisor device 120 for storage in the network security information log 125. - If, however,
primary supervisor device 120 is not available to host the network security information fromNSD 130, the NSD determines an alternate host supervisor device (referred to as a âfail-overâ). Sincesupervisor device 160 has been designated as the only secondary supervisor device,NSD 130 determines if that supervisor device is available to host the network security information. If so,supervisor device 160 becomes the supervisor device currently associated withNSD 130, and the NSD forwards the information to the supervisor device. Ifsupervisor device 160 is not available, the NSD determines a next supervisor device (e.g., supervisor device 210) to check for availability. In this manner, the network security information for a single NSD may be stored across multiple host supervisor devices. As discussed above, the manager device can be informed as to the NSDs currently associated with each supervisor device in a variety of ways, such as by the supervisor devices or the NSDs periodically sending status messages to the manager device. - The details of how the fail-over process works can be implemented in a variety of ways. For example, in some embodiments after
NSD 130 has switched its current association to an alternate supervisor device such assupervisor device 160,NSD 130 will continue to use that supervisor device as its host device until that supervisor device becomes unavailable. Alternately, the NSD could instead continue to try to send network security information to its primary supervisor device even if the current supervisor device remains available, such as by periodically checking the availability of the primary supervisor device or by first attempting to send each portion of network security information to the primary supervisor device. In addition, if an alternate supervisor device such assupervisor device 160 becomes unavailable,NSD 130 could first check the primary supervisor device for availability before checking other alternate supervisor devices, or could instead check the next supervisor device (supervisor device 210) that is associated with the NSD. - Those skilled in the art will also appreciate that fail-over among multiple supervisor devices can occur in a variety of ways. For example, additional supervisor devices can be associated with an NSD only when needed, such as when the primary supervisor device becomes unavailable. In addition, the NSDs may use a currently associated host supervisor device for reasons other than storing network security information, such as for forwarding messages to the manager device or to other NSDs.
- FIGS. 3A-3H are examples of security policy templates. FIG. 3A is a conceptual diagram illustrating the generation from a single security policy template of specific security policies for each of several NSDs and their respective internal networks. A
security template 300 is first generated, such as by a user of the manager device. Then, for each of a number ofdifferent networks security policy 315 fornetwork 1, thesecurity policy template 300 is combined withnetwork profile 310 fornetwork 1. - FIG. 3B is a conceptual diagram illustrating the creation of a security policy in greater detail. In particular, FIG. 3B shows the creation of
security policy 315 fornetwork 1 shown in FIG. 3A. FIG. 3B shows that thesecurity policy template 300 contains a number of security policy filter rules, includingsecurity policy rule 301.Security policy rule 301 specifies that outgoing FTP connections are allowed only from network elements defined as being within the âInformationServicesâ alias. While only one security policy rule is shown insecurity policy template 300 to simplify this example, security policy templates often have a larger number of such security policy rules. - The
network profile 310 fornetwork 1 contains a definition of the âInformationServicesâalias 311. It can be seen that this definition defines the âInformationServicesâ alias to include the network elements at the following IP addresses: - 220.15.23.52
- 220.15.23.53
- 220.15.23.97
- In general, a network profile contains an alias definition like
alias definition 311 for each alias used in the security policy template. - When the
security policy template 300 and thenetwork profile 310 fornetwork 1 are combined to create thesecurity policy 315 fornetwork 1, the facility replaces the âInformationServicesâ alias inrule 301 with the network addresses listed for the âInformationServicesâ alias indefinition 311. Doing so producesrule 316 in thesecurity policy 315 fornetwork 1, which indicates that outgoing FTP connections are allowed only from the network elements having IP addresses 220.15.23.52, 220.15.23.53, and 220.15.23.97. In the same manner, for each additional rule insecurity policy template 300, each occurrence of an alias is replaced with the network addresses of the network elements defined to be within the alias in thenetwork profile 310 fornetwork 1. As a result, the rules insecurity policy 315 fornetwork 1, which are to be implemented innetwork 1, specifically refer to network elements withinnetwork 1. In this sense, they differ from the rules insecurity policies networks - FIGS. 3C-3H provide exemplary graphical user interface screens such as may be provided by a manager device to assist in defining security policy templates. Referring now to FIG. 3C, a variety of aliases are available to be used in creating security policy templates. Note that aliases may be related to services and protocols (e.g., H323 and FTP) as well as to conceptual identifications of one or more network devices such as may be based on a particular NSD customer's network (e.g., Accounting, Marketing, Production, Sales, and TopMgmt). As is illustrated, filter rules have been defined for the H323 and FTP aliases. Referring now to FIG. 3D, a specific filter rule such as for a particular service is illustrated in detail, allowing control for incoming and outgoing packets based on specific senders and recipients. Each filter rule can include associated information as to whether to generate network security information when the rule applies (e.g., via the Logging button). Referring now to FIG. 3E, an interface for defining aliases is shown along with a list of various defined exemplary aliases.
- Referring now to FIG. 3F, an example of a user interface for configuring a security policy template for a specific NSD of a particular customer is shown. In particular, a filter rule for the available service ping is shown. In the illustrated embodiment, a WatchGuard service has also been defined to manage communications between the NSD and supervisor devices. Configuring the NSD can include specifying Contact Information for the customer (e.g., company name, contact person, customer ID, etc.), Identification and Access information (e.g., the NSD name and serial number, the NSD external IP address, a modem number that is used by the NSD, etc.), Network Configuration information (e.g., IP addresses for the default gateway and for the trusted, external and optional interfaces, as well as hosts and networks related to each of the interfaces), Out Of Band (OOB) information to specify how to communicate with the NSD in ways other than through the external network (e.g., via a modem or serial port), Route information (e.g., network routing information when the customer uses a router to connect one or more secondary networks to a network behind the NSD), Authentication information to specify how user and/or device authentication will be performed, Log Host information about the one or more supervisor devices associated with the NSD (e.g., a list of supervisor devices in order of precedence, with the primary supervisor device first, as well as password and other access information needed to interact with the devices), and Miscellaneous information such as the current time zone.
- FIGS. 3G and 3H provide exemplary information related to events of interest and the specifying of network security information of interest. Referring first to FIG. 3H, various configuration information for an HTTP proxy service is shown, including types of information which may be denied passage (e.g., submissions, JAVAâą or ACTIVEXâą applets, and various types of information such as audio, images, text, and video) as well as whether to log network security information about accesses of the service. Referring now to FIG. 3G, a GUI is shown for specifying how to generate network security information, such as for a filter rule or service, and how to notify indicated users or devices of the network security information.
- Those skilled in the art will appreciate that this information is provided for exemplary purposes only, and that the invention is not limited to the specific details discussed.
- FIGS. 4A-4H provide an example of various network security information and NSD status information generated by implementing a specific security policy. Those skilled in the art will appreciate that network security information can include a variety of types of information about packets of interest, such as the direction, network interface, total length, protocol, header length, time to live, source IP address, destination IP address, source port, destination port, ICMP type and code, information about IP fragmentation, TCP flag bits, and IP options. The network security information can also include information about the logging itself, such as a time stamp, the action taken after applying filter rules, and information about the supervisor/host device such as the device name, corresponding process name, and corresponding process ID.
- Those skilled in the art will also appreciate that this information is provided for exemplary purposes only, and that the invention is not limited to the specific details discussed.
- FIGS. 5A-5D provide examples of a GUI displaying to a user of a manager device a hierarchical view of multiple supervisor devices and NSDs as well as corresponding configuration and network information.
- Referring now to FIG. 5A, a manager device (âNetwork Operations Centerâ), two supervisor devices (âWEP_1â and âWEP_2â), and seven NSDs (âComputer_Enterprises,â âBilington_Insurance,â âGeneral_Automotive,â âFields_Bank,â âStarr_Manufacturing,â âVision_Cable,â and âGray_Design_Groupâ) are illustrated in the upper left pane of the GUI. The first three NSDs are currently associated with the WEP_1 supervisor device, and the next four NSDs are currently associated with the WEP_2 supervisor device. The hierarchical arrangement allows devices to be accessed in a variety of ways, such as by selecting all of the security devices associated with a supervisor device by merely selecting or indicating the supervisor device. Note that supervisor devices and their associated security devices can be organized in a variety of ways, such as by geographical proximity or by conceptual similarity (e.g., grouping customers based on similar types of business).
- As is illustrated by the icons shown beside the devices in the left pane, a variety of information about the devices can be displayed graphically (e.g., type of device and connection status). In addition, as is shown in the right pane of the GUI, various information about the supervisor devices and NSDs can be displayed textually (e.g., the IP address, connection status, and phone number). The current contents of the right pane indicate that a variety of specific information can be displayed for a particular security device (in this example, âComputer_Enterprisesâ). Similarly, other information accessible to the device executing the GUI can be displayed, such as the available security policy templates shown in the lower left pane.
- In addition to the currently displayed information, other tools and information can also be accessed via the GUI (e.g., via the top-level menus, pop-up menus for particular displayed items, via the toolbar, etc.). For example, other available tools include the Security Management System (SMS) tool provides a GUI for viewing and modifying the existing security policy, as well as access to higher-level functions such as adjusting proxy settings, customizing web surfing rules and configuring a VPN. The SMS tool allows a user to specify access information for an NSD, examine or edit the configuration information of an NSD, save NSD configuration information either locally or on an NSD, add and delete services for the NSD, specify network-specific addresses for the NSD, set up logging and notification details about network security information, define default packet handling rules, block network information passing to or from certain IP addresses and port numbers, set up IP masquerading so that the NSD presents its IP address to the external network in lieu of any specific internal network addresses, set up port forwarding so that the NSD redirects incoming packets to a specific masqueraded device in the internal network based on the destination port numbers of the packets, determine the level of security for incoming and outgoing sessions using proxy services, and organize the internal network by defining aliases, defining groups of internal devices, and defining groups of users (e.g., with different levels of access privileges).
- Other tools also include the Status Viewer for retrieving specific status information about an NSD (e.g., version information, uptime, memory usage, active connections, etc.), the Log Viewer for displaying network security information, the Host Watch for providing a graphical view of real-time connections between an NSD's trusted and external networks, the Service Watch for graphing the number of connections of service, the Mazameter for displaying real-time bandwidth usage for a particular NSD interface, and the Historical Reporting to run NSD reports related to exceptions (such as denied packets), usage by supervisor device, service, or session, time series reports, masquerading information reports, and URL reports.
- FIG. 5B provides an example of a GUI for a Host Watch tool that provides a graphical view of real-time connections, and FIGS. 5C and 5D provide examples of GUIs for a Status Viewer tool. FIG. 5C indicates various users associated with specific IP addresses, and FIG. 5D includes information about IP addresses and ports which are currently blocked.
- Those skilled in the art will also appreciate that this information is provided for exemplary purposes only, and that the invention is not limited to the specific details discussed.
- FIG. 6 is an example of one or more NSD software components which can be distributed by a manager device to an NSD. In the illustrated embodiment, the NSD is a security appliance device capable of executing the Linux operating system. In addition to implementing a specific security policy that generates network security information, the NSD can also perform additional tasks, such as providing support for Virtual Private Networks (VPNs). The NSD software components include a version of the
Linux OS kernel 610 which is capable of executing on the NSD to provide various OS functionality (e.g., TCP/IP support, network drivers, etc.). The OS software component can also include an application programming interface (API) so that various other software components can interact with the OS kernel in a consistent manner. - One software component which interacts directly with the OS is the
packet filter engine 615. The packet filter engine implements the specific security policy for the NSD, and interacts with various other software components including thefirewall 630, proxies forvarious network services 635, andauthentication software 640. The firewall component can provide a variety of functions such as configuring security policy filter rules, providing an interface to implement communication and access security (e.g., via encryption), launching proxies for various network services, and communicating with management software of the NSD client (e.g., a business which owns the trusted devices protected by the NSD). The firewall component can provide aclient API 645 which client computers can contact, or can instead communicate with such an API provided by the client. The various network service proxies can provide a variety of information about the activities and configuration of the proxies, and the authentication software can ensure that users or devices provide the necessary access information before gaining access to the NSD or being able to receive information (e.g., network security information) from the NSD. - Other software components which interact directly with the OS include various functionality-specific drivers (e.g., VPN drivers)620, and various service and protocol drivers (e.g., TCP/IP driver) 625. Most functionality-specific drivers will also have a corresponding software component which implements the functionality and which interacts with the driver, such as the
VPN software 650 interacting withdriver 620. Similarly, one or more software components may be associated with the service and protocol drivers to implement or provide support for those protocols and services, such as theinitialization program 655 interacting withdrivers 625. - It is also possible for some software components to execute on the NSD in a manner such that they do not directly interact with other software components. For example, the network security
information logging component 660 provides network security information to supervisor devices. While the logging component could interact with other components such as the packet filter engine to retrieve the network security information of interest, the logging component could also retrieve the information from a temporary local storage without such direct interaction. The logging component can provide asupervisor device API 670 which supervisor devices can contact, or can instead communicate with such an API provided by the supervisor devices. As with the firewall component and other components providing information or access to external devices, the logging component can provide for the security of the information it provides in a variety of ways (e.g., encrypting the information before transmitting it). - Finally, as illustrated by the
software components 670, a variety of other optional software components can be provided to and executed by an NSD. These components may or may not interact with other displayed software components. Those skilled in the art will appreciate that various of the displayed software components may interact with each other even if such interaction is not graphically illustrated, that existing software components could be removed, and that various software components could alternately be grouped together into a single component or separated into separate sub-components. In addition, those skilled in the art will appreciate that various specific types of software (e.g., the Linux OS and the TCP/IP protocol) could be replaced with alternate types of software providing similar functionality. - Those skilled in the art will also appreciate that this information is provided for exemplary purposes only, and that the invention is not limited to the specific details discussed.
- FIG. 7 is an exemplary flow diagram of an embodiment of the Network Security Device routine700. The routine implements a specific security policy for an NSD by monitoring network information passing between devices of interest (e.g., between external devices and trusted devices), applying security policy filter rules when appropriate, and generating network security information about events of interest. In addition, the routine responds to management-related messages (e.g., from supervisor devices) when appropriate.
- The routine begins at
step 705 where the NSD executes an initial boot program that loads the software to be executed by the NSD. After the software is loaded, the routine continues to step 710 to load various NSD-specific network packet filter rules that will be used to implement the specific security policy for the NSD, as well as any other NSD-specific configuration information. The software and NSD-specific configuration information will typically be stored in non-volatile memory (e.g., flash RAM or a magnetic disk) by the NSD, but can also be loaded from a remote device. - After
step 710, the routine continues to step 715 to monitor any passing network information. When network information packets of interest are detected, the routine continues to step 720 to filter the network information packets by executing the FilterNetwork Packets subroutine 720. After filtering the network information packets, the routine continues to step 725 to generate network security information about any events of interest by executing the Generate NetworkSecurity Information subroutine 725. The routine then continues to step 730 to respond to any management-related messages received (e.g., from a supervisor device) by executing the Respond ToManagement Message subroutine 730. Afterstep 730, the routine continues to step 790 to determine whether to continue monitoring network information packets. If so, the routine returns to step 715, and if not the routine ends atstep 795. - Those skilled in the art will appreciate that network information can be monitored and altered in a variety of ways. In addition, network information can be specified in a variety of different types of packets, and can take a variety of forms other than packets. In addition, an NSD can be implemented in a variety of ways, such as by using a general-purpose computer executing specialized software or by using a special-purpose computer. For example, the Firebox10 and Firebox100 products from WatchGuard Technologies, Inc., of Seattle, Wash., can be used to implement some aspects of an NSD.
- FIG. 8 is an exemplary flow diagram of an embodiment of the Filter
Network Packets subroutine 720. The subroutine determines whether network information packets match one or more security policy filter rules, applies filter rules as appropriate to determine what actions to take for the packets, and then takes the appropriate action. The subroutine begins atstep 805 where information about the network information packets of interest are received. The subroutine continues to step 810 to determine if the packets match one or more of the filter rules. If so, the subroutine continues to step 815 to apply one or more of the filter rules as appropriate to determine an action to be taken for the packets. For example, if multiple rules apply then only the rule with the highest precedence may be used, or alternately each matching rule may be applied in order of increasing or decreasing precedence. - If it is instead determined in
step 810 that none of the filter rules apply, the subroutine continues to step 820 to determine a default action to be taken for the packets. A variety of types of default actions can be used, including denying passage of all packets that are not explicitly approved, blocking spoofing attacks, blocking port space probes, and blocking address space probes. Aftersteps step 825, the subroutine continues to step 895 and returns. - Those skilled in the art will appreciate that a network information security policy can be implemented in ways other than using filter rules. In addition, default filtering rules can be used such that some filter rules will apply to any packet. Moreover, a variety of actions can be taken on packets other than allowing or denying passage of the packets, including modifying the packets to add or remove information, or holding the packets until additional processing (e.g., manual review) can be performed on the packets. In addition, additional actions may be necessary for the subroutine based on the format of the packets. For example, determining whether a packet matches a filter rule may require first stripping various network transmission information from the packet, and this information may need to be added back to the packet if the determined action for the packet is to allow its passage to its intended recipient.
- FIG. 9 is an exemplary flow diagram of an embodiment of the Generate Network
Security Information subroutine 725. The subroutine determines whether an event of interest has occurred (e.g., the application of a filter rule of interest or the detection of a packet matching predefined characteristics of interest such as corresponding to a particular network service), logs network security information about the event if appropriate, and notifies one or more specified entities about the event if appropriate. The subroutine encrypts information before it is transmitted so that it can be transmitted over an external network without fear of the information of interest being intercepted. The subroutine begins atstep 905 where information about the network information packets of interest are received. The subroutine continues to step 910 to determine if the packets indicate an event of interest for which network security information is to be logged. - If it is determined in
step 910 that the packets indicate an event of interest for which network security information is to be logged, the subroutine continues to step 915 to generate the network security information about the event, such as by extracting information of interest from the packet including the packet sender, intended packet recipient, packet direction, etc. The subroutine then continues to step 920 to determine the supervisor device currently associated with the NSD. The subroutine next determines instep 925 if the current supervisor device is available to receive network security information from the NSD. If not, the subroutine continues to step 930 to determine an alternate supervisor device to be the current supervisor device, and then returns to step 925 to determine if the new supervisor device is available. After a supervisor device is found to be available and designated as the current supervisor device, the subroutine continues to step 933 to encrypt the network security information in a manner accessible by the current supervisor device (e.g., with an asymmetric public key for the supervisor device, or with a symmetric key available to all supervisor devices). The subroutine then continues to step 935 to send the encrypted network security information to the current supervisor device. Any necessary access information (e.g., passwords) can also be included with the sent information. - After
step 935, or if it is instead determined instep 910 that the packets do not indicate an event of interest for which network security information is to be logged, the subroutine continues to step 940 to determine if the packets are of a type that require immediate notification of one or more entities (e.g., users, devices, services, etc.). If so, the subroutine continues to step 945 to notify the designated entities in the appropriate manner, such as by using a predefined notification means (e.g., email, a pager, voice mail, a message containing predefined information, etc.). This communication can also be encrypted as appropriate. Afterstep 945, or if it is instead determined instep 940 that immediate notification of one or more entities is not required, the subroutine continues to step 995 and returns. - Those skilled in the art will appreciate that network security information can be sent to a supervisor device in alternate ways. For example, the NSD could store network security information until a sufficient amount was available before sending it to a supervisor, could send network security information on a periodic basis, could send network security information only when requested by a supervisor device, or could temporarily store network security information while the primary supervisor device or all supervisor devices are unavailable. In addition, network security information can be generated in a variety of ways and can include a variety of information, including sending the entire packets of interest, sending only some information from each packet, or sending only summary reports about multiple packets. In addition, events of interest which trigger the logging of network security information or the notification of some entity can be defined and identified in a variety of ways, such as any packets to or from a particular device or a device in a particular class of devices, any packets for which a specific action are taken (e.g., deny passage), any packets containing contents of interest (e.g., particular words or an attached file of a particular type), any packets corresponding to a particular type of network service (e.g., HTTP requests), etc. Finally, a variety of means for providing security to information being transmitted over a non-secure network can be utilized, including symmetric keys, asymmetric keys, passwords, etc.).
- FIG. 10 is an exemplary flow diagram of an embodiment of the Respond To Management Messages subroutine730. The subroutine determines whether the NSD has received a management-related message, determines whether the sender of the message is authorized to access management functions of the NSD, decrypts the message if necessary, and responds to the message when appropriate. The subroutine begins at
step 1005 where information about the network information packets of interest are received. The subroutine continues to step 1010 to determine whether the packets contain a message that is directed to the NSD. If so, the subroutine continues to step 1015 to determine what access information (e.g., passwords, the sender being on a list of authorized devices, etc.) is required for the message, as well as any information needed to decrypt the message if it is encrypted (e.g., a password, or a public or private key). The subroutine continues to step sz17 to decrypt the message if it is encrypted. The subroutine then continues to step 1020 to verify whether the sender of the message has supplied any necessary access information and otherwise met any other access criteria. - If the necessary access has been verified, the subroutine continues to step1025 to determine if the message is a request for information (e.g., status of the NSD, NSD configuration information, or network security information), information being supplied (e.g., a security policy template, NSD-specific configuration information, or NSD software), or some other instruction (e.g., reboot the NSD so that new software is used). If it is determined in
step 1025 that the message is a request for information, the subroutine continues to step 1030 to supply the requested information if possible, including encrypting the information before sending if appropriate (e.g., if the intended recipient is able to decrypt the information, and the information is sensitive or if all communications are encrypted) and including any necessary access information. If it is determined instep 1025 that the message is information being supplied, the subroutine continues to step 1035 to store the information in the appropriate location. In addition, other actions may be taken automatically if appropriate, such as loading new software immediately if possible. If it is determined instep 1025 that the message is some other instruction, the subroutine continues to step 1040 to process the instruction if possible. - After
steps step 1010 that the packets do not contain a message directed to the NSD or instep 1020 that the necessary access has not been verified, the subroutine continues to step 1095 and returns. Those skilled in the art will appreciate that a variety of types of messages can be supplied from a supervisor device, directly from a manager device, from another NSD, or from an internal device. In addition, management-related messages can include a variety of types of requests, information, and other instructions. - FIG. 11 is an exemplary flow diagram of an embodiment of the
Supervisor Device routine 1100. The routine implements a host device for one or more NSDs by receiving network security information of interest and storing the information until requested by a manager device, as well as assisting the manager device in distributing various information to the NSDs which are currently associated with the supervisor device. - The routine begins at
step 1105 where the supervisor device executes an initial boot program that loads the software to be executed by the supervisor device. Those skilled in the art will appreciate that the software can be loaded from local or remote storage. After the software is loaded, the routine continues to step 1110 to wait for a message. After a message is received, the routine continues to step 1115 to decrypt the message if it is encrypted. The decryption can be done in a variety of ways, such as by retrieving decryption information based on the specific sender of the message or based on the type of sender (e.g., NSD or manager device). The routine then continues to step 1120 to determine if the message is from an NSD. If so, the routine processes the message by executing the ProcessNSD Message subroutine 1125, and if not the routine processes the message by executing the Process Manager Or SupervisorDevice Message subroutine 1130. Aftersteps step 1195. - Those skilled in the art will appreciate that a supervisor/host device can be implemented in a variety of ways, such as by using a general-purpose computer executing specialized software or by using a special-purpose computer. For example, a general-purpose computer executing an operating system (e.g., SOLARISâą from Sun Microsystems) and executing software from WatchGuard Technologies, Inc., of Seattle, Wash., such as the WatchGuard Event Processor software, can be used to implement such aspects of a supervisor/host device. In addition, those skilled in the art will appreciate that each supervisor/host device may be able to support a large number (e.g., 500) of NSDs.
- FIG. 12 is an exemplary flow diagram of an embodiment of the Process
NSD Message subroutine 1125. The subroutine stores network security information sent by NSDs, notifies the manager device if an NSD not previously associated with the supervisor device begins sending information, and processes other NSD requests as appropriate. The subroutine begins atstep 1205 where it receives a decrypted copy of the message sent from the NSD. The subroutine continues to step 1210 to determine if the sending NSD is on the list of NSDs that are currently associated with the supervisor device. If not, the subroutine continues to step 1215 to add the NSD to the current list. - After
step 1215, or if it was instead determined that the sending NSD is on the list of NSDs that are currently associated with the supervisor device, the subroutine continues to step 1220 where any NSDs that are shown on the current list but which are not currently associated with the supervisor device are removed from the current list. Whether a listed NSD is still associated with the supervisor device can be determined in a variety of ways, such as by removing NSDs from whom no messages have been received for a certain amount of time or by removing NSDs indicated to be associated with other supervisor devices (e.g., by the NSD, the manager device, or the other supervisor device). The subroutine then continues to step 1225 where, if any NSDs have been added or removed, the manager device is notified of the changes in the current list of NSDs. As with other communications, this communication can be encrypted if appropriate and any necessary access information can be included in the message. - The subroutine then continues to step1230 to determine if the message from the NSD is composed of network security information. If so, the subroutine continues to step 1235 to store the information in the log maintained by the supervisor device. The information in the log is encrypted before it is stored so that any other device able to access the log cannot obtain access to the contents of the stored network security information. If it is determined in
step 1230 that the message from the NSD is not composed of network security information, the subroutine instead continues to step 1240 to process the message from the NSD as appropriate. For example, the NSD may be using the supervisor device as an intermediary when sending a message to another device such as the manager device, another NSD, or another supervisor device. Aftersteps - Those skilled in the art will appreciate that NSD messages can be processed in a variety of alternate ways. For example, the list of NSDs may be purged on a periodic basis rather than when each new NSD message is received, and the manager device can be updated as to the changes in the list in a similar manner. In addition, each supervisor device can maintain a single log in which the network security information of multiple NSDs is stored, or can alternately maintain individual logs for each NSD. Similarly, if the supervisor device's log is not accessible to other devices, the information stored in the log file may not be encrypted, with the supervisor device instead encrypting the information before it is sent.
- FIG. 13 is an exemplary flow diagram of an embodiment of the Process Manager Or Supervisor
Device Message subroutine 1130. The subroutine receives a copy of a message from the manager device that is to be distributed to multiple NSDs, and distributes a copy of the message to each of those NSDs which are currently associated with the supervisor device. The subroutine also receives requests from the manager device or another supervisor device, such as requests from the manager device for the various (potentially distributed) network security information of an NSD, and responds to the request if possible. - The subroutine begins at
step 1305 where it receives a decrypted copy of the sent message. The subroutine then continues to step 1310 to determine if the intended recipients of the message include one or more NSDs. If so, the subroutine continues to step 1315 to send a copy of the message to each of the intended recipient NSDs which are on the list of NSDs currently associated with the supervisor device. As with other communications, the messages are sent in an encrypted manner if appropriate and any necessary access information is added to the message. - If it is instead determined in
step 1310 that the received message is not intended for NSDs, the subroutine continues to step 1320 to determine if the message is a request from a manager device for the network security information of an NSD. If so, the subroutine continues to step 1325 to retrieve any portions of the requested information which are stored by the supervisor device in the log. The subroutine then continues to step 1330 to determine if any other supervisor devices store at least a portion of the requested information. This can be determined in a variety of ways, such as by receiving a list of all such supervisor devices from the manager device, by querying other supervisor devices if they store any of the requested information (e.g., after analyzing the retrieved information and determining that it is not complete), by querying the NSD to determine to which supervisor devices the NSD has sent network security information, etc. - If it is determined in
step 1330 that other supervisor devices store at least a portion of the requested information, the subroutine continues to step 1335 to contact those other supervisor devices and retrieve those portions of the information. The subroutine then continues to step 1340 to combine the various portions of network security information together. Afterstep 1340, or if it was determined instep 1330 that other supervisor devices do not store at least a portion of the requested information, the subroutine sends the retrieved network security information to the requester instep 1345. As with other communications, the network security information is encrypted and the necessary access information is supplied with the information. - The encryption of the network security information to be sent to the manager device can be handled in a variety of ways. If the other supervisor devices from which information is retrieved also encrypt the information stored in their logs, the information can be sent to the requesting supervisor device without decrypting the information. If the manager device is able to decrypt the various portions of the network security information encrypted by different supervisor devices (e.g., if all supervisor devices use the same key for encryption), then the requesting supervisor device can just forward the various encrypted portions of information to the manager device. Alternately, if the requesting supervisor device can decrypt the information from the various other supervisor devices, the requesting supervisor device can combine all of the network security information in a decrypted form and then encrypt the information before sending it to the manager device. Yet another option is for each of the other supervisor devices to encrypt their network security information before sending it to the requesting supervisor device, with the encryption such that the requesting supervisor device can decrypt it (e.g., by using the public key of the requesting supervisor device). Those skilled in the art will appreciate that other methods of sending this information are readily apparent.
- If it was instead determined in
step 1320 that the message received by the supervisor device is not a request from a manager device for the network security information of an NSD, the subroutine continues to step 1350 to process the message as appropriate. For example, the message may be from another supervisor device that is gathering the network security information of an NSD in preparation for forwarding the information to the manager device. In this situation, the supervisor device forwards the requested network security information to the other supervisor device. Aftersteps - Those skilled in the art will appreciate that requests for network security information may be for amounts of information other than all available information, such as information generated during a specified time period or information of a certain type. In such situations, only the information requested can be returned, or instead all available information can be returned and the requester can extract the desired information. In addition, when sending information to multiple NSDs that are currently associated with multiple supervisor devices, the manager device could send a single message to a single supervisor device (rather than a single message to each of those supervisor devices) and have the single supervisor device distribute the message as necessary to the other supervisor device, or to other NSDs with which the supervisor device is not currently associated.
- FIGS. 14A and 14B are exemplary flow diagrams of an embodiment of the Manager Device routine. The routine executes on the manager device, and receives messages from supervisor devices such as indications of the supervisor devices currently associated with NSDs that are being managed by the manager device. The manager device also receives a variety of user commands related to managing the NSDs and supervisor devices, and processes the commands as appropriate.
- The routine begins at
step 1405 where a graphical user interface (GUI) is displayed to the user. This display provides a hierarchical tree view of the various supervisor devices and the NSDs which are associated with each supervisor device. A variety of other types of information can also be conveyed, such as the status of supervisor devices (e.g., available or unavailable), the status of NSDs, the flow of information that is occurring between devices, etc. The GUI also allows the user to easily enter management-related commands, and to display information of interest such as the aggregated network information of one or more NSDs. Afterstep 1405, the routine continues to step 1410 to wait for a user command or for a message. - After receiving a user command or message, the routine continues to step1415 to determine if a user command was received. If not, the routine continues to step 1420 to determine if the received message is an indication of a current association between an NSD and a supervisor device, such as after a fail-over when the indicated supervisor device became the current supervisor device for an NSD after the primary supervisor device for the NSD was unavailable. If it is determined in
step 1420 that the received message is an indication of a current association between an NSD and a supervisor device, the routine continues to step 1425 to store the association information. If it is determined instep 1420 that the received message is not an indication of a current association between an NSD and a supervisor device, the routine continues to step 1430 to process the message as appropriate. - If it was instead determined in
step 1415 that a user command was received, the routine continues to step 1435 to determine if the command is to create or modify a security policy template. If so, the routine continues to step 1440 to display a list of possible network services and protocols that may be of interest. The routine then continues to step 1445 where the user can indicate one or more services or protocols for which filter rules are to created. For each service or protocol, the user specifies the specific characteristics which network information packets must have to match the rule (e.g., from a specific sender to any recipient, or incoming messages from any device of a specified type or class). The user also specifies the appropriate action to be taken with network information packets that satisfy the rule. The user can also specify aliases which are to be customized with NSD-specific configuration information when the template is loaded on a particular NSD. For example, if the user defines one or more filter rules related to an internal HTTP server, an alias can be created that will eventually hold the NSD-specific information about the particular HTTP server. After the filter rules and other information of the security policy template are defined or modified, the security policy template is stored. - If it was instead determined in
step 1435 that the command is not to create or modify a security policy template, the routine continues to step 1450 to determine if the command is to distribute a security policy template to one or more NSDs. If so, the routine continues to step 1455 to receive an indication from the user of the template to be distributed, and to then retrieve a copy of the indicated template. If it was instead determined instep 1450 that the command is not to distribute a security policy template to one or more NSDs, the routine continues to step 1460 to determine if the command is to distribute one or more software components to one or more NSDs. If so, the routine continues to step 1462 to receive an indication from the user of the software components to be distributed, and to then retrieve copies of the indicated software components. Aftersteps - If it was instead determined in
step 1460 that the command is not to distribute one or more software components, the routine continues to step 1470 to determine if the command is to configure an NSD by supplying NSD-specific information to customize a security policy template. If so, the routine continues to step 1472 to receive an indication of the NSD to be configured. The routine then continues to step 1474 to receive an indication from the user of the NSD-specific information which is to be used to configure the NSD. The routine then determines instep 1476 the supervisor device that is currently associated with the NSD, and instep 1478 sends the NSD-specific information to the supervisor device for forwarding to the NSD. Those skilled in the art will appreciate that rather than merely sending the information to the NSD, the supervisor device could send instructions to the NSD to load or modify the configuration of the NSD in an appropriate manner. - If it was instead determined in
step 1470 that the command is not to configure an NSD, the routine continues to step 1480 to determine if the command is to retrieve aggregated network security information from an NSD. If so, the routine continues to step 1482 to receive an indication of the NSD. The routine then continues to step 1484 to determine the supervisor device that is currently associated with the NSD, and instep 1485 determines all supervisor devices which store network security information for the NSD. The routine then continues to step 1486 to notify the current supervisor device to retrieve the network security information of interest for the NSD, including indicating to the current supervisor device the other supervisor devices which may store portions of the network security information. The routine then continues to step 1487 to wait for the network security information. After receiving the network security information, the routine instep 1488 aggregates the network security information as appropriate. Those skilled in the art will appreciate that the network security information can be aggregated in a variety of ways, either automatically or in response to user indications. - If it was instead determined in
step 1480 that the command is not to retrieve aggregated network security information, the routine continues to step 1490 to process the command if appropriate. Aftersteps step 1495. - Those skilled in the art will appreciate that a manager device can be implemented in a variety of ways, such as by using a general-purpose computer executing specialized software or by using a special-purpose computer. For example, a general-purpose computer executing an operating system (e.g., WINDOWS 95âą or WINDOWS NTâą from Microsoft Corp.) and executing software from WatchGuard Technologies, Inc., of Seattle, Wash., such as the Global Policy Manager, Graphical Monitor, Historical Reporting Module, Global Console, WebBlocker, Branch Office VPN, Network Configuration Wizard and Security Management System (SMS) Control Center software components, can be used to implement some aspects of a manager device.
- From the foregoing it will be appreciated that, although specific embodiments of the invention have been described herein for purposes of illustration, various modifications may be made without deviating from the spirit and scope of the invention. Accordingly, the invention is not limited except as by the appended claims.
Claims (105)
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US10/712,313 US20040181690A1 (en) | 1999-05-06 | 2003-11-12 | Managing multiple network security devices from a manager device |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US09/307,332 US6678827B1 (en) | 1999-05-06 | 1999-05-06 | Managing multiple network security devices from a manager device |
US10/712,313 US20040181690A1 (en) | 1999-05-06 | 2003-11-12 | Managing multiple network security devices from a manager device |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/307,332 Continuation US6678827B1 (en) | 1999-05-06 | 1999-05-06 | Managing multiple network security devices from a manager device |
Publications (1)
Publication Number | Publication Date |
---|---|
US20040181690A1 true US20040181690A1 (en) | 2004-09-16 |
Family
ID=23189269
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/307,332 Expired - Lifetime US6678827B1 (en) | 1999-05-06 | 1999-05-06 | Managing multiple network security devices from a manager device |
US10/712,313 Abandoned US20040181690A1 (en) | 1999-05-06 | 2003-11-12 | Managing multiple network security devices from a manager device |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/307,332 Expired - Lifetime US6678827B1 (en) | 1999-05-06 | 1999-05-06 | Managing multiple network security devices from a manager device |
Country Status (5)
Country | Link |
---|---|
US (2) | US6678827B1 (en) |
EP (1) | EP1175752A1 (en) |
JP (1) | JP2002544607A (en) |
AU (1) | AU4346600A (en) |
WO (1) | WO2000069120A1 (en) |
Cited By (111)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20020107950A1 (en) * | 2000-12-29 | 2002-08-08 | Lu Larry L. | Message screening system |
US20030118038A1 (en) * | 2001-11-29 | 2003-06-26 | Mika Jalava | Personalized firewall |
US20030217292A1 (en) * | 2002-04-04 | 2003-11-20 | Steiger John Thomas | Method and system for communicating data to and from network security devices |
US20040093524A1 (en) * | 2002-09-11 | 2004-05-13 | Nec Corporation | Network, IPsec setting server apparatus, IPsec processing apparatus, and IPsec setting method used therefor |
US20040107274A1 (en) * | 2002-12-03 | 2004-06-03 | Mastrianni Steven J. | Policy-based connectivity |
US20050097357A1 (en) * | 2003-10-29 | 2005-05-05 | Smith Michael R. | Method and apparatus for providing network security using security labeling |
US20050132046A1 (en) * | 2003-12-10 | 2005-06-16 | De La Iglesia Erik | Method and apparatus for data capture and analysis system |
US20050235340A1 (en) * | 2004-04-16 | 2005-10-20 | To William C | Configuration management apparatus and related methods |
US20050240990A1 (en) * | 2004-04-22 | 2005-10-27 | Microsoft Corporation | Systems and methods for managing networks |
US20060026673A1 (en) * | 2004-07-28 | 2006-02-02 | Canon Kabushiki Kaisha | Image processing apparatus, control method for image processing apparatus and control program for image processing apparatus |
US20060048209A1 (en) * | 2004-08-31 | 2006-03-02 | Microsoft Corporation | Method and system for customizing a security policy |
US20060075503A1 (en) * | 2004-09-13 | 2006-04-06 | Achilles Guard, Inc. Dba Critical Watch | Method and system for applying security vulnerability management process to an organization |
US20060106750A1 (en) * | 2004-11-16 | 2006-05-18 | Smith Michael R | Method and apparatus for best effort propagation of security group information |
US20060112425A1 (en) * | 2004-11-23 | 2006-05-25 | Smith Michael R | Method and system for including security information with a packet |
US20060117058A1 (en) * | 2004-12-01 | 2006-06-01 | Cisco Technology, Inc. | Method and apparatus for ingress filtering using security group information |
US20060129808A1 (en) * | 2004-11-19 | 2006-06-15 | Microsoft Corporation | Method and system for distributing security policies |
US20060174318A1 (en) * | 2005-01-28 | 2006-08-03 | Microsoft Corporation | Method and system for troubleshooting when a program is adversely impacted by a security policy |
US20060177063A1 (en) * | 2005-02-07 | 2006-08-10 | Conway Adam M | Wireless network having multiple security interfaces |
US20060201438A1 (en) * | 2005-03-08 | 2006-09-14 | Anttila Arthur L | Clumping, non-dusting calcium carbonate-based animal litter |
US20060265739A1 (en) * | 2005-05-19 | 2006-11-23 | International Business Machines Corporation | Method and system for autonomic security configuration |
US20070061458A1 (en) * | 2005-09-14 | 2007-03-15 | Infoexpress, Inc. | Dynamic address assignment for access control on DHCP networks |
US20070064689A1 (en) * | 2003-09-19 | 2007-03-22 | Shin Yong M | Method of controlling communication between devices in a network and apparatus for the same |
US20070174501A1 (en) * | 2006-01-06 | 2007-07-26 | Hon Hai Precision Industry Co., Ltd. | System and method for managing a data transfer channel between communication devices |
US20070180258A1 (en) * | 2006-01-20 | 2007-08-02 | Broussard Scott J | Confidential content search engine system and method |
US20070192500A1 (en) * | 2006-02-16 | 2007-08-16 | Infoexpress, Inc. | Network access control including dynamic policy enforcement point |
US20070192858A1 (en) * | 2006-02-16 | 2007-08-16 | Infoexpress, Inc. | Peer based network access control |
US20070204323A1 (en) * | 2006-02-24 | 2007-08-30 | Rockwell Automation Technologies, Inc. | Auto-detection capabilities for out of the box experience |
US20080066145A1 (en) * | 2006-09-08 | 2008-03-13 | Ibahn General Holdings, Inc. | Monitoring and reporting policy compliance of home networks |
US20080072032A1 (en) * | 2006-09-19 | 2008-03-20 | Searete Llc, A Limited Liability Corporation Of The State Of Delaware | Configuring software agent security remotely |
US20080092069A1 (en) * | 2006-10-13 | 2008-04-17 | Allan Chan | Graphical representation of a port security state |
US20080098308A1 (en) * | 2001-10-24 | 2008-04-24 | At&T Labs, Inc. | Unified interface for managing dsl services |
US20080098455A1 (en) * | 2006-10-20 | 2008-04-24 | Canon Kabushiki Kaisha | Document management system and document management method |
US20080155424A1 (en) * | 2006-12-22 | 2008-06-26 | Verizon Data Services, Inc. | Network element abstraction within a network management system |
US20080196104A1 (en) * | 2007-02-09 | 2008-08-14 | George Tuvell | Off-line mms malware scanning system and method |
US20080222698A1 (en) * | 2004-02-27 | 2008-09-11 | Bae Systems Plc | Secure Computer Communication |
US20080235760A1 (en) * | 2006-05-02 | 2008-09-25 | International Business Machines Corporation | Confidential Content Reporting System and Method with Electronic Mail Verification Functionality |
US20090041026A1 (en) * | 2007-08-06 | 2009-02-12 | At&T Knowledge Ventures, L.P. | System for configuring network elements |
US20090049196A1 (en) * | 2007-08-13 | 2009-02-19 | Smith Michael R | Method and system for the assignment of security group information using a proxy |
US20090083830A1 (en) * | 2003-09-24 | 2009-03-26 | Lum Stacey C | Systems and Methods of Controlling Network Access |
US20090094621A1 (en) * | 2007-10-05 | 2009-04-09 | Pano Logic, Inc. | Universal serial bus host controller driver over a network |
US20090150513A1 (en) * | 2007-12-10 | 2009-06-11 | At&T Knowledge Ventures, Lp | Method and System for Gathering Network Data |
US20090217355A1 (en) * | 2003-09-10 | 2009-08-27 | Smith Michael R | Method and Apparatus For Providing Network Security Using Role-Based Access Control |
US20090219392A1 (en) * | 2008-02-01 | 2009-09-03 | Third Iris Corp | Point of recordation terminal apparatus for sending high complexity image sequences over an unreliable low-bandwidth channel |
US7591010B2 (en) | 2005-01-19 | 2009-09-15 | Microsoft Corporation | Method and system for separating rules of a security policy from detection criteria |
US20090288135A1 (en) * | 2008-05-19 | 2009-11-19 | Rohati Systems, Inc. | Method and apparatus for building and managing policies |
US20090328219A1 (en) * | 2008-06-27 | 2009-12-31 | Juniper Networks, Inc. | Dynamic policy provisioning within network security devices |
US20100017843A1 (en) * | 2008-06-27 | 2010-01-21 | Microsoft Corporation | Scenario Based Security |
US20100037287A1 (en) * | 2008-08-07 | 2010-02-11 | Mallikarjun Netrakanti | Method and apparatus for providing routing and access control filters |
US7769851B1 (en) | 2005-01-27 | 2010-08-03 | Juniper Networks, Inc. | Application-layer monitoring and profiling network traffic |
US20100223657A1 (en) * | 2004-11-23 | 2010-09-02 | Finn Norman W | Method and system for including network security information in a frame |
US20100246547A1 (en) * | 2009-03-26 | 2010-09-30 | Samsung Electronics Co., Ltd. | Antenna selecting apparatus and method in wireless communication system |
US7809826B1 (en) | 2005-01-27 | 2010-10-05 | Juniper Networks, Inc. | Remote aggregation of network traffic profiling data |
US20100257580A1 (en) * | 2009-04-03 | 2010-10-07 | Juniper Networks, Inc. | Behavior-based traffic profiling based on access control information |
US7818326B2 (en) | 2005-08-31 | 2010-10-19 | Mcafee, Inc. | System and method for word indexing in a capture system and querying thereof |
US20110001850A1 (en) * | 2008-02-01 | 2011-01-06 | Gaubatz Matthew D | Automatic Redeye Detection |
US20110047369A1 (en) * | 2006-09-19 | 2011-02-24 | Cohen Alexander J | Configuring Software Agent Security Remotely |
US7899828B2 (en) | 2003-12-10 | 2011-03-01 | Mcafee, Inc. | Tag data structure for maintaining relational data over captured objects |
US7904554B1 (en) | 2002-12-30 | 2011-03-08 | Aol Inc. | Supervising user interaction with online services |
US7907608B2 (en) | 2005-08-12 | 2011-03-15 | Mcafee, Inc. | High speed packet capture |
US7930540B2 (en) | 2004-01-22 | 2011-04-19 | Mcafee, Inc. | Cryptographic policy enforcement |
US7937755B1 (en) * | 2005-01-27 | 2011-05-03 | Juniper Networks, Inc. | Identification of network policy violations |
US7949849B2 (en) | 2004-08-24 | 2011-05-24 | Mcafee, Inc. | File system for a capture system |
US7958227B2 (en) | 2006-05-22 | 2011-06-07 | Mcafee, Inc. | Attributes of captured objects in a capture system |
US7962591B2 (en) | 2004-06-23 | 2011-06-14 | Mcafee, Inc. | Object classification in a capture system |
US7966659B1 (en) | 2006-04-18 | 2011-06-21 | Rockwell Automation Technologies, Inc. | Distributed learn mode for configuring a firewall, security authority, intrusion detection/prevention devices, and the like |
US20110153788A1 (en) * | 2009-12-23 | 2011-06-23 | Jacobus Van Der Merwe | Method and System for Automated Network Operations |
US8005863B2 (en) | 2006-05-22 | 2011-08-23 | Mcafee, Inc. | Query generation for a capture system |
US8010689B2 (en) | 2006-05-22 | 2011-08-30 | Mcafee, Inc. | Locational tagging in a capture system |
US20110283207A1 (en) * | 2002-05-22 | 2011-11-17 | Sony Pictures Entertainment Inc. | System and method for platform and language-independent development and delivery of page-based content |
US8166307B2 (en) | 2003-12-10 | 2012-04-24 | McAffee, Inc. | Document registration |
US8176049B2 (en) | 2005-10-19 | 2012-05-08 | Mcafee Inc. | Attributes of captured objects in a capture system |
US8200026B2 (en) | 2005-11-21 | 2012-06-12 | Mcafee, Inc. | Identifying image type in a capture system |
US8205242B2 (en) | 2008-07-10 | 2012-06-19 | Mcafee, Inc. | System and method for data mining and security policy management |
US8209756B1 (en) | 2002-02-08 | 2012-06-26 | Juniper Networks, Inc. | Compound attack detection in a computer network |
US20120216239A1 (en) * | 2011-02-23 | 2012-08-23 | Cisco Technology, Inc. | Integration of network admission control functions in network access devices |
US8266267B1 (en) | 2005-02-02 | 2012-09-11 | Juniper Networks, Inc. | Detection and prevention of encapsulated network attacks using an intermediate device |
US8271794B2 (en) | 2003-12-10 | 2012-09-18 | Mcafee, Inc. | Verifying captured objects before presentation |
US20120265865A1 (en) * | 2011-04-14 | 2012-10-18 | Ricoh Company, Ltd. | Device management system |
US20120266073A1 (en) * | 2011-04-14 | 2012-10-18 | Ricoh Company, Ltd. | Device management system including reporter server |
US8302157B2 (en) | 2004-10-21 | 2012-10-30 | Cisco Technology, Inc. | Method and system for generating user group identifiers |
US8346953B1 (en) | 2007-12-18 | 2013-01-01 | AOL, Inc. | Methods and systems for restricting electronic content access based on guardian control decisions |
US8447722B1 (en) | 2009-03-25 | 2013-05-21 | Mcafee, Inc. | System and method for data mining and security policy management |
US20130160129A1 (en) * | 2011-12-19 | 2013-06-20 | Verizon Patent And Licensing Inc. | System security evaluation |
US8473442B1 (en) | 2009-02-25 | 2013-06-25 | Mcafee, Inc. | System and method for intelligent state management |
US8504537B2 (en) | 2006-03-24 | 2013-08-06 | Mcafee, Inc. | Signature distribution in a document registration system |
US8548170B2 (en) | 2003-12-10 | 2013-10-01 | Mcafee, Inc. | Document de-registration |
US8560534B2 (en) | 2004-08-23 | 2013-10-15 | Mcafee, Inc. | Database for a capture system |
US8590011B1 (en) * | 2005-02-24 | 2013-11-19 | Versata Development Group, Inc. | Variable domain resource data security for data processing systems |
US8621573B2 (en) | 2007-08-28 | 2013-12-31 | Cisco Technology, Inc. | Highly scalable application network appliances with virtualized services |
WO2014011704A1 (en) * | 2012-07-10 | 2014-01-16 | Microsoft Corporation | Data detection and protection policies for e-mail |
US8656039B2 (en) | 2003-12-10 | 2014-02-18 | Mcafee, Inc. | Rule parser |
US8667121B2 (en) | 2009-03-25 | 2014-03-04 | Mcafee, Inc. | System and method for managing data and policies |
US8700561B2 (en) | 2011-12-27 | 2014-04-15 | Mcafee, Inc. | System and method for providing data protection workflows in a network environment |
US8706709B2 (en) | 2009-01-15 | 2014-04-22 | Mcafee, Inc. | System and method for intelligent term grouping |
US8806615B2 (en) | 2010-11-04 | 2014-08-12 | Mcafee, Inc. | System and method for protecting specified data combinations |
US8850591B2 (en) | 2009-01-13 | 2014-09-30 | Mcafee, Inc. | System and method for concept building |
EP2693355A4 (en) * | 2011-03-31 | 2015-05-27 | Hitachi Ltd | Security-level visualization device |
US9253154B2 (en) * | 2008-08-12 | 2016-02-02 | Mcafee, Inc. | Configuration management for a capture/registration system |
US9516473B1 (en) * | 2016-04-04 | 2016-12-06 | Ricoh Company, Ltd. | Device management based on tracking path taken by user |
US9680699B2 (en) | 2006-09-19 | 2017-06-13 | Invention Science Fund I, Llc | Evaluation systems and methods for coordinating software agents |
US10749906B2 (en) * | 2014-04-16 | 2020-08-18 | Centripetal Networks, Inc. | Methods and systems for protecting a secured network |
US10757126B2 (en) | 2015-04-17 | 2020-08-25 | Centripetal Networks, Inc. | Rule-based network-threat detection |
US10785266B2 (en) | 2012-10-22 | 2020-09-22 | Centripetal Networks, Inc. | Methods and systems for protecting a secured network |
US10931797B2 (en) | 2015-02-10 | 2021-02-23 | Centripetal Networks, Inc. | Correlating packets in communications networks |
US11012415B2 (en) | 2013-03-12 | 2021-05-18 | Centripetal Networks, Inc. | Filtering network data transfers |
US11233777B2 (en) | 2017-07-24 | 2022-01-25 | Centripetal Networks, Inc. | Efficient SSL/TLS proxy |
US11477224B2 (en) | 2015-12-23 | 2022-10-18 | Centripetal Networks, Inc. | Rule-based network-threat detection for encrypted communications |
US11496497B2 (en) | 2013-03-15 | 2022-11-08 | Centripetal Networks, Inc. | Protecting networks from cyber attacks and overloading |
US11539665B2 (en) | 2013-01-11 | 2022-12-27 | Centripetal Networks, Inc. | Rule swapping in a packet network |
US11574047B2 (en) | 2017-07-10 | 2023-02-07 | Centripetal Networks, Inc. | Cyberanalysis workflow acceleration |
US11956338B2 (en) | 2023-05-19 | 2024-04-09 | Centripetal Networks, Llc | Correlating packets in communications networks |
Families Citing this family (181)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6008805A (en) | 1996-07-19 | 1999-12-28 | Cisco Technology, Inc. | Method and apparatus for providing multiple management interfaces to a network device |
US7254781B1 (en) * | 1996-07-19 | 2007-08-07 | Cisco Technology, Inc. | Method and apparatus for providing multiple management interfaces to a network device |
US8914410B2 (en) * | 1999-02-16 | 2014-12-16 | Sonicwall, Inc. | Query interface to policy server |
US7821926B2 (en) * | 1997-03-10 | 2010-10-26 | Sonicwall, Inc. | Generalized policy server |
US6408336B1 (en) | 1997-03-10 | 2002-06-18 | David S. Schneider | Distributed administration of access to information |
US20010048738A1 (en) * | 1997-04-03 | 2001-12-06 | Sbc Technology Resourses, Inc. | Profile management system including user interface for accessing and maintaining profile data of user subscribed telephony services |
US6778651B1 (en) * | 1997-04-03 | 2004-08-17 | Southwestern Bell Telephone Company | Apparatus and method for facilitating service management of communications services in a communications network |
US6158010A (en) | 1998-10-28 | 2000-12-05 | Crosslogix, Inc. | System and method for maintaining security in a distributed computer network |
US7673323B1 (en) | 1998-10-28 | 2010-03-02 | Bea Systems, Inc. | System and method for maintaining security in a distributed computer network |
US6169059B1 (en) * | 1998-11-19 | 2001-01-02 | Superior Graphite Co. | High-temperature, water-based lubricant and process for making the same |
US7305562B1 (en) | 1999-03-09 | 2007-12-04 | Citibank, N.A. | System, method and computer program product for an authentication management infrastructure |
EP1056010A1 (en) | 1999-05-28 | 2000-11-29 | Hewlett-Packard Company | Data integrity monitoring in trusted computing entity |
US7213068B1 (en) * | 1999-11-12 | 2007-05-01 | Lucent Technologies Inc. | Policy management system |
JP2001273388A (en) * | 2000-01-20 | 2001-10-05 | Hitachi Ltd | System and method for security management |
FR2804564B1 (en) * | 2000-01-27 | 2002-03-22 | Bull Sa | MULTI-APPLICATION SAFETY RELAY |
US7096495B1 (en) * | 2000-03-31 | 2006-08-22 | Intel Corporation | Network session management |
FI111681B (en) | 2000-04-10 | 2003-08-29 | Sonera Oyj | Blocking against use of a service in telecommunication systems |
US7200863B2 (en) * | 2000-05-16 | 2007-04-03 | Hoshiko Llc | System and method for serving content over a wide area network |
US7266595B1 (en) * | 2000-05-20 | 2007-09-04 | Ciena Corporation | Accessing network device data through user profiles |
US7216225B2 (en) * | 2000-05-24 | 2007-05-08 | Voltaire Ltd. | Filtered application-to-application communication |
US7152240B1 (en) * | 2000-07-25 | 2006-12-19 | Green Stuart D | Method for communication security and apparatus therefor |
US7124440B2 (en) * | 2000-09-07 | 2006-10-17 | Mazu Networks, Inc. | Monitoring network traffic denial of service attacks |
US7043759B2 (en) * | 2000-09-07 | 2006-05-09 | Mazu Networks, Inc. | Architecture to thwart denial of service attacks |
US7398317B2 (en) * | 2000-09-07 | 2008-07-08 | Mazu Networks, Inc. | Thwarting connection-based denial of service attacks |
US7702806B2 (en) * | 2000-09-07 | 2010-04-20 | Riverbed Technology, Inc. | Statistics collection for network traffic |
US7278159B2 (en) * | 2000-09-07 | 2007-10-02 | Mazu Networks, Inc. | Coordinated thwarting of denial of service attacks |
US7743134B2 (en) * | 2000-09-07 | 2010-06-22 | Riverbed Technology, Inc. | Thwarting source address spoofing-based denial of service attacks |
US6986061B1 (en) * | 2000-11-20 | 2006-01-10 | International Business Machines Corporation | Integrated system for network layer security and fine-grained identity-based access control |
US7155001B2 (en) * | 2001-10-24 | 2006-12-26 | Sbc Properties, L.P. | System and method for restricting and monitoring telephone calls |
US7317787B2 (en) * | 2000-11-21 | 2008-01-08 | At&T Knowledge Ventures, L.P. | Voice enhancing for advance intelligent network services |
US20020078382A1 (en) * | 2000-11-29 | 2002-06-20 | Ali Sheikh | Scalable system for monitoring network system and components and methodology therefore |
US8219662B2 (en) * | 2000-12-06 | 2012-07-10 | International Business Machines Corporation | Redirecting data generated by network devices |
US7249170B2 (en) * | 2000-12-06 | 2007-07-24 | Intelliden | System and method for configuration, management and monitoring of network resources |
US7054946B2 (en) * | 2000-12-06 | 2006-05-30 | Intelliden | Dynamic configuration of network devices to enable data transfers |
US6978301B2 (en) | 2000-12-06 | 2005-12-20 | Intelliden | System and method for configuring a network device |
US6931529B2 (en) * | 2001-01-05 | 2005-08-16 | International Business Machines Corporation | Establishing consistent, end-to-end protection for a user datagram |
US7168093B2 (en) * | 2001-01-25 | 2007-01-23 | Solutionary, Inc. | Method and apparatus for verifying the integrity and security of computer networks and implementation of counter measures |
US7272848B1 (en) * | 2001-02-13 | 2007-09-18 | Network Appliance, Inc. | Method for device security in a heterogeneous storage network environment |
EP1244264B1 (en) * | 2001-02-14 | 2006-06-28 | Mitsubishi Denki Kabushiki Kaisha | Illegal access data handling apparatus and method |
GB2372595A (en) * | 2001-02-23 | 2002-08-28 | Hewlett Packard Co | Method of and apparatus for ascertaining the status of a data processing environment. |
GB2372594B (en) * | 2001-02-23 | 2004-10-06 | Hewlett Packard Co | Trusted computing environment |
GB2372592B (en) * | 2001-02-23 | 2005-03-30 | Hewlett Packard Co | Information system |
US7150037B2 (en) * | 2001-03-21 | 2006-12-12 | Intelliden, Inc. | Network configuration manager |
US8141144B2 (en) * | 2001-05-10 | 2012-03-20 | Hewlett-Packard Development Company, L.P. | Security policy management for network devices |
US20020178365A1 (en) * | 2001-05-24 | 2002-11-28 | Shingo Yamaguchi | Method and system for controlling access to network resources based on connection security |
GB0117429D0 (en) * | 2001-07-17 | 2001-09-12 | Trustis Ltd | Trust management |
GB2378013A (en) * | 2001-07-27 | 2003-01-29 | Hewlett Packard Co | Trusted computer platform audit system |
US7222359B2 (en) * | 2001-07-27 | 2007-05-22 | Check Point Software Technologies, Inc. | System methodology for automatic local network discovery and firewall reconfiguration for mobile computing devices |
GB2378272A (en) * | 2001-07-31 | 2003-02-05 | Hewlett Packard Co | Method and apparatus for locking an application within a trusted environment |
US7200548B2 (en) * | 2001-08-29 | 2007-04-03 | Intelliden | System and method for modeling a network device's configuration |
US8296400B2 (en) * | 2001-08-29 | 2012-10-23 | International Business Machines Corporation | System and method for generating a configuration schema |
US20030046583A1 (en) * | 2001-08-30 | 2003-03-06 | Honeywell International Inc. | Automated configuration of security software suites |
US7207061B2 (en) * | 2001-08-31 | 2007-04-17 | International Business Machines Corporation | State machine for accessing a stealth firewall |
US7177869B2 (en) * | 2001-09-19 | 2007-02-13 | Fuji Xerox Co., Ltd. | Service retrieving apparatus and service retrieving method |
JP2003099341A (en) * | 2001-09-20 | 2003-04-04 | Canon Inc | Network device-managing device, managing system, managing method and network device |
US8776230B1 (en) * | 2001-10-02 | 2014-07-08 | Mcafee, Inc. | Master security policy server |
US6999998B2 (en) * | 2001-10-04 | 2006-02-14 | Hewlett-Packard Development Company, L.P. | Shared memory coupling of network infrastructure devices |
JP3864743B2 (en) * | 2001-10-04 | 2007-01-10 | æ ȘćŒäŒç€Ÿæ„ç«èŁœäœæ | Firewall device, information device, and information device communication method |
US20030069949A1 (en) * | 2001-10-04 | 2003-04-10 | Chan Michele W. | Managing distributed network infrastructure services |
US7392537B2 (en) * | 2001-10-08 | 2008-06-24 | Stonesoft Oy | Managing a network security application |
US7536712B2 (en) * | 2001-10-16 | 2009-05-19 | Microsoft Corporation | Flexible electronic message security mechanism |
EP1303097A3 (en) * | 2001-10-16 | 2005-11-30 | Microsoft Corporation | Virtual distributed security system |
US7676540B2 (en) | 2001-10-16 | 2010-03-09 | Microsoft Corporation | Scoped referral statements |
US8015204B2 (en) * | 2001-10-16 | 2011-09-06 | Microsoft Corporation | Scoped access control metadata element |
US20030074579A1 (en) * | 2001-10-16 | 2003-04-17 | Microsoft Corporation | Virtual distributed security system |
US7194553B2 (en) | 2001-10-16 | 2007-03-20 | Microsoft Corporation | Resolving virtual network names |
US20030079053A1 (en) * | 2001-10-23 | 2003-04-24 | Kevin Burns | System and method for evaluating effectiveness of network configuration management tools |
US7065562B2 (en) * | 2001-11-26 | 2006-06-20 | Intelliden, Inc. | System and method for generating a representation of a configuration schema |
US7899047B2 (en) | 2001-11-27 | 2011-03-01 | Microsoft Corporation | Virtual network with adaptive dispatcher |
US7487233B2 (en) * | 2001-12-05 | 2009-02-03 | Canon Kabushiki Kaisha | Device access based on centralized authentication |
US7213264B2 (en) | 2002-01-31 | 2007-05-01 | Mazu Networks, Inc. | Architecture to thwart denial of service attacks |
US7743415B2 (en) * | 2002-01-31 | 2010-06-22 | Riverbed Technology, Inc. | Denial of service attacks characterization |
US8966081B1 (en) * | 2002-02-13 | 2015-02-24 | Netapp, Inc. | Method for device security in a heterogeneous storage network environment |
US7093283B1 (en) * | 2002-02-15 | 2006-08-15 | Cisco Technology, Inc. | Method and apparatus for deploying configuration instructions to security devices in order to implement a security policy on a network |
US7502457B2 (en) * | 2002-02-28 | 2009-03-10 | At&T Intellectual Property I, L.P. | Outbound call rules routing |
US7136916B2 (en) * | 2002-03-08 | 2006-11-14 | Siemens Aktiengesellschaft | Method for event management |
US7430667B2 (en) | 2002-04-04 | 2008-09-30 | Activcard Ireland Limited | Media router |
US7957509B2 (en) * | 2002-04-30 | 2011-06-07 | At&T Intellectual Property I, L.P. | Voice enhancing for advance intelligent network services |
US7662094B2 (en) * | 2002-05-14 | 2010-02-16 | Given Imaging Ltd. | Optical head assembly with dome, and device for use thereof |
US6959329B2 (en) * | 2002-05-15 | 2005-10-25 | Intelliden | System and method for transforming configuration commands |
AU2003276819A1 (en) | 2002-06-13 | 2003-12-31 | Engedi Technologies, Inc. | Out-of-band remote management station |
US7325140B2 (en) * | 2003-06-13 | 2008-01-29 | Engedi Technologies, Inc. | Secure management access control for computers, embedded and card embodiment |
US20040003067A1 (en) * | 2002-06-27 | 2004-01-01 | Daniel Ferrin | System and method for enabling a user interface with GUI meta data |
US20080301298A1 (en) * | 2002-07-29 | 2008-12-04 | Linda Bernardi | Identifying a computing device |
US7287269B2 (en) | 2002-07-29 | 2007-10-23 | International Buiness Machines Corporation | System and method for authenticating and configuring computing devices |
US7143283B1 (en) * | 2002-07-31 | 2006-11-28 | Cisco Technology, Inc. | Simplifying the selection of network paths for implementing and managing security policies on a network |
US7366893B2 (en) * | 2002-08-07 | 2008-04-29 | Intelliden, Inc. | Method and apparatus for protecting a network from attack |
US7461158B2 (en) * | 2002-08-07 | 2008-12-02 | Intelliden, Inc. | System and method for controlling access rights to network resources |
US7669237B2 (en) * | 2002-08-27 | 2010-02-23 | Trust Digital, Llc | Enterprise-wide security system for computer devices |
JP4786116B2 (en) | 2002-09-06 | 2011-10-05 | ăœăăŒæ ȘćŒäŒç€Ÿ | Information processing apparatus and method, and program |
US7558847B2 (en) * | 2002-09-13 | 2009-07-07 | Intelliden, Inc. | System and method for mapping between and controlling different device abstractions |
US20040078457A1 (en) * | 2002-10-21 | 2004-04-22 | Tindal Glen D. | System and method for managing network-device configurations |
US8504879B2 (en) * | 2002-11-04 | 2013-08-06 | Riverbed Technology, Inc. | Connection based anomaly detection |
US8479057B2 (en) * | 2002-11-04 | 2013-07-02 | Riverbed Technology, Inc. | Aggregator for connection based anomaly detection |
US7363656B2 (en) * | 2002-11-04 | 2008-04-22 | Mazu Networks, Inc. | Event detection/anomaly correlation heuristics |
US7107445B2 (en) * | 2002-11-20 | 2006-09-12 | International Business Machines Corporation | Method and apparatus for secure processing of sensitive data |
US20040230681A1 (en) * | 2002-12-06 | 2004-11-18 | John Strassner | Apparatus and method for implementing network resources to provision a service using an information model |
US20040117437A1 (en) * | 2002-12-16 | 2004-06-17 | Exanet, Co. | Method for efficient storing of sparse files in a distributed cache |
JP3852017B2 (en) * | 2003-02-05 | 2006-11-29 | æ„æŹé»äżĄé»è©±æ ȘćŒäŒç€Ÿ | Firewall device |
US7181546B2 (en) * | 2003-03-21 | 2007-02-20 | Cameo Communications Inc. | Network communication display device |
US20040255167A1 (en) * | 2003-04-28 | 2004-12-16 | Knight James Michael | Method and system for remote network security management |
TWI227612B (en) * | 2003-06-25 | 2005-02-01 | Hon Hai Prec Ind Co Ltd | System and method for IP logging |
US7373660B1 (en) | 2003-08-26 | 2008-05-13 | Cisco Technology, Inc. | Methods and apparatus to distribute policy information |
US7764778B2 (en) * | 2003-09-12 | 2010-07-27 | At&T Intellectual Property I, L.P. | International origin dependent customized routing of calls to toll-free numbers |
US8473729B2 (en) | 2003-09-15 | 2013-06-25 | Intel Corporation | Method and apparatus for managing the privacy and disclosure of location information |
US7519826B2 (en) * | 2003-10-01 | 2009-04-14 | Engedi Technologies, Inc. | Near real-time multi-party task authorization access control |
US20050257245A1 (en) * | 2003-10-10 | 2005-11-17 | Bea Systems, Inc. | Distributed security system with dynamic roles |
WO2005043304A2 (en) * | 2003-10-21 | 2005-05-12 | Engedi Technologies, Inc. | Secure management access control for computers, embedded and card embodiment |
JP3758661B2 (en) * | 2003-11-17 | 2006-03-22 | æ ȘćŒäŒç€Ÿă€ăłăăȘăžă§ăłăăŠă§ă€ă | Fraud monitoring program, fraud monitoring method and fraud monitoring system |
US8635661B2 (en) | 2003-12-23 | 2014-01-21 | Mcafee, Inc. | System and method for enforcing a security policy on mobile devices using dynamically generated security profiles |
US7305706B2 (en) * | 2004-01-15 | 2007-12-04 | Cisco Technology, Inc. | Establishing a virtual private network for a road warrior |
US20050193429A1 (en) * | 2004-01-23 | 2005-09-01 | The Barrier Group | Integrated data traffic monitoring system |
US8161520B1 (en) * | 2004-04-30 | 2012-04-17 | Oracle America, Inc. | Methods and systems for securing a system in an adaptive computer environment |
WO2005107132A1 (en) * | 2004-04-30 | 2005-11-10 | Research In Motion Limited | System and method for configuring devices for secure operations |
US7422152B2 (en) * | 2004-05-13 | 2008-09-09 | Cisco Technology, Inc. | Methods and devices for providing scalable RFID networks |
US7929534B2 (en) * | 2004-06-28 | 2011-04-19 | Riverbed Technology, Inc. | Flow logging for connection-based anomaly detection |
US10284571B2 (en) * | 2004-06-28 | 2019-05-07 | Riverbed Technology, Inc. | Rule based alerting in anomaly detection |
US7920577B2 (en) * | 2004-07-08 | 2011-04-05 | Avaya Communication Israel Ltd. | Power saving in wireless packet based networks |
US8146142B2 (en) * | 2004-09-03 | 2012-03-27 | Intel Corporation | Device introduction and access control framework |
US7593892B2 (en) | 2004-10-04 | 2009-09-22 | Standard Chartered (Ct) Plc | Financial institution portal system and method |
US7421739B2 (en) * | 2004-10-04 | 2008-09-02 | American Express Travel Related Services Company, Inc. | System and method for monitoring and ensuring data integrity in an enterprise security system |
US7760653B2 (en) * | 2004-10-26 | 2010-07-20 | Riverbed Technology, Inc. | Stackable aggregation for connection based anomaly detection |
US7509431B2 (en) * | 2004-11-17 | 2009-03-24 | Cisco Technology, Inc. | Performing message and transformation adapter functions in a network element on behalf of an application |
US7664879B2 (en) * | 2004-11-23 | 2010-02-16 | Cisco Technology, Inc. | Caching content and state data at a network element |
US7987272B2 (en) | 2004-12-06 | 2011-07-26 | Cisco Technology, Inc. | Performing message payload processing functions in a network element on behalf of an application |
US7496750B2 (en) * | 2004-12-07 | 2009-02-24 | Cisco Technology, Inc. | Performing security functions on a message payload in a network element |
US7725934B2 (en) * | 2004-12-07 | 2010-05-25 | Cisco Technology, Inc. | Network and application attack protection based on application layer message inspection |
US8082304B2 (en) * | 2004-12-10 | 2011-12-20 | Cisco Technology, Inc. | Guaranteed delivery of application layer messages by a network element |
US7606267B2 (en) * | 2004-12-10 | 2009-10-20 | Cisco Technology, Inc. | Reducing the sizes of application layer messages in a network element |
US8051296B2 (en) * | 2004-12-30 | 2011-11-01 | Honeywell International Inc. | System and method for initializing secure communications with lightweight devices |
US7551567B2 (en) * | 2005-01-05 | 2009-06-23 | Cisco Technology, Inc. | Interpreting an application message at a network element using sampling and heuristics |
US20060155862A1 (en) * | 2005-01-06 | 2006-07-13 | Hari Kathi | Data traffic load balancing based on application layer messages |
US7698416B2 (en) * | 2005-01-25 | 2010-04-13 | Cisco Technology, Inc. | Application layer message-based server failover management by a network element |
WO2006085313A2 (en) * | 2005-02-09 | 2006-08-17 | Enure Networks Ltd. | Device, method, and system for module level network supervision |
EP1866789B8 (en) * | 2005-02-28 | 2020-04-15 | McAfee, LLC | Mobile data security system and methods |
US9137251B2 (en) | 2005-03-16 | 2015-09-15 | Fortinet, Inc. | Inheritance based network management |
US8539587B2 (en) | 2005-03-22 | 2013-09-17 | Hewlett-Packard Development Company, L.P. | Methods, devices and data structures for trusted data |
US8667106B2 (en) * | 2005-05-20 | 2014-03-04 | At&T Intellectual Property Ii, L.P. | Apparatus for blocking malware originating inside and outside an operating system |
US7603696B2 (en) * | 2005-06-10 | 2009-10-13 | Intel Corporation | Hybrid distributed firewall apparatus, systems, and methods |
US20060288411A1 (en) * | 2005-06-21 | 2006-12-21 | Avaya, Inc. | System and method for mitigating denial of service attacks on communication appliances |
US7345585B2 (en) * | 2005-08-01 | 2008-03-18 | Cisco Technology, Inc. | Network based device for providing RFID middleware functionality |
FR2897736B1 (en) * | 2006-02-22 | 2008-04-11 | Viaccess Sa | METHOD FOR ESTABLISHING A CRYPTOGRAPHIC KEY, NET HEAD AND RECEIVER FOR THIS METHOD, AND METHOD FOR TRANSMITTING SIGNALS |
US7592906B1 (en) * | 2006-06-05 | 2009-09-22 | Juniper Networks, Inc. | Network policy evaluation |
JP4916227B2 (en) * | 2006-06-14 | 2012-04-11 | ăă€ăăłæ ȘćŒäŒç€Ÿ | Device management apparatus and control method of the management apparatus |
US8259568B2 (en) | 2006-10-23 | 2012-09-04 | Mcafee, Inc. | System and method for controlling mobile device access to a network |
US20080103529A1 (en) * | 2006-10-26 | 2008-05-01 | Old Dominion University | Apparatus and methods for performing cellular electro-manipulations |
US8302179B2 (en) * | 2006-12-13 | 2012-10-30 | Avaya Inc. | Embedded firewall at a telecommunications endpoint |
US20090063650A1 (en) * | 2007-09-05 | 2009-03-05 | International Business Machines Corporation | Managing Collections of Appliances |
DE202007019129U1 (en) | 2007-10-31 | 2010-09-30 | Concept04 Gmbh | Mobile radio terminal with filter device and network element for configuring the filter device |
US8036106B1 (en) | 2007-10-31 | 2011-10-11 | World Wide Packets, Inc. | Distributed control packet transmission |
US8144574B1 (en) * | 2007-10-31 | 2012-03-27 | World Wide Packets, Inc. | Distributed control packet processing |
WO2009157897A1 (en) * | 2008-06-25 | 2009-12-30 | Thomson Licensing | Targeted user notification of messages in a monitoring system |
WO2010054258A1 (en) * | 2008-11-06 | 2010-05-14 | Trust Digital | System and method for mediating connections between policy source servers, corporate repositories, and mobile devices |
US8316113B2 (en) * | 2008-12-19 | 2012-11-20 | Watchguard Technologies, Inc. | Cluster architecture and configuration for network security devices |
US8682985B2 (en) * | 2009-01-15 | 2014-03-25 | Microsoft Corporation | Message tracking between organizations |
US8284699B1 (en) | 2009-04-30 | 2012-10-09 | Palo Alto Networks, Inc. | Managing network devices |
US8108495B1 (en) | 2009-04-30 | 2012-01-31 | Palo Alto Networks, Inc. | Managing network devices |
KR20110089650A (en) * | 2010-02-01 | 2011-08-09 | ìŒì±ì ììŁŒìíìŹ | Host device, image forming apparatus and method for managing of secure setting |
US8935384B2 (en) | 2010-05-06 | 2015-01-13 | Mcafee Inc. | Distributed data revocation using data commands |
WO2011149558A2 (en) | 2010-05-28 | 2011-12-01 | Abelow Daniel H | Reality alternate |
US9232015B1 (en) | 2011-08-04 | 2016-01-05 | Wyse Technology L.L.C. | Translation layer for client-server communication |
US9027077B1 (en) * | 2012-04-30 | 2015-05-05 | Palo Alto Networks, Inc. | Deploying policy configuration across multiple security devices through hierarchical configuration templates |
US9189636B2 (en) * | 2012-07-30 | 2015-11-17 | Hewlett-Packard Development Company, L.P. | Office machine security policy |
US8977746B2 (en) * | 2013-03-20 | 2015-03-10 | Watchguard Technologies, Inc. | Systems and methods for scalable network monitoring |
US9088543B2 (en) | 2013-06-03 | 2015-07-21 | International Business Machines Corporation | Coordinated network security management |
US9807604B2 (en) | 2013-07-19 | 2017-10-31 | Intel Corporation | Area-based location privacy management |
US9361432B2 (en) | 2014-01-15 | 2016-06-07 | Hewlett-Packard Development Company, L.P. | Configuring a security setting for a set of devices using a security policy |
US9832219B2 (en) * | 2014-09-05 | 2017-11-28 | International Business Machines Corporation | System for tracking data security threats and method for same |
US10367828B2 (en) | 2014-10-30 | 2019-07-30 | International Business Machines Corporation | Action response framework for data security incidents |
US9531757B2 (en) | 2015-01-20 | 2016-12-27 | Cisco Technology, Inc. | Management of security policies across multiple security products |
US9401933B1 (en) | 2015-01-20 | 2016-07-26 | Cisco Technology, Inc. | Classification of security policies across multiple security products |
US9571524B2 (en) * | 2015-01-20 | 2017-02-14 | Cisco Technology, Inc. | Creation of security policy templates and security policies based on the templates |
US9680875B2 (en) | 2015-01-20 | 2017-06-13 | Cisco Technology, Inc. | Security policy unification across different security products |
US9641540B2 (en) | 2015-05-19 | 2017-05-02 | Cisco Technology, Inc. | User interface driven translation, comparison, unification, and deployment of device neutral network security policies |
US10425447B2 (en) | 2015-08-28 | 2019-09-24 | International Business Machines Corporation | Incident response bus for data security incidents |
US10348754B2 (en) | 2015-12-28 | 2019-07-09 | International Business Machines Corporation | Data security incident correlation and dissemination system and method |
US10700894B2 (en) | 2016-06-01 | 2020-06-30 | At&T Intellectual Property I, L.P. | Network caching of outbound content from endpoint device to prevent unauthorized extraction |
US11785052B2 (en) | 2016-06-21 | 2023-10-10 | International Business Machines Corporation | Incident response plan based on indicators of compromise |
US10594725B2 (en) * | 2017-07-27 | 2020-03-17 | Cypress Semiconductor Corporation | Generating and analyzing network profile data |
US11244058B2 (en) | 2019-09-18 | 2022-02-08 | Bank Of America Corporation | Security tool |
US11245703B2 (en) | 2019-09-27 | 2022-02-08 | Bank Of America Corporation | Security tool for considering multiple security contexts |
Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5577209A (en) * | 1991-07-11 | 1996-11-19 | Itt Corporation | Apparatus and method for providing multi-level security for communication among computers and terminals on a network |
US5968176A (en) * | 1997-05-29 | 1999-10-19 | 3Com Corporation | Multilayer firewall system |
US5991877A (en) * | 1997-04-03 | 1999-11-23 | Lockheed Martin Corporation | Object-oriented trusted application framework |
US6052728A (en) * | 1997-01-08 | 2000-04-18 | Hitachi, Ltd. | Method of collectively managing dispersive log, network system and relay computer for use in the same |
US6243815B1 (en) * | 1997-04-25 | 2001-06-05 | Anand K. Antur | Method and apparatus for reconfiguring and managing firewalls and security devices |
US6353886B1 (en) * | 1998-02-04 | 2002-03-05 | Alcatel Canada Inc. | Method and system for secure network policy implementation |
US6502140B1 (en) * | 1999-01-29 | 2002-12-31 | International Business Machines Corporation | Multicast support for small groups |
-
1999
- 1999-05-06 US US09/307,332 patent/US6678827B1/en not_active Expired - Lifetime
-
2000
- 2000-04-13 AU AU43466/00A patent/AU4346600A/en not_active Abandoned
- 2000-04-13 JP JP2000617601A patent/JP2002544607A/en active Pending
- 2000-04-13 EP EP00923320A patent/EP1175752A1/en not_active Withdrawn
- 2000-04-13 WO PCT/US2000/009942 patent/WO2000069120A1/en not_active Application Discontinuation
-
2003
- 2003-11-12 US US10/712,313 patent/US20040181690A1/en not_active Abandoned
Patent Citations (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5577209A (en) * | 1991-07-11 | 1996-11-19 | Itt Corporation | Apparatus and method for providing multi-level security for communication among computers and terminals on a network |
US5940591A (en) * | 1991-07-11 | 1999-08-17 | Itt Corporation | Apparatus and method for providing network security |
US6052728A (en) * | 1997-01-08 | 2000-04-18 | Hitachi, Ltd. | Method of collectively managing dispersive log, network system and relay computer for use in the same |
US5991877A (en) * | 1997-04-03 | 1999-11-23 | Lockheed Martin Corporation | Object-oriented trusted application framework |
US6243815B1 (en) * | 1997-04-25 | 2001-06-05 | Anand K. Antur | Method and apparatus for reconfiguring and managing firewalls and security devices |
US5968176A (en) * | 1997-05-29 | 1999-10-19 | 3Com Corporation | Multilayer firewall system |
US6353886B1 (en) * | 1998-02-04 | 2002-03-05 | Alcatel Canada Inc. | Method and system for secure network policy implementation |
US6502140B1 (en) * | 1999-01-29 | 2002-12-31 | International Business Machines Corporation | Multicast support for small groups |
Cited By (242)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7174453B2 (en) * | 2000-12-29 | 2007-02-06 | America Online, Inc. | Message screening system |
US20070124690A1 (en) * | 2000-12-29 | 2007-05-31 | Aol Llc | Message screening system |
US9621501B2 (en) | 2000-12-29 | 2017-04-11 | Facebook, Inc. | Message screening system utilizing supervisory screening and approval |
US20020107950A1 (en) * | 2000-12-29 | 2002-08-08 | Lu Larry L. | Message screening system |
US9083666B2 (en) | 2000-12-29 | 2015-07-14 | Facebook, Inc. | Message screening system utilizing supervisory screening and approval |
US8776222B2 (en) | 2000-12-29 | 2014-07-08 | Facebook, Inc. | Message screening system |
US8099780B2 (en) | 2000-12-29 | 2012-01-17 | Aol Inc. | Message screening system |
US20080098308A1 (en) * | 2001-10-24 | 2008-04-24 | At&T Labs, Inc. | Unified interface for managing dsl services |
US20030118038A1 (en) * | 2001-11-29 | 2003-06-26 | Mika Jalava | Personalized firewall |
US8099776B2 (en) * | 2001-11-29 | 2012-01-17 | Stonesoft Corporation | Personalized firewall |
US8209756B1 (en) | 2002-02-08 | 2012-06-26 | Juniper Networks, Inc. | Compound attack detection in a computer network |
US7484097B2 (en) * | 2002-04-04 | 2009-01-27 | Symantec Corporation | Method and system for communicating data to and from network security devices |
US20030217292A1 (en) * | 2002-04-04 | 2003-11-20 | Steiger John Thomas | Method and system for communicating data to and from network security devices |
US20110283207A1 (en) * | 2002-05-22 | 2011-11-17 | Sony Pictures Entertainment Inc. | System and method for platform and language-independent development and delivery of page-based content |
US8301875B2 (en) * | 2002-09-11 | 2012-10-30 | NEC Infrontia Coropration | Network, IPsec setting server apparatus, IPsec processing apparatus, and IPsec setting method used therefor |
US20040093524A1 (en) * | 2002-09-11 | 2004-05-13 | Nec Corporation | Network, IPsec setting server apparatus, IPsec processing apparatus, and IPsec setting method used therefor |
US20040107274A1 (en) * | 2002-12-03 | 2004-06-03 | Mastrianni Steven J. | Policy-based connectivity |
USRE45558E1 (en) | 2002-12-30 | 2015-06-09 | Facebook, Inc. | Supervising user interaction with online services |
US7904554B1 (en) | 2002-12-30 | 2011-03-08 | Aol Inc. | Supervising user interaction with online services |
US7954163B2 (en) | 2003-09-10 | 2011-05-31 | Cisco Technology, Inc. | Method and apparatus for providing network security using role-based access control |
US20110231907A1 (en) * | 2003-09-10 | 2011-09-22 | Smith Michael R | Method and apparatus for providing network security using role-based access control |
US8661556B2 (en) | 2003-09-10 | 2014-02-25 | Cisco Technology, Inc. | Method and apparatus for providing network security using role-based access control |
US9237158B2 (en) | 2003-09-10 | 2016-01-12 | Cisco Technology, Inc. | Method and apparatus for providing network security using role-based access control |
US9860254B2 (en) | 2003-09-10 | 2018-01-02 | Cisco Technology, Inc. | Method and apparatus for providing network security using role-based access control |
US20090217355A1 (en) * | 2003-09-10 | 2009-08-27 | Smith Michael R | Method and Apparatus For Providing Network Security Using Role-Based Access Control |
US20070064689A1 (en) * | 2003-09-19 | 2007-03-22 | Shin Yong M | Method of controlling communication between devices in a network and apparatus for the same |
US8112788B2 (en) | 2003-09-24 | 2012-02-07 | Infoexpress, Inc. | Systems and methods of controlling network access |
US8347351B2 (en) | 2003-09-24 | 2013-01-01 | Infoexpress, Inc. | Systems and methods of controlling network access |
US20110231915A1 (en) * | 2003-09-24 | 2011-09-22 | Infoexpress, Inc. | Systems and methods of controlling network access |
US20110231928A1 (en) * | 2003-09-24 | 2011-09-22 | Infoexpress, Inc. | Systems and methods of controlling network access |
US8578444B2 (en) | 2003-09-24 | 2013-11-05 | Info Express, Inc. | Systems and methods of controlling network access |
US20090083830A1 (en) * | 2003-09-24 | 2009-03-26 | Lum Stacey C | Systems and Methods of Controlling Network Access |
US20110231916A1 (en) * | 2003-09-24 | 2011-09-22 | Infoexpress, Inc. | Systems and methods of controlling network access |
US8650610B2 (en) | 2003-09-24 | 2014-02-11 | Infoexpress, Inc. | Systems and methods of controlling network access |
US8051460B2 (en) | 2003-09-24 | 2011-11-01 | Infoexpress, Inc. | Systems and methods of controlling network access |
US8108909B2 (en) | 2003-09-24 | 2012-01-31 | Infoexpress, Inc. | Systems and methods of controlling network access |
US7523484B2 (en) | 2003-09-24 | 2009-04-21 | Infoexpress, Inc. | Systems and methods of controlling network access |
US8117645B2 (en) | 2003-09-24 | 2012-02-14 | Infoexpress, Inc. | Systems and methods of controlling network access |
US8347350B2 (en) | 2003-09-24 | 2013-01-01 | Infoexpress, Inc. | Systems and methods of controlling network access |
US8677450B2 (en) | 2003-09-24 | 2014-03-18 | Infoexpress, Inc. | Systems and methods of controlling network access |
US7836490B2 (en) * | 2003-10-29 | 2010-11-16 | Cisco Technology, Inc. | Method and apparatus for providing network security using security labeling |
US20050097357A1 (en) * | 2003-10-29 | 2005-05-05 | Smith Michael R. | Method and apparatus for providing network security using security labeling |
US8539571B2 (en) | 2003-10-29 | 2013-09-17 | Cisco Technology, Inc. | Method and apparatus for providing network security using security labeling |
US9092471B2 (en) | 2003-12-10 | 2015-07-28 | Mcafee, Inc. | Rule parser |
US20050132046A1 (en) * | 2003-12-10 | 2005-06-16 | De La Iglesia Erik | Method and apparatus for data capture and analysis system |
US8548170B2 (en) | 2003-12-10 | 2013-10-01 | Mcafee, Inc. | Document de-registration |
US8762386B2 (en) | 2003-12-10 | 2014-06-24 | Mcafee, Inc. | Method and apparatus for data capture and analysis system |
US8166307B2 (en) | 2003-12-10 | 2012-04-24 | McAffee, Inc. | Document registration |
US8271794B2 (en) | 2003-12-10 | 2012-09-18 | Mcafee, Inc. | Verifying captured objects before presentation |
US8656039B2 (en) | 2003-12-10 | 2014-02-18 | Mcafee, Inc. | Rule parser |
US7984175B2 (en) | 2003-12-10 | 2011-07-19 | Mcafee, Inc. | Method and apparatus for data capture and analysis system |
US8301635B2 (en) | 2003-12-10 | 2012-10-30 | Mcafee, Inc. | Tag data structure for maintaining relational data over captured objects |
US9374225B2 (en) | 2003-12-10 | 2016-06-21 | Mcafee, Inc. | Document de-registration |
US7899828B2 (en) | 2003-12-10 | 2011-03-01 | Mcafee, Inc. | Tag data structure for maintaining relational data over captured objects |
US8307206B2 (en) | 2004-01-22 | 2012-11-06 | Mcafee, Inc. | Cryptographic policy enforcement |
US7930540B2 (en) | 2004-01-22 | 2011-04-19 | Mcafee, Inc. | Cryptographic policy enforcement |
US20080222698A1 (en) * | 2004-02-27 | 2008-09-11 | Bae Systems Plc | Secure Computer Communication |
US20050235340A1 (en) * | 2004-04-16 | 2005-10-20 | To William C | Configuration management apparatus and related methods |
US7734740B2 (en) * | 2004-04-16 | 2010-06-08 | The Boeing Company | Configuration management apparatus and related methods |
US7725921B2 (en) * | 2004-04-22 | 2010-05-25 | Microsoft Corporation | Systems and methods for managing networks |
US20050240990A1 (en) * | 2004-04-22 | 2005-10-27 | Microsoft Corporation | Systems and methods for managing networks |
US7962591B2 (en) | 2004-06-23 | 2011-06-14 | Mcafee, Inc. | Object classification in a capture system |
US7996889B2 (en) * | 2004-07-28 | 2011-08-09 | Canon Kabushiki Kaisha | Image processing apparatus, control method for image processing apparatus and control program for image processing apparatus |
US20060026673A1 (en) * | 2004-07-28 | 2006-02-02 | Canon Kabushiki Kaisha | Image processing apparatus, control method for image processing apparatus and control program for image processing apparatus |
US8560534B2 (en) | 2004-08-23 | 2013-10-15 | Mcafee, Inc. | Database for a capture system |
US7949849B2 (en) | 2004-08-24 | 2011-05-24 | Mcafee, Inc. | File system for a capture system |
US8707008B2 (en) | 2004-08-24 | 2014-04-22 | Mcafee, Inc. | File system for a capture system |
US20060048209A1 (en) * | 2004-08-31 | 2006-03-02 | Microsoft Corporation | Method and system for customizing a security policy |
US7549158B2 (en) * | 2004-08-31 | 2009-06-16 | Microsoft Corporation | Method and system for customizing a security policy |
US20060075503A1 (en) * | 2004-09-13 | 2006-04-06 | Achilles Guard, Inc. Dba Critical Watch | Method and system for applying security vulnerability management process to an organization |
US8302157B2 (en) | 2004-10-21 | 2012-10-30 | Cisco Technology, Inc. | Method and system for generating user group identifiers |
US20060106750A1 (en) * | 2004-11-16 | 2006-05-18 | Smith Michael R | Method and apparatus for best effort propagation of security group information |
US7877796B2 (en) | 2004-11-16 | 2011-01-25 | Cisco Technology, Inc. | Method and apparatus for best effort propagation of security group information |
US9407604B2 (en) | 2004-11-16 | 2016-08-02 | Cisco Technology Inc. | Method and apparatus for best effort propagation of security group information |
US10193861B2 (en) | 2004-11-16 | 2019-01-29 | Cisco Technology, Inc. | Method and apparatus for best effort propagation of security group information |
US8621596B2 (en) | 2004-11-16 | 2013-12-31 | Cisco Technology, Inc. | Method and apparatus for best effort propagation of security group information |
EP1677484A2 (en) * | 2004-11-19 | 2006-07-05 | Microsoft Corporation | Method and system for distributing security policies |
EP1677484A3 (en) * | 2004-11-19 | 2007-05-09 | Microsoft Corporation | Method and system for distributing security policies |
US7831826B2 (en) | 2004-11-19 | 2010-11-09 | Microsoft Corporation | Method and system for distributing security policies |
US7509493B2 (en) | 2004-11-19 | 2009-03-24 | Microsoft Corporation | Method and system for distributing security policies |
US20060129808A1 (en) * | 2004-11-19 | 2006-06-15 | Microsoft Corporation | Method and system for distributing security policies |
US20090172774A1 (en) * | 2004-11-19 | 2009-07-02 | Microsoft Corporation | Method and system for distributing security policies |
KR101183423B1 (en) | 2004-11-19 | 2012-09-14 | ë§ìŽíŹëĄìííž ìœíŹë ìŽì | Method and system for distributing security policies |
US9461979B2 (en) | 2004-11-23 | 2016-10-04 | Cisco Technology, Inc. | Method and system for including network security information in a frame |
US20060112426A1 (en) * | 2004-11-23 | 2006-05-25 | Smith Michael R | Method and system for including security information with a packet |
US8561140B2 (en) | 2004-11-23 | 2013-10-15 | Cisco Technology, Inc. | Method and system for including network security information in a frame |
US7886145B2 (en) | 2004-11-23 | 2011-02-08 | Cisco Technology, Inc. | Method and system for including security information with a packet |
US8555056B2 (en) | 2004-11-23 | 2013-10-08 | Cisco Technology, Inc. | Method and system for including security information with a packet |
US20060112425A1 (en) * | 2004-11-23 | 2006-05-25 | Smith Michael R | Method and system for including security information with a packet |
US7877601B2 (en) | 2004-11-23 | 2011-01-25 | Cisco Technology, Inc. | Method and system for including security information with a packet |
US20100223657A1 (en) * | 2004-11-23 | 2010-09-02 | Finn Norman W | Method and system for including network security information in a frame |
US8301882B2 (en) | 2004-12-01 | 2012-10-30 | Cisco Technology, Inc. | Method and apparatus for ingress filtering using security group information |
US7827402B2 (en) | 2004-12-01 | 2010-11-02 | Cisco Technology, Inc. | Method and apparatus for ingress filtering using security group information |
US20060117058A1 (en) * | 2004-12-01 | 2006-06-01 | Cisco Technology, Inc. | Method and apparatus for ingress filtering using security group information |
US7591010B2 (en) | 2005-01-19 | 2009-09-15 | Microsoft Corporation | Method and system for separating rules of a security policy from detection criteria |
US7937755B1 (en) * | 2005-01-27 | 2011-05-03 | Juniper Networks, Inc. | Identification of network policy violations |
US7809826B1 (en) | 2005-01-27 | 2010-10-05 | Juniper Networks, Inc. | Remote aggregation of network traffic profiling data |
US7769851B1 (en) | 2005-01-27 | 2010-08-03 | Juniper Networks, Inc. | Application-layer monitoring and profiling network traffic |
US20060174318A1 (en) * | 2005-01-28 | 2006-08-03 | Microsoft Corporation | Method and system for troubleshooting when a program is adversely impacted by a security policy |
US7707619B2 (en) | 2005-01-28 | 2010-04-27 | Microsoft Corporation | Method and system for troubleshooting when a program is adversely impacted by a security policy |
US8266267B1 (en) | 2005-02-02 | 2012-09-11 | Juniper Networks, Inc. | Detection and prevention of encapsulated network attacks using an intermediate device |
US8280058B2 (en) | 2005-02-07 | 2012-10-02 | Juniper Networks, Inc. | Wireless network having multiple security interfaces |
US20060177063A1 (en) * | 2005-02-07 | 2006-08-10 | Conway Adam M | Wireless network having multiple security interfaces |
US7627123B2 (en) * | 2005-02-07 | 2009-12-01 | Juniper Networks, Inc. | Wireless network having multiple security interfaces |
US20100050240A1 (en) * | 2005-02-07 | 2010-02-25 | Juniper Networks, Inc. | Wireless network having multiple security interfaces |
US8799991B2 (en) * | 2005-02-07 | 2014-08-05 | Juniper Networks, Inc. | Wireless network having multiple security interfaces |
US20120324533A1 (en) * | 2005-02-07 | 2012-12-20 | Juniper Networks, Inc. | Wireless network having multiple security interfaces |
US8590011B1 (en) * | 2005-02-24 | 2013-11-19 | Versata Development Group, Inc. | Variable domain resource data security for data processing systems |
US20060201438A1 (en) * | 2005-03-08 | 2006-09-14 | Anttila Arthur L | Clumping, non-dusting calcium carbonate-based animal litter |
US20060265739A1 (en) * | 2005-05-19 | 2006-11-23 | International Business Machines Corporation | Method and system for autonomic security configuration |
US8904486B2 (en) * | 2005-05-19 | 2014-12-02 | International Business Machines Corporation | Method and system for autonomic security configuration |
US7907608B2 (en) | 2005-08-12 | 2011-03-15 | Mcafee, Inc. | High speed packet capture |
US8730955B2 (en) | 2005-08-12 | 2014-05-20 | Mcafee, Inc. | High speed packet capture |
US8554774B2 (en) | 2005-08-31 | 2013-10-08 | Mcafee, Inc. | System and method for word indexing in a capture system and querying thereof |
US7818326B2 (en) | 2005-08-31 | 2010-10-19 | Mcafee, Inc. | System and method for word indexing in a capture system and querying thereof |
US20100005506A1 (en) * | 2005-09-14 | 2010-01-07 | Lum Stacey C | Dynamic address assignment for access control on dhcp networks |
US20070061458A1 (en) * | 2005-09-14 | 2007-03-15 | Infoexpress, Inc. | Dynamic address assignment for access control on DHCP networks |
US7890658B2 (en) | 2005-09-14 | 2011-02-15 | Infoexpress, Inc. | Dynamic address assignment for access control on DHCP networks |
US7590733B2 (en) | 2005-09-14 | 2009-09-15 | Infoexpress, Inc. | Dynamic address assignment for access control on DHCP networks |
US8463800B2 (en) | 2005-10-19 | 2013-06-11 | Mcafee, Inc. | Attributes of captured objects in a capture system |
US8176049B2 (en) | 2005-10-19 | 2012-05-08 | Mcafee Inc. | Attributes of captured objects in a capture system |
US8200026B2 (en) | 2005-11-21 | 2012-06-12 | Mcafee, Inc. | Identifying image type in a capture system |
US20070174501A1 (en) * | 2006-01-06 | 2007-07-26 | Hon Hai Precision Industry Co., Ltd. | System and method for managing a data transfer channel between communication devices |
US20070180258A1 (en) * | 2006-01-20 | 2007-08-02 | Broussard Scott J | Confidential content search engine system and method |
US9262727B2 (en) | 2006-01-20 | 2016-02-16 | International Business Machines Corporation | Confidential content search engine |
US20080235196A1 (en) * | 2006-01-20 | 2008-09-25 | International Business Machines Corporation | Confidential Content Search Engine |
US7926102B2 (en) | 2006-01-20 | 2011-04-12 | International Business Machines Corporation | Confidential content search engine method |
US20070192858A1 (en) * | 2006-02-16 | 2007-08-16 | Infoexpress, Inc. | Peer based network access control |
US20070192500A1 (en) * | 2006-02-16 | 2007-08-16 | Infoexpress, Inc. | Network access control including dynamic policy enforcement point |
US20070204323A1 (en) * | 2006-02-24 | 2007-08-30 | Rockwell Automation Technologies, Inc. | Auto-detection capabilities for out of the box experience |
US8504537B2 (en) | 2006-03-24 | 2013-08-06 | Mcafee, Inc. | Signature distribution in a document registration system |
US7966659B1 (en) | 2006-04-18 | 2011-06-21 | Rockwell Automation Technologies, Inc. | Distributed learn mode for configuring a firewall, security authority, intrusion detection/prevention devices, and the like |
US20080235760A1 (en) * | 2006-05-02 | 2008-09-25 | International Business Machines Corporation | Confidential Content Reporting System and Method with Electronic Mail Verification Functionality |
US8683035B2 (en) | 2006-05-22 | 2014-03-25 | Mcafee, Inc. | Attributes of captured objects in a capture system |
US9094338B2 (en) | 2006-05-22 | 2015-07-28 | Mcafee, Inc. | Attributes of captured objects in a capture system |
US8307007B2 (en) | 2006-05-22 | 2012-11-06 | Mcafee, Inc. | Query generation for a capture system |
US7958227B2 (en) | 2006-05-22 | 2011-06-07 | Mcafee, Inc. | Attributes of captured objects in a capture system |
US8005863B2 (en) | 2006-05-22 | 2011-08-23 | Mcafee, Inc. | Query generation for a capture system |
US8010689B2 (en) | 2006-05-22 | 2011-08-30 | Mcafee, Inc. | Locational tagging in a capture system |
US8522304B2 (en) * | 2006-09-08 | 2013-08-27 | Ibahn General Holdings Corporation | Monitoring and reporting policy compliance of home networks |
US20080066145A1 (en) * | 2006-09-08 | 2008-03-13 | Ibahn General Holdings, Inc. | Monitoring and reporting policy compliance of home networks |
US20080072032A1 (en) * | 2006-09-19 | 2008-03-20 | Searete Llc, A Limited Liability Corporation Of The State Of Delaware | Configuring software agent security remotely |
US9680699B2 (en) | 2006-09-19 | 2017-06-13 | Invention Science Fund I, Llc | Evaluation systems and methods for coordinating software agents |
US20110047369A1 (en) * | 2006-09-19 | 2011-02-24 | Cohen Alexander J | Configuring Software Agent Security Remotely |
US20080092069A1 (en) * | 2006-10-13 | 2008-04-17 | Allan Chan | Graphical representation of a port security state |
US9178909B2 (en) * | 2006-10-13 | 2015-11-03 | Hewlett-Packard Development Company, L.P. | Graphical representation of a port security state |
US20080098455A1 (en) * | 2006-10-20 | 2008-04-24 | Canon Kabushiki Kaisha | Document management system and document management method |
US8561128B2 (en) * | 2006-10-20 | 2013-10-15 | Canon Kabushiki Kaisha | Document management system and document management method |
US8218570B2 (en) * | 2006-12-22 | 2012-07-10 | Verizon Patent And Licensing Inc. | Network element abstraction within a network management system |
US20080155424A1 (en) * | 2006-12-22 | 2008-06-26 | Verizon Data Services, Inc. | Network element abstraction within a network management system |
US20080196104A1 (en) * | 2007-02-09 | 2008-08-14 | George Tuvell | Off-line mms malware scanning system and method |
US7711000B2 (en) * | 2007-08-06 | 2010-05-04 | At&T Intellectual Property I, L.P. | System for configuring network elements |
US20090041026A1 (en) * | 2007-08-06 | 2009-02-12 | At&T Knowledge Ventures, L.P. | System for configuring network elements |
US8713201B2 (en) | 2007-08-13 | 2014-04-29 | Cisco Technology, Inc. | Method and system for the assignment of security group information using a proxy |
US20090049196A1 (en) * | 2007-08-13 | 2009-02-19 | Smith Michael R | Method and system for the assignment of security group information using a proxy |
US7840708B2 (en) | 2007-08-13 | 2010-11-23 | Cisco Technology, Inc. | Method and system for the assignment of security group information using a proxy |
US8621573B2 (en) | 2007-08-28 | 2013-12-31 | Cisco Technology, Inc. | Highly scalable application network appliances with virtualized services |
US8984580B2 (en) * | 2007-10-05 | 2015-03-17 | Samsung Electronics Co., Ltd. | Universal serial bus selective encryption |
US20090094387A1 (en) * | 2007-10-05 | 2009-04-09 | Pano Logic, Inc. | Universal serial bus assistance engine |
US20090094672A1 (en) * | 2007-10-05 | 2009-04-09 | Pano Logic, Inc. | Universal serial bus selective encryption |
US8813098B2 (en) | 2007-10-05 | 2014-08-19 | Samsung Electronics Co., Ltd. | Universal serial bus host controller driver over a network |
US20090094621A1 (en) * | 2007-10-05 | 2009-04-09 | Pano Logic, Inc. | Universal serial bus host controller driver over a network |
US8260985B2 (en) | 2007-10-05 | 2012-09-04 | Pano Logic, Inc. | Universal serial bus assistance engine |
US8799533B2 (en) | 2007-10-05 | 2014-08-05 | Samsung Electronics Co., Ltd. | Universal serial bus assistance engine |
US20090150513A1 (en) * | 2007-12-10 | 2009-06-11 | At&T Knowledge Ventures, Lp | Method and System for Gathering Network Data |
US8346953B1 (en) | 2007-12-18 | 2013-01-01 | AOL, Inc. | Methods and systems for restricting electronic content access based on guardian control decisions |
US20090219392A1 (en) * | 2008-02-01 | 2009-09-03 | Third Iris Corp | Point of recordation terminal apparatus for sending high complexity image sequences over an unreliable low-bandwidth channel |
US20110001850A1 (en) * | 2008-02-01 | 2011-01-06 | Gaubatz Matthew D | Automatic Redeye Detection |
US8667556B2 (en) * | 2008-05-19 | 2014-03-04 | Cisco Technology, Inc. | Method and apparatus for building and managing policies |
US20090288135A1 (en) * | 2008-05-19 | 2009-11-19 | Rohati Systems, Inc. | Method and apparatus for building and managing policies |
US8856926B2 (en) | 2008-06-27 | 2014-10-07 | Juniper Networks, Inc. | Dynamic policy provisioning within network security devices |
US20100017843A1 (en) * | 2008-06-27 | 2010-01-21 | Microsoft Corporation | Scenario Based Security |
US20090328219A1 (en) * | 2008-06-27 | 2009-12-31 | Juniper Networks, Inc. | Dynamic policy provisioning within network security devices |
US8601537B2 (en) | 2008-07-10 | 2013-12-03 | Mcafee, Inc. | System and method for data mining and security policy management |
US8635706B2 (en) | 2008-07-10 | 2014-01-21 | Mcafee, Inc. | System and method for data mining and security policy management |
US8205242B2 (en) | 2008-07-10 | 2012-06-19 | Mcafee, Inc. | System and method for data mining and security policy management |
US8819201B2 (en) * | 2008-08-07 | 2014-08-26 | At&T Intellectual Property I, L.P. | Method and apparatus for providing routing and access control filters |
US20100037287A1 (en) * | 2008-08-07 | 2010-02-11 | Mallikarjun Netrakanti | Method and apparatus for providing routing and access control filters |
US10367786B2 (en) * | 2008-08-12 | 2019-07-30 | Mcafee, Llc | Configuration management for a capture/registration system |
US20160241518A1 (en) * | 2008-08-12 | 2016-08-18 | Mcafee, Inc. | Configuration management for a capture/registration system |
US9253154B2 (en) * | 2008-08-12 | 2016-02-02 | Mcafee, Inc. | Configuration management for a capture/registration system |
US8850591B2 (en) | 2009-01-13 | 2014-09-30 | Mcafee, Inc. | System and method for concept building |
US8706709B2 (en) | 2009-01-15 | 2014-04-22 | Mcafee, Inc. | System and method for intelligent term grouping |
US9602548B2 (en) | 2009-02-25 | 2017-03-21 | Mcafee, Inc. | System and method for intelligent state management |
US8473442B1 (en) | 2009-02-25 | 2013-06-25 | Mcafee, Inc. | System and method for intelligent state management |
US9195937B2 (en) | 2009-02-25 | 2015-11-24 | Mcafee, Inc. | System and method for intelligent state management |
US8558888B2 (en) * | 2009-02-27 | 2013-10-15 | Third Iris Corp. | Bandwidth shaping client to capture, transform, cache, and upload images from a remote point of recordation to a network service |
US9313232B2 (en) | 2009-03-25 | 2016-04-12 | Mcafee, Inc. | System and method for data mining and security policy management |
US8447722B1 (en) | 2009-03-25 | 2013-05-21 | Mcafee, Inc. | System and method for data mining and security policy management |
US8918359B2 (en) | 2009-03-25 | 2014-12-23 | Mcafee, Inc. | System and method for data mining and security policy management |
US8667121B2 (en) | 2009-03-25 | 2014-03-04 | Mcafee, Inc. | System and method for managing data and policies |
US20100246547A1 (en) * | 2009-03-26 | 2010-09-30 | Samsung Electronics Co., Ltd. | Antenna selecting apparatus and method in wireless communication system |
US8621615B2 (en) * | 2009-04-03 | 2013-12-31 | Juniper Networks, Inc. | Behavior-based traffic profiling based on access control information |
US20100257580A1 (en) * | 2009-04-03 | 2010-10-07 | Juniper Networks, Inc. | Behavior-based traffic profiling based on access control information |
US8955119B2 (en) | 2009-04-03 | 2015-02-10 | Juniper Networks, Inc. | Behavior-based traffic profiling based on access control information |
US20110153788A1 (en) * | 2009-12-23 | 2011-06-23 | Jacobus Van Der Merwe | Method and System for Automated Network Operations |
US9794254B2 (en) | 2010-11-04 | 2017-10-17 | Mcafee, Inc. | System and method for protecting specified data combinations |
US8806615B2 (en) | 2010-11-04 | 2014-08-12 | Mcafee, Inc. | System and method for protecting specified data combinations |
US11316848B2 (en) | 2010-11-04 | 2022-04-26 | Mcafee, Llc | System and method for protecting specified data combinations |
US10666646B2 (en) | 2010-11-04 | 2020-05-26 | Mcafee, Llc | System and method for protecting specified data combinations |
US10313337B2 (en) | 2010-11-04 | 2019-06-04 | Mcafee, Llc | System and method for protecting specified data combinations |
US9071611B2 (en) * | 2011-02-23 | 2015-06-30 | Cisco Technology, Inc. | Integration of network admission control functions in network access devices |
US20120216239A1 (en) * | 2011-02-23 | 2012-08-23 | Cisco Technology, Inc. | Integration of network admission control functions in network access devices |
EP2693355A4 (en) * | 2011-03-31 | 2015-05-27 | Hitachi Ltd | Security-level visualization device |
US20120266073A1 (en) * | 2011-04-14 | 2012-10-18 | Ricoh Company, Ltd. | Device management system including reporter server |
US20120265865A1 (en) * | 2011-04-14 | 2012-10-18 | Ricoh Company, Ltd. | Device management system |
US9298574B2 (en) * | 2011-04-14 | 2016-03-29 | Ricoh Company, Ltd. | Device management system including reporter server |
US20130160129A1 (en) * | 2011-12-19 | 2013-06-20 | Verizon Patent And Licensing Inc. | System security evaluation |
US9430564B2 (en) | 2011-12-27 | 2016-08-30 | Mcafee, Inc. | System and method for providing data protection workflows in a network environment |
US8700561B2 (en) | 2011-12-27 | 2014-04-15 | Mcafee, Inc. | System and method for providing data protection workflows in a network environment |
US9317696B2 (en) | 2012-07-10 | 2016-04-19 | Microsoft Technology Licensing, Llc | Data detection and protection policies for e-mail |
WO2014011704A1 (en) * | 2012-07-10 | 2014-01-16 | Microsoft Corporation | Data detection and protection policies for e-mail |
US10372916B2 (en) | 2012-07-10 | 2019-08-06 | Microsoft Technology Licensing, Llc | Data detection and protection policies for electronic file systems |
US10785266B2 (en) | 2012-10-22 | 2020-09-22 | Centripetal Networks, Inc. | Methods and systems for protecting a secured network |
US11012474B2 (en) | 2012-10-22 | 2021-05-18 | Centripetal Networks, Inc. | Methods and systems for protecting a secured network |
US11539665B2 (en) | 2013-01-11 | 2022-12-27 | Centripetal Networks, Inc. | Rule swapping in a packet network |
US11012415B2 (en) | 2013-03-12 | 2021-05-18 | Centripetal Networks, Inc. | Filtering network data transfers |
US11418487B2 (en) | 2013-03-12 | 2022-08-16 | Centripetal Networks, Inc. | Filtering network data transfers |
US11496497B2 (en) | 2013-03-15 | 2022-11-08 | Centripetal Networks, Inc. | Protecting networks from cyber attacks and overloading |
US11477237B2 (en) | 2014-04-16 | 2022-10-18 | Centripetal Networks, Inc. | Methods and systems for protecting a secured network |
US10944792B2 (en) | 2014-04-16 | 2021-03-09 | Centripetal Networks, Inc. | Methods and systems for protecting a secured network |
US10951660B2 (en) | 2014-04-16 | 2021-03-16 | Centripetal Networks, Inc. | Methods and systems for protecting a secured network |
US10749906B2 (en) * | 2014-04-16 | 2020-08-18 | Centripetal Networks, Inc. | Methods and systems for protecting a secured network |
US10931797B2 (en) | 2015-02-10 | 2021-02-23 | Centripetal Networks, Inc. | Correlating packets in communications networks |
US11683401B2 (en) | 2015-02-10 | 2023-06-20 | Centripetal Networks, Llc | Correlating packets in communications networks |
US11700273B2 (en) | 2015-04-17 | 2023-07-11 | Centripetal Networks, Llc | Rule-based network-threat detection |
US10757126B2 (en) | 2015-04-17 | 2020-08-25 | Centripetal Networks, Inc. | Rule-based network-threat detection |
US11496500B2 (en) | 2015-04-17 | 2022-11-08 | Centripetal Networks, Inc. | Rule-based network-threat detection |
US11792220B2 (en) | 2015-04-17 | 2023-10-17 | Centripetal Networks, Llc | Rule-based network-threat detection |
US11516241B2 (en) | 2015-04-17 | 2022-11-29 | Centripetal Networks, Inc. | Rule-based network-threat detection |
US11012459B2 (en) | 2015-04-17 | 2021-05-18 | Centripetal Networks, Inc. | Rule-based network-threat detection |
US11811808B2 (en) | 2015-12-23 | 2023-11-07 | Centripetal Networks, Llc | Rule-based network-threat detection for encrypted communications |
US11563758B2 (en) | 2015-12-23 | 2023-01-24 | Centripetal Networks, Inc. | Rule-based network-threat detection for encrypted communications |
US11811810B2 (en) | 2015-12-23 | 2023-11-07 | Centripetal Networks, Llc | Rule-based network threat detection for encrypted communications |
US11477224B2 (en) | 2015-12-23 | 2022-10-18 | Centripetal Networks, Inc. | Rule-based network-threat detection for encrypted communications |
US11811809B2 (en) | 2015-12-23 | 2023-11-07 | Centripetal Networks, Llc | Rule-based network-threat detection for encrypted communications |
US11824879B2 (en) | 2015-12-23 | 2023-11-21 | Centripetal Networks, Llc | Rule-based network-threat detection for encrypted communications |
US9516473B1 (en) * | 2016-04-04 | 2016-12-06 | Ricoh Company, Ltd. | Device management based on tracking path taken by user |
US11574047B2 (en) | 2017-07-10 | 2023-02-07 | Centripetal Networks, Inc. | Cyberanalysis workflow acceleration |
US11797671B2 (en) | 2017-07-10 | 2023-10-24 | Centripetal Networks, Llc | Cyberanalysis workflow acceleration |
US11233777B2 (en) | 2017-07-24 | 2022-01-25 | Centripetal Networks, Inc. | Efficient SSL/TLS proxy |
US11956338B2 (en) | 2023-05-19 | 2024-04-09 | Centripetal Networks, Llc | Correlating packets in communications networks |
Also Published As
Publication number | Publication date |
---|---|
AU4346600A (en) | 2000-11-21 |
WO2000069120B1 (en) | 2001-05-17 |
US6678827B1 (en) | 2004-01-13 |
EP1175752A1 (en) | 2002-01-30 |
JP2002544607A (en) | 2002-12-24 |
WO2000069120A1 (en) | 2000-11-16 |
WO2000069120A9 (en) | 2002-04-04 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US6678827B1 (en) | Managing multiple network security devices from a manager device | |
US7512968B2 (en) | System and method for secure management of remote systems | |
US10601874B2 (en) | System and apparatus for providing network security | |
US9832227B2 (en) | System and method for network level protection against malicious software | |
US11374905B2 (en) | Methods and systems for efficient cyber protections of mobile devices | |
US9467470B2 (en) | System and method for local protection against malicious software | |
CN113612784B (en) | Dynamic service processing using honeypots | |
EP2555486A2 (en) | Multi-method gateway-based network security systems and methods | |
EP1668511A2 (en) | System and method for dynamic distribution of intrusion signatures | |
Cisco | Configuring the Device-Specific Settings of Network Objects | |
Cisco | Configuring the Device-Specific Settings of Network Objects | |
Cisco | Configuring the Device-Specific Settings of Network Objects | |
US20230051016A1 (en) | Systems and methods for network monitoring, reporting, and risk mitigation | |
Antoine et al. | Router Security Configuration Guide | |
Crichigno et al. | Security Aspects | |
JP2004297749A (en) | Vpn device | |
Paez | Security Technology & Terminology Guide | |
Solutions | Hewlett-Packard A5547A Central Web Console Administrator Guide | |
Orvis et al. | Connecting to the Internet Securely; Protecting Home Networks CIAC-2324 | |
TerlegÄrd | Design of a Secure Network Management System | |
Esposito | OIF Control Plane Logging and Auditing with Syslog |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |
|
AS | Assignment |
Owner name: SILICON VALLEY BANK, CALIFORNIA Free format text: SECURITY AGREEMENT;ASSIGNORS:WATCHGUARD TECHNOLOGIES, INC.;GLADIATOR CORPORATION;REEL/FRAME:023098/0771 Effective date: 20090730 Owner name: SILICON VALLEY BANK,CALIFORNIA Free format text: SECURITY AGREEMENT;ASSIGNORS:WATCHGUARD TECHNOLOGIES, INC.;GLADIATOR CORPORATION;REEL/FRAME:023098/0771 Effective date: 20090730 |
|
AS | Assignment |
Owner name: WATCHGUARD TECHNOLOGIES, INC., WASHINGTON Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:SILICON VALLEY BANK;REEL/FRAME:028477/0268 Effective date: 20120628 Owner name: GLADIATOR CORPORATION, WASHINGTON Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:SILICON VALLEY BANK;REEL/FRAME:028477/0268 Effective date: 20120628 |