DETAILED ACTION
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 .
This communication is in response to the amendments filed on 09/22/2025. Claims 1-10, 12-18, and 20 are currently pending in the application.
Response to Arguments
Applicant’s arguments with respect to claims 1, 14, and 20 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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-6, 9-10, 13-18, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over US. PGPUb. No. 20200193022 to Lunsford et al. (hereinafter Lunsford) in view of US. PGPUb No. 20210398001 to Forte et al. (hereinafter Forte).
Regarding claim 1, Lunsford discloses a cyber event response playbook generation system (¶0008, “An aspect is a method for responding to cyber events. The method includes receiving a cyber event; identifying a playbook of tasks, where the playbook constitutes a response to the cyber event,…”) comprising:
a data interface arranged to: i) receive, from a cyber security event and response database,
a plurality of types of cyber security events and corresponding cyber security event response actions associated with each of the types of cyber security events (¶0010, “The system includes a memory and a processor. The processor is configured to execute instructions stored in the memory to receive a cyber event; identify a playbook of tasks, where the playbook constitutes a response to the cyber event, and where a task of the tasks is assignable to a user;…”), (¶0101- ¶0103, FIG. 3, “The intel feed 324 can be an incoming stream of information related to potential or current threats (i.e., cyber events) that the system 302 is managing or is configured to identify and manage. As such, in an implementation, the system 302 may be configured to receive intelligence items from the intel feed 324…A cyber event related to an email system has been identified and a playbook (as further described below) is being executed to respond to (e.g., resolve, mitigate, etc.) the cyber event. In the process of carrying out the response (e.g., executing the tasks of the playbook) to the cyber event,..”), (¶0104- ¶0107, FIG. 3, “the SIEM 326 system can programmatically create (such as via an API of the system 302) an incident in the system 302. In an example, the SIEM 326 can specify the name of a playbook and/or other values for attributes of the incident. The programmatically created incident can be accessed and worked on (such as by completing tasks) by users of the system 302. In another example, a programmatically created incident by the SIEM 326 can cause the system 302 to automatically create a request (e.g., a ticket) in the CMDB 320, the change management system 328, or some system… the system 302 can query the CMDB 320 to determine whether the database is configured for encryption. This is so because a control may be that “personally identifiable information must be encrypted at rest…If the system 302 cannot determine whether the database is encrypted, and if the IP address is outside the range of IPs of the instant enterprise, then the system 302 can determine that unencrypted PII data was moved outside the instant enterprise in violation of general data protection regulation (GDPR). As such, the system 302 can initiate an incidence response, as further described below”, wherein the configuration management database (CMDB) 320 is interpreted as the claimed cyber security event and response database), (¶0121, “…an event (a trigger, a ticket, etc.) may be received from the CMDB 320 such that the event causes the common incident 904 to be initiated (e.g., instantiated). As such, the cyber event can be received from at least one of a configuration management system, a change management system, a records management system, or a security information and event management system.”), (¶0061- ¶0062, “…A playbook can provide a recipe (e.g., a pre-configured or prespecified set of tasks) for responding to specific incident types…The incidents module 312 can be used to manage cyber events. For example, via the incidents module 312, incidents can be created, modified, and resolved. The incidents module 312 can provide mechanisms, such as user interfaces or programmatic interfaces (e.g., APIs) for the creation of incidents. Workflows and states may be associated with different incidents types (for example, based on attribute values of the incidents)…”); and ii) receive, from at least one cyber security event monitor, first cyber security event data, indicating a detected cyber security event (¶0122- ¶0123, “…receiving the cyber event can include receiving, from a configuration management system, asset information for an asset; identifying, using at least one of the asset information or the asset, a violated policy; and identifying the cyber event in response to identifying the violated policy.”); and
a cyber event response playbook generator (¶0011, “The method includes receiving a first document constituting an authority; creating one or more playbooks of tasks based on the first document, a playbook of the one or more playbooks includes tasks, and at least some of the tasks are to be completed in response to a cyber event…”), in communications with the data interface (¶0104, FIG. 3, “ (API of the system 302), arranged to: i) receive the plurality of types of cyber security events and corresponding cyber security event response actions from the data interface (¶0010, “The system includes a memory and a processor. The processor is configured to execute instructions stored in the memory to receive a cyber event; identify a playbook of tasks, where the playbook constitutes a response to the cyber event, and where a task of the tasks is assignable to a user;…”), (¶0101- ¶0103, FIG. 3, “The intel feed 324 can be an incoming stream of information related to potential or current threats (i.e., cyber events) that the system 302 is managing or is configured to identify and manage. As such, in an implementation, the system 302 may be configured to receive intelligence items from the intel feed 324…A cyber event related to an email system has been identified and a playbook (as further described below) is being executed to respond to (e.g., resolve, mitigate, etc.) the cyber event. In the process of carrying out the response (e.g., executing the tasks of the playbook) to the cyber event,..”), (¶0104, FIG. 3, “the SIEM 326 system can programmatically create (such as via an API of the system 302) an incident in the system 302. In an example, the SIEM 326 can specify the name of a playbook and/or other values for attributes of the incident. The programmatically created incident can be accessed and worked on (such as by completing tasks) by users of the system 302. In another example, a programmatically created incident by the SIEM 326 can cause the system 302 to automatically create a request (e.g., a ticket) in the CMDB 320, the change management system 328, or some system”), (¶0061- ¶0062, “…A playbook can provide a recipe (e.g., a pre-configured or prespecified set of tasks) for responding to specific incident types…The incidents module 312 can be used to manage cyber events. For example, via the incidents module 312, incidents can be created, modified, and resolved. The incidents module 312 can provide mechanisms, such as user interfaces or programmatic interfaces (e.g., APIs) for the creation of incidents. Workflows and states may be associated with different incidents types (for example, based on attribute values of the incidents)…”) ii) receive the first cyber security event data from the data interface (¶0122- ¶0123, “…receiving the cyber event can include receiving, from a configuration management system, asset information for an asset; identifying, using at least one of the asset information or the asset, a violated policy; and identifying the cyber event in response to identifying the violated policy.”), (¶0062, “The incidents module 312 can be used to manage cyber events. For example, via the incidents module 312, incidents can be created, modified, and resolved. The incidents module 312 can provide mechanisms, such as user interfaces or programmatic interfaces (e.g., APIs) for the creation of incidents. Workflows and states may be associated with different incidents types (for example, based on attribute values of the incidents)…”), (¶0104, “the SIEM 326 system can programmatically create (such as via an API of the system 302) an incident in the system 302. In an example, the SIEM 326 can specify the name of a playbook and/or other values for attributes of the incident…”), and iii) automatically generate a first cyber event response playbook including one or more response actions based on the received plurality of types of cyber security events and corresponding response actions and the first cyber security event data (¶0102, “A cyber event related to an email system has been identified and a playbook (as further described below) is being executed to respond to (e.g., resolve, mitigate, etc.) the cyber event. In the process of carrying out the response (e.g., executing the tasks of the playbook) to the cyber event, a task may be assigned to a user of the users/groups module 304. The system 302 can automatically identify for the user any intel items (e.g., stories, resolution techniques, mitigation techniques, etc.) from intel feeds related to the cyber event and the email system...”), (¶0096, “…Playbooks and/or tasks can be (e.g., automatically or manually) added, deleted, or changed to provide the contract-required coverage for breach incident responses and reporting for the jurisdiction.”), (¶0116, “The playbooks can be tailored (e.g., created, configured, customized, etc.) to the specific circumstances of the instant enterprise and an incident type. For example, if the instant enterprise is a New York-based enterprise and also serves customers in at least some European Union member states, then a playbook related to data breach can include tasks related to both GDPR and NYDFS. The playbooks can be tailored to the types of events. For example, different tasks may be executed in cases of PII data loss that is due to theft by an employee versus PII data loss that is due to an external hack.”), (¶0124, “… the event received from the CMDB 320 can indicate the assets (e.g., servers, applications, etc.) that experienced (e.g., are affected by) the incident (e.g., the event). Information regarding the affected assets can be used to determine the playbook to be instantiated…”).
a user interface for receiving a user confirmation that the generated first cyber event response playbook is valid to be executed (¶0125, FIG. 11, “…The current user can accept a task if the user current is a member of a user group to which the task is assigned. In an example, to accept a task, the current user can select an accept 1102 menu action associated with the task. Selecting the accept 1102 menu item can cause a confirmation user interface 1104 to be invoked…”), (¶0086, “…, a task-details interface 614, which can be displayed when a user interface control 612 that is associated with the task 602 is initiated, indicates which teams 618 (i.e., user groups) are responsible for performing (e.g., resolving, responding to, executing, carrying out, etc.) the task 602 in response to a cyber event that is of a type that is listed in the attribute 556 of FIG. 5B, affects data that are classified as specified by the attribute 558 of FIG. 5B, is of a type as indicated by the attribute 560 of FIG. 5B,…”), (¶0011, “The method includes receiving a first document constituting an authority; creating one or more playbooks of tasks based on the first document, a playbook of the one or more playbooks includes tasks, and at least some of the tasks are to be completed in response to a cyber event; receiving a second document constituting a revision of the authority; identifying differences between the first document and the second document; and based on the differences, updating at least one of the one or more playbooks of tasks.”).
However, Lunsford does not explicitly disclose the following limitation:
wherein the generated one or more response actions for the first cyber event response playbook are different from the cyber security event response actions for a plurality of types of cyber security events received from the data interface; and
Forte discloses wherein the generated one or more response actions for the first cyber event response playbook are different from the cyber security event response actions for a plurality of types of cyber security events received from the data interface (¶0006, “according to this system for playbook generation, a user of the security incident response platform can respond to a cybersecurity incident by initiating prescriptive procedures that differ from the prescriptive procedures contained in the playbook, and then the cybersecurity incident is recorded in the feature space and the prescriptive procedures actually initiated by the user are automatically tied to the cybersecurity incident, thereby automatically altering subsequent recommendations of playbooks for responding to cybersecurity incidents having features similar or identical to the set of features of the new cybersecurity incident…”), (¶0160, FIGs. 9-11, “… the custom playbook is produced by the playbook generation and parent recommendation system according to the techniques described herein, and the user may choose to use the custom playbook, or use a different playbook, or remove an action to the custom playbook, or add an action to the custom playbook, and the playbook generation and parent recommendation system records the user actions according to the techniques described herein, so to affect future custom playbook recommendations.”), see also ¶0117, and ¶0143,FIG. 8;
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the system of Lunsford to include cyber incident response actions different from the playbook response actions as disclosed by Forte and be motivated in doing so in order to integrate the user’s cyber incident response actions into a playbook response actions to cybersecurity incidents having features similar or identical to the set of features of the new cybersecurity incident (playbook updating).
Regarding claim 2, Lunsford in view of Forte discloses the system of claim 1.
Lunsford further discloses wherein the cyber event response playbook generator sends through the user interface a notification to an operator indicating that the first cyber event response playbook has been generated (¶0010, “The processor is configured to execute instructions stored in the memory to receive a cyber event; identify a playbook of tasks, where the playbook constitutes a response to the cyber event, and where a task of the tasks is assignable to a user; receive, from the user, a completion of the task; receive a proof of completion of the task; and generate an compliance report including the task and the proof of completion.”), (¶0086, “…a task-details interface 614, which can be displayed when a user interface control 612 that is associated with the task 602 is initiated, indicates which teams 618 (i.e., user groups) are responsible for performing (e.g., resolving, responding to, executing, carrying out, etc.) the task 602 in response to a cyber event that is of a type that is listed in the attribute 556 of FIG. 5B, affects data that are classified as specified by the attribute 558 of FIG. 5B, is of a type as indicated by the attribute 560 of FIG. 5B, implicates the country and/or state as indicated by the attributes 562 and 564, respectively, or a combination thereof....”), (¶0127-¶0129, “…At 810, the process 800 can generate a compliance report. The compliance report can include all information available to the process 800 and which pertain to the tasks of the playbook identified for the cyber event. In an example, the compliance report can be or can be a basis for a final compliance report that is mandated to be provided to a regulatory agency…”), (¶0102, “…the relevant item items can be presented to the user in a user interface that is related to the task that is assigned to the user. In an example, a relevant intel item may be presented to the user as a hyperlink, which, when clicked (e.g., selected) by the user, can navigate the user to a full description of the intel item.”).
Regarding claim 3, Lunsford in view of Forte discloses the system of claim 1.
Lunsford further discloses wherein the cyber event response playbook generator, via the user interface, provides a report to an operator including information describing the generated first cyber event response playbook (¶0126, “… In an example, a control associated with a user interface of the task can include a button marked “Completed.” Upon selecting the button, the task can be marked as completed by the process 800...”) (¶0128-¶0129, “At 810, the process 800 can generate a compliance report. The compliance report can include all information available to the process 800 and which pertain to the tasks of the playbook identified for the cyber event. In an example, the compliance report can be or can be a basis for a final compliance report that is mandated to be provided to a regulatory agency. In an example, the compliance report can include the assets that were compromised (if any), the chronology of events related to the incident, the classifications of the affected data, one or more of the tasks of the playbook, the list of users who completed each task, completion timestamps of the tasks, or the associated proofs”).
Regarding claim 4, Lunsford in view of Forte discloses the system of claim 3.
Lunsford further discloses wherein the report includes at least one recommendation regarding a type of cyber security event response action (¶0070, “The attribute 516 can specify the types of incidents (e.g., cyber events) that the NYDFS regulation covers (e.g., is concerned with, inferred to be concerned with, etc.)…”), (¶0112, “…The process 800 can be used to, in the case that a cyber event occurs, respond to (e.g., manage, resolve, communicate about, etc.) as mandated (e.g., required, suggested, recommended, proscribed, etc.) by an authority.”), (¶0128, FIG. 8, step 810, “At 810, the process 800 can generate a compliance report. The compliance report can include all information available to the process 800 and which pertain to the tasks of the playbook identified for the cyber event. In an example, the compliance report can be or can be a basis for a final compliance report that is mandated to be provided to a regulatory agency.”).
Regarding claim 5, Lunsford in view of Forte discloses the system of claim 4.
Lunsford further discloses wherein the type of cyber security event response action includes a type of security application to implement in response to a detected type of cyber security event of the types of cyber security events (¶0103-¶0104, “…SIEM 326 system can programmatically create (such as via an API of the system 302) an incident in the system 302. In an example, the SIEM 326 can specify the name of a playbook and/or other values for attributes of the incident…”), (¶0108, “the system 302 can scan and assess events that are received from the S 326 to determine an updated risk to the instant enterprise of a cyber event. Playbooks and/or tasks can be added, deleted, and/or changed, by one or more components of the system 302, to reflect the updated risk. The system 302 can report changes to risk score of the instant enterprise based on the changes”, wherein a playbook is executed to respond to cyber event, ¶0102, ¶0061, ¶0092).
Regarding claim 6, Lunsford in view of Forte discloses the system of claim 3.
Lunsford further discloses wherein at least one human operator, via the user interface, provides an input confirming that the first cyber event response playbook is valid to execute and the system initiates at least one response on the first cyber event response playbook in response to the confirmation (¶0125, “… to accept a task, the current user can select an accept 1102 menu action associated with the task. Selecting the accept 1102 menu item can cause a confirmation user interface 1104 to be invoked. In the confirmation user interface 1104, the current user can provide an intended start date 1106, an expected planned end date 1108, and an expected budget 1110. to complete the task. The intended start date 1106 can indicate when the current user intends to start work on the task. The expected planned end date 1108 can indicate when the current user expects to complete the task…”), (¶0120, “the cyber event can be received when a user selects a playbook to execute from a list of available playbooks, such as described with respect to FIG. 9. Selecting a playbook can include creating an incident that is pre-configured with a playbook.”, wherein selecting a playbook by the user from a list is an indication that the selected playbook is confirmed and/or validated), (¶0116, “The playbooks can be tailored (e.g., created, configured, customized, etc.) to the specific circumstances of the instant enterprise and an incident type. For example, if the instant enterprise is a New York-based enterprise and also serves customers in at least some European Union member states, then a playbook related to data breach can include tasks related to both GDPR and NYDFS. The playbooks can be tailored to the types of events. For example, different tasks may be executed in cases of PII data loss that is due to theft by an employee versus PII data loss that is due to an external hack.”).
Regarding claim 7, Lunsford in view of Forte discloses the system of claim 6.
Forte further discloses wherein the cyber security event playbook generator stores the valid first cyber event response playbook in a cyber security event playbook database (¶0126, “Some commands from user 704 trigger actions in cybersecurity incident response system 700 that call playbook generation and parent recommendation system 702, which in turn fetches data from database 706 and stores used playbook actions and playbook customizations in database 706…”), see also ¶0143.
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the system of Lunsford to include storing of Playbooks in a database as disclosed by Forte and be motivated in doing so in order to make reference to the database in the generation of future playbooks in response to cybersecurity incidents-Forte ¶0143 in parts.
Regarding claim 9, Lunsford in view of Forte discloses the system of claim 1.
Lunsford further discloses wherein the at least one cyber security event monitor includes at least one of an intrusion detection system (IDS), a network scanner, endpoint protection software, antivirus software, a firewall, and an cyber event management platform (¶0110, “…if a change indicates that a firewall setting on an asset (such as a server) of the instant enterprise is changed such that the asset can receive request from outside the enterprise, then a playbook to remediate that vulnerability can be initiated.”), (¶0108, “the system 302 can scan and assess events that are received from the S 326 to determine an updated risk to the instant enterprise of a cyber event. Playbooks and/or tasks can be added, deleted, and/or changed, by one or more components of the system 302, to reflect the updated risk…”), (¶0050, FIG. 3, “cyber event response management system…”).
Regarding claim 10, Lunsford in view of Forte discloses the system of claim 1.
Lunsford further discloses wherein the one or more response actions of the first cyber event response playbook include actions that augment the cyber security event response actions associated with a detected type of cyber security event of the types of cyber security events received from the cyber security event and response database (¶0098-¶0100, “The system 302 can, and/or can provide facilities or tools to, identify differences between two (e.g., versions of) authorities and update playbooks based on the differences. In an example, updating playbooks can include creating a new playbook from an existing playbook such that the new playbook reflects the differences in the authorities. The updated playbooks can included additions, deletions, or edits to the tasks of the original playbook…”wherein updating the playbooks by additions, deletions, or edits to the task of the original playbook are actions to actions that augment the cyber security event response actions associated with a detected type of cyber security event of the types of cyber security events).
Regarding claim 13, Lunsford in view of Forte discloses the system of claim 1.
Lunsford further discloses wherein the cyber event response playbook generator monitors the performance of the first cyber event response playbook and generates a second cyber event response playbook with improved performance with respect to the first cyber event response playbook (¶0098- ¶0100, “…The system 302 can, and/or can provide facilities or tools to, identify differences between two (e.g., versions of) authorities and update playbooks based on the differences. In an example, updating playbooks can include creating a new playbook from an existing playbook such that the new playbook reflects the differences in the authorities. The updated playbooks can included additions, deletions, or edits to the tasks of the original playbook…”).
Regarding claim 14, Lunsford discloses a method for generating a cyber event response playbook (¶0008, “An aspect is a method for responding to cyber events. The method includes receiving a cyber event; identifying a playbook of tasks, where the playbook constitutes a response to the cyber event,…”) comprising:
receiving, from a cyber security event and response database, a plurality of types of cyber security events and corresponding cyber security event response actions associated with each of the types of cyber security events (¶0010, “The system includes a memory and a processor. The processor is configured to execute instructions stored in the memory to receive a cyber event; identify a playbook of tasks, where the playbook constitutes a response to the cyber event, and where a task of the tasks is assignable to a user;…”), (¶0101- ¶0103, FIG. 3, “The intel feed 324 can be an incoming stream of information related to potential or current threats (i.e., cyber events) that the system 302 is managing or is configured to identify and manage. As such, in an implementation, the system 302 may be configured to receive intelligence items from the intel feed 324…A cyber event related to an email system has been identified and a playbook (as further described below) is being executed to respond to (e.g., resolve, mitigate, etc.) the cyber event. In the process of carrying out the response (e.g., executing the tasks of the playbook) to the cyber event,..”), (¶0104- ¶0107, FIG. 3, “the SIEM 326 system can programmatically create (such as via an API of the system 302) an incident in the system 302. In an example, the SIEM 326 can specify the name of a playbook and/or other values for attributes of the incident. The programmatically created incident can be accessed and worked on (such as by completing tasks) by users of the system 302. In another example, a programmatically created incident by the SIEM 326 can cause the system 302 to automatically create a request (e.g., a ticket) in the CMDB 320, the change management system 328, or some system… the system 302 can query the CMDB 320 to determine whether the database is configured for encryption. This is so because a control may be that “personally identifiable information must be encrypted at rest…If the system 302 cannot determine whether the database is encrypted, and if the IP address is outside the range of IPs of the instant enterprise, then the system 302 can determine that unencrypted PII data was moved outside the instant enterprise in violation of general data protection regulation (GDPR). As such, the system 302 can initiate an incidence response, as further described below”, wherein the configuration management database (CMDB) 320 is interpreted as the claimed cyber security event and response database), (¶0121, “…an event (a trigger, a ticket, etc.) may be received from the CMDB 320 such that the event causes the common incident 904 to be initiated (e.g., instantiated). As such, the cyber event can be received from at least one of a configuration management system, a change management system, a records management system, or a security information and event management system.”), (¶0061- ¶0062, “…A playbook can provide a recipe (e.g., a pre-configured or prespecified set of tasks) for responding to specific incident types…The incidents module 312 can be used to manage cyber events. For example, via the incidents module 312, incidents can be created, modified, and resolved. The incidents module 312 can provide mechanisms, such as user interfaces or programmatic interfaces (e.g., APIs) for the creation of incidents. Workflows and states may be associated with different incidents types (for example, based on attribute values of the incidents)…”);
receiving, from at least one cyber security event monitor, first cyber security event data, indicating a detected cyber security event (¶0122- ¶0123, “…receiving the cyber event can include receiving, from a configuration management system, asset information for an asset; identifying, using at least one of the asset information or the asset, a violated policy (cyber security event data); and identifying the cyber event in response to identifying the violated policy.”); and
automatically generating, at a cyber event response playbook generator, a first cyber event response playbook including one or more response actions based on the received plurality of types of cyber security events and corresponding response actions and the first cyber security event data (¶0102, “A cyber event related to an email system has been identified and a playbook (as further described below) is being executed to respond to (e.g., resolve, mitigate, etc.) the cyber event. In the process of carrying out the response (e.g., executing the tasks of the playbook) to the cyber event, a task may be assigned to a user of the users/groups module 304. The system 302 can automatically identify for the user any intel items (e.g., stories, resolution techniques, mitigation techniques, etc.) from intel feeds related to the cyber event and the email system...”), (¶0096, “…Playbooks and/or tasks can be (e.g., automatically or manually) added, deleted, or changed to provide the contract-required coverage for breach incident responses and reporting for the jurisdiction.”), (¶0116, “The playbooks can be tailored (e.g., created, configured, customized, etc.) to the specific circumstances of the instant enterprise and an incident type. For example, if the instant enterprise is a New York-based enterprise and also serves customers in at least some European Union member states, then a playbook related to data breach can include tasks related to both GDPR and NYDFS. The playbooks can be tailored to the types of events. For example, different tasks may be executed in cases of PII data loss that is due to theft by an employee versus PII data loss that is due to an external hack.”), (¶0124, “… the event received from the CMDB 320 can indicate the assets (e.g., servers, applications, etc.) that experienced (e.g., are affected by) the incident (e.g., the event). Information regarding the affected assets can be used to determine the playbook to be instantiated…”), and receiving a user confirmation that the generated first cyber event response playbook is valid to be executed (¶0125, FIG. 11, “…The current user can accept a task if the user current is a member of a user group to which the task is assigned. In an example, to accept a task, the current user can select an accept 1102 menu action associated with the task. Selecting the accept 1102 menu item can cause a confirmation user interface 1104 to be invoked…”), (¶0086, “…, a task-details interface 614, which can be displayed when a user interface control 612 that is associated with the task 602 is initiated, indicates which teams 618 (i.e., user groups) are responsible for performing (e.g., resolving, responding to, executing, carrying out, etc.) the task 602 in response to a cyber event that is of a type that is listed in the attribute 556 of FIG. 5B, affects data that are classified as specified by the attribute 558 of FIG. 5B, is of a type as indicated by the attribute 560 of FIG. 5B,…”), (¶0011, “The method includes receiving a first document constituting an authority; creating one or more playbooks of tasks based on the first document, a playbook of the one or more playbooks includes tasks, and at least some of the tasks are to be completed in response to a cyber event; receiving a second document constituting a revision of the authority; identifying differences between the first document and the second document; and based on the differences, updating at least one of the one or more playbooks of tasks.”)
However, Lunsford does not explicitly disclose the following limitation:
wherein the generated one or more response actions for the first cyber event response playbook are different from the cyber security event response actions for a plurality of types of cyber security events received from the data interface;
Forte discloses wherein the generated one or more response actions for the first cyber event response playbook are different from the cyber security event response actions for a plurality of types of cyber security events received from the data interface (¶0006, “according to this system for playbook generation, a user of the security incident response platform can respond to a cybersecurity incident by initiating prescriptive procedures that differ from the prescriptive procedures contained in the playbook, and then the cybersecurity incident is recorded in the feature space and the prescriptive procedures actually initiated by the user are automatically tied to the cybersecurity incident, thereby automatically altering subsequent recommendations of playbooks for responding to cybersecurity incidents having features similar or identical to the set of features of the new cybersecurity incident…”), (¶0160, “… the custom playbook is produced by the playbook generation and parent recommendation system according to the techniques described herein, and the user may choose to use the custom playbook, or use a different playbook, or remove an action to the custom playbook, or add an action to the custom playbook, and the playbook generation and parent recommendation system records the user actions according to the techniques described herein, so to affect future custom playbook recommendations.”), see also ¶0117, and ¶0143,FIG. 8;
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the system of Lunsford to include cyber incident response actions different from the playbook response actions as disclosed by Forte and be motivated in doing so in order to integrate the user’s cyber incident response actions into a playbook response actions to cybersecurity incidents having features similar or identical to the set of features of the new cybersecurity incident (playbook updating).
Regarding claim 15, Lunsford in view of Forte discloses the method of claim 14.
Lunsford further discloses comprising at least one of sending a notification to an operator indicating that the first cyber event response playbook has been generated and displaying the notification to an operator indicating that the first cyber event response playbook has been generated (¶0010, “The processor is configured to execute instructions stored in the memory to receive a cyber event; identify a playbook of tasks, where the playbook constitutes a response to the cyber event, and where a task of the tasks is assignable to a user; receive, from the user, a completion of the task; receive a proof of completion of the task; and generate an compliance report including the task and the proof of completion.”), (¶0126, “… In an example, a user interface control associated with a user interface of the task can include a button marked “Completed.” Upon selecting the button, the task can be marked as completed by the process 800...”), (¶0127-¶0129, “…At 810, the process 800 can generate a compliance report. The compliance report can include all information available to the process 800 and which pertain to the tasks of the playbook identified for the cyber event. In an example, the compliance report can be or can be a basis for a final compliance report that is mandated to be provided to a regulatory agency…”), (¶0136, “the system 302 can provide a user interface, such as user interfaces 1300 and 1350 of FIGS. 13A and 13B, respectively. FIG. 13A is an illustration of the user interface 1300 for creating an incident according to implementations of this disclosure. As the user provides values for some attributes of the incident to be created, the process 1200 can populate the tasks that are required to resolve and/or respond to the incident. The user interface 1300 illustrates attributes 1302-1310. The attribute 1302 indicates the incident type(s), the attribute 1304 indicates the data classification(s) of the data impacted by the incident, the attribute 1306 indicates the event type(s) of the incident, the attribute 1308 indicates the country(ies) where the incident has occurred, the attribute 1310 indicates the state(s) where the incident has occurred.”), (¶0086, “…a task-details interface 614, which can be displayed when a user interface control 612 that is associated with the task 602 is initiated, indicates which teams 618 (i.e., user groups) are responsible for performing (e.g., resolving, responding to, executing, carrying out, etc.) the task 602 in response to a cyber event that is of a type that is listed in the attribute 556 of FIG. 5B,…”).
Regarding claim 16, Lunsford in view of Forte discloses the method of claim 14.
Lunsford further discloses comprising displaying a report to an operator including information describing the generated first cyber event response playbook (¶0126, “… In an example, a control associated with a user interface of the task can include a button marked “Completed.” Upon selecting the button, the task can be marked as completed by the process 800...”), (¶0128-¶0129, “At 810, the process 800 can generate a compliance report. The compliance report can include all information available to the process 800 and which pertain to the tasks of the playbook identified for the cyber event. In an example, the compliance report can be or can be a basis for a final compliance report that is mandated to be provided to a regulatory agency. In an example, the compliance report can include the assets that were compromised (if any), the chronology of events related to the incident, the classifications of the affected data, one or more of the tasks of the playbook, the list of users who completed each task, completion timestamps of the tasks, or the associated proofs”).
Regarding claim 17, Lunsford in view of Forte discloses the method of claim 16.
Lunsford further discloses wherein the report includes at least one recommendation regarding a type of cyber security event response action (¶0070, “The attribute 516 can specify the types of incidents (e.g., cyber events) that the NYDFS regulation covers (e.g., is concerned with, inferred to be concerned with, etc.)…”), (¶0112, “…The process 800 can be used to, in the case that a cyber event occurs, respond to (e.g., manage, resolve, communicate about, etc.) as mandated (e.g., required, suggested, recommended, proscribed, etc.) by an authority.”), (¶0128, FIG. 8, step 810, “At 810, the process 800 can generate a compliance report. The compliance report can include all information available to the process 800 and which pertain to the tasks of the playbook identified for the cyber event. In an example, the compliance report can be or can be a basis for a final compliance report that is mandated to be provided to a regulatory agency.”).
Regarding claim 18, Lunsford in view of Forte discloses the method of claim 17.
Lunsford further discloses wherein the type of cyber security event response action includes a type of security application to implement in response to a detected type of cyber security event of the types of cyber security events (¶0103-¶0104, “…SIEM 326 system can programmatically create (such as via an API of the system 302) an incident in the system 302. In an example, the SIEM 326 can specify the name of a playbook and/or other values for attributes of the incident…”), (¶0108, “the system 302 can scan and assess events that are received from the S 326 to determine an updated risk to the instant enterprise of a cyber event. Playbooks and/or tasks can be added, deleted, and/or changed, by one or more components of the system 302, to reflect the updated risk. The system 302 can report changes to risk score of the instant enterprise based on the changes”, wherein a playbook is executed to respond to cyber event, ¶0102, ¶0061, ¶0092).
Regarding claim 20, Lunsford discloses a non-transient computer readable medium containing program instructions for causing a computer (¶0145, “A computer-usable or computer-readable medium can be any device that can, for example, tangibly contain, store, communicate, or transport a program or data structure for use by or in connection with any processor. The medium can be, for example, an electronic, magnetic, optical, electromagnetic, or a semiconductor device. Other suitable mediums are also available. Such computer-usable or computer-readable media can be referred to as non-transitory memory or media, and may include RAM or other volatile memory or storage devices that may change over time…”) to generate a cyber event response playbook (¶0008, “An aspect is a method for responding to cyber events. The method includes receiving a cyber event; identifying a playbook of tasks, where the playbook constitutes a response to the cyber event,…”) comprising the method of:
receiving, from a cyber security event and response database, a plurality of types of cyber security events and corresponding cyber security event response actions associated with each of the types of cyber security events (¶0010, “The system includes a memory and a processor. The processor is configured to execute instructions stored in the memory to receive a cyber event; identify a playbook of tasks, where the playbook constitutes a response to the cyber event, and where a task of the tasks is assignable to a user;…”), (¶0101- ¶0103, FIG. 3, “The intel feed 324 can be an incoming stream of information related to potential or current threats (i.e., cyber events) that the system 302 is managing or is configured to identify and manage. As such, in an implementation, the system 302 may be configured to receive intelligence items from the intel feed 324…A cyber event related to an email system has been identified and a playbook (as further described below) is being executed to respond to (e.g., resolve, mitigate, etc.) the cyber event. In the process of carrying out the response (e.g., executing the tasks of the playbook) to the cyber event,..”), (¶0104- ¶0107, FIG. 3, “the SIEM 326 system can programmatically create (such as via an API of the system 302) an incident in the system 302. In an example, the SIEM 326 can specify the name of a playbook and/or other values for attributes of the incident. The programmatically created incident can be accessed and worked on (such as by completing tasks) by users of the system 302. In another example, a programmatically created incident by the SIEM 326 can cause the system 302 to automatically create a request (e.g., a ticket) in the CMDB 320, the change management system 328, or some system… the system 302 can query the CMDB 320 to determine whether the database is configured for encryption. This is so because a control may be that “personally identifiable information must be encrypted at rest…If the system 302 cannot determine whether the database is encrypted, and if the IP address is outside the range of IPs of the instant enterprise, then the system 302 can determine that unencrypted PII data was moved outside the instant enterprise in violation of general data protection regulation (GDPR). As such, the system 302 can initiate an incidence response, as further described below”, wherein the configuration management database (CMDB) 320 is interpreted as the claimed cyber security event and response database), (¶0121, “…an event (a trigger, a ticket, etc.) may be received from the CMDB 320 such that the event causes the common incident 904 to be initiated (e.g., instantiated). As such, the cyber event can be received from at least one of a configuration management system, a change management system, a records management system, or a security information and event management system.”), (¶0061- ¶0062, “…A playbook can provide a recipe (e.g., a pre-configured or prespecified set of tasks) for responding to specific incident types…The incidents module 312 can be used to manage cyber events. For example, via the incidents module 312, incidents can be created, modified, and resolved. The incidents module 312 can provide mechanisms, such as user interfaces or programmatic interfaces (e.g., APIs) for the creation of incidents. Workflows and states may be associated with different incidents types (for example, based on attribute values of the incidents)…”);
receiving, from at least one cyber security event monitor, first cyber security event data, indicating a detected cyber security event (¶0122- ¶0123, “…receiving the cyber event can include receiving, from a configuration management system, asset information for an asset; identifying, using at least one of the asset information or the asset, a violated policy; and identifying the cyber event in response to identifying the violated policy.”);
and automatically generating, at a cyber event response playbook generator, a first cyber event response playbook including one or more response actions based on the received plurality of types of cyber security events and corresponding response actions and the first cyber security event data (¶0102, “A cyber event related to an email system has been identified and a playbook (as further described below) is being executed to respond to (e.g., resolve, mitigate, etc.) the cyber event. In the process of carrying out the response (e.g., executing the tasks of the playbook) to the cyber event, a task may be assigned to a user of the users/groups module 304. The system 302 can automatically identify for the user any intel items (e.g., stories, resolution techniques, mitigation techniques, etc.) from intel feeds related to the cyber event and the email system...”), (¶0096, “…Playbooks and/or tasks can be (e.g., automatically or manually) added, deleted, or changed to provide the contract-required coverage for breach incident responses and reporting for the jurisdiction.”), (¶0116, “The playbooks can be tailored (e.g., created, configured, customized, etc.) to the specific circumstances of the instant enterprise and an incident type. For example, if the instant enterprise is a New York-based enterprise and also serves customers in at least some European Union member states, then a playbook related to data breach can include tasks related to both GDPR and NYDFS. The playbooks can be tailored to the types of events. For example, different tasks may be executed in cases of PII data loss that is due to theft by an employee versus PII data loss that is due to an external hack.”), (¶0124, “… the event received from the CMDB 320 can indicate the assets (e.g., servers, applications, etc.) that experienced (e.g., are affected by) the incident (e.g., the event). Information regarding the affected assets can be used to determine the playbook to be instantiated…”),
and receiving a user confirmation that the generated first cyber event response playbook is valid to be executed (¶0125, FIG. 11, “…The current user can accept a task if the user current is a member of a user group to which the task is assigned. In an example, to accept a task, the current user can select an accept 1102 menu action associated with the task. Selecting the accept 1102 menu item can cause a confirmation user interface 1104 to be invoked…”), (¶0086, “…, a task-details interface 614, which can be displayed when a user interface control 612 that is associated with the task 602 is initiated, indicates which teams 618 (i.e., user groups) are responsible for performing (e.g., resolving, responding to, executing, carrying out, etc.) the task 602 in response to a cyber event that is of a type that is listed in the attribute 556 of FIG. 5B, affects data that are classified as specified by the attribute 558 of FIG. 5B, is of a type as indicated by the attribute 560 of FIG. 5B,…”), (¶0011, “The method includes receiving a first document constituting an authority; creating one or more playbooks of tasks based on the first document, a playbook of the one or more playbooks includes tasks, and at least some of the tasks are to be completed in response to a cyber event; receiving a second document constituting a revision of the authority; identifying differences between the first document and the second document; and based on the differences, updating at least one of the one or more playbooks of tasks.”)
However, Lunsford does not explicitly disclose the following limitation:
wherein the generated one or more response actions for the first cyber event response playbook are different from the cyber security event response actions for a plurality of types of cyber security events received from the data interface;
Forte discloses wherein the generated one or more response actions for the first cyber event response playbook are different from the cyber security event response actions for a plurality of types of cyber security events received from the data interface (¶0006, “according to this system for playbook generation, a user of the security incident response platform can respond to a cybersecurity incident by initiating prescriptive procedures that differ from the prescriptive procedures contained in the playbook, and then the cybersecurity incident is recorded in the feature space and the prescriptive procedures actually initiated by the user are automatically tied to the cybersecurity incident, thereby automatically altering subsequent recommendations of playbooks for responding to cybersecurity incidents having features similar or identical to the set of features of the new cybersecurity incident…”), (¶0160, “… the custom playbook is produced by the playbook generation and parent recommendation system according to the techniques described herein, and the user may choose to use the custom playbook, or use a different playbook, or remove an action to the custom playbook, or add an action to the custom playbook, and the playbook generation and parent recommendation system records the user actions according to the techniques described herein, so to affect future custom playbook recommendations.”), see also ¶0117, and ¶0143,FIG. 8;
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the system of Lunsford to include cyber incident response actions different from the playbook response actions as disclosed by Forte and be motivated in doing so in order to integrate the user’s cyber incident response actions into a playbook response actions to cybersecurity incidents having features similar or identical to the set of features of the new cybersecurity incident (playbook updating).
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over US. PGPUb. No. 20200193022 to Lunsford et al. (hereinafter Lunsford) US. PGPUb. No. 20200193022 to Lunsford et al. (hereinafter Lunsford) in view of US. PGPUb No. 20210398001 to Forte et al. (hereinafter Forte) and further in view of US. PGPUb No. 20250016185 to HAN et al. (hereinafter HAN).
Regarding claim 8, Lunsford in view of Forte discloses the system of claim 7. However, Lunsford in view of Forte does not explicitly disclose wherein the cyber
security event and response database includes a MITRE Adversarial Tactics, Techniques, and Common Knowledge (ATT&CK) framework.
HAN discloses wherein the cyber security event and response database includes a
MITRE Adversarial Tactics, Techniques, and Common Knowledge (ATT&CK) framework (¶0085, “Referring to FIG. 5, the AI engine that may be employed in the automatic analysis device is a chatbot engine to which EDR is applied, and may analyze an event extracted from an endpoint using rules first time (S51 and S52) and store the analysis result in an AI analysis server DB (S53 and S54), and the AI module may perform analysis log grouping on the stored data by PID and SID. The rules may include indicators of compromise (IOC) breach indicator and the MITRE Adversarial Tactics, Techniques and Common Knowledge (ATT&CK) attack technique.”).
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the system of Lunsford and Forte in claim 7 to include MTRE Adversarial Tactics, Techniques and Common Knowledge (ATT&CK) attack technique as disclosed by HAN and be motivated in doing so in order to prevent major information leakage incidents through advanced persistent threats (APTs)-HAN ¶0002 in parts.
Claim 12, is rejected under 35 U.S.C. 103 as being unpatentable over US. PGPUb. No. 20200193022 to Lunsford et al. (hereinafter Lunsford) in view of US. PGPUb No. 20210398001 to Forte et al. (hereinafter Forte) and further in view of by Pat. No. 12294645 to Kunz et al. (hereinafter Kunz).
Regarding claim 12, Lunsford in view of Forte discloses the system of claim 1.
However, Lunsford in view of Forte does not explicitly disclose wherein the cyber event response playbook generator generates the first cyber event response playbook based additionally on an input from a SOAR engine.
Kunz in the provisional application No. 63252062 filed on 10/04/2021 discloses wherein the cyber event response playbook generator generates the first cyber event response playbook based additionally on an input from a SOAR engine (¶0057-¶0059, ““SOAR”, which stands for “Security Orchestration, Automation and Response” software technology, allows an organization to collect and monitor security events and execute automated workflow and playbook responses to incidents. This may be combined with other AI automation tools and orchestration. “SIEM”, which stands for “Security Information and Event Management” is a set of technology tools that collect logging and event information in real-time across the enterprise to provide a consolidated view of all information security systems. QDS SIEM is integrated with SOAR and the QSOC (Security Operations Center), and forms part of the overall QDS Security Fabric. “Continuous Monitoring & Managed Detection & Response (MDR)’, is part of the QDS Security Fabric and includes the implementation of 24/7 security monitoring combined with MDR capabilities to provide additional threat hunting, correlation, and threat response actions in response to security alerts occurring within the security infrastructure.”).
Thus, one of ordinary skill in the art would have found it obvious before the effective filing date of applicant’s claimed invention to modify the system of Lunsford and Forte to include SOAR in responding to cyber event as disclosed by Kunz and be motivated in doing so in order to augment cyber event response action playbook associated with a detected type of cyber security event.
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 nonprovisional extension fee (37 CFR 1.17(a)) 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 mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MUDASIRU K OLAEGBE whose telephone number is (571)272-2082. The examiner can normally be reached MON-FRI. 7.30AM-5.30PM.
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 at 5712723739. 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.
/MUDASIRU K OLAEGBE/Examiner, Art Unit 2495
/FARID HOMAYOUNMEHR/Supervisory Patent Examiner, Art Unit 2495