System and method for managing access to active devices operably connected to a data network

A system and method for managing access of one or more active devices through a data network is disclosed. The system comprises a service station operative to communicate with a requesting active device and a router, the active device and router operative to communicate with a data network. Connection management software executes at least partially in the service station to direct the router to control access to a responding active device by the requesting active device based on a detectable state of a predetermined characteristic of the requesting active device, the state being disclosed to the service station upon a request by the service station. It is submitted with the understanding that it will not be used to interpret or limit the scope of meaning of the claims.

FIELD OF THE INVENTION

The present invention relates to management of access to a device connected to a data network from another device connected to the data network.

BACKGROUND OF THE INVENTION

In an interconnected computing environment, access to a resource such as a server or other computer or active device may give rise to vulnerabilities such as exposure to one or more viruses. Additionally, a version of software or other data, such as a database or data file, on an active device may be incompatible with versions on other active devices, leading to system difficulties or failure.

Further, it may be desirable to restrict access from an active device to another active device or other resource, e.g. restrict access to a known group of active devices or group of active devices which satisfy a minimum level of desired characteristics.

Access between active devices interconnected on a data network may be controlled, however, to disallow access between those active devices which do not meet certain standards as imposed by a “watchdog” function existing on the data network.

SUMMARY

A system and method for managing access between active devices interconnectable through a data network. In an exemplary embodiment, the system comprises a service station operative to communicate active devices and a router. Connection management software executes at least partially in the service station and at least partially at a requesting active device.

The connection management software is operable to direct the router to control access through the router by the requesting active device based on one or more detectable states of one or more predetermined characteristics of the requesting active device according to dynamically definable rules.

A service station determines if a requesting active device possesses the required state of a predetermined characteristic of the requesting active device which is acceptable according to the dynamically definable rules. Access through the router may then be denied or allowed depending on the determined state.

The scope of protection is not limited by the summary of an exemplary embodiment set out above, but is only limited by the claims

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

In general, throughout this description, if an item is described as implemented in software, it can equally well be implemented as hardware. It is also understood that “data,” as used herein, is either singular or plural as the context requires. As used herein, “active device” comprises personal computers, other computers having a central processor unit, intelligent devices having a processor such as intelligent printers, or the like. As further used herein, “HTML” comprises generalized markup language (GML), standard generalized markup language (SGML), hypertext markup language (HTML), extensible hypertext markup language (“XML”), extensible graph markup and modeling language (“XGMML”), or the like.

FIG. 1illustrates an exemplary computer system, shown generally as “10” inFIG. 1, whose active devices are interconnected by a data network. System10comprises a data network, generally indicated by the numeral “12;” at least one active device that is a requesting client, generally indicated by the numeral “30” and more specifically illustrated as devices30a,30b,30c, and30d; at least one active device that is a responding active device, e.g. server40; and router50.

Data network12comprises the Internet as well as other data networks, such as a data packet network, a TCP/IP network, a peer-to-peer network, or the like. Data network12may be wired, wireless, or a combination thereof. Additionally, data network12may comprise additional networks, e.g. private network13, local area networks (not shown in the figures), or the like, or combinations thereof.

A first portion of active devices30,40operatively connected to data network12are disposed logically upstream from a second portion of active devices30,40. For example, inFIG. 1, clients30a,30b,30c, and30dare logically upstream from server40and private network13.

As will be familiar to those of ordinary skill in the art, router50is connected to data network12and is logically disposed intermediate the first portion of active devices30,40and the second portion of active devices30,40, including private network13. Router50is capable of selectively allowing access by a requesting active device, e.g. client30a, to an active device of the second portion of active devices, e.g. server40. In a preferred embodiment, router50uses a network address translation protocol (“NAT”) to forward data traffic to service station20.

