DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This office action is in response to the application filed on 06/22/2023.
Claims 1-20 are currently pending in this application.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 06/22/2023 was filed. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Examiner’s Note
Applicants are suggested to include information from figure 5 with related text into the claims to provide a better condition for an allowance.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(B) CONCLUSION. —The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
Claims 1-20 are rejected under 35 U.S.C. 112(b) as being indefinite for failing to particularly point out and distinctly claim the subject matter which applicant regards as the invention.
Claims 1 (claims 8 and 15 include similar limitations) recites:
“… computer readable code stored collectively in the one or more computer readable storage media … to cause … to perform at lease … identifying … mapping … automatically generating … executing …”, however, it is not clear whether the computer readable code is stored as a group (e.g., collectively) to perform different functions (e.g., identifying, mapping, generating, etc.);
“… identifying a new incident and TTP that specify the new incident …”, however, it is not clear (1) whether the information of the new incident has already been defined in the TTP or not (e.g., the new incident is not new to the TTP, etc.); (2) whether the new incident is occurred in the claimed computer system or not; (3) how to define a (new) incident (e.g., not storing information, not executing the code, etc.) – it is not clear to define a boundary of the limitations/components;
“… mapping the TTP to actions included in a TTP-based response matrix, wherein the TTP-based response matrix associates a plurality of actions with respective TTPs that specify security incidents, and wherein the plurality of actions is required to address the security incidents …”, however, it is not clear whether the security incidents have any relationship with the new incident defined before or not (for examining purpose different terms, such as a security incident, a new incident, etc., are interpreted as not related) – it is not clear to define a boundary of the limitations/components;
“… mapping the actions to technologies included in a defense capabilities matrix … technologies deployed in a network by an organization with a plurality of countermeasures …”, however, it is not clear (1) whether the organization of the network has any relationship with the claimed computer system; (2) how to define the technologies defined in the network (e.g., Wi-Fi technology, routing technology, etc.) – omitting necessary step/component which causes the limitations unclear;
“… automatically generating a playbook that specifies one or more countermeasures to counter the new incident …countermeasures being based on the actions, the technologies… executing the one or more countermeasures by using the defense capabilities matrix”, however, it is not clear (1) whether “one or more countermeasures” has any relationship with “a plurality of countermeasures” include before or not; (2) whether “a playbook (interpreted as a book or guide that contains a set of strategies, rules or plans)” is defined as naming (or specifying) of the countermeasures or not; (3) whether the execution of the countermeasures requires the defense capabilities matrix or not (note: the countermeasures is based on the actions, the mapped technologies, the TTP, etc.).
Claims 2-7, 9-14 and 16-20 depend from the claim 1, 8 or 15, and are analyzed and rejected accordingly.
Claims 4, 11 and 18 recite “… providing the SOAR platform with a knowledge of: defenses the SOAR platform can deploy automatically and without human intervention in response to a cyber attack; incident types that can be defended against based on a maturity scale; and playbooks that can be automatically built and integrated into, and that are aligned to the TTP-based response matrix”, however, it is not clear (1) what “defenses the SOAR platform can deploy” means (may be “defenses of the SOAR can deploy …); (2) whether the functions (e.g., defending, building, etc.) after the term “can be” is actually limiting or not (e.g., the intended use); (3) whether “maturity scale” is defined for the claimed computer system or not; (4) whether the playbooks have any relationship with the generated playbook of the claim 1, 8 or 15 – or it is not clear to define a boundary of limitations; (5) whether the playbooks are automatically built and integrated into the TTP-based response matrix or not.
Claims 7 and 14 recite “… generating a playbook generates a playbook dynamically, and wherein the executing the countermeasures does not use or require a static playbook”, however, it is not clear (1) whether “a playbook” included in several locations (see also claim 1 or 8) are the same or not – suggested to use a first/second/third playbook if they are not the same; (2) whether “a static playbook” is the same as the dynamically generated playbook before or not – it is not clear to define a boundary of the limitation/terms.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1-20 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Kannan et al. (US 12,107,869 B1).
As per claim 1, Kannan teaches a computer system comprising: one or more computer processors; one or more computer readable storage media; and computer readable code stored collectively in the one or more computer readable storage media, with the computer readable code including data and instructions to cause the one or more computer processors to perform [see figs. 1, 2] at least the following operations:
identifying a new incident and the tactics, techniques, and procedures (TTP) that specify the new incident; mapping the TTP to actions included in a TTP-based response matrix, wherein the TTP-based response matrix associates a plurality of actions with respective TTPs that specify security incidents, and wherein the plurality of actions is required to address the security incidents [figs. 1, 3; tables 1, 2; col. 2, lines 28-44; col. 3, lines 25-35; col. 8, lines 10-22; col. 11, lines 11-33 of Kannan teaches identifying a new incident (e.g., receiving detections, alerts and associated metadata) and the tactics, techniques, and procedures (TTP) (e.g., the threat component in the form of TTP) that specify the new incident; mapping the TTP to actions included in a TTP-based response matrix (e.g., the specific TTP used by the identified threats, type of threats, and threat groups, etc.), wherein the TTP-based response matrix associates a plurality of actions with respective TTPs that specify security incidents, and wherein the plurality of actions is required to address the security incidents];
mapping the actions to technologies included in a defense capabilities matrix, wherein the defense capabilities matrix associates a plurality of technologies deployed in a network by an organization with a plurality of countermeasures [tables 3-5; col. 3, lines 36-45; col. 11, lines 53-67; col. 15, lines 55-67; col. 17, lines 18-23 of Kannan teaches mapping the actions to technologies (e.g., the identified categories) included in a defense capabilities matrix (see table 5), wherein the defense capabilities matrix associates a plurality of technologies deployed in a network by an organization (e.g., list of tools the enterprise has, etc.) with a plurality of countermeasures (e.g., the some level of mitigation, etc.];
automatically generating a playbook that specifies one or more countermeasures to counter the new incident, the one or more countermeasures being based on the actions, the technologies to which the actions are mapped, and the TTP mapped to the actions; and executing the one or more countermeasures by using the defense capabilities matrix [col. 18, lines 11-43; col. 19, lines 66-67; col. 20, lines 14-60 of Kannan teaches automatically generating a playbook (e.g., the detailed recommendations) that specifies one or more countermeasures (e.g., the threat mitigation actions) to counter the new incident (e.g., received detections, alerts and associated metadata), the one or more countermeasures being based on the actions, the technologies to which the actions are mapped, and the TTP mapped to the actions; and executing the one or more countermeasures (e.g., the threat mitigation actions) by using the defense capabilities matrix (see table 5)].
As per claim 2, Kannan teaches the computer system of claim 1.
Kannan further teaches wherein the computer readable code including the data and the instructions causes the one or more computer processors to perform the following further operations:
building a contextual understanding of the network and capabilities of the network by identifying assets available on the network by using an asset database in a side-channel repository or a Security Information and Event Management (SIEM) platform [figs. 1, 3; table 3; col. 1, lines 48-57; col. 4, lines 35-51; col. 12, lines 16-27 of Kannan teaches building a contextual understanding of the network and capabilities of the network by identifying assets available on the network by using an asset database (e.g., to determine a prioritization of threats to which the enterprise is especially vulnerable, the nature of enterprise itself is analyzed) in a side-channel repository or a Security Information and Event Management (SIEM) platform]; and
in response to the building the contextual understanding, automatically extending defense capabilities of a Security Orchestration, Automation, and Response (SOAR) platform [table 4; col. 16, lines 9-17; col. 17, lines 18-40 of Kannan teaches in response to the building the contextual understanding, automatically extending defense capabilities of a Security Orchestration, Automation, and Response (SOAR) platform].
As per claim 3, Kannan teaches the computer system of claim 1.
Kannan further teaches identifying capabilities provided by the plurality of technologies; and based on the identified capabilities, providing a Security Orchestration, Automation, and Response (SOAR) platform with a knowledge of (i) an antivirus platform and scanning capabilities provided by the antivirus platform, (ii) an endpoint detection and response (EDR) platform, and capabilities provided by the EDR platform, including blocking files from executing, and isolating assets from accessing other assets on the network, (iii) a firewall and capabilities provided by the firewall, including blocking connections and ports to the internet or different segments of the network, and (iv) an Active Directory and capabilities provided by the Active Directory, including disabling accounts, resetting passwords, and deploying updated defensive Group Policy Object (GPO) policies [fig. 1; tables 4, 5; col. 2, lines 28-44; col. 8, lines 10-34; col. 16, lines 9-17; col. 17, lines 18-40 of Kannan teaches identifying capabilities provided by the plurality of technologies; and based on the identified capabilities, providing a Security Orchestration, Automation, and Response (SOAR) platform with a knowledge of (i) an antivirus platform and scanning capabilities provided by the antivirus platform (see table 5), (ii) an endpoint detection and response (EDR) platform, and capabilities provided by the EDR platform, including blocking files from executing, and isolating assets from accessing other assets on the network (e.g., terminating active malicious processes, etc.), (iii) a firewall and capabilities provided by the firewall, including blocking connections and ports to the internet or different segments of the network (e.g., changing firewall setting or fixing vulnerabilities, etc.), and (iv) an Active Directory and capabilities provided by the Active Directory, including disabling accounts, resetting passwords, and deploying updated defensive Group Policy Object (GPO) policies (e.g., updating the detection rules, etc.)].
As per claim 4, Kannan teaches the computer system of claim 1.
Kannan further teaches: overlaying, by a Security Orchestration, Automation, and Response (SOAR) platform, the TTP-based response matrix with the defense capabilities matrix; and based on the overlaying of the TTP-based response matrix with the defense capabilities matrix, providing the SOAR platform with a knowledge of: defenses the SOAR platform can deploy automatically and without human intervention in response to a cyber-attack; incident types that can be defended against based on a maturity scale; and playbooks that can be automatically built and integrated into, and that are aligned to the TTP-based response matrix [fig. 1; tables 4, 5; col. 3, lines 1-19; col. 4, lines 9-34; col. 8, lines 10-34; col. 16, lines 9-17; col. 17, lines 18-40; col. 18, lines 34-67 of Kannan teaches overlaying, by a Security Orchestration, Automation, and Response (SOAR) platform, the TTP-based response matrix with the defense capabilities matrix; and based on the overlaying of the TTP-based response matrix with the defense capabilities matrix, providing the SOAR platform with a knowledge of: defenses the SOAR platform can deploy automatically and without human intervention (e.g., by the SOAR system) in response to a cyber-attack; incident types (e.g., the multiple relevant categories concerning threat, etc.) that can be defended against based on a maturity scale (e.g., the maturity level or the score); and playbooks (e.g., the detailed recommendations) that can be automatically built and integrated into, and that are aligned to the TTP-based response matrix – see also rejections to the claim 1].
As per claim 5, Kannan teaches the computer system of claim 1.
Kannan further teaches aligning, by a Security Orchestration, Automation, and Response (SOAR) platform, a type of the new incident to the TTP-based response matrix; and in response to the aligning the type of the new incident, providing the SOAR platform with a knowledge of workings of the type of the new incident and one or more actions to defend against the type of the new incident [fig. 1; tables 4, 5; col. 3, lines 1-19; col. 4, lines 9-34; col. 8, lines 10-34; col. 16, lines 9-17; col. 17, lines 18-40; col. 18, lines 34-67; col. 20, lines 9-60 of Kannan teaches aligning, by a Security Orchestration, Automation, and Response (SOAR) platform, a type of the new incident to the TTP-based response matrix; and in response to the aligning the type of the new incident (e.g., the multiple relevant categories concerning threat, etc.), providing the SOAR platform with a knowledge of workings of the type of the new incident and one or more actions (e.g., the threat mitigation actions) to defend against the type of the new incident – see also rejections to the claims 1 and 4].
As per claim 6, Kannan teaches the computer system of claim 1.
Kannan further teaches: wherein the automatically generating the playbook includes generating a dynamic playbook using the TTP and based on a contextual understanding of the network provided by the defense capabilities matrix, and wherein the computer readable code including the data and the instructions causes the one or more computer processors to perform the following further operation: performing automated defensive measures to counter the new incident by deploying the dynamic playbook without requiring human intervention [tables 4, 5; col. 1, lines 8-11; col. 3, lines 1-19; col. 4, lines 9-34; col. 8, lines 10-34; col. 16, lines 9-17; col. 17, lines 18-40; col. 18, lines 34-67; col. 20, lines 9-60 of Kannan teaches wherein the automatically generating the playbook (e.g., the detailed recommendations) includes generating a dynamic playbook (e.g., the detailed recommendations) using the TTP and based on a contextual understanding of the network provided by the defense capabilities matrix (see tables 4, 5), and wherein the computer readable code including the data and the instructions causes the one or more computer processors to perform the following further operation: performing automated defensive measures to counter the new incident (e.g., received detections, alerts and associated metadata or the current threat landscape, etc.) by deploying the dynamic playbook without requiring human intervention (e.g., automated quantified assessment, recommendations and mitigation actions, etc.) – see also rejections to the claims 1 and 2].
As per claim 7, Kannan teaches the computer system of claim 1.
Kannan further teaches wherein the automatically generating a playbook generates a playbook dynamically, and wherein the executing the countermeasures does not use or require a static playbook [figs. 1, 3; col. 1, lines 8-11; col. 3, lines 1-45; col. 20, lines 9-60 of Kannan teaches wherein the automatically generating a playbook generates a playbook dynamically (e.g., the recommendations for the dynamic threat landscape, etc.), and wherein the executing the countermeasures (e.g., the threat mitigation actions) does not use or require a static playbook (e.g., automatically processing quantified assessment, recommendations and mitigation actions, etc.) – see also rejections to the claim 1].
Claims 8-14 are computer program product claims that correspond to the system claims 1-7, and are analyzed and rejected accordingly.
Claims 15-20 are method claims that correspond to the system claims 1-6, and are analyzed and rejected accordingly.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MAUNG T LWIN whose telephone number is (571)270-7845. The examiner can normally be reached on Monday - Friday 10:00 am - 6:00 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, Farid Homayounmehr can be reached on 571-272-3739. 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.
/MAUNG T LWIN/Primary Examiner, Art Unit 2495
Prosecution Insights