WO2001071496A1

WO2001071496A1 - System for data transfer in a secured network environment

Info

Publication number: WO2001071496A1
Application number: PCT/US2000/031953
Authority: WO
Inventors: Shyh-Pei Yen; Luke Ciamboli
Original assignee: Mynetlab Communications International, Inc.
Priority date: 2000-03-16
Filing date: 2000-11-22
Publication date: 2001-09-27
Also published as: JP2001325163A; AU2001230730A1

Abstract

A network communications system (20) for communicating data securely via an unsecured path (38, 84) between an agent (22, 82) and a console (24, 72). The agent (82) may be located inside a secured network segment (76) and the console (72) may be located inside a network segment (74) elsewhere in a LAN (70). Alternately, the agent (22) may be located inside a secured LAN (28) and the console (24) located inside a LAN (34), with the path (38) being via a wide area network such as the Internet (26). The data may be communicated variously using: e-mail; FTP; tunneling protocols, like HTTP or VPN; or a proprietary protocol. Conventionally assigned ports may be statically or dynamically used, or the network communications system (20) may programmatically find an open port.

Description

SYSTEM FOR DATA TRANSFER LN A SECURED NETWORK ENVIRONMENT

TECHNICAL FIELD The present invention relates generally to the operation of electrical computers and digital processing systems, and more particularly to process and apparatus for communicating securely within such systems which employ unsecured network segments.

BACKGROUND ART Communicating with computer systems is a vexing problem, particularly when such computer systems are connected to networks and even more particularly when some segments of such networks are inherently not secure able. The present growth in the connection of personal and organizational computer systems to the Internet well illustrates this. The Internet is inherently not secure able, or at least not so by the individuals and organizations generally using it today. Nonetheless, transferring data via large networks like the Internet is increasingly desirable and in some cases even regarded as necessary.

Accordingly, developing and improving upon architectures to transfer data in such networks is much needed today.

Obtaining the benefits of increased security almost always involves also paying a cost, usually in the form of giving up some liberties. In the computer and network contexts, this cost-benefit approach to security often means tolerating elements of distrust and overly burdensome protection in the sake of security which can sometimes interfere with otherwise valid purposes.

One example where this is seen today is in remote computer system and network management. Although there are many other possible examples as well, this example serves particularly well because such management usually requires access to even the most vulnerable levels of such systems.

FIG. 1 (background art) is a schematic diagram depicting a traditional system 1 as currently used for such remote computer system and network management. An agent 2 is placed inside a remote local area network (LAN 3). It is desirable that this agent 2 and a console 4 elsewhere in the traditional system 1 be able to communicate via a wide area network (WAN 5), which typically is the Internet. The LAN 3 connects to the WAN 5 via a gateway 6. As shown, the console 4 may be a computer system located in a different LAN 7 and reachable via its own gateway 8. A path 9 for communications between the agent 2 and the console 4 is further shown. The agent 2 is usually placed inside the LAN 3, and even when this is not necessary it is usually desirable. The agent 2 may run on a particular piece of hardware or a sub-system which it is to report on, or it may monitor activity throughout the LAN 3. Typical scenarios where this scheme is employed are in performance and security monitoring. For instance, the agent 2 might be used to diagnose why a particular computer system or device in the LAN 3 is failing. Alternately the agent 2 might be used to monitor accesses to a critical database residing in the LAN 3.

The variety of uses for such agents 2 is huge, and is probably too large to list here. In particular, the reader should not assume that such is limited to the remote computer system and network management example used above. Instead, the salient point to be appreciated here is that such agents 2 typically need to be started, stopped, retasked, and to be able to have their findings communicated. When using remote entities, like the console 4 here, these operations necessarily entail communication outside of the LAN 3 and through an unsecured medium like the WAN 5. The problem that this traditional system 1 poses is how to permit the agent 2 and the console 4 to communicate and yet maintain security in the LAN 3. Security concerns can, simplistically, be categorized as maintaining privacy and preventing meddling (malicious or simply unauthorized). For example, privileged information may be present in the LAN 3, information which it is desirable to keep others from obtaining. The integrity of information in the LAN 3 as well as its very operations also must not be disruptable by outside meddling. If the security of the LAN 3 is not adequately maintained, even the agent 2 itself can be used as an instrument to nefarious ends. One or multiple instances of the agent 2 might be inappropriately started to degrade the performance of the LAN 3. Or the agent 2 might be retasked to snoop out privileged information and to communicate it outside the LAN 3. Particularly powerful or poorly designed instances of the agent 2 might even alter important information present in the LAN 3, either in a storage location or as it is being transferred.