Router50may further comprise router control server54which may further comprise router control message queue52and IP address database53. Routers50such as manufactured by Cisco Systems Inc. of San Jose, Calif. are typical of routers50which support traffic filtering security features that dynamically filter IP protocol traffic.

Service station20is operative to communicate with router50, either via data network12, direct connection via wired or wireless data communications, integration into router50or router control server54, or the like, or a combination thereof. In certain contemplated embodiments, service station20may be in communication with one or more active devices30,40such as through data network12. Service station may further comprise service station message queue22.

Referring now toFIG. 2, connection management software100executes at least partially in service station20. Some components of connection management software100may reside in router control server54(FIG. 1). Connection management software100comprises functions, e.g.100a,100b, that allow service station20to direct router50(FIG. 1) to control access to a responding active device such as server40(FIG. 1) by a requesting active device such as client30. Access may be allowed or denied based on a detectable state of a predetermined characteristic of the requesting active device, e.g. client30. In a preferred embodiment, the desired state information is disclosed to service station20upon a request issued by service station20to client30.

In a preferred embodiment, connection management software100further comprises one or more pages102,104containing executable code, directives to executable code, or the like, or combinations thereof. In an exemplary embodiment, pages102,104are written in HTML or the like and comprise first page102and second page104controllable by service station20to which a confirmation code may be passed by a requesting active device, e.g. client30.

Rule set60comprises a logically grouped set of rules62for client30. In a preferred embodiment, each rule62within rule set60must be satisfied at client30. As discussed below, several levels of satisfaction may exist.

Rule set60may be centrally stored and configured, e.g. in rule file61contained within persistent data store23. In an exemplary embodiment, rule set60for client30will be in the form of a database, but tools may be provided to simplify configuration, e.g. a text editor may be used such as for rule sets60in text files or a specialized tool used which comprises a specialized user interface.

In an exemplary embodiment, client control software110executing at client30may be responsible for performing one or more functions at client30such as when requested by receipt of directives from service station20, e.g. directives embedded within first page102. These functions may include downloading rule set60from server station20and interpreting and being guided by rules62within rule set60to perform further functions at client30. In an exemplary embodiment, ActiveX controls, e.g. a http request to download a rule62, may be used to obtain rule set60and may be further used to process rules62such as those downloaded from rule set60. In this manner, tests and results as defined by rules62may be dynamically definable with respect to client control software110at client30.

Additionally, client control software110may be used to generate a log reflecting or otherwise reporting a predetermined set of actions undertaken and/or results generated at client30by client control software110, upload a predetermined portion of the log such as to service station20, and redirect client30to an appropriate display, e.g. page102or page104, upon grant or denial of access to private network13(FIG. 1) by client30, or the like, or a combination thereof.

In an exemplary embodiment, client control software110may comprise one or more ActiveX controls, HTML code contained in first page102, or a combination thereof. An exemplary HTML code segment illustrating a set of parameters112which may be passed to client control software110to further define locations at which rule set60may be located is shown below in Table 1:

As further indicated in Table 1, rule set60may further comprise a codebase attribute to specify a location into which client control software110may be downloaded if it is not yet installed on the requesting active device, e.g. client30. The location may be an absolute universal resource locator (“URL”), e.g. “http://servername/path/to/LhRemoteAccess.ocx,” or a relative URL such as may be obtained from an hypertext markup language (HTML) page, e.g. a relative URL from an HTML page defining the <OBJECT> tag, as shown in Table 1.

Rule62may further comprise one or more tags to define one or more parameters112that may be needed by client control software110. In an exemplary embodiment, parameter112may comprise operating system identifier112a; URL uplog identifier112b; URL fail identifier112c; URL112dthat may be used to specify a page such as an HTML page responsible for displaying information upon denial of network access, e.g. page104inFIG. 4c; boolean112e; or the like, or a combination thereof.

