This invention relates to computer system security and, more particularly, to a system and method for improved reliability in secure packet communication systems.
Computer system resources such as web servers and database services may be directly accessible through networks such as LANs, WANs, and the Internet. Communication between computer systems over a network typically takes place through transmitted data structures called packets. A packet may include data being transported from one system to another system. Such data is generally referred to as payload. A packet may also include other data that defines the structure and nature of the packet, including information indicating the origin and destination of the packet and information indicating other packet characteristics. A stream of packets may constitute a communication from one system to another system.
The invention may be embodied as a method or system for inserting a security tag into a packet in one or more locations within the packet so that the packet may pass through a number of network impediments with the security tag or tags intact.
The sending node and receiving node may determine security tag placement using different methods. They may negotiate placement when they first establish secure communications. The sending node may determine placement based on known network impediments between it and the receiving node. The sending node may send a test packet to the receiving node to determine locations where security tags are removed and then determine placement based on the results (the received test packet). The sending node may arbitrarily or randomly determine one or more placement locations in each packet and the receiving node may check for the security tag in various placement locations when it receives the packet.
By providing a variety of security tag placement locations within a packet and then determining one or more locations to overcome network impediments between the sending node and the receiving node, secure communications may be enabled using security tags in network environments that may not typically allow such security tags within packets.
The invention is best understood from the following detailed description when read in connection with the accompanying drawings. According to common practice, various features/elements of the drawings may not be drawn to scale. Common numerical references represent like features/elements. The following figures are included in the drawings:
Although the invention is illustrated and described herein with reference to specific embodiments, the invention is not intended to be limited to the details shown. Rather, various modifications may be made in the details within the scope and range of equivalents of the claims and without departing from the invention.
Direct user/client access through networks such as LANs, WANs, and the Internet may make them vulnerable to malicious trespasses. Computer security systems may prevent such trespasses by authenticating users that desire to use resources and then ensuring that the communications between authenticated users and resources are not taken over by outside entities intent on malicious trespass.
One method to maintain secure communications via packets is to insert a security tag into each packet. The security tag may include information that the sender and receiver may verify, and, thus ensures to the receiver that the packet is from a known (verified) sender and, for example, is not from an outside source that is attempting to break into a stream of packets. It may also ensure that the packet's payload has not been altered during transmission.
A security tag within a packet, however, may not make it through (across) a network. Different network elements that check (verify) packets as the packets pass through the network may, for example, remove the security tag from a passing packet. A proxy server may, for example, consider a security tag as extraneous data and remove it, or stateful firewalls and intrusion detection systems may misinterpret the security tag and generate false alarms. In such cases, these network element (impediments) may reduce or eliminate the effectiveness of the security of the communication.
Referring to
In certain exemplary embodiments, a security plug-in 40 that may run within OS 30, may examine (analyze) and/or may modify packets sent by sending node 20. In other exemplary embodiments, the security plug-in may be an application program, other program or hardware module executing on sending node 20.
A receiving node 60 may be a gateway to a sub-network 90 of network 50 that connects to one or more network resources 95 such as web servers, database servers, and other services that user 10 may desire to access. A security gateway 70 (e.g., a program or hardware module) may run on receiving node 60. A security server 80 may run as part of security gateway 70 to examine and/or modify incoming packets and may communicate with sending node 20 via sub-network 90 and/or network 50.
Although the security plug-in and security gateway are illustrated in the network application and security server, respectively, the security plug-in and security gateway may be provided in any device on the network or sub-network that interacts with the stream of packets being secured.
Referring to
In certain exemplary embodiments, receiving node 60 may include: (1) a receiving unit 62 for receiving the tagged packets from sending node 20; (2) a packet processor 64 for authenticating each of the security tags of the tagged packets, and (3) a transmitting unit 66 for transmitting information such as the network conditions table 68.
A TCP/IP packet may include; (1) an IP header 120 that includes Internet Protocol (IP) information about packet 110; (2) a TCP header 140 that includes transmission control protocol information about packet 110; and (3) payload 160 may include data that one node requested to send to another node. IP header 120 may include an IP option field 130 that may include optional information. The TCP header 140 may include a TCP option field 150 that may include optional information. The payload 160 may include any kind of data or information a node desires to communicate to another node.
In certain exemplary embodiments, security plug-in 40 may insert a security tag in one or more placement locations within the packet 110 (e.g., in the IP option field 130, in the TCP option field 150, at the start of the payload field 170, at the end of the payload field 180 and/or, anywhere within the payload).
If the security tag is inserted in either IP option field 130 or TCP option field 150, the option field having the inserted security tag may start with an op-code, (for example, a one-byte value that may indicate the rest of the contents of the option field. The op-code value may be inserted in TCP or IP option field 130 or 150 to specify to receiving node 60 that the TCP or IP option field 130 or 150 includes a security tag.
Now referring to
At block 202 when user 10 logs into a network-connected computer and presents user credentials, such as user name and password, sending node 20 may send an authentication request including the user credentials along with information about the sending node's capabilities and a profile of sending node 20. This information about sending node 20 may be pre-established. For example, such information may be entered into security plug-in 40 when it was installed on sending node 20.
At block 204, receiving node 60 authenticates user 10 using the information in the request and an authentication server, such as a Light Directory Access Protocol (LDAP) server, that may be accessed by receiving node 60. Receiving node 60, may also read packet data from the packets that include the log-in information. The packet data may indicate to receiving node 60, sending node's 20 (i) IP address, (ii) system health status (e.g., security compliance information), (iii) host capabilities and/or (iv) profile.
At block 206, receiving node 60 may then create a unique client ID and session key for user 10 for the authenticated session. Receiving node 60 may also assemble session data that may include security tag directives, a list of protected subnets that are available through receiving node 60, and a network conditions table 310 (shown in
Security tag directives may specify a tag location in a TCP/IP packet that sending node 20 may use when it inserts a security tag into outgoing packets traversing through receiving node 60. If the security tag directives specify an IP option location or a TCP option location, then an op-code value may also be specified for IP/TCP option field 130 or 150 to indicate that it contains a security tag.
In various exemplary embodiments, security tag directives may also specify that sending node 20 may auto sense a tag location. That is, sending node 20 may automatically determine the best (optimum) security tag location by performing an automated test procedure.
At block 208, receiving node 60 may send a client ID, a session key, and any other relevant connection data to sending node 20. At block 210, sending node 20 may use the client ID, the session key, and the other session data, as appropriate, to create a digital signature for the outgoing packet. The digital signature may be created in many ways including hashing the client ID with all or part of the packet's payload using the session key.
At block 212, sending node 20 may check whether receiving node 60 specified an auto-sense, as a security tag directive. If receiving node 60 did not specify the auto-sense, at block 214, sending node 20 checks for (e.g., notes) the tag location that receiving node 60 may have specified. Sending node 20 has then established an authenticated session to receiving node 60 for user 10.
If receiving node 60 specified the auto-sense, as a security tag directive, at block 216, sending node 20 may insert a security tag at each possible location (e.g., in the IP header field, in the TCP header field, and/or the beginning or end of the payload field) in a test packet and may send the test packet to receiving node 60.
At block 218, receiving node 60 may check for security tags in each possible location and may detect from which locations the security tags have been removed by the network impediments. At block 220, receiving node 60 may send a placement message to sending node 20. The placement message may indicate one or more successful tag locations (e.g., locations which were not affected by the network impediments). At block 222, sending node 20 may choose one of those tag locations.
In certain exemplary embodiments, the tag locations are prioritized such that when the successful tag locations are determined, sending and receiving nodes 20 and 60 both determine the actual tag location based on the predetermined prioritization.
At block 224, sending node 20 establishes an authenticated session to receiving node 60 for user 10.
Now referring to
Referring to
At block 404, sending node 20 may check whether receiving node 60 sent network conditions table 310. If not, at block 408 sending node 20 may insert a security tag in the packet at the specified location. The specified location was previously determined when sending node 20 established the authenticated session with receiving node 60 for user 10.
At block 406, if receiving node 60 sent network conditions table 310, sending node 20 may check network conditions table 310 to determine if the sending node's current IP address is within the IP address ranges 320 defined by entries in network conditions table 310. At block 408, if the current IP address is not defined within an IP address range in the network conditions table 310, sending node 20 may insert the security tag in the packet at the specified location.
At block 410, if the current IP address is defined in an IP address range in the network conditions table 310, sending node may read the table entry's tag placement directives 330 to determine network impediments which are located between sending and receiving nodes 20 and 60. Sending node 20 may determine the tag location or locations that are most likely to carry the security tag intact over network 50 and may insert the security tag at one or more of these locations.
At block 412, sending node 20 may send the packet with the security tag to receiving node 60. At block 414, when receiving node 60 receives the packet from sending node 20, receiving node 60 may determine whether or not it previously specified a fixed tag location to sending node 20. At block 416, if receiving node 60 specified a fixed location, receiving node 60 may check for the security tag in the specified location. At block 418, if receiving node 60 locates (finds) the security tag at the specified location, it may read the security tag and, at block 446, may check whether the security tag is authentic.
Many different methods for authentication are possible including receiving node 60 reading the client ID in the security tag, retrieving the session key it created for that user for the authenticated session, then hashing the client ID with the packet's payload using the session key and checking the resultant value against the digital signature contained in the security tag.
At block 420, if receiving node 60 had not previously specify a fixed tag location, or if receiving node 60 is unable to allocate the security tag in the fixed location, receiving node 60 may check a size of the packet's IP option field. At block 422, if the IP option field size is greater than or equal to the security tag size, receiving node 60 may check the op code value of IP option field 130 to determine if it matches the op code value receiving node 60 previously specified when it first negotiated the session information with sending node 20. At block, 424, if so, receiving node 60 may read IP option field 130 to determine if it finds a valid security tag. At block 428, if the size of IP option field 130 is less than the size of the security tag, if receiving node 60 does not find the specified op code value in IP option field 130 or if receiving node 60 cannot find a valid security tag, receiving node 60 may check TCP option field 150. At block 424, if receiving node 60 finds a valid security tag, receiving node 60 may read the security tag in IP option field 130 and then at block 446 may check to determine if the security tag is authentic.
If receiving node 60 does not find a security tag in IP option field 130, it may check the size of the packet's TCP option field 150. At block 430, if the TCP option field size is greater than or equal to the security tag size, receiving node 60 may check the TCP option's op code value to determine if it matches the specified op code value the receiving node 60 previously specified when it first negotiated the session information with sending node 20. At block 432, if receiving node 60 does find the specified op code value, receiving node may read TCP option field 150 to determine if it finds a valid security tag. At block 438, if the option field size is less than the size of the security tag, if receiving node 60 does not find the specified op code value in TCP option field 130, or if receiving node 60 does not find a valid security tag, receiving node 60 may check the start of the payload field 170. At block 436, if the node finds a valid security tag, receiving node 60 may read the security tag in TCP option field 150 and then, at block 446, may check to determine if the security tag is authentic.
If receiving node 60 does not find a security tag in TCP option field 150, it may read the start of the packet's payload field 160 to determine if there is a valid security tag. If so, at block 440, receiving node 60 may read the security tag and then, at block 446, may check to determine if the security tag is authentic.
At block 442, if no security tag is located in the start of the payload field 170, receiving node 60 may read the end of the packet's payload field 180 to determine if there is a valid security tag. If so, at block 440, receiving node 60 may read the security tag and then, at block 446, may check whether the security tag is authentic. If no security tag is located at the start or end of the payload field 170 or 180, receiving node 60 has not found a valid security tag and, at block 444, may drop the packet (e.g., to prevent or restrict access by the packet to the protected resource 95 and/or the protected network 90), thus blocking access to the protected resource 95 and/or the protected network 90. In certain exemplary embodiments receiving node 60 may quarantine the packet and/or send the packet elsewhere for analysis.
At block 448, if the security tag is authentic, receiving node 60 may remove the security tag from the packet and may send the packet to the desired network resource located behind (after) security gateway 70. In certain exemplary embodiments, security gateway 70 may include receiving node 60.
At block 450, when a subsequent packet for this authenticated session arrives at receiving node 60, receiving node 60 may check the same tag location where it found the security tag in the last session packet. At block 446, if receiving node 60 finds a security tag at the same location, it may determine the security tag's authenticity. If receiving node 60 does not find a security tag at the same location, it may continue processing at block 420 and search for the security tag in other locations.
The security system and the method for inserting a security tag at variable locations in a packet disclosed herein have diverse applicability in a range of markets including financial services, wireless LAN (e.g., wireless sales force automation and contractor services), and government regulated markets such as banking and health care, among others.
Although tag location are disclosed as being selected using either placement messages, network conditions tables or auto sense procedures, it is also possible that sending node may insert the security tags randomly or at a predetermined location or locations and then may send the packet with the security tag. In such cases, it is possible for the receiving node to check for security tags in packets and to drop packets, for example, when a valid security tag is not found within a predetermined number of packets or after a predetermined timeframe from the last valid security tag.
Although the sending node is shown as inserting a single security tags in each packet sent to the receiving node, it is contemplated that the sending node may select one or more of tag locations and may insert the security tag into the first packet, each packet or selected packets (periodically or pseudo-randomly) of the session according to network security levels indicated by receiving node 60.
Although verification of the security tag in placement locations is illustrated in a particular order (e.g., checking the IP option field, the TCP option field and then the payload), the verification may occur in any order. Moreover, the order of such checking may be based on any known network impediments.
Although various embodiments of the present invention have been described in terms of creating secure connections between nodes in a network, it is not limited thereto. The methods may be carried out between networks, for example, using any number of different protocols.
Although various embodiments of the present invention have been described in terms of messages being transmitted between client and server, it is not limited thereto. The identification techniques disclosed herein apply to communications transmitted with respect to a wide range of computer applications, and are not limited to server applications.
The terms message and communication as used herein are intended to refer to a broad class of transmissions carried out between computer systems or portions thereof; for example, inquiries, data updates, data edits, and data requests, among others.
As described herein, for example, the invention may be embodied in software, in a machine (e.g., a computer system, a microprocessor based appliance, etc.) that includes software in memory, or in a tangible computer storage carrier configured to carry out the protection scheme (e.g., in a self contained silicon device, a solid state memory, an optical disc, a magnetic disc, etc.). Further, when the invention is embodied in a remote system for a user to access a resource, the remote system is not limited to an application server, and the resource is not limited to an application on an application server. It is contemplated that the security system may be included in other layers of the network such as the network layer, or firewall layer of combinations of the other layers.
As described herein, the remote system may be any remotely accessible microprocessor based device (e.g., a PDA, a personal computer, a network server, etc.), and the resource may be any resource installed on (or accessible through a connection to) the remotely accessible device.
Although the invention is illustrated and described herein with reference to specific embodiments, the invention is not intended to be limited to the details shown. Rather, various modifications may be made in the details within the scope and range equivalents of the claims and without departing from the invention.
This application claims the benefit of U.S. Provisional Application No. 60/986,833, filed Nov. 9, 2007, entitled “System And Method For Using Variable Security Tag Location In Network Communications” the contents of which are hereby incorporated by reference.
Number | Name | Date | Kind |
---|---|---|---|
5218637 | Angebaud et al. | Jun 1993 | A |
5757916 | MacDoran et al. | May 1998 | A |
5784562 | Diener | Jul 1998 | A |
5867494 | Krishnaswamy et al. | Feb 1999 | A |
5887065 | Audebert | Mar 1999 | A |
5983270 | Abraham et al. | Nov 1999 | A |
5987611 | Freund | Nov 1999 | A |
5999525 | Krishnaswamy et al. | Dec 1999 | A |
6021495 | Jain et al. | Feb 2000 | A |
6070245 | Murphy et al. | May 2000 | A |
6076108 | Courts et al. | Jun 2000 | A |
6105136 | Cromer et al. | Aug 2000 | A |
6141758 | Benantar et al. | Oct 2000 | A |
6145083 | Shaffer et al. | Nov 2000 | A |
6161182 | Nadooshan | Dec 2000 | A |
6170019 | Dresel et al. | Jan 2001 | B1 |
6199113 | Alegre et al. | Mar 2001 | B1 |
6219669 | Haff et al. | Apr 2001 | B1 |
6253326 | Lincke et al. | Jun 2001 | B1 |
6304969 | Wasserman et al. | Oct 2001 | B1 |
6335927 | Elliott et al. | Jan 2002 | B1 |
6345291 | Murphy et al. | Feb 2002 | B2 |
6393569 | Orenshteyn | May 2002 | B1 |
6418472 | Mi et al. | Jul 2002 | B1 |
6442571 | Haff et al. | Aug 2002 | B1 |
6452915 | Jorgensen | Sep 2002 | B1 |
6470453 | Vilhuber | Oct 2002 | B1 |
6473794 | Guheen et al. | Oct 2002 | B1 |
6480967 | Jensen et al. | Nov 2002 | B1 |
6502192 | Nguyen | Dec 2002 | B1 |
6510350 | Steen et al. | Jan 2003 | B1 |
6519571 | Guheen et al. | Feb 2003 | B1 |
6523027 | Underwood | Feb 2003 | B1 |
6535917 | Zamanzadeh et al. | Mar 2003 | B1 |
6536037 | Guheen et al. | Mar 2003 | B1 |
6594589 | Coss, Jr. et al. | Jul 2003 | B1 |
6601233 | Underwood | Jul 2003 | B1 |
6609128 | Underwood | Aug 2003 | B1 |
6615166 | Guheen et al. | Sep 2003 | B1 |
6633878 | Underwood | Oct 2003 | B1 |
6640248 | Jorgensen | Oct 2003 | B1 |
6704873 | Underwood | Mar 2004 | B1 |
6718535 | Underwood | Apr 2004 | B1 |
6721713 | Guheen et al. | Apr 2004 | B1 |
6725269 | Megiddo | Apr 2004 | B1 |
6731625 | Eastep et al. | May 2004 | B1 |
6735691 | Capps et al. | May 2004 | B1 |
6748287 | Hagen et al. | Jun 2004 | B1 |
6754181 | Elliott et al. | Jun 2004 | B1 |
6766314 | Burnett | Jul 2004 | B2 |
6785692 | Wolters et al. | Aug 2004 | B2 |
6826616 | Larson et al. | Nov 2004 | B2 |
6839759 | Larson et al. | Jan 2005 | B2 |
6850252 | Hoffberg | Feb 2005 | B1 |
6856330 | Chew et al. | Feb 2005 | B1 |
6870921 | Elsey et al. | Mar 2005 | B1 |
6909708 | Krishnaswamy et al. | Jun 2005 | B1 |
6944279 | Elsey et al. | Sep 2005 | B2 |
6947992 | Shachor | Sep 2005 | B1 |
6954736 | Menninger et al. | Oct 2005 | B2 |
6957186 | Guheen et al. | Oct 2005 | B1 |
6985922 | Bashen et al. | Jan 2006 | B1 |
7013290 | Ananian | Mar 2006 | B2 |
7039606 | Hoffman et al. | May 2006 | B2 |
7054837 | Hoffman et al. | May 2006 | B2 |
7072843 | Menninger et al. | Jul 2006 | B2 |
7096495 | Warrier et al. | Aug 2006 | B1 |
7100195 | Underwood | Aug 2006 | B1 |
7107285 | Von Kaenel et al. | Sep 2006 | B2 |
7120596 | Hoffman et al. | Oct 2006 | B2 |
7145898 | Elliott | Dec 2006 | B1 |
7149698 | Guheen et al. | Dec 2006 | B2 |
7149803 | Douglis et al. | Dec 2006 | B2 |
7160599 | Hartman | Jan 2007 | B2 |
7165041 | Guheen et al. | Jan 2007 | B1 |
7171379 | Menninger et al. | Jan 2007 | B2 |
7188138 | Schneider | Mar 2007 | B1 |
7188180 | Larson et al. | Mar 2007 | B2 |
7194552 | Schneider | Mar 2007 | B1 |
7331061 | Ramsey et al. | Feb 2008 | B1 |
7334125 | Pellacuru | Feb 2008 | B1 |
7353533 | Wright et al. | Apr 2008 | B2 |
7363347 | Thomas | Apr 2008 | B2 |
7386889 | Shay | Jun 2008 | B2 |
7398552 | Pardee et al. | Jul 2008 | B2 |
7430760 | Townsend et al. | Sep 2008 | B2 |
7509687 | Ofek et al. | Mar 2009 | B2 |
7519986 | Singhal | Apr 2009 | B2 |
7567510 | Gai et al. | Jul 2009 | B2 |
7593529 | Yang | Sep 2009 | B1 |
7596803 | Barto et al. | Sep 2009 | B1 |
7637147 | Lee et al. | Dec 2009 | B2 |
7644434 | Pollutro et al. | Jan 2010 | B2 |
7660902 | Graham et al. | Feb 2010 | B2 |
7660980 | Shay et al. | Feb 2010 | B2 |
7770223 | Shevenell et al. | Aug 2010 | B2 |
7877601 | Smith et al. | Jan 2011 | B2 |
7978700 | Kopelman et al. | Jul 2011 | B2 |
8412838 | Wang et al. | Apr 2013 | B1 |
20010020195 | Patel et al. | Sep 2001 | A1 |
20010052012 | Rinne et al. | Dec 2001 | A1 |
20010054044 | Liu et al. | Dec 2001 | A1 |
20010054147 | Richards | Dec 2001 | A1 |
20020002577 | Garg et al. | Jan 2002 | A1 |
20020022969 | Berg et al. | Feb 2002 | A1 |
20020029086 | Ogushi et al. | Mar 2002 | A1 |
20020062367 | Debber et al. | May 2002 | A1 |
20020077981 | Takatori et al. | Jun 2002 | A1 |
20020078015 | Ponnekanti | Jun 2002 | A1 |
20020080822 | Brown et al. | Jun 2002 | A1 |
20020083183 | Pujare et al. | Jun 2002 | A1 |
20020116643 | Raanan et al. | Aug 2002 | A1 |
20020133723 | Tait | Sep 2002 | A1 |
20020146026 | Unitt et al. | Oct 2002 | A1 |
20020146129 | Kaplan | Oct 2002 | A1 |
20020184224 | Haff et al. | Dec 2002 | A1 |
20020193966 | Buote et al. | Dec 2002 | A1 |
20030005118 | Williams | Jan 2003 | A1 |
20030005300 | Noble et al. | Jan 2003 | A1 |
20030009538 | Shah et al. | Jan 2003 | A1 |
20030023726 | Rice et al. | Jan 2003 | A1 |
20030033545 | Wenisch et al. | Feb 2003 | A1 |
20030055962 | Freund et al. | Mar 2003 | A1 |
20030063750 | Medvinsky et al. | Apr 2003 | A1 |
20030083991 | Kikinis | May 2003 | A1 |
20030084350 | Eibach et al. | May 2003 | A1 |
20030171885 | Coss et al. | Sep 2003 | A1 |
20030179900 | Tian et al. | Sep 2003 | A1 |
20030200439 | Moskowitz | Oct 2003 | A1 |
20030204421 | Houle et al. | Oct 2003 | A1 |
20030208448 | Perry et al. | Nov 2003 | A1 |
20030208562 | Hauck et al. | Nov 2003 | A1 |
20030217126 | Polcha et al. | Nov 2003 | A1 |
20030217166 | Dal Canto et al. | Nov 2003 | A1 |
20030220768 | Perry et al. | Nov 2003 | A1 |
20030220821 | Walter et al. | Nov 2003 | A1 |
20040006710 | Pollutro et al. | Jan 2004 | A1 |
20040022191 | Bernet et al. | Feb 2004 | A1 |
20040024764 | Hsu et al. | Feb 2004 | A1 |
20040031058 | Reisman | Feb 2004 | A1 |
20040049515 | Haff et al. | Mar 2004 | A1 |
20040107342 | Pham et al. | Jun 2004 | A1 |
20040107360 | Herrmann et al. | Jun 2004 | A1 |
20040111410 | Burgoon et al. | Jun 2004 | A1 |
20040139313 | Buer et al. | Jul 2004 | A1 |
20040142686 | Kirkup et al. | Jul 2004 | A1 |
20040193606 | Arai et al. | Sep 2004 | A1 |
20040193912 | Li et al. | Sep 2004 | A1 |
20040214576 | Myers et al. | Oct 2004 | A1 |
20040228362 | Maki et al. | Nov 2004 | A1 |
20040230797 | Ofek et al. | Nov 2004 | A1 |
20050010528 | Pelz et al. | Jan 2005 | A1 |
20050015624 | Ginter et al. | Jan 2005 | A1 |
20050027788 | Koopmans et al. | Feb 2005 | A1 |
20050038779 | Fernandez et al. | Feb 2005 | A1 |
20050132030 | Hopen et al. | Jun 2005 | A1 |
20050185647 | Rao et al. | Aug 2005 | A1 |
20050265351 | Smith et al. | Dec 2005 | A1 |
20050283822 | Appleby et al. | Dec 2005 | A1 |
20060005240 | Sundarrajan et al. | Jan 2006 | A1 |
20060068755 | Shraim et al. | Mar 2006 | A1 |
20060075464 | Golan et al. | Apr 2006 | A1 |
20060080441 | Chen et al. | Apr 2006 | A1 |
20060080667 | Sanghvi et al. | Apr 2006 | A1 |
20060090196 | Van Bemmel et al. | Apr 2006 | A1 |
20060198394 | Gotoh et al. | Sep 2006 | A1 |
20060218273 | Melvin | Sep 2006 | A1 |
20060245414 | Susai et al. | Nov 2006 | A1 |
20060248480 | Faraday et al. | Nov 2006 | A1 |
20060248580 | Fulp et al. | Nov 2006 | A1 |
20060271652 | Stavrakos et al. | Nov 2006 | A1 |
20060274774 | Srinivasan et al. | Dec 2006 | A1 |
20060277275 | Glaenzer | Dec 2006 | A1 |
20060277591 | Arnold et al. | Dec 2006 | A1 |
20060282545 | Arwe et al. | Dec 2006 | A1 |
20060282876 | Shelest et al. | Dec 2006 | A1 |
20070038618 | Kosciusko et al. | Feb 2007 | A1 |
20070061434 | Schmieder et al. | Mar 2007 | A1 |
20070113269 | Zhang | May 2007 | A1 |
20070136317 | Przywara | Jun 2007 | A1 |
20070192853 | Shraim et al. | Aug 2007 | A1 |
20070271592 | Noda et al. | Nov 2007 | A1 |
20070283014 | Shinomiya et al. | Dec 2007 | A1 |
20070294762 | Shraim et al. | Dec 2007 | A1 |
20070299915 | Shraim et al. | Dec 2007 | A1 |
20080005779 | Takenaka et al. | Jan 2008 | A1 |
20080008202 | Terrell et al. | Jan 2008 | A1 |
20080215889 | Celik et al. | Sep 2008 | A1 |
20090158384 | Kanade et al. | Jun 2009 | A1 |
20090210364 | Adi et al. | Aug 2009 | A1 |
20100037284 | Sachs | Feb 2010 | A1 |
20100223222 | Zhou et al. | Sep 2010 | A1 |
20100235879 | Burnside et al. | Sep 2010 | A1 |
20110280215 | Nakagawa et al. | Nov 2011 | A1 |
20120051529 | Dobbins et al. | Mar 2012 | A1 |
20120096513 | Raleigh et al. | Apr 2012 | A1 |
20120304277 | Li et al. | Nov 2012 | A1 |
Number | Date | Country |
---|---|---|
2286534 | Apr 2001 | CA |
1 071 256 | Jan 2001 | EP |
1 418 730 | May 2004 | EP |
1 641 215 | Mar 2006 | EP |
06097905 | Aug 1994 | JP |
11205388 | Jul 1999 | JP |
2001306521 | Feb 2001 | JP |
2003008651 | Oct 2003 | JP |
WO-0133759 | May 2001 | WO |
WO-0138995 | May 2001 | WO |
WO-02079949 | Oct 2002 | WO |
WO-2005066737 | Jul 2005 | WO |
Entry |
---|
Aleksander Svelokken, “Biometric Authentication and Identification Using Keystroke Dynamics With Alert Levels”, Master Thesis (Retrieved from University of Oslo), May 23, 2007, pp. 1-124. |
Darryle Merlette, Dr. Parag Pruthi; Network Security; NetDetector: Identifying Real Threats and Securing Your Network; Copyright © 2003 Niksun, Inc., Monmouth Junction NJ, USA. |
Darryle Merlette; Spencer Parker, Dr. Parag Pruthi; Niksun Network Security; NetDetector: Monitoring and Minimizing Instant Messaging Risks; Copyright © 2003 Niksun, Inc., Monmouth Junction NJ, USA. |
International Search Report for International Application No. PCT/US2008/007984; Completed Aug. 22, 2009; Mailed Sep. 3, 2009. |
International Search Report for PCT Application No. PCT/US2004/043405; Completed Mar. 15, 2005; Mailed Mar. 23, 2005. |
Japanese Office Action on 2006-547397 dated Jul. 5, 2011. |
Notice of Allowance for U.S. Appl. No. 10/423,444 dated Nov. 16, 2009. |
Notice of Allowance on U.S. Appl. No. 10/583,578 dated Mar. 27, 2012. |
Office Action for Japanese Application 2006-547397 dated Nov. 30, 2010. |
Office Action for U.S. Appl. No. 10/423,444 dated Mar. 14, 2008. |
Office Action for U.S. Appl. No. 10/423,444 dated Jul. 27, 2009. |
Office Action for U.S. Appl. No. 10/423,444 dated Jun. 13, 2006. |
Office Action for U.S. Appl. No. 10/423,444 dated Mar. 12, 2007. |
Office Action for U.S. Appl. No. 10/423,444 dated Sep. 19, 2008. |
Office Action for U.S. Appl. No. 10/423,444 dated Sep. 7, 2007. |
Office Action for U.S. Appl. No. 12/163,292 dated Aug. 8, 2011. |
Office Action for U.S. Appl. No. 12/163,292 dated Feb. 2, 2011. |
Office Action for U.S. Appl. No. 10/423,444 dated Dec. 2, 2008. |
Office Action for U.S. Appl. No. 10/423,444 dated Feb. 25, 2009. |
Office Action on U.S. Appl. No. 10/583,578 dated Jun. 24, 2010. |
Office Action on U.S. Appl. No. 10/583,578 dated Feb. 11, 2011. |
Office Action on U.S. Appl. No. 10/583,578 dated Jul. 19, 2011. |
Office Action on U.S. Appl. No. 12/267,804 dated Apr. 10, 2012. |
Office Action on U.S. Appl. No. 12/267,804 dated Aug. 16, 2011. |
Office Action on U.S. Appl. No. 12/267,804 dated Apr. 25, 2011. |
Office Action on U.S. Appl. No. 12/270,278 dated Nov. 9, 2011. |
Office Action on U.S. Appl. No. 12/270,278 dated Jun. 24, 2011. |
Office Action on U.S. Appl. No. 12/406,613 dated Mar. 20, 2012. |
Office Action on U.S. Appl. No. 12/406,613 dated Oct. 24, 2011. |
Scarfone et ai, Guide to Intrusion Detection and Prevention Systems (IOPS), Feb. 2007, NIST, Special Publication 800-94. |
Written Opinion of the International Search Authority for PCT Application No. PCT/US2004/043405; Completed Mar. 15, 2005; Mailed Mar. 23, 2005. |
Office Action on U.S. Appl. No. 12/432,186 dated Jun. 25, 2012. |
US Notice of Allowance on U.S. Appl. No. 12/267,804 dated Apr. 24, 2013. |
US Office Action on U.S. Appl. No. 12/267,804 dated Sep. 27, 2012. |
US Office Action on U.S. Appl. No. 12/432,186 dated Feb. 21, 2013. |
US Notice of Allowance for U.S. Appl. No. 12/163,292 dated Aug. 6, 2014. |
US Office Action for U.S. Appl. No. 12/270,278 dated Feb. 20, 2014. |
US Office Action for U.S. Appl. No. 12/163,292 dated Apr. 25, 2014. |
US Office Action for U.S. Appl. No. 12/270,278 dated Aug. 15, 2014. |
US Office Action for U.S. Appl. No. 12/406,613 dated Jun. 9, 2014. |
US Notice of Allowance for U.S. Appl. No. 12/432,186 dated Sep. 10, 2014. |
US Office Action for U.S. Appl. No. 12/406,613 dated Oct. 6, 2014. |
Number | Date | Country | |
---|---|---|---|
20090144818 A1 | Jun 2009 | US |
Number | Date | Country | |
---|---|---|---|
60986833 | Nov 2007 | US |