Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
DETAILED ACTION
Claims 1-14 are pending in Instant Application.
Priority
Examiner acknowledges Applicant’s claim to priority benefits of EP22 21 2700.3 filed 12/12/2022.
Information Disclosure Statement
The information disclosure statement(s) (IDS) submitted on 09/29/2023 is/are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement(s) is/are being considered if signed and initialed by the Examiner.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same and shall set forth the best mode contemplated by the inventor of carrying out his invention.
The following is a quotation of the second paragraph of 35 U.S.C. 112:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
The following is a quotation of the fourth paragraph of 35 U.S.C. 112:
Subject to the [fifth paragraph of 35 U.S.C. 112], a claim in dependent form shall contain a reference to a claim previously set forth and then specify a further limitation of the subject matter claimed. A claim in dependent form shall be construed to incorporate by reference all the limitations of the claim to which it refers.
Claim 2 is rejected under 35 U.S.C. 112, second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which applicant regards as the invention.
There is insufficient antecedent basis in the following claim(s) for the limitation(s) enumerated below: Claim 2, lacks antecedent basis for " the computer-implemented method ". If the claim 2 is an independent claim, then it should be “a computer-implemented method”.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-9, 11-14 are rejected under 35 U.S.C. 103 as being unpatentable over Capalik (U.S. patent Application: 20150074811) in view of Gukal et al., “hereinafter Gukal” (U.S. patent Application: 20170353491).
As per Claim 1, Capalik discloses a computer-implemented method for intrusion detection, comprising:
detecting, at a first decoy instance hosted by an embedded device connected to a communications network (Capalik, Para.15, a system and method for analyzing unauthorized intrusion into a computer network. Access is allowed through one or more open ports to one or more virtualized decoy operating systems running on a hypervisor operating system hosted on a decoy network device), an intrusion event generated by an intruding instance that is not hosted by the embedded device (Capalik, Para.15, A network attack on the virtualized operating system is then intercepted by a virtual-machine-based rootkit module running on the hypervisor operating system. The attack-identifying information is communicated through a private network interface channel and stored on a database server as forensic data. A signature generation engine uses this forensic data to generate a signature of the attack. An intrusion prevention system then uses the attack signature to identify and prevent subsequent attacks, Para.22, attacker activity 10 directed at protected computer network 20. As in a typical attack, attack 10 is scanning for an open port on computer network 20 in an attempt to make a connection and then access one or more protected network devices 20a on network 20. );
generating an intrusion event trace based on the detected intrusion event (Capalik, Para.48, The introspection module 538 examines the memory of virtualized decoy operating systems 512 by means of three functional components: a code region selector, a trace instrumentor, and a trace analyzer… The instrumentor copies the memory traces of interest identified by the code selector and then profiles and instruments them. The trace analyzer takes the instrumented traces and uses them to replay the memory behavior of the decoy operating system 512, Para.12, the processing module generates a report of the attack. The report consists of user-friendly information that paints a picture of the attack for a system administrator. This may include information on which sockets were accessed, what happened at a particular socket, the key strokes entered or bytes transferred to the port, what files were transferred, registry changes, how the attack was run, what happened on the primary network, on its servers or how the network services were affected. The report may also include information on the location of the attacker or the attacker's service provider.); and
However Capalik does not explicitly disclose transmitting the intrusion event trace from the first decoy instance to a first intrusion detection instance that is communicably coupled to the embedded device.
Gukal discloses transmitting the intrusion event trace from the first decoy instance to a first intrusion detection instance that is communicably coupled to the embedded device (Gujal, Para.268, the deception center 1208 can include packet scanning tools, such as an Intrusion Detection System (IDS) 1390, which can filter and/or analyze scan-related packets received by the deception sensor 1380. The deception center 1308 can be connected to the example network 1302, or can be located outside the network 1302 and communicate with the network 1302 using intermediate networks. In either case, the deception center 1308 can be in communication with external networks 1350 in order to communicate with a network security services provider 1306 and/or the greater security community 1352, Para.270, The deception sensor 1380 can assume one or more network addresses, and for each network address can present a decoy network device 1382a-1382b to the network 1302. The deception sensor 1380 can use the decoy network devices 1382a-1382b to monitor network activity, including, for example, packets sent into and out of the network 1302, and/or packets sent between devices in the network 1302.).
The reference Capalik discloses the intrusion event trace and the reference Gukal discloses transmitting analyzed packets from the first decoy instance to a first intrusion detection instance that is communicably coupled to the embedded device.
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings as in Capalik with the teachings as in Gukal. The motivation for implementing systems, methods (including computer-implemented methods), and computer-program products for using deceptions to detect network scans. In various implementations, a network device on a network can be configured to determine a particular network address. The network device can configured as a decoy network device. A decoy network device monitors network activity and does not participate in network activity (Gukal, Para.04).
With respect to Claim 11, 12, 14 is substantially similar to Claim 1 and are rejected in the same manner, the same art and reasoning applying.
As per Claim 2, Capalik in view of Gukal discloses the computer-implemented method, wherein detecting the of the intrusion event includes:
monitoring at least one attribute of the first decoy instance during runtime (Capalik, Para.10, The sentinel kernel driver monitors connections to the operating system as well as activity on the operating system and activity on services running on the operating system. When an attacker connects to a port, the sentinel kernel driver captures the data coming through the socket.);
comparing the at least one attribute to a register of attributes (Capalik, Para.15, The attack-identifying information is communicated through a private network interface channel and stored on a database server as forensic data. A signature generation engine uses this forensic data to generate a signature of the attack. An intrusion prevention system then uses the attack signature to identify and prevent subsequent attacks, Para.04, When a connection is attempted to a network port, the IDS or IPS examines the low-level IP data packets and compares them to its library of signatures for a match. When a match is identified the IDS or IPS provides notification of the match.); and
when the at least one attribute is determined to be indicative of an intrusion event based on the comparison of the at least one attribute to the register of attributes, asserting that an intrusion event has been detected (Capalik, Para.55, the processing module 508 generates a report of the attack that includes attack-identifying information (See FIG. 3). This report is for review and use by a system administrator responsible for the security of a protected network 504. The attack may contain, but is not limited to, one or more data transfers or keystrokes, which are analyzed at Step 46. By observing whether the attacker is successful in interacting with the system (i.e., if the system is responding in a manner that shows that the attacker has gained access), a determination can be made at Step 48 as to whether an attack signature should be generated, and the attack signature is created at step 52 (See FIG. 4).).
As per Claim 3, Capalik in view of Gukal discloses the computer-implemented method according to claim 1, further comprising:
receiving, at the first intrusion detection instance, the intrusion event trace from the first decoy instance (Capalik, Para.48, The trace analyzer takes the instrumented traces and uses them to replay the memory behavior of the decoy operating system 512. In this manner, the introspection module 538 examines the contents of the decoy operating systems' 512 memory segments in an instrumented context that generates and retrieves forensic data for analysis by the processing module 508, Para.50, The captured information, containing attack-identifying information, is then sent from the introspection module 538 to the processing module 508 by means of a virtual machine-based rootkit userland process 522.);
analyzing the intrusion event trace to determine a reconfiguration action to apply to the first decoy instance; transmitting the reconfiguration action to the first decoy instance; and reconfiguring the first decoy instance based on the analysis of the intrusion event trace (Capalik, Para.56, the report of the attack is written and then displayed via a visualization interface 532 and can include information about which sockets were accessed by the attack 550, what happened at a particular socket, the keystrokes entered or data transferred, what files were transferred, how the attack 550 was run, what happened on the virtualized operating system module 506, and how the virtualized decoy operating systems 512 running on the hypervisor operating system 510 and any related network services were affected. In some embodiments, the visualization interface 532 is AJAX- and/or FLASH-based. The report may also include information on the location of the instigator of the attack 550 or the service provider used for the attack. Graphical representations of key information and interactive mapping of attack locales by region or country may also be included in the report. The visualization interface may also be used to analyze, configure, and automate the system's response to attack activity 550 on timescales ranging from near-immediate to several minutes from the initiation of an attack.);
As per Claim 4, Capalik in view of Gukal discloses the computer-implemented method according to claim 1, further comprising:
receiving the intrusion event trace at a security operations center; analyzing the intrusion event trace using an automated or manual process at the security operations center (Capalik, Para.56, Thus the virtual-machine-based rootkit module 520 can cleanse or reset the virtualized decoy operating system of any malicious software or payload, removing the possibility that attacker(s) can use that virtualized decoy operating system 512 for further attacks on other networks. In this manner, the attack can be thwarted, and the operating system does not become a tool of the attacker(s). This procedure may also be automated, i.e., may occur without further human intervention.); and reconfiguring the first decoy instance and/or the first intrusion detection instance based on the analysis (Capalik, Para.11,The captured data, which contains the attack-identifying information, is sent to the back-end or processing module though the backplane fabric of the appliance using Layer 2 Ethernet communication protocol. The processing module is separate and independent from the client operating system modules and communicates the processed information to security administrators through a network port connected to the private and secure VLAN. Unbeknownst to the intruder, the exploit is thus captured, transferred and analyzed.).
As per Claim 5, Capalik in view of Gukal discloses the computer-implemented method according to claim 4, further comprising:
reconfiguring at least a second decoy instance and/or functional instances based on the analysis of the intrusion event trace obtained at the first decoy instance (Capalik, Para.43, Attack 10 is monitored by decoy 100 that includes at least one monitor/intercept module 30. Monitor/intercept module 30 comprises fully functioning decoy operating system 32 that monitors each of the access ports for network 20. Any operating system may be used as decoy operating system 32 including Windows.RTM., Sun Microsystems Solaris.RTM. or any version of Linux.RTM. known to persons skilled in the art. All known operating systems are within the scope of the present invention. FIG. 1 shows one monitoring/intercept module 30 in the foreground, however any number of homogeneous or heterogeneous monitoring/intercept modules may be utilized (shown as a stack behind monitor/intercept module 30).).
As per Claim 6, Capalik in view of Gukal discloses the computer-implemented method according to claim 1, further comprising:
polling, via the first decoy instance or the first intrusion detection instance, plurality of further decoy instances and/or further intrusion detection instances with the intrusion event trace (Capalik, Para.45, When the attacker activity 550 connects to a virtualized decoy operating system 512 through an open port, the attacker sees a fully-functional standard operating system fingerprint. Since the virtualized operating system module 506 can be configured to present any operating system as a fully-functional virtualized decoy 512, responses to connection requests from attacker activity 550 are guaranteed to be authentic for the operating system running on that decoy. For example, an FTP port access request for WINDOWS may return a specific character sequence that differs from an FTP response for LINUX. Similarly, an FTP access request to a WINDOWS port may return a response ">ftp: connect: Connection refused." This character sequence may be slightly different from that generated by LINUX. Further, different versions of WINDOWS may respond with slightly different, version-specific character sequences. Since attackers often use these sequences to identify what type of operating system is at a particular network address and the version (or range of possible versions) for that operating system, the fact that virtualized decoy operating systems 512 generate authentic responses makes them realistic decoys and encourages intruders to access them.); aggregating, at the first decoy instance or the first intrusion detection instance, a plurality of responses to the intrusion event trace from the plurality of further decoy instances and/or further intrusion detection instances (Capalik, Para.45, virtualized decoy operating systems 512 generate authentic responses makes them realistic decoys and encourages intruders to access them.); and reconfiguring the first decoy instance based on the aggregation of the responses from the further decoy instances and/or further intrusion detection instances (Capalik, Para.45, different versions of WINDOWS may respond with slightly different, version-specific character sequences. Since attackers often use these sequences to identify what type of operating system is at a particular network address and the version (or range of possible versions) for that operating system, the fact that virtualized decoy operating systems 512 generate authentic responses makes them realistic decoys and encourages intruders to access them. The instigator of the attack 550 is thus lured into accessing the decoy 512, which is overseen by the hypervisor operating system 510 running on the hardware-based, virtualized operating system module 506. Attacker activity 550 may then initiate custom or known exploits for the observed operating system. When the attacker activity 550 proceeds to interact with the decoy 512, the attacker provides the decoy 512 with the data used to obtain control of the decoy 512.);
As per Claim 7, Capalik in view of Gukal discloses the computer-implemented method according to claim 1, further comprising:
upon receiving, at the first intrusion detection instance the intrusion event trace: monitoring one or more attributes of a device hosting the first decoy instance, determining at least one reaction based on the monitoring of the device, and communicating the reaction to the first decoy instance (Capalik, Para.10, monitors connections to the operating system as well as activity on the operating system and activity on services running on the operating system. When an attacker connects to a port, the sentinel kernel driver captures the data coming through the socket. Generally all relevant data coming through the socket is captured. In most cases this means whatever data is received as part of an incoming attack is captured by the sentinel driver. Captured data is sent as a slew of common UDP packets to the back end processing module over the fabric network connection separate from the vulnerable front-end modules. In this manner, there is no way for the intruder to know that his or her communications with the operating system are being analyzed, Para.24, The instigator of attack 10 is thus lured into accessing decoy 100, which includes monitor/intercept module 30, and running custom or known exploits for the observed operating system. When attacker activity proceeds to interact with decoy 100, the attacker provides decoy 100 with the data used to obtain control of decoy 100, which is recorded and analyzed without knowledge of the attacker, Para.25, The instigator of attack 10 is thus lured into accessing decoy 100, which includes monitor/intercept module 30, and running custom or known exploits for the observed operating system. When attacker activity proceeds to interact with decoy 100, the attacker provides decoy 100 with the data used to obtain control of decoy 100, which is recorded and analyzed without knowledge of the attacker.).
As per Claim 8, Capalik in view of Gukal discloses the computer-implemented method according to claim 7, further comprising:
detecting, at a second decoy instance hosted by the device (Capalik, Para.15, a system and method for analyzing unauthorized intrusion into a computer network. Access is allowed through one or more open ports to one or more virtualized decoy operating systems running on a hypervisor operating system hosted on a decoy network device), a second intrusion event generated by an intruding instance that is not hosted by the device (Capalik, Para.15, A network attack on the virtualized operating system is then intercepted by a virtual-machine-based rootkit module running on the hypervisor operating system. The attack-identifying information is communicated through a private network interface channel and stored on a database server as forensic data. A signature generation engine uses this forensic data to generate a signature of the attack. An intrusion prevention system then uses the attack signature to identify and prevent subsequent attacks);
generating a second intrusion event trace based on the second detected intrusion event Capalik, Para.48, The introspection module 538 examines the memory of virtualized decoy operating systems 512 by means of three functional components: a code region selector, a trace instrumentor, and a trace analyzer… The instrumentor copies the memory traces of interest identified by the code selector and then profiles and instruments them. The trace analyzer takes the instrumented traces and uses them to replay the memory behavior of the decoy operating system 512.);
transmitting the second intrusion event trace from the second decoy instance to the first intrusion detection instance that is communicably coupled to the device (Capalik, Para.55, processing starts at Step 200 and waits for activity from the introspection module 538 at Step 43. At Step 44, the processing module 508 generates a report of the attack that includes attack-identifying information (See FIG. 3). This report is for review and use by a system administrator responsible for the security of a protected network 504… Any attack signature generated is sent to the IDS/IPS signature library 534 at Step 56, and processing continues at Step 43.); and
reconfiguring the first and/or second decoy instances based on a time relationship between first and second intrusion events (Capalik, Para.56, the report of the attack is written and then displayed via a visualization interface 532 and can include information about which sockets were accessed by the attack 550, what happened at a particular socket, the keystrokes entered or data transferred, what files were transferred, how the attack 550 was run, what happened on the virtualized operating system module 506, and how the virtualized decoy operating systems 512 running on the hypervisor operating system 510 and any related network services were affected. In some embodiments, the visualization interface 532 is AJAX- and/or FLASH-based. The report may also include information on the location of the instigator of the attack 550 or the service provider used for the attack. Graphical representations of key information and interactive mapping of attack locales by region or country may also be included in the report. The visualization interface may also be used to analyze, configure, and automate the system's response to attack activity 550 on timescales ranging from near-immediate to several minutes from the initiation of an attack.), and/or based on a functional comparison of the first and second intrusion events (Capalik, Para.24, an FTP port access for Windows.RTM. may return a particular character sequence that is different than an FTP response for LINUX.RTM.. An FTP access to a Windows.RTM. port for example may return a response ">ftp: connect: Connection refused". This characters sequence may be slightly different on LINUX.RTM. and hence allows the intruder to determine what type of operating system is at a particular network address. In addition, different versions of Windows.RTM. may respond with slightly different character sequences which allows the intruder to determine the specific version of the operating system or to determine a possible range of versions for the responding operating system. The instigator of attack 10 is thus lured into accessing decoy 100, which includes monitor/intercept module 30, and running custom or known exploits for the observed operating system. When attacker activity proceeds to interact with decoy 100, the attacker provides decoy 100 with the data used to obtain control of decoy 100, which is recorded and analyzed without knowledge of the attacker.).
As per Claim 9, Capalik in view of Gukal discloses the computer-implemented method according to claim 1, wherein the intrusion event includes one or any combination of: i) a scan a network ports of the first decoy instance (Capalik, Para.44, As in a typical attack, the attacker activity 550 scans for an open port, ostensibly in an attempt to make a network connection and then access one or more computing devices on the protected computer network 504. When the attacker activity 550 scans for open ports at non-existent network addresses, however, the attacker is presented with a virtualized decoy operating system 512 instead), ii) an attempt to load an application hosted by the first decoy instance, iii) at attempt to enter a predetermined command, or a predetermined combination of commands into an application hosted by the first decoy device, iv) an attempt to download data from the first decoy instance (Capalik, Para.44, Para.57, the attack-identifying information is analyzed for known attack patterns as well as non-standard patterns, such as repeating binary patterns, keystroke patterns, downloaded daemons, or errors (such as buffer overflow attempts, malicious payloads attempting to execute arbitrary code on the system, memory overwriting attempts, stack attacks, and heap attacks).), v) an attempt to write a data payload to a predetermined memory location in the first decoy instance, vi) an attempt to operate an IO device from the first decoy instance, vii) an attempt to communicate with a predetermined network address or URL from the first decoy instance.
As per Claim 13, Capalik in view of Gukal discloses the system according to claim 12, further comprising: a further device including a communications interface, a processor, and a memory (Capalik, Para.39, computing devices may include one or more processors, input/output devices, communication circuitry, power sources, memory (both physical, e.g., RAM, and disks, e.g., hard disk drives), and any other physical hardware necessary for hosting and running the aforementioned modules. In some embodiments, the modules 506 and 508 are as present in physical memory once the system has been booted and is operational.); wherein the further device is configured to communicate a further intrusion event trace to the intrusion detection system via the communications network (Capalik, Para.15, a system and method for analyzing unauthorized intrusion into a computer network. Access is allowed through one or more open ports to one or more virtualized decoy operating systems running on a hypervisor operating system hosted on a decoy network device. This may be done by opening a port on one of the virtualized decoy operating systems. A network attack on the virtualized operating system is then intercepted by a virtual-machine-based rootkit module running on the hypervisor operating system. The attack-identifying information is communicated through a private network interface channel and stored on a database server as forensic data. A signature generation engine uses this forensic data to generate a signature of the attack. An intrusion prevention system then uses the attack signature to identify and prevent subsequent attacks); and wherein the intrusion detection system is configured to transmit commands to reconfigure one or both of the device and the further device based on a time relationship between first and second intrusion events, and/or based on a functional comparison of the first and second intrusion events (Para.13, The processing module is used to generate an attack signature by analyzing all the data passed through the socket. The signature is generated by analyzing the attack payload including the keystrokes or transferred bytes and any files uploaded to the client operating system of an ASCII or binary nature. The files uploaded are assumed to be of a malicious nature created to deliver a malicious payload in the form of a compiled program or an interpreted script. In the event that no malicious files are uploaded to the operating system, the signature generation engine analyzes all the keystrokes or bytes delivered through the socket and creates a pattern signature which when applied to an IDS or IPS system, enables the IDS or IPS systems to detect the attack if repeated on production systems. Once generated, the attack signatures can be viewed by a system administrator to determine the appropriate course of action. The system administrator can instruct the signature to be uploaded to the intrusion detection system (IDS) or intrusion prevention system (IPS) for the protected network where it is added to the IDS's or IPS's library of signatures to protect production systems. In one or more embodiments of the invention, the signature may be uploaded or saved in a third party system that maintains all known exploits. In this manner, other systems may be notified through secure channels of an impending threat.).
Claims 10 is rejected under 35 U.S.C. 103 as being unpatentable over Capalik (U.S. patent Application: 20150074811) in view of Gukal et al., “hereinafter Gukal” (U.S. patent Application: 20170353491) and further in view if HAREL et al., “hereinafter HAREL” (U.S. patent Application: 2017035349120230275877).
As per Claim 10, Capalik in view of Gukal discloses the computer-implemented method according to claim 7,
However Capalik in view of Gukal does not disclose the device is an electronic control unit in a vehicle.
HAREL discloses the device is an electronic control unit in a vehicle (HAREL, Para.11, the cyber security capabilities of a device controllers such as ECUs to be protected against cyber security attacks (sometimes referred to as cybersecurity hardening), even before those controllers are fully finalized. Beginning with the development specifications for a controller, so-called “trap images” are made accessible on the public Internet. These trap image are designed with libraries that are specified for use in an as-of-yet undeveloped controller. Data communications with the trap images are monitored to identify possible malicious attacks, and those attacks may then be monitored. Sometimes, such a setup is referred to as a “honeypot.”).
It would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings as in Capalik, Gukal with the teachings as in HAREL. The motivation for describing a technological solution that can be used to strengthen the cyber security capabilities of a device controllers such as ECUs to be protected against cyber security attacks (sometimes referred to as cybersecurity hardening), even before those controllers are fully finalized. Beginning with the development specifications for a controller, so-called “trap images” are made accessible on the public Internet. These trap image are designed with libraries that are specified for use in an as-of-yet undeveloped controller. Data communications with the trap images are monitored to identify possible malicious attacks, and those attacks may then be monitored. Sometimes, such a setup is referred to as a “honeypot.” (HAREL, Para.11).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to NORMIN ABEDIN whose telephone number is (571)270-5970. The examiner can normally be reached Monday to Friday from 10 am to 6 pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Vivek Srivastava can be reached at 5712727304. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/NORMIN ABEDIN/Primary Examiner, Art Unit 2449