Operating system identifier112amay be used to specify a URL at which rules file61may be accessed. Rule set60and/or rules file61may further correspond to the platform on which client30executes, e.g. “Win32” used to specify rule set60and/or rule file61for an operating system compliant with a 32-bit Microsoft WINDOWS® software environment, “Win95” used to specify an operating system compliant with a Microsoft WINDOWS 95® software environment, “Win98” used to specify a rules file61for an operating system compliant with a Microsoft WINDOWS 98® software environment, “WinME” used to specify an operating system compliant with a Microsoft WINDOWS MILLENNIUM EDITION® software environment, “WinNT” used to specify an operating system compliant with a Microsoft WINDOWS NT® software environment, “Win2K” used to specify an operating system compliant with a Microsoft WINDOWS 2000® software environment, “WinXP” used to specify an operating system compliant with a Microsoft WINDOWS XP® software environment, and the like. In a preferred embodiment, operating system identifier112afurther comprises an absolute URL definition.

URL uplog identifier112bmay be used to specify a URL usable by processes responsible for uploading the logs. The processes may comprise a script, an executable file, a portion of an HTML file, or the like, or combinations thereof.

In a preferred embodiment, client control software110supports versioning. For example, the codebase attribute illustrated in Table 1 may be used to define a requested, specific version of client control software110, e.g. of an ActiveX control. By way of example and not limitation, a codebase of “./LhRemoteAccess.ocx#version=1,0,0,16” may be used to request that client control software110identified as “LhRemoteAccess.ocx” at a relative URL has a version of “1.0.0.16.” If a browser or other software executing in client30has already installed a different version of client control software110, client control software110may automatically download and use the requested version of control software110.

Rule file61may exist at or accessible to service station20. Rule file61comprises one or more predefined rules62. Rules62are dynamically definable and may further comprise a name-value pair that defines rule parameter66and an associated value67.

In an exemplary embodiment, rule file61is a text file formatted to be compliant with a Windows INI file format and comprises one or more identifiably named sections64. In alternative exemplary embodiments, rule file61may be an HTML file, a database, a table in a database, or the like. Rule file61may further comprise an “INI” section in rule file61. Each INI section may further comprise a section name where the section name further comprises a name of a rule62. In a preferred embodiment, each section name is unique within rule file61.

A plurality of rules62may exist and rule file61may contain more than one rule62of the same type (for instance, two registry rules may be useful to check two different registry values) or none of a given type.

In an exemplary embodiment, rule62comprises one or more name-value pairs which may be of the form<name>=<value>
where<name>is the name of rule parameter66and<value>is the value assigned to rule parameter66.

Referring now toFIG. 2a, in an exemplary embodiment, each rule62may further comprise rule characteristics67, including rule type67a, log level67b, severity level67c, URL67d, or a combination thereof. In an exemplary embodiment, each rule62may further comprise a list of name-value pairs defining parameters67specific to that rule62in addition to a common set rule parameters66.

Rule type67acomprises a descriptor for a type of rule62. As shown in the exemplary tables below, rule type67amay comprise a literal string and may be case sensitive, in which event a rule engine (not shown in the figures) will treat rule62as unknown and fail it should the case not match.

A log of actions taken by client control software110(FIG. 2) may be generated at client30and captured by a desired computer such as service station20(FIG. 2). Log level67bmay be used to define a level of logging in log file101. In an exemplary embodiment, log level67bmay indicate no logging, a minimum set of logging information such as “pass” or “fail,” or a maximum set of logging information such as information that includes values read from rule62. Log files101may further be stored in a specified folder at the computer, e.g. service station20. In an exemplary embodiment, log file101may be created using a naming convention to further facilitate access management, e.g. “<remote-ip>—<remote-hostname>—<timestamp>.log” where “<remote-ip>” is the IP address of the remote machine accessing the network, e.g. client30; “<remote-hostname>” is the hostname of the remote machine, e.g. client30; “<timestamp>” is the timestamp which may be of the form YYYYMMDDhhmmss where “YYYY” is a four-digit year, “MM” is the two-digit month, “DD” is the two-digit date, “hh” is the two-digit 24-hour based, “mm” is the two-digit minute, and “ss” is the two-digit second of when log file ______ was created.