Obviously, severing all connection between the LAN 3 and the WAN 5 is one solution. However, in an increasingly "connected" communications environment, as we are seeing WANs such as the Internet rapidly develop into, eschewing any outside connection is a decreasingly acceptable option. For instance, if the agent 2 and the console 4 are being employed for performance or security monitoring, the path 9 which they communicate over may necessarily have to pass through an insecure intermediate such as the WAN 5. Increasingly, as organizations expand into many separate locations and as the globalization of communications mediums progresses, entities such as the agent 2 and the console 4 may even be owned by the same organization and controlled by the very same people, yet be in quite separate physical locations. Or, as outsourcing of organization's non-core services becomes increasingly popular, the agent 2 may be at a client site and the console 4 may be at a remote service provider's site. Turning now to FIG. 2 (background art), a selective form of connection severing is depicted which actually is the most common security technique in use today. The scheme of FIG. 2 particularly differs from FIG. 1 in that a firewall 10 is added, making the LAN 3 into a secured LAN 11. Firewalls are the most widely adopted WAN and Internet security mechanism, using hardware and software combinations that sit at gateways between an intranet (e.g., the secured LAN 11) and the a WAN or the Internet (e.g., the WAN 5). They allow people and systems inside an intranet to use it and usually to also use the WAN or Internet, yet they stop people and systems elsewhere from getting access to some or all which is inside the intranet. [Typically the console might also have a firewall, but that is not germane to the present discussion. Also, although herein depicted otherwise for emphasis, firewalls are often integrated into the same hardware used for gateways.]

In their simplest form, firewalls operate by filtering data packet passage based on source and destination addresses, and in more complex forms they may also filter based on other user specified criteria. For example, the firewall 10 in FIG. 2 might be configured to pass data packets into the secured LAN 11 which are identified as having originated in the LAN 7. This works if the packets originate in the LAN 7, but what if the data packets are miss-identified as having originated in the LAN 7? Spoofing, the intentional misrepresentation of data packet basic source addressing, is just one way which the security of a firewall may be breached.

Firewalls often are also configured to filter data packets based on their destination address. Thus, if there is no valid purpose for an address inside the secured LAN 11 to be accessed from the outside, any data packets directed to such an address can simply be blocked. This is a problem, however, if an instance of the agent 2 needs to be run on a device at the particular blocked intranet address, say, due to a newly created valid purpose for outside access by the console 4. After all, one of the major utilities of computer systems is their dynamic adaptation to new tasks.

The next level of currently used sophistication is to configure the firewall 10 to only pass outside data packets directed to certain ports at addresses inside the secured LAN 11. A port is a numbered access point for data to enter and exit, not a physical connection. Port numbers below 1024 are generally reserved or provide access to non-public applications and services. But ports between 1024 and 65535 are not considered private and are generally available. Therefore, the firewall 10 might be configured to pass inbound data packets to port number 23 on a specific system, say, to permit telnet type remote access to that system inside the secured LAN 11. However, even this form of static filtering is not sophisticated enough to provide adequate security today. Port sniffing utilities are widely available which can iteratively pole all of the ports at a specific target address to determine which are currently open. Once an open port is found, it can be sent data packets which may effect the operation of what such a port is a portal to. Or the port may be flooded with data packets which cannot pass the internal protections at that portal. For instance, telnet access will almost always be configured to require a telnet password. Such a port may be flooded with repeated login requests trying different passwords, or simply flooded with data packets just to burden the system or tie it up (often termed a "denial of service attack") and thus deny access to valid data packets or otherwise degrade system performance. A still more sophisticated approach is dynamic filtering, wherein the firewall 10 adapts to data packet traffic needs by learning which ports are needed and opening them while closing all others. The firewall 10 monitors the requests to open ports and when a legitimate communications session is needed it opens only those ports needed for the duration of the session. Still more sophistication can be applied here by closing a port if the traffic volume through it becomes excessive, say, if a port has been sniffed out and an attempt is being made to swamp it.

The preceding discussion is not exhaustive of all firewall security capabilities. In deed, such is not possible, since firewall capabilities are constantly being refined and new ones created. Rather, this discussion serves to frame a key problem. How can an outside system like the console 4 even initiate a communications dialog with the agent 2 when no port is open to reach it inside the secured LAN 11? FIG. 2 further includes a broken path 12, depicting the console 4 making a request of the agent 2 but being blocked from access by the firewall 10.

Today there are many users of firewalls, including large corporate users and the rapidly increasing number of home or small office users connecting to WANs or the Internet using digital subscriber line (DSL) and cable modem access. In large part, these users "configure" their firewalls to have most, if not all, of the ports closed to outsiders to prevent intrusion. Simple human inertia and the often daunting complexity of properly configuring firewalls then exacerbates the problem, by providing powerful disincentives to implementing or changing anything which may require firewall configuration or reconfiguration.

