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
The instant application having Application No.18/691,925 is presented for examination by
the examiner. Claims 1, 10 and 19 are amended. Claims 2-3 and 11-12 have been cancelled. Claims 1, 4-10 and 13-19 have been examined.
Response to Arguments
The previous rejection under 35 U.S.C. §112 and Double Patenting have been removed with the amendment claim limitations and the filling of a Terminal Disclaimer.
Applicant’s arguments with respect to claim(s) 1, 10 and 19 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
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, 4, 7-10, 13 and 16-19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Santos (US 2021/0203673 A1), in further view of Lotem (US20130312101A1).
Regarding Claim 1
Santos discloses:
A cyber security system, the cyber security system comprising a processing circuitry configured to:
obtain: (a) an attack-vector scenario, the attack-vector scenario comprising a sequence of cyber tactics, each of the cyber tactics being associated with one or more respective cyber techniques which are possible manifestations of the corresponding cyber tactic in the context of the attack-vector scenario (Santos ¶39, 133–139, 148–149: discloses scenario-based leveraging of previously defined attack scenarios, in which new alerts are attached to those scenarios if relevant. It further teaches pattern matching for complex multi-event patterns including cyber kill chain and MITRE ATT&CK TTPs. Event chains are described as sequences of alerts/events linked over time across entities, and pattern matching engines access input pattern files (e.g., JSON) with defined event sequences, which are then executed against live data. This teaches “obtaining an attack-vector scenario” comprising a sequence of tactics (kill chain/ATT&CK), each tactic tied to specific techniques (e.g., login attempts, insecure protocol usage, reconfiguration events).), each cyber technique is associated with a corresponding event type of a plurality of event types that can occur on one or more entities of an organizational network, wherein occurrence of an actual event of the respective event type indicates implementation of the respective cyber technique (Santos ¶118, 126, 133–139, 154: discloses that actual events (alerts, logs, changes) are classified into event types such as CVE exploitation, malware, weak password usage, and authentication anomalies. The system matches these event types to technique definitions in kill chain or ATT&CK patterns. Thus, the occurrence of an actual event of a given type (e.g., Telnet use, login attempt) is treated as the implementation of the corresponding cyber technique in the attack-vector scenario, and event chaining/pattern matching recognizes the technique as part of the scenario sequence.), and (b) information about actual events that occurred on the one or more entities of the organizational network, wherein each of the actual events is associated with a respective actual event type (Santos ¶113, 118, 126: discloses that the system collects information about actual events (alerts, network logs, host change logs) that occur on various network entities (e.g., laptops, servers, IoT/OT devices, accounts, users). Each event is explicitly classified into an event type such as CVE exploitation, malware, weak password usage, DNS queries, authentication anomalies, or operational misconfiguration. The taxonomy is encoded in event_type_id values, so that each actual event is linked to a respective event type.);
identify, based on the information, the cyber techniques that occurred on the organizational network by matching the actual event types with the event types associated with the cyber techniques, giving rise to implemented cyber techniques (Santos ¶113, 118, 126, 133–134, 152–154: teaches that the system first determines actual events (alerts, logs, host changes) and classifies them into event types (e.g., CVE exploitation, weak password usage, DNS queries, authentication anomalies). These event types are then used in event chaining and pattern matching. Santos explains that cyber techniques are represented in kill chain and MITRE ATT&CK patterns, which encode expected event types in an attack-vector scenario. The system then matches actual event types with the event types defined in these cyber techniques (e.g., Telnet protocol use, login attempts, PLC reconfiguration), thereby identifying which techniques have actually been implemented on the network.); and
alert a user of the cyber security system of a potential cyber-attack upon determining that alert requirements being met, the alert requirements including that: (a) each of the cyber tactics forming the attack vector scenario, is associated with at least one of the implemented cyber techniques (Santos ¶49–51, 115–116, 133– 134, 179: discloses that the system correlates and aggregates events into higher-level issues, where each issue represents a collection of related alerts/events across entities. Events can include process reconfigurations, insecure Telnet protocol usage, malware infections, and anomalous communications (¶49–51). The correlation component and clustering group alerts of different types into meaningful attack stages (¶115–116), while event chaining builds an ordered sequence of events across entities (¶133–134), analogous to the sequence of tactics in an attack-vector scenario. An alert is then raised to the user when these correlation and chaining requirements are satisfied, e.g., “Embodiments may generate an event or alert that an attack is going on and optionally that it is a possible Mirai attack.” (¶179). Thus, the system alerts a user when each tactic in the scenario is associated with at least one implemented cyber technique evidenced by correlated events.), (b) each pair of implemented cyber techniques associated with a pair of subsequent cyber tactics is associated with a respective common property, the common property comprising at least one of: a time dimension, a location dimension, or a cyber tool dimension (Santos ¶51, 119, 125-129, 133-134: teaches that implemented cyber techniques associated with subsequent cyber tactics are correlated and chained using shared attributes of events and entities. Specifically, the time dimension, Santos teaches timestamp similarity functions where two events are considered related if their timestamps fall within a defined granularity parameter (¶125), thereby linking pairs of implemented techniques across subsequent tactics through temporal proximity. Regarding the location dimension, Santo’s event chaining constructs an ordered sequence of events in which the destination entity of one event becomes the source entity of the next, linking subsequent techniques through their shared host. This is further illustrated by the Telnet attack scenario, where protocol alerts are correlated across entities to show the spread of an attack and pairwise distance clustering links alerts and host using common attributes.).
Santos teaches a cybersecurity system that correlates and chains large volumes of network events into attack scenarios using kill chain patterns. However, they do not disclose the following limitation “(c) at least two of the implemented cyber techniques meet a validation rule associated with the attack-vector scenario, the validation rule validating at least a part of the attack-vector scenario based on one or more properties of each of the at least two implemented cyber techniques.” However, Lotem discloses a security event management system that performs attack simulation on a network model and uses the results to generate validation rules associated with the attack scenario (Lotem ¶54: discloses that rules are automatically generated from attack simulation knowledge and are specific to the predefined attack scenario, including rules that correlate between events indicating exploitation of an attack step and events indicating success or continuation of that attack step, thereby requiring at least two implemented technique to satisfy the scenario derived rule before a security event is confirmed), the validation rule validating at least a part of the attack vector scenario based on one or more properties of each of the at least two implemented cyber techniques (Lotem ¶55, 97-100: discloses that the generated rules are associated with confidence and priority based on parameters of the attack steps they identify, which are properties of each of the implemented cyber techniques being validated against the scenario derived rules.).
Regarding Claim 4
Santos discloses:
The system of claim 1, wherein the information is obtained periodically or continuously and wherein the identify and the alert are performed periodically or continuously while maintaining previously identified implemented cyber techniques (Santos teaches that alerts are not triggered on a single event but require multiple correlated techniques/events to satisfy a rule. Events are aggregated if they share features such as event type, source, destination, or protocol (¶59–60). For example, Telnet-related alerts are grouped to show the spread of an attack (¶51). The system uses clustering and pattern-matching to merge alerts into an “issue,” validating that the correlated events form part of a known attack pattern (¶49, 121–123). Controller reconfiguration patterns are explicitly matched by requiring multiple events from the same host or protocol (¶150–151). This ensures that at least two techniques meet validation rules before the system raises an alert).
Regarding Claim 7
Santos discloses:
The system of claim 1, wherein the actual events include at least one normal event that is not identified as abnormal (Santos ¶118 teaches that events are classified as either security events (abnormal) or operational events (normal, e.g., network communication problems, misconfiguration). This shows the system processes both normal and abnormal events, so at least one normal event is included in the actual events.).
Regarding Claim 8
Santos discloses:
The system of claim 1, wherein at least some of the information is obtained by an agent installed on a given entity of the entities (Santos ¶92: teaches that a device can include agent 140, which is installed on the entity and configured to gather information such as OS version, patch level, services, open ports, MAC address, and logs, and send that information to the network monitoring device.).
Regarding Claim 9
Santos discloses:
The system of claim 1, wherein at least some of the information is retrieved by proactively querying a given entity of the entities (Santos ¶90, 105 teaches that the monitoring device can query an entity directly (via API, CLI, web interface, SNMP) and can perform an active scan by sending requests to the entity to retrieve information.).
Regarding Claim 10
Claim 10 is directed to a method corresponding to the processor-implemented system in claim 1. Claim 10 is similar in scope to claim 1 and is therefore rejected under similar rationale.
Regarding Claim 13
Claim 13 is directed to a method corresponding to the processor-implemented system in claim 4. Claim 13 is similar in scope to claim 4 and is therefore rejected under similar rationale.
Regarding Claim 16
Claim 16 is directed to a method corresponding to the processor-implemented system in claim 7. Claim 16 is similar in scope to claim 7 and is therefore rejected under similar rationale.
Regarding Claim 17
Claim 17 is directed to a method corresponding to the processor-implemented system in claim 8. Claim 17 is similar in scope to claim 8 and is therefore rejected under similar rationale.
Regarding Claim 18
Claim 18 is directed to a method corresponding to the processor-implemented system in claim 9. Claim 18 is similar in scope to claim 9 and is therefore rejected under similar rationale.
Regarding Claim 19
Claim 19 is directed to a computer readable program code corresponding to the processor-implemented system in claim 1. Claim 19 is similar in scope to claim 1 and is therefore rejected under similar rationale.
Claims 5-6 and 14-15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Santos (US 2021/0203673 A1), in view of Lotem (US 20130312101 A1) as applied to claims 1 and 10 above, and in further view of EZRA (US 20180069876 A1).
Regarding Claim 5
Santos and Lotem combined teach a cybersecurity system that correlates and chains large volumes of network events into attack scenarios using kill chain patterns. However, they do not disclose the following limitation “wherein the processing circuitry is further configured to: predict, based on: (a) the attack-vector scenario, (b) the implemented cyber techniques, and (c) the previously identified implemented cyber techniques, a next step cyber tactic of the cyber tactics; and perform a prevention action to prevent the next step cyber tactic.”
However, in an analogous art, EZRA discloses a cyber techniques system/method that includes:
The system of claim 4, wherein the processing circuitry is further configured to:
predict, based on: (a) the attack-vector scenario (EZRA (¶[0008]–[0009], ¶[0015]–[0016]): teaches using sequences of actions across attack stages (the attack-vector scenario) as the basis for predicting potential cyber-attacks.), (b) the implemented cyber techniques (EZRA (¶[0006], ¶[0029]): teaches that actual security events generated by devices represent real attacks or suspicious behavior, corresponding to the implemented cyber techniques on the network.), and (c) the previously identified implemented cyber techniques, a next step cyber tactic of the cyber tactics (EZRA ¶[0031], ¶[0042], ¶[0053] teaches storing previously identified malicious techniques and using them to predict the next step in the attack chain (cyber tactic).); and
perform a prevention action to prevent the next step cyber tactic (EZRA (¶[0062]): teaches executing mitigation actions such as suspending a host, blacklisting, or changing policies, which are prevention actions to stop the next-step cyber tactic.).
Given the teachings of the EZRA, a person having ordinary skill in the art before the effective filing date of the claimed invention would have recognized the desirability of modifying the teachings of Santos and Lotem by predicting next-step cyber tactics based on attack sequences and executing prevention actions. EZRA discloses that cyber-attacks span a sequence of actions across stages (an attack-vector scenario) such as reconnaissance, lateral movement, and exfiltration, which are modeled and used for prediction (¶¶0008–0009, 0015–0016). EZRA further teaches that actual security events generated by devices (e.g., detections of attacks, breaches, suspicious behavior) correspond to implemented cyber techniques on the organizational network (¶¶0006, 0029). Additionally, EZRA discloses storing previously identified malicious event sequences and attack patterns, and using them to predict subsequent steps in an attack chain (¶¶0031, 0042, 0053). Finally, EZRA teaches executing mitigation actions such as suspending a host, applying a blacklist, or changing policies, which are prevention actions intended to stop the next-step tactic (¶0062).
Regarding Claim 6
Santos and Lotem combined teach a cybersecurity system that correlates and chains large volumes of network events into attack scenarios using kill chain patterns. However, they do not disclose the following limitation “wherein the prevention action is one or more of: (a) report the next step cyber tactic to the user of the cyber security system, (b) simulate the next step cyber tactic, or (c) implement one or more honeypots within one or more entities of the organizational network wherein events associated with the next step cyber tactic can occur.”
However, in an analogous art, EZRA discloses a cyber techniques system/method that includes:
The system of claim 5, wherein the prevention action is one or more of: (a) report the next step cyber tactic to the user of the cyber security system, (b) simulate the next step cyber tactic, or (c) implement one or more honeypots within one or more entities of the organizational network wherein events associated with the next step cyber tactic can occur (EZRA (¶[0062]): teaches generating an alert to the user when a next-step tactic is predicted).
Given the teachings of EZRA, a person having ordinary skill in the art before the effective filing date of the claimed invention would have recognized the desirability of modifying the teachings of Santos and Lotem by reporting the next-step cyber tactic to a user when an attack is predicted. EZRA discloses that, upon identifying a match to an attack pattern, the system computes a risk score and generates an alert as part of the mitigation action (¶0062). This alert communicates the predicted attack to the security operator, which is equivalent to reporting the next-step cyber tactic to the user of the cybersecurity system. It would have been obvious to implement such reporting because providing alerts to human operators is a well understood and predictable way of ensuring that security teams are aware of developing attacks, enabling them to respond appropriately.
Regarding Claim 14
Claim 14 is directed to a method corresponding to the processor-implemented system in claim 5. Claim 14 is similar in scope to claim 5 and is therefore rejected under similar rationale.
Regarding Claim 15
Claim 15 is directed to a method corresponding to the processor-implemented system in claim 6. Claim 15 is similar in scope to claim 6 and is therefore rejected under similar rationale.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SAAD A ABDULLAH whose telephone number is (571) 272-1531. The examiner can normally be reached on Monday - Friday, 8:30am - 5:00pm, EST. If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Lynn Feild can be reached on (571) 272-2092. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/SAAD AHMAD ABDULLAH/Examiner, Art Unit 2431
/LYNN D FEILD/Supervisory Patent Examiner, Art Unit 2431
Prosecution Insights