Severity level67cmay comprise a descriptor indicating a consequence of a failure of client30(FIG. 2) to comply with the related rule62. In an exemplary embodiment, severity level67cmay include “required,” to indicate that a failure to comply with rule62is to be noted, e.g. form104inFIG. 4c, and prevents client30from accessing private network13(FIG. 1) or active devices40(FIG. 1) such as by a denial of network access by service station20(FIG. 1) and/or router50(FIG. 1); “desired,” to indicate that a failure to comply with rule62is to be noted, e.g. on page104(FIG. 4d), as a failure of one or more criteria of rule62but does not prevent further access by client30to private network13or active devices40; “minimal,” to indicate that failure to comply with rule62is logged such as to log file101but not noted, e.g. on page104(FIG. 4e), as a failure and does not prevent further access by client30to private network13or active devices40; and/or “off” which may be used to disable rule62, in which case a rule engine (not shown in the figures) will not attempt to evaluate rule62. “Off” may be used to ease management of rules62by allowing selective enablement of a rule62without having to delete that rule62.

URL67dcomprises a URL descriptor to a page such as page104(FIG. 2) containing instructions on how to set up client30(FIG. 2) to be in compliance with rule62.

Referring back toFIG. 2, in an exemplary embodiment, rules62may comprise a command rule62, a file exist rule62, a file property rule62, an INI rule62, a process rule62, a registry rule62, or a combination thereof.

Command rule62may be used to direct client control software110to execute a specified command at client30. An exemplary command rule62is illustrated in Table 2:

TABLE 2[Run NotePad]RuleType=CommandRuleLogLevel=maxSeverity=RequiredURL=/Instructions/RunCommand.htmlCommand=%windir%\notepad.exe
In this example, client control software110is directed to execute an application named “NotePad.”

File exist rule62may be used to direct client control software110to check for the existence of a described file at client30. An exemplary file exist rule62is illustrated in Table 3:

File property rule62may be used to direct client control software110to check for one or more specific properties of a given file which may be specified by a “property” parameter for file property rule62. In an exemplary embodiment, file properties comprise version, date/time, and attribute. An exemplary file property rule62is illustrated in Table 4:

INI rule62may be used to direct client control software110to check for an INI value in a desired INI file. Table 5 illustrates an exemplary INI rule:

Alternative formats may be used for rule file61. For example, Table 5aillustrates an exemplary HTML implementation of the rule62illustrated in Table 5:

Process rule62may be used to direct client control software110to check whether a desired process is running at client30. Table 6 illustrates an exemplary process rule62which directs client control software110to determine whether an application named “NotePad” is currently executing at client30:

Registry rule62may be used to provide client control software110with information required to check for a specific key value in a registry of the operating system executing in client30. Table 7 illustrates an exemplary descriptor of registry rule62:

By way of further example, Table 8 illustrates an exemplary HTML version of rule file61comprising rule set60named “Win95”:

In the operation of an exemplary method, referring back toFIG. 1, access to desired active devices such as server40, e.g. through private network13, may be managed by allowing service station20to determine if a requesting active device, e.g. client30, possesses a state of one or more predetermined characteristics which is acceptable to one or more predefined criteria for that state. If the requesting active device, e.g. client30, does possess that state, client30will be allowed access to a responding active device, e.g. server40, by the requesting active device, e.g. client30, only if the state of the predetermined characteristic is acceptable to the predefined criterion for that state.

FIG. 3athroughFIG. 3dillustrate a process flow for an exemplary method. As illustrated inFIG. 3a, a request for access is received at router50, operative to communicate with data network12, from a first active device, e.g. client30, which is also operative to communicate with data network12. The request may comprise a request to access a second active device operative to communicate with data network12, e.g. server40.