In the case of smaller, less sophisticated users or organizations set-up is often not even consciously thought through, since many of the increasingly common simple firewalls used for DSL and cable modem access come with high security pre-set as the default. Also, even though decision making may be more centralized and rapid, the cost of bringing in an outside network professional or teaching oneself to implement firewall configuration changes here may be a serious disincentive which undercuts the dynamic utility of computer systems, or which even motivates deliberately circumventing the network security.

In the case of larger organizations, which are often more sophisticated, set-up and change may be more commonly by choice, but typically is as also burdened by inflexible policy. In such organizations, obtaining firewall configuration changes may require review and authorization, since a change for one purpose may have far reaching ramifications. Even once it is determined that a configuration change is appropriate, such may take considerable time while an already otherwise busy network professional is tasked to implement the change.

Accordingly, what is need today is an improved architecture for communicating data between entities in secured and unsecured segments of a network.

__ _

DISCLOSURE OF INVENTION Accordingly, it is an object of the present invention to provide an improved architecture for communicating data between entities in secured and unsecured segments of a network. Another object of the invention is to provide such an architecture which does not compromise security in secured segments of a network.

Another object of the invention is to provide such an architecture which does not unduly require the involvement of precious human resources, such as sophisticated network professionals, to initially implement. And another object of the invention is to provide such an architecture which does not unduly require the involvement of network professionals to employ on an ongoing basis, or to dynamically add, reconfigure or retask, or remove agents employing the architecture.

Briefly, one preferred embodiment of the present invention is a method for communicating within a network. The method includes the steps of placing an agent within a first segment of the network which is protected by a security system. Message data is then collected in the first network segment by the agent. Next communications is initiated by the agent. Finally, the agent communicates the message data outside the first segment of the network to a console unit in a second segment of the network, thus avoiding the situation of a request from being the console unit or anywhere outside of the first segment of the network impeded by the security system.

Briefly, another preferred embodiment of the present invention is a system for communicating message data securely. A first segment of a network is provided which is secured by a security system and includes an agent. A second segment of the network is provided which includes a console unit. The agent includes a logic that initiates communications between itself and the console unit. The agent further includes a logic that communicates the message data to the console unit such that it proceeds outward bound from the first segment to the second segment of the network, thereby not having it impeded by the security system.

An advantage of the present invention is that it effectively provides an improved architecture for communicating data between entities in secured and unsecured segments of a network.

Another advantage of the invention is that the architecture which it provides is economical. It may be embodied essentially in only computer software, and thus require only a small capitol investment. It may also be embodied in a manner requiring only minimal, if any, involvement of expensive network professionals for either initial implementation or maintenance once in use.

Another advantage of the invention is that it does not require reconfiguring network security features, such as firewalls. Initial implementation of the invention thus requires only slight review as to security ramifications, and the need for such security review is essentially eliminated as the inventive architecture is used. In particular, once in place, even major changes of the architecture may be safely and confidently made without the often odious review and authorization procedures commonly required when security issues are present. And another advantage of the invention is that it provides no incentives for undermining security in secured network segments. Users of the inventive architecture have no need to circumvent security to accomplish their work. Security review and authorization are essentially eliminated as a cause for delay and as an organizational political issue. Since the need for network professionals is minimized, cost disincentives for maintaining security are minimized, and delay is further reduced. These and other objects and advantages of the present invention will become clear to those skilled in the art in view of the description of the best presently known mode of carrying out the invention and the industrial applicability of the preferred embodiment as described herein and as illustrated in the several figures of the drawings.

BRIEF DESCRIPTION OF THE DRAWINGS The purposes and advantages of the present invention will be apparent from the following detailed description in conjunction with the appended drawings in which:

FIG. 1 (background art) is a schematic diagram depicting the traditional system used for communicating with an agent;

FIG. 2 (background art) is a schematic diagram depicting the problem with the traditional system of FIG. 1;

FIG. 3 is a schematic diagram depicting a system for communicating with an agent according to the present invention; FIG. 4 (background art) is a schematic diagram depicting a local area network (LAN) based variation of the traditional system;

FIG. 5 (background art) is a schematic diagram depicting the problem with the traditional system of FIG. 4;

FIG. 6 is a schematic diagram depicting a system for communicating with an agent according to the present invention;

FIG. 7 is a flow chart depicting a data sender's process flow using e-mail, according to the present invention;

FIG. 8 is a flow chart depicting a data receiver's process flow using e-mail, as provided for in FIG. 7; FIG. 9 is a flow chart depicting a data sender's process flow using hyper text transfer protocol (HTTP) tunneling;

FIG. 10 is a flow chart depicting a data receiver's process flow using HTTP tunneling, as provided for in FIG. 9;

FIG. 11 is a flow chart depicting a data sender's process flow using file transfer protocol (FTP);

FIG. 12 is a flow chart depicting a data receiver's process flow using FTP, as provided for in FIG. 11;

FIG. 13 is a flow chart depicting a data sender's process flow using a proprietary protocol; and FIG. 14 is a flow chart depicting a data receiver's process flow using the proprietary protocol, as provided for in FIG. 13. BEST MODE FOR CARRYING OUT THE INVENTION A preferred embodiment of the present invention is a network communications system. As illustrated in the various drawings herein, and particularly in the view of FIG. 3, a form of this preferred embodiment of the inventive device is depicted by the general reference character 10.

FIG. 3 is a schematic diagram depicting an embodiment network communications system 20 in which an agent 22 and a console 24 may communicate via an unsecured medium such as the internet 26 (or another type of WAN).

The agent 22 is located inside a secured local area network (secured LAN 28) which connects to the Internet 26 via a firewall 30 and a gateway 32. The agent 22 is one or more applications which may be started and stopped, and which particularly needs to communicate data of some type to the console 24. The firewall 30 and the gateway 32 are depicted as distinct in FIG. 3, but in many implementations they can be integrated into one physical piece of hardware. The console 24 is located in a second local area network (LAN 34), which is shown here connecting to the Internet 26 via a gateway 36. In theory, the gateway 36 could even be physically integrated into the console 24, and the LAN 34 simply omitted. However, such a simple implementation will rarely be the typical case.

The agent 22, secured LAN 28, firewall 30, gateway 32, Internet 26, gateway 36, LAN 34, and console 24 thus form a complete communications path, which is stylistically shown in FIG. 3 as a path 38.

The firewall 30 is of particular present interest, since it is what secures the secured LAN 28. In performing its valid security role, the firewall 30 is likely to prove somewhat of an obstacle to communications between the console 24 and the agent 22. As described previously, in the Background Art section, communications originating at a console outside of the immediate secured LAN 28 will be highly suspect. Even if such communications are permitted here, the firewall 30 will need to exercise considerable sophistication to pass only valid communications which truly do originate at the outside console 24. Furthermore, even if all possible sophistication by today's standards is employed by the firewall 30, there is no assurance that even more might not be needed to deal with a new form of threat tomorrow. Thus, communications originating at the console 24 are more than just suspect, they are undesirable. Accordingly, the present network communications system 20 minimizes them, and in some situations it can eliminate the use of them entirely.

The network communications system 20 operates differently than prior art systems in one very key respect, the console 24 does not initiate communications with the agent 22 (or with an entity inside the secured LAN 28). Rather, when communications is desired it is the agent 22 which decides this and initiates it. The agent 22 may run continuously, or it may start in response to an event, such as a triggering request by a device or system elsewhere in the secured LAN 28. Such triggering requests might be in response to the passage of time since the agent 22 last stopped, to the arrival of a particular time, or to the failure or abnormal performance of some item of hardware or system in the secured LAN 28. It should be appreciated that his list of triggers is not exhaustive. The true spirit of the present invention does not lie in what triggers its use, but rather in the manner in which it performs once it is triggered.

Since the secured LAN 28 is connected to the Internet 26, even if incoming communication to the secured LAN 28 is absolutely denied by the firewall 30, it should be possible for some form of outgoing communication to take place from the secured LAN 28. If this were not the case, there would be no point in having the secured LAN 28 connected to the Internet 26 at all. Thus, the firewall 30 may permit external e-mail or web site access, i.e., minimal outside services which are generally safe to permit, or it may keep particular ports open in a static manner. But even if all of these are prohibited, the firewall 30 may be configured to accede to internal requests to open ports dynamically. The firewall 30 can be set to permit momentary opening of a port for occasional outgoing bursts of data from the agent 22, or it can permit the agent 22 to initiate a tunneling link with the console 24, wherein cryptographic or other measures are employed to insure that only the agent 22 and the console 24 are able to communicate with one another via the link that is established.

Before turning to a more detailed discussion of some particular examples of how the inventive network communications system 20 may operate, it should be noted that it may also be employed in some local area network (LAN) contexts. FIG. 4 through FIG. 6 illustrate this.

FIG. 4 (background art) is a schematic diagram depicting a traditional system 51 sometimes used in a local area network (LAN). A console 52, which will be an ultimate data recipient, is present in a first network segment 53. The first network segment 53 is connected to a second network segment 54 via a router 55. An agent 56, which will be an ultimate data provider, is provided in the second network segment 54. Accordingly, a path 57 exists between the console 52 and the agent 56, and in this traditional scheme the console 52 is able to request data and the agent 56 provide it across the path 57.