Router50, as described below, blocks access by the first active device, e.g. client30, to the second active device, e.g. server40, and forwards the request for access to service station20. Service station20causes a request for information, e.g. first page102(FIG. 2) comprising rules62, to be delivered to the requesting active device. Access by the requesting active device to the second active device will be allowed only if the requesting active device returns an acceptable response to the request for information, e.g. if all rules62are satisfied.

By way of example, in an exemplary embodiment software executing in client30, such as an Internet browser, browses to an IP address of router50(step201). Router50may uses a protocol, e.g. network address translation (NAT), to forward data traffic from client30to service station20(step202). Service station20sends a message, e.g. containing an IP address of and indicating a new client, to message queue52at or controlled by router control server54(step203). Router control server54updates IP address database53with the IP address of the pending connection, i.e. the IP address of client30(step204). Router control server54further sends a message, e.g. comprising a directive to accept a client, to message queue22at service station20(step205). In an exemplary embodiment, router control server54determines if a connection exists between router50and client30, and, if there is an existing connection, router control server54clears it from router50(step206).

In response to its request to access a downstream active device intercepted by router50, client30is provided access to and downloads welcome page102(FIG. 4a) from service station20(step207). Welcome page102may comprise client control software110and/or directives for client control software110. Message area102a(FIG. 4b) in welcome page102may be used to provide feedback to requesting active device30.

Using directives provided at least partially in welcome page102, e.g. rules62(FIG. 2), client control software110examines client30and determines the state of one or more components of client30pursuant to rules62. For example, client control software110may be directed to determine if a desired component exists at the requesting active device and one or more predetermined characteristics of the component if it exists.

If the requesting active device, e.g. client30, does not satisfy all required rules62, client30may be presented with a resource to change the state to satisfy each of the predefined criteria, e.g. within each rule62, if the state is not acceptable to the predefined criterion for that state. For example, as illustrated inFIG. 4c, client30may be presented with an opportunity to update non-compliant component if the predetermined characteristic is not at an acceptable level such as by using page104. As an example, inFIG. 4c, hyperlinks104aare provided to allow a user at requesting active device30to access further resources to correct deficiencies uncovered at requesting active device30.

Referring now toFIG. 3b, after client control software110has examined client30, if all criteria of rules62are met by client30client control software110may redirect the software, e.g. the browser, to a new page, e.g. page104(FIG. 2) on service station20, passing it a confirmation code (step208).

Upon receipt of the confirmation code, service station20sends a message, e.g. a connection request message, to message queue52of router control server54(step209). Router control server54updates IP address database53with data reflecting a successful scan of client30(step210) and creates a new user account in the domain (step211). Router control server54further sends a message, e.g. a connection approval message, to message queue22of service station20(step212). Service station may present a user name and password to the software executing in client30, e.g. browser software (step213). Additionally upon a successful scan, router control server54may begin pinging client30, waiting for a response (step214).

Referring now toFIG. 3c, client20may then supply router50with the supplied user name and password, such as by using a known protocol such as Telnet (step215). Router50may verify the user name and password, e.g. with software executing at router control server54. Once authenticated, router creates a dynamic access list for the client (step216). Router control server54may receive a ping reply from the client (step217) and update a status entry for client30in IP address database53(step218). After updating the status, router control server54may then delete the user name from the domain (not shown in the figures) (step219) and, after client30disconnects, no longer receive ping replies.

As further illustrated inFIG. 3d, router control server54may use a protocol to communicate with router50, e.g. Telnet, to request that router50remove an access list for client30(step220). Router control server54may then remove the IP address of client30from IP address database53(step221).

It will be understood that various changes in the details, materials, and arrangements of the parts which have been described and illustrated above in order to explain the nature of this invention may be made by those skilled in the art without departing from the principle and scope of the invention as recited in the following claims.