FIG. 5 (background art) is a schematic diagram depicting the problem with the — — traditional system 51 of FIG. 4. A firewall 58 has been added, making the second network segment 54 into a secured segment 59.

For example, the first network segment 53 might be for a management information services (MIS) department and the secured segment 59 might be for a human resources (HR) department. Since the HR department would typically have sensitive data like salary lists, it would have the firewall 58 to secure it from intrusion from elsewhere on the overall LAN.

The problem with the traditional system 51 in FIG. 5, however, remains the same as that with the traditional system 1 in FIG. 2 (background art). Rather than the usable path 57 of FIG. 4, the addition of the firewall 58 now permits only an incomplete path 60 between the console 52 and the agent 56, and console-to-agent communication cannot occur.

FIG. 6 is a schematic diagram depicting the network communications system 20 in use in a local area network (LAN 70), i.e., a modification of the traditional system 51 of FIG. 5 according to the present invention. A console 72 is present on a network segment 74. The network segment 74 is connected to a secured network segment 76 via a router 78, and a firewall 80 which protects the secured network segment 76. An agent 82 is present in the secured network segment 76, and in the characteristic manner of the invention is able to initiate communication with the console 72 via a path 84 through the LAN 70.

In the embodiment of the network communications system 20 depicted in FIG. 6, as was also the case for the embodiment in FIG. 3, data can be communicated between the agent 82 and the console 72 in a number of manners. Without limitation, these may include conventional versions of e-mail, file transfer protocol (FTP), tunneling protocols, proprietary protocols, combinations of these, and the use of unconventional ports or dynamic open port searching. Discussion now turns to some particular likely examples of these in use in the inventive network communications system 20. FIG. 7 is a flow chart depicting a data sender's process flow 110 using e-mail and the network communications system 20, with reference also made to FIG. 3.

In a step 112, a schedule sub-process runs to specify when the network communications system 20 should have the agent 22 send data to the console 24. In a step 114, the data to be sent is prepared. This may include encrypting or formatting it, or such may be optional and this step simply omitted. In a step 116, the data is "sent" by the agent 22. It should be noted that steps 112, 114, and 116 are presented separately here to emphasize their functional aspects. Those skilled in the art will readily appreciate that they may be integrated, to more or lesser degree, in actual embodiments of the network communications system 20. After step 116, the data to be sent as an e-mail message is typically passed to a conventional e-mail client for sending via a conventional e-mail server, but not necessarily. Implementations of the network communications system 20 can simply use existing such communications sub-process when present (e.g., the widely used Outlook (TM) or Outlook Express (TM) clients, Microsoft Exchange Server (TM), and UNIX's "sendmail" available for UNIX, Linux, and Microsoft and other OSs), or the network communications system 20 can provide and use such conventional versions for its use. Alternately, a proprietary e-mail system may even be used.

In a step 118, an e-mail message is formally sent from the agent 22 by an e-mail client sub-process. The steps 112-118 are typically performed in the same computer system, but this also is not necessary. For instance, an obvious variation would be for step 114 to be handled, all or in part, on various computer systems in the secured LAN 28 which are providing the data.

In a step 120, the e-mail message is formally sent and travels via the Internet 26 to where the console 24 (i.e., to the intended receiver in the above scenario) can receive it. As depicted in FIG. 7, an SMTP server may be employed. This is the most popular type of e- mail server in use today. But other systems may also be used. In the simplest case, the e-mail server may be on the very same computer system running the agent 22. Alternately, in cases where there is no e-mail server inside the secured LAN 28, it can be present at an outside Internet service provider (ISP). Most typically, however, it will be in the secured LAN 28 but elsewhere than on the same computer system running the agent 22.

FIG. 8 is a flow chart depicting a data receiver's process flow 130 using e-mail and the network communications system 20. As described for FIG. 7, an e-mail message has been created at the agent 22 and sent via the Internet 26.

In a step 132, the e-mail message is received and stored at an e-mail server. As depicted, a popular SMTP/POP-3 type server may be employed, but others may also be used. In a simple case, the e-mail server may even be the very same one that the agent 22 first communicated the e-mail message to in step 120. Generally, however, it will be a different e- mail server located elsewhere on the network. The e-mail server may be outside the LAN 34, say, at an ISP. But most commonly it will be inside the LAN 34, where it may be on the same computer system running the console 24 or elsewhere (which will probably become the most common case).

In a step 134, a scheduling or "watchdog" sub-process determines when to check for e-mail messages from the agent 22 (of course, more than one may accumulate and be ready for retrieval). In a step 136, upon instruction from the sub-process in step 134, an e-mail client sub-process retrieves the e-mail message from the e-mail server, by requesting messages and receiving one or more back.

In a step 138, the received e-mail is initially processed. In particular, it loses its distinctness as an e-mail here, and becomes received data from the agent 22. In a step 140, the data is decoded, if it was ever encrypted, or it may be formatted as desired. If these are not needed, step 140 may be optional and simply omitted. Finally, in a step 142, the data is ready and is used by the console 24.

To emphasize their functional aspects steps 138, 140, and 142 are presented separately. But they also may be integrated, to more or lesser degree, in actual embodiments of the network communications system 20.

Summarizing for FIG. 7 and 8, the agent 22 may employ e-mail to communicate data which it has collected to the console 24. If the data collected by the agent 22 is not particularly sensitive, it may be sent by conventional, open e-mail (and via commonly assigned port 25). For example, the data might merely be very simple network performance statistics. Alternately, if the data collected by the agent 22 has some attribute motivating a desire for privacy, the agent 22 can employ encrypted e-mail, using a proprietary system or any of the widely available systems for such, so long as the e-mail message received can be decrypted.

FIG. 9 is a flow chart depicting a data sender's process flow 150 using hyper text transfer protocol (HTTP) tunneling and the network communications system 20. In a step 152, a schedule sub-process runs to specify when the network communications system 20 should have the agent 22 send data to the console 24. In a step 154, the data to be sent is prepared (e.g., encrypted or formatted; or this step may be optional and omitted). In a step 156, the data is "sent" by the agent 22. As was the case in FIG. 7, these steps are presented separately here to emphasize their functional aspects. Those skilled in the art will readily appreciate that they may be integrated, to more or lesser degree, in actual embodiments of the network communications system 20. Furthermore, steps 152, 154, and 156 may be essentially the same and employ the same resources as steps 112, 114, and 116 of FIG. 7. In a step 158, the data is sent by a web client sub-process as an HTTP request with the data included, via the Internet 26 to a web server located in the LAN 34. The salient point here is that the data goes non-traditionally as part the HTTP request, but in what can otherwise be essentially a traditional HTTP communications request. Finally, in conventional manner when using HTTP, a response is received back from the web server receiving the — —

request.

FIG. 10 is a flow chart depicting a data receiver's process flow 170 using HTTP tunneling and the network communications system 20. As described for FIG. 9, the data has been sent by the agent 22 embedded in an HTTP request sent via the Internet 26. In a step 172, the data is received at a web server in the LAN 34, as part of the request from the web client sub-process in step 158. The web server may be entirely conventional. In a step 174, an applet running with the web server discerns that a request has been received with data from the agent 22 and separates out the data. The applet may be commercially available software or proprietary to the network communications system 20. In a step 176, the data received from the applet is initially processed. In a step 178, the data is decoded, if ever encrypted, or formatted as desired (or this step may be optional and simply omitted). Finally, in a step 180, the data is ready and is used by the console 24.

Again, the figures and this discussion emphasize the functional aspects of steps 176, 178, and 180. These may be integrated, to more or lesser degree, in actual embodiments of the network communications system 20.

Summarizing for FIG. 9 and 10, the agent 22 may employ a tunneling protocol, like hypertext transfer protocol (HTTP) tunneling using traditional port 80, or virtual private network (VPN) which establishes sessions using a public-private key scheme.

FIG. 11 is a flow chart depicting a data sender's process flow 190 using file transfer protocol (FTP) and the network communications system 20. In many respects this is similar to the use of e-mail to deliver data, as described above for FIG. 7 and 8.

In a step 192, a schedule sub-process runs to specify when the network communications system 20 should have the agent 22 send data to the console 24. In a step 194, the data to be sent is prepared. In a step 196, the data is "sent" by the agent 22, by passing it to a FTP client for sending. These steps 192, 194, and 196 can also be integrated, and can also be essentially the same and employ the same resources as steps 112, 114, and 116 of FIG. 7.

In a step 198, the file is formally sent from the agent 22 by a FTP client sub-process and travels via the Internet 26 to where the console 24 (i.e., to the intended receiver in the above scenario) can receive it. The FTP client typically will be conventional, but not necessarily. The network communications system 20 can use a proprietary FTP client, but the prevalence of suitable conventional ones will probably make such embodiments rare.

FIG. 12 is a flow chart depicting a data receiver's process flow 210 using FTP and the network communications system 20. As described for FIG. 1 1 , a file has been created at the agent 22 (i.e., the sender) and sent via the Internet 26.

In a step 212, the file is received and stored at a FTP server. The FTP server may be outside the LAN 34. But most commonly it will be inside the LAN 34, as implied in FIG. 12, where it may be on the same computer system running the console 24 or elsewhere (which will probably be more common).

In a step 214, a scheduling sub-process determines when to check for files sent by the agent 22 (multiple files may accumulate and be ready for retrieval). In a step 216, upon instruction from the sub-process in step 214, a FTP client sub-process retrieves a file from the FTP server, by requesting such files and receiving one or more back. In a step 218, the received file is initially processed. In particular, it loses its distinctness as a file here and becomes received data from the agent 22. In a step 220, the data is decoded if encrypted, or formatted as desired (or this step may be optional and simply omitted). Finally, in a step 222, the data is ready and is used by the console 24.

Summarizing for FIG. 11 and 12, the agent 22 may also employ FTP (typically via commonly assigned port 21) to communicate data to the console 24. Motivated by the desired degree of security outside the secured LAN 28, the FTP system employed may use anonymous login or use a robust password based login.

FIG. 13 is a flow chart depicting a data sender's process flow 230 using a proprietary protocol as part of the network communications system 20. In many respects this may be similar to the use of e-mail or FTP to deliver data, as described above with reference to FIG. 7-8 and 11-12.

In a step 232, a schedule sub-process runs to specify when the network communications system 20 data should be sent. In a step 234, the data to be sent is prepared (if desired). In a step 236, the data is "sent" by the agent 22, by passing it to a proprietary client for actual sending. In a step 238, the data is formally sent from the agent 22 by the proprietary client sub-process and travels via the Internet 26 to where the console 24 can receive it.

FIG. 14 is a flow chart depicting a data receiver's process flow 250 using the proprietary protocol of FIG. 13 in the network communications system 20. As described for FIG. 13, data has been created at the agent 22 and sent via the Internet 26 (whether as a "file" or a "message" being largely a matter of semantics).

In a step 252, a scheduling sub-process determines when to check for data from the agent 22. In a step 254, upon instruction from the sub-process in step 252, a proprietary client sub-process retrieves the data sent by the agent 22. In a step 256, the received data is initially processed. In a step 258, the data is optionally decoded or formatted. And, in a step 260, the data is ready and is used by the console 24.

Summarizing for FIG. 13 and 14, the agent 22 can also use a pre-defined open port in the secured LAN 28 to send data to the console 24 (typically an "unassigned" port, conventionally ports numbered higher than 1024). The port used on the secured LAN 28 may be statically open or may be briefly opened just to communicate the outbound data. However, since such pre-defined ports tend to be sparingly used and may be assigned, or frequently reassigned, by network administrators, the agent 22 can dynamically "sniff out available open outbound ports from its position of advantage inside the secured LAN 28. In this manner the agent 22 need not be statically set-up to use pre-known and rigidly defined parameters. It can be provided, say, on diskette or CD, to a relatively unsophisticated user of the secured LAN 28 who then executes it. The agent 22 can intelligently find available ways to communicate with the console 24.

Although the discussion above has primarily been about outward bound communications from the secured LAN 28, the agent 22 can also initiate interactive communications with the console 24. If the agent 22 sends a unique one-time code to the console 24, say, in an e-mail and perhaps including a hash code (rather than anything as complex as a cipher), this can be used to insure the validity of a reply communication from the console 24. Thus, continuing with our example of an unsophisticated user of the secured LAN 28, once the agent 22 is executed by loading from a diskette on the secured LAN 28 it can perform initial analysis, communicate its findings in a public-private key encrypted e- mail to the console 24 along with a hash code, and receive an e-mail reply back from the console 24 with instructions for further operations (optionally also public-private key encrypted or just hash marked using a confidential method). The processes usable by the inventive network communications system 20 are also in many cases readily extendible and combinable. The agent 22 can send a FTP file, say, one suitably protected and including a one-time reply token to the console 24, and the console 24 can send back a FTP file of instructions to the agent 22, assuming that FTP is permitted in the secured LAN 28 and that the agent 22 can obtain and send any password and other necessary data to the console 24 for doing this. The agent 22 then just checks, periodically or at a specific time, to see if the console 24 has replied.

If the agent 22 employs a tunneling protocol, as described above, initiating interactive communications with the console 24 is quite easy. Similarly, static and dynamic port based methods for interactive communications with the console 24 are simple when initiated by the ι

agent 22 from inside the secured LAN 28.

Of course, combinations of these techniques may also be used. For instance, e-mail to the console 24 and FTP back from it, once the agent 22 has determined how this may be carried out. Or the agent 22 can be made particularly flexible, perhaps in keeping with its filling a diagnostic role in network maintenance, and be able to dynamically resort to FTP when the e-mail component of the secured LAN 28 is malfunctioning. Or to resort to port sniffing and any still working method of those available when there are problems with a server customarily used for VPN communications in the secured LAN 28.

While various embodiments have been described above, it should be understood that they have been presented by way of example only, and not limitation. Thus, the breadth and scope of a preferred embodiment should not be limited by any of the above described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.

INDUSTRIAL APPLICABILITY The present network communications system 20 is well suited for application in modern, unsecured networks. It may be used in local area networks (LANs) or in wide are networks (WANs), including global WANs such as the Internet. The network communications system 20 may be used for a wide range of communications purposes, wherein passing of data or messages is desired between an entity in a secured network segment and an entity in another network segment. The purpose of the messages is essentially irrelevant to the network communications system 20. One network management example has been presented herein, but it is merely suggestive of the potential scope of utility of the invention.

The network communications system 20 is highly flexible, being able to use many different protocols, either individually or in combination. Furthermore, sophisticated embodiments of the invention may use adaptive techniques to search out which protocols will work in a given situation, and particularly to discover and automatically use the available ports for carrying out its role in communications.

The network communications system 20 may employ essentially conventional technology and powerful embodiments may readily prepared. Some examples, without limitation, of such conventional technology include e-mail, file transfer protocol (FTP), and tunneling protocols (e.g., HTTP and VPN). Alternately, proprietary protocols may be used, employing conventional programming technologies to generally any desired degree.

The inventive network communications system 20 may be implemented entirely in software, and thus may be quite reproducible and easily transportable, and therefore generally be quite economical.

For the above, and other, reasons, it is expected that the network communications system 20 of the present invention will have widespread industrial applicability. Therefore, it is expected that the commercial utility of the present invention will be extensive and long lasting.

Claims

— —

ΓN THE CLAIMS What is claimed is: 1. AA i method for communicating within a network, the method comprising the steps of:

(a) placing an agent within a first segment of the network which is protected by a security system;

(b) collecting message data in the first network segment with said agent;

(c) initiating communications with said agent; and

( ) communicating said message data from said agent to a console unit within a second segment of the network such that said message data proceeds outward bound from said first segment to said second segment of the network and is thereby not impeded by said security system.

2. The method of claim 1, wherein said agent passively receives said message data.

3. The method of claim 2, wherein said message is automatically produced by said first segment of the network during its operation.

4. The method of claim 1 , wherein said agent actively generates said message data by running at least one sub-routine within said first segment of the network under control of said agent.

5. The method of claim 1, wherein said agent actively receives said message data from another entity by running at least one sub-routine within said first segment of the network under control of said agent.

6. The method of claim 1 , wherein said step (b) includes at least one of formatting and encrypting said message data.

7. The method of claim 1, wherein: said step (b) includes accumulating data across a period of time into said message data; and said step (c) initiates based on a schedule. _

8. The method of claim 1, wherein: said step (b) further includes assigning priorities to respective instances of said message data; and said step (c) initiates based on said priorities.

9. The method of claim 1, wherein said step (d) includes communicating said message data via a member of the set consisting of e-mail, file transfer protocols, tunneling protocols, and proprietary protocols.

10. The method of claim 1, wherein said step (d) includes communicating said message data via a pre-specified open port in said first segment.

11. The method of claim 1 , wherein said step (d) includes communicating said message data via a programmatically determined open port in said first segment.

12. A system for communicating message data securely, comprising: a first segment of a network, wherein said first segment is secured by a security system and includes an agent; a second segment of said network, wherein said second segment includes a console unit; said agent including a logic that initiates communications; and said agent further including a logic that communicates the message data to said console unit such that the message data proceeds outward bound from said first segment to said second segment of said network and is thereby not impeded by said security system.

13. The system of claim 12, wherein said agent is passive and receives the message data.

14. The system of claim 13, wherein the message is automatically produced by said first segment of said network during its operation.

15. The system of claim 12, wherein said agent is active and runs at least one sub-routine within said first segment of the network causing generation of the message data.

16. The system of claim 12, wherein said agent further includes a logic that performs at least one of formatting and encrypting the message data.

17. The system of claim 12, wherein said agent further includes a logic that accumulates data across a period of time into the message data and then communicates the message data at a time based on a schedule.

18. The system of claim 12, wherein said agent further includes a logic that assigns priorities to respective instances of the message data and then communicates the message data at a time based on said priorities.

19. The system of claim 12, wherein said agent communicates the message data via a member of the set consisting of e-mail, file transfer protocols, tunneling protocols, and proprietary protocols.

20. The system of claim 12, wherein said agent communicates the message data via a pre- specified open port in said first segment.

21. The system of claim 12, wherein said agent communicates the message data via a programmatically determined open port in said first segment.

22. The system of claim 12, wherein said network is the Internet.

23. The system of claim 12, wherein said security system includes a firewall.