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 action is responsive to communication received on 01/09/2026. Claims 1,7-9,15-17 and 21-33 are pending of which claims 1, 9, 17, 30-33 are amended.
The Examiner recommends filing a written authorization for Internet communication in response to the present action. Doing so permits the USPTO to communicate with Applicant using Internet email to schedule interviews or discuss other aspects of the application. Without a written authorization in place, the USPTO cannot respond to Internet correspondence received from Applicant. The preferred method of providing authorization is by filing form PTO/SB/439, available at: https://www.uspto.gov/patent/forms/forms. See MPEP § 502.03 for other methods of providing written authorization.
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, 7-9, 15-16, 31-33 are rejected under 35 U.S.C. 103 as being unpatentable over Bhatia US 2020/0272741, and further in view of Shahvarivar US 2024/0333768.
Regarding claims 1 and 9, Bhatia teaches a device and method comprising:
generating a representative attributes template for use in a production environment(generate detection rules from threat characteristics, ¶103)
[0103] Once trained to correlate input threat characteristics with output SIEM rule components, when the RNN 124 is presented with new threat characteristics, such as may be identified from parsing and NLP performed on threat intelligence feeds from the threat intelligence feed computing systems 160 or external source computing systems 170, the RNN 124 is able to automatically generate the correct combination of STEM rule components, and their sequence, that should be used to define a SIEM rule to address the new threat. The output from the RNN 124 may then be input to a template used by the rule generation engine 122 to convert the output of the RNN 124 into a text definition of the STEM rule's test, such as the test portion of the SIEM rule shown in FIG. 3, as discussed previously. The newly generated rule may then be deployed to the enterprise computing environment 130 as part of a modified SIEM rule set data structure 136, for example.
wherein the representative attributes template as associated with an anomaly, wherein the representative attributes template identifies representative attributes to be collected for security analysis of the anomaly(threat characteristics , anomaly conditions correspond to attribute that represent an attack/threats, such characteristics are collected for machine learning engine to generate detection rules, ¶s43,97)
[0043] In further aspects of the illustrative embodiments, the ARA provides mechanisms for decomposing rules into their constituent components, e.g., rule conditions, for use in generating new rules. The ARA trains a machine learning or cognitive computing system comprising machine learning mechanisms, such as a Recurrent Neural Network (RNN) or the like, to learn to generate new rules from threat characteristics and from various rule conditions available from STEM rule creation tools. That is, the ARA is trained using known threat characteristics and known rules with their corresponding conditions, to learn how human analysts compose rules to address threats, e.g., when these threat characteristics are present, human analysts uses these rule conditions to address those threat characteristics. Based on this learning, through a supervised machine learning process, the RNN is trained such that when given input threat characteristics and/or rule conditions that are satisfied by a threat, the RNN generates a new SIEM rule based on its machine learning, such that the new SIEM rule may be presented to a human analyst for consideration, editing, and deployment into an enterprise STEM rule set, or in some cases may be automatically deployed without human intervention.
[0097] FIG. 10A is an example diagram illustrating the STEM rules that may be provided by a STEM tools provider computing system 190 to the rule decomposition engine 120. The parse and NLP engine 102 of the ARA 100 may be employed by the rule decomposition engine 120 to parse and perform NLP operations on the STEM rules, or the “cleaned” or reformatted version of these SIEM rules, so as to extract the various conditions of the STEM rules, e.g., offense conditions, flow conditions, behavior conditions, event conditions, anomaly conditions, threshold conditions, and common conditions. Such conditions are typically used by analysts to manually create rules combining them with thresholds, clauses, log sources, etc. These conditions are compared and used to train a machine learning model to create new rules.
And wherein generating the representative attributes template comprises generating multiple respective template for multiple respective instances of the anomaly, wherein generating a respective template comprises of the multiple respective templates comprises (The process of machine learning comprise a iterative process where the machine learning algorithm learns threat characteristics such learning comprises multiple iterations(i.e. cycles) where the RNN output rule components on each iterations as it refines toward a convergence RNN model , ¶s 45,97,100 )
[0045] It should be appreciated that while the illustrative embodiments described herein reference SIEM rules and security rule based computing environments, the illustrative embodiments may be applied to any rules and rule based computing environments, including other security rules and non-security rules, e.g., business rules or the like. SIEM rules are based off of events or flows from inline network devices throughout a network of a managed computing environment, e.g., events may be obtained from firewalls, servers, endpoints, and the like, and the SIEM rules are applied based on the activities happening throughout the network. Other types of security rules are also inline or are associated with span/tap ports and look at packet level datagrams and take actions based on packet signatures or heuristics. Business rules based computing mechanisms provide structured logic for controlling the operation or behavior of a business by describing the operations, definitions, and constraints that apply to the organization, such that the rules may be applied by appropriate computing systems to control interactions of processes and the flow of data in the computing environment. In any of these cases, the mechanism of the illustrative embodiments described herein may be implemented to perform rule management and generation, and in some illustrative embodiments may be implemented with regard specifically to SIEM rules, as will be assumed in the following description for purposes of illustration. Thus, in general, references to SIEM rules hereafter may also be considered to reference other types of security rules, or rules used in other computing environments, in other illustrative embodiments.
[0097] FIG. 10A is an example diagram illustrating the STEM rules that may be provided by a STEM tools provider computing system 190 to the rule decomposition engine 120. The parse and NLP engine 102 of the ARA 100 may be employed by the rule decomposition engine 120 to parse and perform NLP operations on the STEM rules, or the “cleaned” or reformatted version of these SIEM rules, so as to extract the various conditions of the STEM rules, e.g., offense conditions, flow conditions, behavior conditions, event conditions, anomaly conditions, threshold conditions, and common conditions. Such conditions are typically used by analysts to manually create rules combining them with thresholds, clauses, log sources, etc. These conditions are compared and used to train a machine learning model to create new rules.
[0100] This process is performed in an iterative manner until a convergence of the RNN 124 is achieved and the error is less than a predetermined threshold. Because the RNN 124 includes the ability to track patterns with regard to a temporal aspect, the RNN 124 can not only learn the particular STEM rule components to utilize, but the particular sequence of these STEM rule components, leading to an output of a sequence of SIEM rule components that together constitute a new STEM rule definition to address the threat characteristics.
receiving respective security event information comprising at least one attribute associated with an instance of the anomaly(SIEM system received threat data and updates or creates new detection/security rules based the data, analysis and rule generation is created from a machine learning model for each event/incident detected ¶s30, 97)
[0030] A Security Incident and Event Management (SIEM) tool or system is the backbone of threat monitoring and detection in a security operations center (SOC). As mentioned above, the SIEM tool or system uses rule correlation to trigger offenses when specific events meet rule threshold criteria. These offenses are then examined by a human or machine analyst to make decisions on whether or not to escalate the offense as a “security incident” and take appropriate remediation action. A security rule, such as a SIEM rule, or simply “rule”, is a data structure that specifies a series of complex logical statements that include correlation logic on log sources, conditions, operators, and thresholds for rule firing, e.g., generating an alert notification as to a detected threat. An example SIEM tool or system installation comes with over 100-300 “out of the box” rules and several more are added when new log sources are commissioned, or new threat intelligence feeds are received. New custom rules are also added continuously on client requests or when a change is detected in the environment.
[0097] FIG. 10A is an example diagram illustrating the STEM rules that may be provided by a STEM tools provider computing system 190 to the rule decomposition engine 120. The parse and NLP engine 102 of the ARA 100 may be employed by the rule decomposition engine 120 to parse and perform NLP operations on the STEM rules, or the “cleaned” or reformatted version of these SIEM rules, so as to extract the various conditions of the STEM rules, e.g., offense conditions, flow conditions, behavior conditions, event conditions, anomaly conditions, threshold conditions, and common conditions. Such conditions are typically used by analysts to manually create rules combining them with thresholds, clauses, log sources, etc. These conditions are compared and used to train a machine learning model to create new rules.
providing the security event information as an input to a neural network-based processor;(threat characteristics provided to RNN, ¶43)
identifying, by the neural network-based processor, at least one respective representative attribute based on the input, wherein the at least one respective representative attribute includes one or more of the at least one attribute or at least one other attribute other than the at least one attribute(threat characteristics are extracted and used to create generate detection rules, ¶43)
[0043] In further aspects of the illustrative embodiments, the ARA provides mechanisms for decomposing rules into their constituent components, e.g., rule conditions, for use in generating new rules. The ARA trains a machine learning or cognitive computing system comprising machine learning mechanisms, such as a Recurrent Neural Network (RNN) or the like, to learn to generate new rules from threat characteristics and from various rule conditions available from STEM rule creation tools. That is, the ARA is trained using known threat characteristics and known rules with their corresponding conditions, to learn how human analysts compose rules to address threats, e.g., when these threat characteristics are present, human analysts uses these rule conditions to address those threat characteristics. Based on this learning, through a supervised machine learning process, the RNN is trained such that when given input threat characteristics and/or rule conditions that are satisfied by a threat, the RNN generates a new SIEM rule based on its machine learning, such that the new SIEM rule may be presented to a human analyst for consideration, editing, and deployment into an enterprise STEM rule set, or in some cases may be automatically deployed without human intervention.
wherein the at least one respective representative attribute is determined by the neural network- based processor to represent the instance of the anomaly for security analyses of production environment instances of the anomaly(neural network machine learning with NLP used to process input to generate rules, ¶97)
[0097] FIG. 10A is an example diagram illustrating the STEM rules that may be provided by a STEM tools provider computing system 190 to the rule decomposition engine 120. The parse and NLP engine 102 of the ARA 100 may be employed by the rule decomposition engine 120 to parse and perform NLP operations on the STEM rules, or the “cleaned” or reformatted version of these SIEM rules, so as to extract the various conditions of the STEM rules, e.g., offense conditions, flow conditions, behavior conditions, event conditions, anomaly conditions, threshold conditions, and common conditions. Such conditions are typically used by analysts to manually create rules combining them with thresholds, clauses, log sources, etc. These conditions are compared and used to train a machine learning model to create new rules.
And including the at least one respective representative attribute in the respective template(rule conditions represent learned threat characteristics for detecting threats, ¶97)
[0097] FIG. 10A is an example diagram illustrating the STEM rules that may be provided by a STEM tools provider computing system 190 to the rule decomposition engine 120. The parse and NLP engine 102 of the ARA 100 may be employed by the rule decomposition engine 120 to parse and perform NLP operations on the STEM rules, or the “cleaned” or reformatted version of these SIEM rules, so as to extract the various conditions of the STEM rules, e.g., offense conditions, flow conditions, behavior conditions, event conditions, anomaly conditions, threshold conditions, and common conditions. Such conditions are typically used by analysts to manually create rules combining them with thresholds, clauses, log sources, etc. These conditions are compared and used to train a machine learning model to create new rules.
deploying a representative attributes template to the respective generated templates to the production environment configured to automatically detect the production environment instances of the anomaly in the network, wherein the production environment is configured to use representative the template to define at least one collected attribute that is collected for the security analyses of the instances production environment of the anomaly(the created new rules can be deployed to the system automatically or after human administrator approval, ¶43 , upon a similarity threshold rules are aggregated into rule and deployed, ¶114).
[0043] In further aspects of the illustrative embodiments, the ARA provides mechanisms for decomposing rules into their constituent components, e.g., rule conditions, for use in generating new rules. The ARA trains a machine learning or cognitive computing system comprising machine learning mechanisms, such as a Recurrent Neural Network (RNN) or the like, to learn to generate new rules from threat characteristics and from various rule conditions available from STEM rule creation tools. That is, the ARA is trained using known threat characteristics and known rules with their corresponding conditions, to learn how human analysts compose rules to address threats, e.g., when these threat characteristics are present, human analysts uses these rule conditions to address those threat characteristics. Based on this learning, through a supervised machine learning process, the RNN is trained such that when given input threat characteristics and/or rule conditions that are satisfied by a threat, the RNN generates a new SIEM rule based on its machine learning, such that the new SIEM rule may be presented to a human analyst for consideration, editing, and deployment into an enterprise STEM rule set, or in some cases may be automatically deployed without human intervention.
[0114] Thus, as shown in FIG. 14, the similarity measures are compared to a predetermined threshold value indicating a threshold level or degree of similarity for integration of standard SIEM rules into the SIEM rule set data structure (step 1470). For those standard SIEM rules in the standard SIEM rule repository, that do not have a corresponding similarity measure with an existing SIEM rule in the SIEM rule set data structure that is equal to or above the predetermined threshold value, those standard SIEM rules are added to the SIEM rule set data structure to generate a modified SIEM rule set data structure (step 1480). The modified SIEM rules data structure is returned to the computing environment for deployment and utilization in monitoring and managing security incidents and events (step 1490). The operation then terminates.
Bhatia does not teach performing a consistency check comprising comparing the multiple respective templates to determine whether the multiple respective templates satisfy a predefined similarity threshold;
and in response to the multiple respective templates satisfying the predefined similarity threshold including identifications of representative attributes from at least one of the multiple respective templates in the representative attributes template. Sharivar in the same field of endeavor as the invention teaches a system for generating machine learning models to detect anomalies. Shariva teaches performing a consistency check comprising comparing the multiple respective templates to determine whether the multiple respective templates satisfy a predefined similarity threshold(model representing anomaly event characteristics is trained in a iterative process where after each iteration, similarity of threat signature that the model represents is determined with previous iteration that is most similar, ¶s99, 137,142)
and in response to the multiple respective templates satisfying the predefined similarity threshold including identifications of representative attributes from at least one of the multiple respective templates in the representative attributes template(performance threshold which is a measure of similarity/consistency of the model is met the model has been trained with the appropriate signature to detect anomalies, and model can be deployed, ¶132,137, 142, 181)
[0099] In some embodiments, the CGR system 120 may use different machine learning models to generate signatures of different event types. For example, the CGR system 120 may use different machine learning models for different types of potential attacks that can be detected by the event detection agents 118-1, 118-2 . . . 118-M. In this example, each of the machine learning models may be trained to generate signatures representing detected potential attacks. To illustrate, the CGR system 120 may include a first autoencoder trained to generate signatures representing SQL injection attacks, a second autoencoder trained to generate signatures representing XSS attacks, and a third autoencoder trained to generate signatures representing XXE attacks. The CGR system 120 may be configured to select a machine learning model to use in generating a signature of an event based on the event type. For example, a dataset including information about the event may include an identification of an agent, event type, sensor that detected the event, or other indication of event type. The CGR system 120 may use the information indicating event type to select a machine learning model from among multiple machine learning models to generate a signature representing the event.
[0132] In some embodiments, an autoencoder used by the system may be continuously trained over time. In some embodiments, the autoencoder may be trained when its performance falls below a threshold (e.g., a threshold f-1 score). In some embodiments, the autoencoder may be retrained incrementally using newly available data. For example, the autoencoder may be retrained periodically using an updated set of input data samples (e.g., initial numeric representations of datasets). For example, the autoencoder may be retrained using a certain number of the most recent input data samples (e.g., 100, 200, 500, 1000, 10,000, or other number of samples). As another example, the autoencoder may be retrained when a threshold number of new input data samples have been processed by the autoencoder. By continuously training the autoencoder with recent data, the autoencoder may mitigate compression loss resulting from shifts in datasets over time.
[0137] In some embodiments, the system may be configured to associate one or more of the signatures obtained at block 204 with an event cluster determined in the previous iteration of clustering. For example, the system may associate a given signature with an event cluster determined from the previous iteration of clustering by: (1) determining a measure of similarity (e.g., a distance) between the given signature and each of multiple event clusters determined in the previous iteration of clustering; and (2) associating the signature to one of the event clusters that the signature is most similar to (e.g., for which it has the greatest measure of similarity).
[0142] In some embodiments, the system may be configured to automatically identify a particular event cluster. The system may be configured to identify the event cluster by applying one or more pre-defined rules to characteristics of events in each of the event clusters. For example, the system may determine that if a certain number of events in a cluster have characteristics matching those of an attack, the system may identify the event cluster. As another example, the system may identify a particular event cluster based on a number of events in the cluster. The system may determine to select the event cluster when there are a threshold number of events in the cluster.
[0181] As shown in FIG. 4A, the interference stage 404 may include real time application monitoring. The real time application monitoring may be performed through a GUI provided by the GDR system. The GUI may allow a user to view activity of the GDR system including activity of specific event detection agents, activity with respect to a software application, and/or other activity. The GDR system may further receive user input through the GUI (e.g., a selection of an event cluster) that the GDR system may use in updating a configuration of the agent's monitoring. The GDR system may be configured to perform ML model decay monitoring. For example, the GDR system may monitor performance of an ML model (e.g., an autoencoder) used to generate signatures representing events. As illustrated in the example embodiment of FIG. 4B, the system determines performance of the ML model at various times. The system retrains the ML model when the performance of the model falls below a threshold performance (e.g., a threshold F-1 score). For example, the system may retrain an autoencoder used in generating signatures when a reconstruction performance of the autoencoder falls below a threshold F-1 score. In the example of FIG. 4B, the system has retrained the model four times in a time period between September and May of a given year. The system may thus ensure a minimum level of performance of the ML model by continuously training the ML model.
It would have been obvious to a person of ordinary skill in the art at the time of the effective filing of the instant application to modify Bhatia’s training of model generating security rules with the method of iterative model training until the performance of the model based similarity of signatures achieves the performance threshold. The reason for this modification would be to ensure a that rules can accurately(i.e. consistently) detect anomalies and that such rules can be updated in response to new threats.
Regarding claims 7 and 15, Bhatia wherein the security event information is first security event information, and further comprising: receiving, from the production environment, second security event information comprising the at least one collected attribute associated with an instance of the anomaly among the instances of the anomaly(system receives reports and logs from threat events in the deployed system continuously, ¶95,105,114)
and repeating, for the second security event information, at least the providing and the identifying in order to increase a consistency of neural network-based processor outputs(process of receiving threat event data and recurrent neural network analysis is performed continuously, ¶s105,114)
[0095] In further aspects of the illustrative embodiments, the ARA 100 comprises a rule decomposition engine 120 and rule generation engine 122 to provide logic that is configured to perform operations for generating new STEM rules in response to threat intelligence indicating new threats that may be potentially encountered by computing resources in the enterprise computing environment 130. The rule decomposition engine 120 comprises logic that imports rule conditions (flow, events, offense, behavior, common, etc.) from SIEM tools provider computing systems 190, i.e. organizations that provide STEM tools with corresponding user selectable rule conditions for defining SIEM rules. The rule decomposition engine 120 further receives log source information from log sources 180, such as log source types and functions from log source databases 180. Pattern detection and regular expressions regex) are used by the rule decomposition engine 120 to extract information from the rule logic specified in the rule conditions and the log source information from the log sources 180, to build a rule component database 126. Entries in the rule component database specify the correlations between log source information, such as log source type, log source name, functions performed, test conditions of the SIEM rules, and the like.
[0105] It should be appreciated that the operation of the ARA 100 to perform the above described operations with regard to rule deduplication and merging, alignment of rules to frameworks and/or standard rule sets, and/or generation of new rules to address new threats, may be performed in a continuous or periodic manner, in response to an event, or in response to a request to perform its actions, such as a human analyst at an enterprise computing environment 130 requesting the functionality of the ARA 100, such as in the case of the ARA 100 being provided as a cloud service or the like, for example. For example, the ARA 100 may perform its operations in response to new rules being added to the enterprise's SIEM rule set, in response to a human analyst's request to the ARA 100 to perform its functions, in response to the expiration of a predetermined time period, in response to a new threat information being received by the ARA, in response to a new standard rule being added to the standard rules repository 150, or any other trigger event, request, or condition.
[0114] Thus, as shown in FIG. 14, the similarity measures are compared to a predetermined threshold value indicating a threshold level or degree of similarity for integration of standard SIEM rules into the SIEM rule set data structure (step 1470). For those standard SIEM rules in the standard SIEM rule repository, that do not have a corresponding similarity measure with an existing SIEM rule in the SIEM rule set data structure that is equal to or above the predetermined threshold value, those standard SIEM rules are added to the SIEM rule set data structure to generate a modified SIEM rule set data structure (step 1480). The modified SIEM rules data structure is returned to the computing environment for deployment and utilization in monitoring and managing security incidents and events (step 1490). The operation then terminates.
Regarding claims 8 and 16, Bhatia teaches wherein the neural network-based processor comprises a natural language processor or a large language model-based processor(NLP processing perform for input into recurrent neural network, ¶103).
[0103] Once trained to correlate input threat characteristics with output SIEM rule components, when the RNN 124 is presented with new threat characteristics, such as may be identified from parsing and NLP performed on threat intelligence feeds from the threat intelligence feed computing systems 160 or external source computing systems 170, the RNN 124 is able to automatically generate the correct combination of STEM rule components, and their sequence, that should be used to define a SIEM rule to address the new threat. The output from the RNN 124 may then be input to a template used by the rule generation engine 122 to convert the output of the RNN 124 into a text definition of the STEM rule's test, such as the test portion of the SIEM rule shown in FIG. 3, as discussed previously. The newly generated rule may then be deployed to the enterprise computing environment 130 as part of a modified SIEM rule set data structure 136, for example.
Regarding claims 30 and 32, Bhatia teaches wherein the anomaly is associated with a new anomaly type, and wherein generating the multiple respective template for multiple respective instances of the anomaly is performed in response to detecting the anomaly associated with the new anomaly type(new threat characteristics… new types of malware/attacks ¶s43, ¶86).
[0043] In further aspects of the illustrative embodiments, the ARA provides mechanisms for decomposing rules into their constituent components, e.g., rule conditions, for use in generating new rules. The ARA trains a machine learning or cognitive computing system comprising machine learning mechanisms, such as a Recurrent Neural Network (RNN) or the like, to learn to generate new rules from threat characteristics and from various rule conditions available from STEM rule creation tools. That is, the ARA is trained using known threat characteristics and known rules with their corresponding conditions, to learn how human analysts compose rules to address threats, e.g., when these threat characteristics are present, human analysts uses these rule conditions to address those threat characteristics. Based on this learning, through a supervised machine learning process, the RNN is trained such that when given input threat characteristics and/or rule conditions that are satisfied by a threat, the RNN generates a new SIEM rule based on its machine learning, such that the new SIEM rule may be presented to a human analyst for consideration, editing, and deployment into an enterprise STEM rule set, or in some cases may be automatically deployed without human intervention.
[0086] For example, the framework provider computing systems 140 may be associated with various standards organizations, such as NIST or ISO, and may provide data structures specifying the frameworks for protecting computing environments from potential threats such as malware, virus, and other types of attacks on computing resources. These data structures are provided in a structured format with the standards of the framework organized in terms of categories and topics with corresponding descriptions. FIG. 8 is an example diagram illustrating one arrangement of a framework definition in which categories and subcategories (or topics) are specified along with corresponding textual descriptions.
Regarding claims 31 and 33, Bhatia teaches wherein the anomaly is associated with a schema, and wherein generating the multiple respective template for multiple respective instances of the anomaly is performed in response to change in the schema(new threat characteristics where new characteristics corresponds to a change in the set of characteristics(ie schema) that define the threat,¶s 86,99) .
[0099] The RNN 124 is trained through a supervised machine learning training operation, to identify these components from the rule component database 126 which may be combined, and the sequence of such combination, to generate a SIEM rule to address particular types of threats. For example, assume a training data set comprising SIEM rules, defined in terms of a sequence of SIEM rule components, and corresponding threat characteristics. The RNN 124 is trained using this training data set such that for a given set of threat characteristics, the RNN 124 will generate a sequence of SIEM rule components to define a SIEM rule to address the threat. The output of the RNN 124 is then evaluated, i.e. the SIEM rule components generated by the RNN 124 are compared to the STEM rule components, as well as the sequence, of the “ground truth” of the training set to determine similarities and differences, i.e. an error or loss in the RNN 124 output. Based on these similarities and differences, the hidden layers of the RNN 124 have their operational parameters, e.g., weights and the like, adjusted to attempt to minimize the error in the output generated by the RNN 124. Linear and/or logistic regression mechanisms may be used to adjust the operational parameters of the hidden layers.
Claims 17 are rejected under 35 U.S.C. 103 as being unpatentable over Bhatia/Shahriva and further in view of Srivatsa US 2024/0137375.
Regarding claim 17, Regarding claims 1 and 9, Bhatia teaches a method comprising:
generating a representative attributes template for use in a production environment(generate detection rules from threat characteristics, ¶103)
[0103] Once trained to correlate input threat characteristics with output SIEM rule components, when the RNN 124 is presented with new threat characteristics, such as may be identified from parsing and NLP performed on threat intelligence feeds from the threat intelligence feed computing systems 160 or external source computing systems 170, the RNN 124 is able to automatically generate the correct combination of STEM rule components, and their sequence, that should be used to define a SIEM rule to address the new threat. The output from the RNN 124 may then be input to a template used by the rule generation engine 122 to convert the output of the RNN 124 into a text definition of the STEM rule's test, such as the test portion of the SIEM rule shown in FIG. 3, as discussed previously. The newly generated rule may then be deployed to the enterprise computing environment 130 as part of a modified SIEM rule set data structure 136, for example.
wherein the representative attributes template as associated with an anomaly, wherein the representative attributes template identifies representative attributes to be collected for security analysis of the anomaly(threat characteristics , anomaly conditions correspond to attribute that represent an attack/threats, such characteristics are collected for machine learning engine to generate detection rules, ¶s43,97)
[0043] In further aspects of the illustrative embodiments, the ARA provides mechanisms for decomposing rules into their constituent components, e.g., rule conditions, for use in generating new rules. The ARA trains a machine learning or cognitive computing system comprising machine learning mechanisms, such as a Recurrent Neural Network (RNN) or the like, to learn to generate new rules from threat characteristics and from various rule conditions available from STEM rule creation tools. That is, the ARA is trained using known threat characteristics and known rules with their corresponding conditions, to learn how human analysts compose rules to address threats, e.g., when these threat characteristics are present, human analysts uses these rule conditions to address those threat characteristics. Based on this learning, through a supervised machine learning process, the RNN is trained such that when given input threat characteristics and/or rule conditions that are satisfied by a threat, the RNN generates a new SIEM rule based on its machine learning, such that the new SIEM rule may be presented to a human analyst for consideration, editing, and deployment into an enterprise STEM rule set, or in some cases may be automatically deployed without human intervention.
[0097] FIG. 10A is an example diagram illustrating the STEM rules that may be provided by a STEM tools provider computing system 190 to the rule decomposition engine 120. The parse and NLP engine 102 of the ARA 100 may be employed by the rule decomposition engine 120 to parse and perform NLP operations on the STEM rules, or the “cleaned” or reformatted version of these SIEM rules, so as to extract the various conditions of the STEM rules, e.g., offense conditions, flow conditions, behavior conditions, event conditions, anomaly conditions, threshold conditions, and common conditions. Such conditions are typically used by analysts to manually create rules combining them with thresholds, clauses, log sources, etc. These conditions are compared and used to train a machine learning model to create new rules.
And wherein generating the representative attributes template comprises generating multiple respective template for multiple respective instances of the anomaly, wherein generating a respective template comprises of the multiple respective templates comprises (The process of machine learning comprise a iterative process where the machine learning algorithm learns threat characteristics such learning comprises multiple iterations(i.e. cycles) where the RNN output rule components on each iterations as it refines toward a convergence RNN model , ¶s 45,97,100 )
[0045] It should be appreciated that while the illustrative embodiments described herein reference SIEM rules and security rule based computing environments, the illustrative embodiments may be applied to any rules and rule based computing environments, including other security rules and non-security rules, e.g., business rules or the like. SIEM rules are based off of events or flows from inline network devices throughout a network of a managed computing environment, e.g., events may be obtained from firewalls, servers, endpoints, and the like, and the SIEM rules are applied based on the activities happening throughout the network. Other types of security rules are also inline or are associated with span/tap ports and look at packet level datagrams and take actions based on packet signatures or heuristics. Business rules based computing mechanisms provide structured logic for controlling the operation or behavior of a business by describing the operations, definitions, and constraints that apply to the organization, such that the rules may be applied by appropriate computing systems to control interactions of processes and the flow of data in the computing environment. In any of these cases, the mechanism of the illustrative embodiments described herein may be implemented to perform rule management and generation, and in some illustrative embodiments may be implemented with regard specifically to SIEM rules, as will be assumed in the following description for purposes of illustration. Thus, in general, references to SIEM rules hereafter may also be considered to reference other types of security rules, or rules used in other computing environments, in other illustrative embodiments.
[0097] FIG. 10A is an example diagram illustrating the STEM rules that may be provided by a STEM tools provider computing system 190 to the rule decomposition engine 120. The parse and NLP engine 102 of the ARA 100 may be employed by the rule decomposition engine 120 to parse and perform NLP operations on the STEM rules, or the “cleaned” or reformatted version of these SIEM rules, so as to extract the various conditions of the STEM rules, e.g., offense conditions, flow conditions, behavior conditions, event conditions, anomaly conditions, threshold conditions, and common conditions. Such conditions are typically used by analysts to manually create rules combining them with thresholds, clauses, log sources, etc. These conditions are compared and used to train a machine learning model to create new rules.
[0100] This process is performed in an iterative manner until a convergence of the RNN 124 is achieved and the error is less than a predetermined threshold. Because the RNN 124 includes the ability to track patterns with regard to a temporal aspect, the RNN 124 can not only learn the particular STEM rule components to utilize, but the particular sequence of these STEM rule components, leading to an output of a sequence of SIEM rule components that together constitute a new STEM rule definition to address the threat characteristics.
receiving respective security event information comprising at least one attribute associated with an instance of the anomaly(SIEM system received threat data and updates or creates new detection/security rules based the data, analysis and rule generation is created from a machine learning model for each event/incident detected ¶s30, 97)
[0030] A Security Incident and Event Management (SIEM) tool or system is the backbone of threat monitoring and detection in a security operations center (SOC). As mentioned above, the SIEM tool or system uses rule correlation to trigger offenses when specific events meet rule threshold criteria. These offenses are then examined by a human or machine analyst to make decisions on whether or not to escalate the offense as a “security incident” and take appropriate remediation action. A security rule, such as a SIEM rule, or simply “rule”, is a data structure that specifies a series of complex logical statements that include correlation logic on log sources, conditions, operators, and thresholds for rule firing, e.g., generating an alert notification as to a detected threat. An example SIEM tool or system installation comes with over 100-300 “out of the box” rules and several more are added when new log sources are commissioned, or new threat intelligence feeds are received. New custom rules are also added continuously on client requests or when a change is detected in the environment.
[0097] FIG. 10A is an example diagram illustrating the STEM rules that may be provided by a STEM tools provider computing system 190 to the rule decomposition engine 120. The parse and NLP engine 102 of the ARA 100 may be employed by the rule decomposition engine 120 to parse and perform NLP operations on the STEM rules, or the “cleaned” or reformatted version of these SIEM rules, so as to extract the various conditions of the STEM rules, e.g., offense conditions, flow conditions, behavior conditions, event conditions, anomaly conditions, threshold conditions, and common conditions. Such conditions are typically used by analysts to manually create rules combining them with thresholds, clauses, log sources, etc. These conditions are compared and used to train a machine learning model to create new rules.
providing the security event information as an input to a neural network-based processor;(threat characteristics provided to RNN, ¶43)
identifying, by the neural network-based processor, at least one respective representative attribute based on the input, wherein the at least one respective representative attribute includes one or more of the at least one attribute or at least one other attribute other than the at least one attribute(threat characteristics are extracted and used to create generate detection rules, ¶43)
[0043] In further aspects of the illustrative embodiments, the ARA provides mechanisms for decomposing rules into their constituent components, e.g., rule conditions, for use in generating new rules. The ARA trains a machine learning or cognitive computing system comprising machine learning mechanisms, such as a Recurrent Neural Network (RNN) or the like, to learn to generate new rules from threat characteristics and from various rule conditions available from STEM rule creation tools. That is, the ARA is trained using known threat characteristics and known rules with their corresponding conditions, to learn how human analysts compose rules to address threats, e.g., when these threat characteristics are present, human analysts uses these rule conditions to address those threat characteristics. Based on this learning, through a supervised machine learning process, the RNN is trained such that when given input threat characteristics and/or rule conditions that are satisfied by a threat, the RNN generates a new SIEM rule based on its machine learning, such that the new SIEM rule may be presented to a human analyst for consideration, editing, and deployment into an enterprise STEM rule set, or in some cases may be automatically deployed without human intervention.
wherein the at least one respective representative attribute is determined by the neural network- based processor to represent the instance of the anomaly for security analyses of production environment instances of the anomaly(neural network machine learning with NLP used to process input to generate rules, ¶97)
[0097] FIG. 10A is an example diagram illustrating the STEM rules that may be provided by a STEM tools provider computing system 190 to the rule decomposition engine 120. The parse and NLP engine 102 of the ARA 100 may be employed by the rule decomposition engine 120 to parse and perform NLP operations on the STEM rules, or the “cleaned” or reformatted version of these SIEM rules, so as to extract the various conditions of the STEM rules, e.g., offense conditions, flow conditions, behavior conditions, event conditions, anomaly conditions, threshold conditions, and common conditions. Such conditions are typically used by analysts to manually create rules combining them with thresholds, clauses, log sources, etc. These conditions are compared and used to train a machine learning model to create new rules.
And including the at least one respective representative attribute in the respective template(rule conditions represent learned threat characteristics for detecting threats, ¶97)
[0097] FIG. 10A is an example diagram illustrating the STEM rules that may be provided by a STEM tools provider computing system 190 to the rule decomposition engine 120. The parse and NLP engine 102 of the ARA 100 may be employed by the rule decomposition engine 120 to parse and perform NLP operations on the STEM rules, or the “cleaned” or reformatted version of these SIEM rules, so as to extract the various conditions of the STEM rules, e.g., offense conditions, flow conditions, behavior conditions, event conditions, anomaly conditions, threshold conditions, and common conditions. Such conditions are typically used by analysts to manually create rules combining them with thresholds, clauses, log sources, etc. These conditions are compared and used to train a machine learning model to create new rules.
deploying a representative attributes template to the respective generated templates to the production environment configured to automatically detect the production environment instances of the anomaly in the network, wherein the production environment is configured to use representative the template to define at least one collected attribute that is collected for the security analyses of the instances production environment of the anomaly(the created new rules can be deployed to the system automatically or after human administrator approval, ¶43 , upon a similarity threshold rules are aggregated into rule and deployed, ¶114).
[0043] In further aspects of the illustrative embodiments, the ARA provides mechanisms for decomposing rules into their constituent components, e.g., rule conditions, for use in generating new rules. The ARA trains a machine learning or cognitive computing system comprising machine learning mechanisms, such as a Recurrent Neural Network (RNN) or the like, to learn to generate new rules from threat characteristics and from various rule conditions available from STEM rule creation tools. That is, the ARA is trained using known threat characteristics and known rules with their corresponding conditions, to learn how human analysts compose rules to address threats, e.g., when these threat characteristics are present, human analysts uses these rule conditions to address those threat characteristics. Based on this learning, through a supervised machine learning process, the RNN is trained such that when given input threat characteristics and/or rule conditions that are satisfied by a threat, the RNN generates a new SIEM rule based on its machine learning, such that the new SIEM rule may be presented to a human analyst for consideration, editing, and deployment into an enterprise STEM rule set, or in some cases may be automatically deployed without human intervention.
[0114] Thus, as shown in FIG. 14, the similarity measures are compared to a predetermined threshold value indicating a threshold level or degree of similarity for integration of standard SIEM rules into the SIEM rule set data structure (step 1470). For those standard SIEM rules in the standard SIEM rule repository, that do not have a corresponding similarity measure with an existing SIEM rule in the SIEM rule set data structure that is equal to or above the predetermined threshold value, those standard SIEM rules are added to the SIEM rule set data structure to generate a modified SIEM rule set data structure (step 1480). The modified SIEM rules data structure is returned to the computing environment for deployment and utilization in monitoring and managing security incidents and events (step 1490). The operation then terminates.
Bhatia does not teach performing a consistency check comprising comparing the multiple respective templates to determine whether the multiple respective templates satisfy a predefined similarity threshold;
and in response to the multiple respective templates satisfying the predefined similarity threshold including identifications of representative attributes from at least one of the multiple respective templates in the representative attributes template. Sharivar in the same field of endeavor as the invention teaches a system for generating machine learning models to detect anomalies. Shariva teaches performing a consistency check comprising comparing the multiple respective templates to determine whether the multiple respective templates satisfy a predefined similarity threshold(model representing anomaly event characteristics is trained in a iterative process where after each iteration, similarity of threat signature that the model represents is determined with previous iteration that is most similar, ¶s99, 137,142)
and in response to the multiple respective templates satisfying the predefined similarity threshold including identifications of representative attributes from at least one of the multiple respective templates in the representative attributes template(performance threshold which is a measure of similarity/consistency of the model is met the model has been trained with the appropriate signature to detect anomalies, and model can be deployed, ¶132,137, 142, 181)
[0099] In some embodiments, the CGR system 120 may use different machine learning models to generate signatures of different event types. For example, the CGR system 120 may use different machine learning models for different types of potential attacks that can be detected by the event detection agents 118-1, 118-2 . . . 118-M. In this example, each of the machine learning models may be trained to generate signatures representing detected potential attacks. To illustrate, the CGR system 120 may include a first autoencoder trained to generate signatures representing SQL injection attacks, a second autoencoder trained to generate signatures representing XSS attacks, and a third autoencoder trained to generate signatures representing XXE attacks. The CGR system 120 may be configured to select a machine learning model to use in generating a signature of an event based on the event type. For example, a dataset including information about the event may include an identification of an agent, event type, sensor that detected the event, or other indication of event type. The CGR system 120 may use the information indicating event type to select a machine learning model from among multiple machine learning models to generate a signature representing the event.
[0132] In some embodiments, an autoencoder used by the system may be continuously trained over time. In some embodiments, the autoencoder may be trained when its performance falls below a threshold (e.g., a threshold f-1 score). In some embodiments, the autoencoder may be retrained incrementally using newly available data. For example, the autoencoder may be retrained periodically using an updated set of input data samples (e.g., initial numeric representations of datasets). For example, the autoencoder may be retrained using a certain number of the most recent input data samples (e.g., 100, 200, 500, 1000, 10,000, or other number of samples). As another example, the autoencoder may be retrained when a threshold number of new input data samples have been processed by the autoencoder. By continuously training the autoencoder with recent data, the autoencoder may mitigate compression loss resulting from shifts in datasets over time.
[0137] In some embodiments, the system may be configured to associate one or more of the signatures obtained at block 204 with an event cluster determined in the previous iteration of clustering. For example, the system may associate a given signature with an event cluster determined from the previous iteration of clustering by: (1) determining a measure of similarity (e.g., a distance) between the given signature and each of multiple event clusters determined in the previous iteration of clustering; and (2) associating the signature to one of the event clusters that the signature is most similar to (e.g., for which it has the greatest measure of similarity).
[0142] In some embodiments, the system may be configured to automatically identify a particular event cluster. The system may be configured to identify the event cluster by applying one or more pre-defined rules to characteristics of events in each of the event clusters. For example, the system may determine that if a certain number of events in a cluster have characteristics matching those of an attack, the system may identify the event cluster. As another example, the system may identify a particular event cluster based on a number of events in the cluster. The system may determine to select the event cluster when there are a threshold number of events in the cluster.
[0181] As shown in FIG. 4A, the interference stage 404 may include real time application monitoring. The real time application monitoring may be performed through a GUI provided by the GDR system. The GUI may allow a user to view activity of the GDR system including activity of specific event detection agents, activity with respect to a software application, and/or other activity. The GDR system may further receive user input through the GUI (e.g., a selection of an event cluster) that the GDR system may use in updating a configuration of the agent's monitoring. The GDR system may be configured to perform ML model decay monitoring. For example, the GDR system may monitor performance of an ML model (e.g., an autoencoder) used to generate signatures representing events. As illustrated in the example embodiment of FIG. 4B, the system determines performance of the ML model at various times. The system retrains the ML model when the performance of the model falls below a threshold performance (e.g., a threshold F-1 score). For example, the system may retrain an autoencoder used in generating signatures when a reconstruction performance of the autoencoder falls below a threshold F-1 score. In the example of FIG. 4B, the system has retrained the model four times in a time period between September and May of a given year. The system may thus ensure a minimum level of performance of the ML model by continuously training the ML model.
It would have been obvious to a person of ordinary skill in the art at the time of the effective filing of the instant application to modify Bhatia’s training of model generating security rules with the method of iterative model training until the performance of the model based similarity of signatures achieves the performance threshold. The reason for this modification would be to ensure a that rules can accurately(i.e. consistently) detect anomalies and that such rules can be updated in response to new threats.
Bhatia teaches a language based(NLP -based ) neural network but does not specifically teach the neural network is a large network model. Srivatsa in the same field of endeavor teach a machine learning based system for network traffic anomaly detection. Srivatsa teaches the neural network is a large network model(BERT LLM used to train model and generated a trained model for anomaly detection, ¶26).
[0026] Deep neural network models have been applied to natural language processing (NLP) and image based tasks. For application to network analysis and detection of anomalies in network traffic for a network, one or more embodiments provide deep neural network models that can be effectively generalized to perform very well on multiple network tasks in different environments. Traditional deep models often rely on categorical features but cannot handle unseen categorical features/values. One method according to one or more embodiments for addressing such problems is to learn contextual embeddings for categorical features/variables used by deep neural networks in order to improve their performance. As discussed herein, one or more embodiments can adapt the NLP pre-training technique and associated deep model BERT to learn semantically meaningful numerical representations (contextual embeddings) for Fully Qualified Domain Names (FQDNs), protocol fields, protocol values, and/or other categorical features used in a communications network, which can be used to quickly detect anomalies and improve cyber security protection, or achieve other network management tasks (e.g., flow classification). One or more techniques of embodiments walk through a series of experiments illustrating that such techniques can be used to generate foundational models that maintain their effectiveness when applied to environments other than the one in which they were trained, thereby being modified for communication networks according to one or more embodiments.
It would have been obvious to a person of ordinary skill in the art at the time of the effective filing of the instant application to modify Bhatia/Shahriva with a large language model type neural network to train and generate trained detection models as taught by Srivatsa. The reason for this modification would be to improve rule generation using well known equivalents to a NLP based neural network.
Claims 21-23 and 24-26 are rejected under 35 U.S.C. 103 as being unpatentable over Bhatia/Shahriva as applied to claims 1, and 9 above, and further in view of Shadbolt US 2021/0385129.
Regarding claims 21, and 24, Bhatia/Shahriva do not teach wherein the anomaly comprises a modification of a setting used by at least one defender system in the network. Shadbolt in the same field of endeavor teaches a system for tamper detection and mitigation using machine learning models. Shadbolt teaches wherein the anomaly comprises a modification of a setting used by at least one defender system in the network( machine learning models trained to detect changes to security settings ¶s 21,28,60)
[0021] The following description discloses systems and methods for protecting and unauthorized changes to system configuration settings. As will be described in detail below, the proposed systems and methods offer a robust tamper protection paradigm for maintaining the desired security of client devices and systems. The tamper protection feature disclosed herein is configured to prevent malicious or other unwanted changes to security settings on devices, such as unauthorized attempts to disable security protection features, by limiting access to the tamper protection feature. For example, in one implementation, changes in management and deployment of the desired tamper protection state may only be made through a designated cloud-based enterprise mobility management tool (MMT), rather than conventional methods such as group policies, registry keys, PowerShell cmdlets, or WMI. When a security administrator enables the tamper protection feature, the policy is first digitally signed. The receiving endpoint verifies the validity and intent of the policy, establishing that it is a signed package that only security operations personnel with the necessary admin rights can control. The feature can be enabled or disabled for the entire organization, or enabled or disabled on selected devices identified through mechanisms such as device and user groups. A wide range of services and settings can then be protected from undesired modification, including virus and threat protection, real-time protection, behavior monitoring, antivirus, cloud-delivered protection, and/or security intelligence updates. The tamper protection feature provides an enterprise-wide shield that blocks attempts by malicious applications, as well as by day-to-day end-users (including, for example, end-users with local administrative privileges), to alter critical settings.
[0028] As noted earlier, one example of a critical policy configuration includes configuration settings affecting the deployment and operation of an anti-virus protection (AVP) system 180. In different implementations, AVP system 180 can be deployed as a cloud service, non-cloud applications (such as at local devices), or a combination of both. The AVP system 180 generally includes one or more computers and storage to store anti-virus detection information (e.g., malware detection metadata) and executable code in some examples. In some examples, the AVP system 180 may be provided to one or more endpoint devices via a computer network. The AVP system 180 may be configured to operate using an anti-virus service that prevents, detects, and/or remediates system abuse by malware. Some or all of the AVP system 180 or the functionality of the AVP system 180 for an end-user computing device can be implemented within the end-user computing device. For example, interceptions of certain operations may be performed by the end-user computing device. In some examples, the malware detection metadata can include signatures, heuristics, data to drive emulation, dynamic translation, cloud queries, and/or machine learning-based techniques (such as, but not limited to, machine data learning models, behavioral analysis, etc.). In some implementations, the functionality of the AVP system 180 is performed, within a protected environment that is isolated from the operating system (for example, using virtualization-based security techniques). In one implementation, AVP system 180 is configured to perform automatic remediation of a generic class of malware which in one example modifies data or files belonging to the operating system. For example, malware detection metadata defines a list of system binary files and configuration files targeted by malware.
[0060] Similarly, in some other implementations, the system can be configured to detect attempts to modify the tamper protection feature by an unauthorized user or other malicious application. In some cases, in response to a detection of such an attempt, the client device can cause a notification to be generated for the security administrator's review. These notifications can be automated, and may be transmitted per system settings and/or security admin preferences, including but not limited to e-mail messages, text messages, chat messages, pop-up windows, automated phone calls, any other form of communication associated with the user's account may be used to provide such information. For example, the system may be configured to detect instances in which a threat attack is directed to the tamper protection feature, an attempt to alter the configuration via registry or other settings is made, or an endpoint device has determined that a command is expired, is associated with an inappropriate tenant identifier, and/or has a signature that cannot be verified.
It would have been obvious to a person of ordinary skill in the art at the time of the effective filing of the instant application to modify Bhatia/Shahriva with training a machine learning model to detect and generate rules to prevent alteration to security/protection settings as taught by Shadbolt. The reason for this modification would be to generate rules that protect against know threat/attack vectors.
Regarding claims 22, and 25, Bhatia/Shahriva does not teach wherein the anomaly comprises a modification of a real-time protection setting used by at least one defender system in the network. Shadbolt in the same field of endeavor teaches a system for tamper detection and mitigation using machine learning models. Shadbolt teaches wherein the anomaly comprises a modification of a real-time protection setting used by at least one defender system in the network( machine learning models trained to detect changes to security settings ¶s 21,28,60)
[0021] The following description discloses systems and methods for protecting and unauthorized changes to system configuration settings. As will be described in detail below, the proposed systems and methods offer a robust tamper protection paradigm for maintaining the desired security of client devices and systems. The tamper protection feature disclosed herein is configured to prevent malicious or other unwanted changes to security settings on devices, such as unauthorized attempts to disable security protection features, by limiting access to the tamper protection feature. For example, in one implementation, changes in management and deployment of the desired tamper protection state may only be made through a designated cloud-based enterprise mobility management tool (MMT), rather than conventional methods such as group policies, registry keys, PowerShell cmdlets, or WMI. When a security administrator enables the tamper protection feature, the policy is first digitally signed. The receiving endpoint verifies the validity and intent of the policy, establishing that it is a signed package that only security operations personnel with the necessary admin rights can control. The feature can be enabled or disabled for the entire organization, or enabled or disabled on selected devices identified through mechanisms such as device and user groups. A wide range of services and settings can then be protected from undesired modification, including virus and threat protection, real-time protection, behavior monitoring, antivirus, cloud-delivered protection, and/or security intelligence updates. The tamper protection feature provides an enterprise-wide shield that blocks attempts by malicious applications, as well as by day-to-day end-users (including, for example, end-users with local administrative privileges), to alter critical settings.
[0028] As noted earlier, one example of a critical policy configuration includes configuration settings affecting the deployment and operation of an anti-virus protection (AVP) system 180. In different implementations, AVP system 180 can be deployed as a cloud service, non-cloud applications (such as at local devices), or a combination of both. The AVP system 180 generally includes one or more computers and storage to store anti-virus detection information (e.g., malware detection metadata) and executable code in some examples. In some examples, the AVP system 180 may be provided to one or more endpoint devices via a computer network. The AVP system 180 may be configured to operate using an anti-virus service that prevents, detects, and/or remediates system abuse by malware. Some or all of the AVP system 180 or the functionality of the AVP system 180 for an end-user computing device can be implemented within the end-user computing device. For example, interceptions of certain operations may be performed by the end-user computing device. In some examples, the malware detection metadata can include signatures, heuristics, data to drive emulation, dynamic translation, cloud queries, and/or machine learning-based techniques (such as, but not limited to, machine data learning models, behavioral analysis, etc.). In some implementations, the functionality of the AVP system 180 is performed, within a protected environment that is isolated from the operating system (for example, using virtualization-based security techniques). In one implementation, AVP system 180 is configured to perform automatic remediation of a generic class of malware which in one example modifies data or files belonging to the operating system. For example, malware detection metadata defines a list of system binary files and configuration files targeted by malware.
[0060] Similarly, in some other implementations, the system can be configured to detect attempts to modify the tamper protection feature by an unauthorized user or other malicious application. In some cases, in response to a detection of such an attempt, the client device can cause a notification to be generated for the security administrator's review. These notifications can be automated, and may be transmitted per system settings and/or security admin preferences, including but not limited to e-mail messages, text messages, chat messages, pop-up windows, automated phone calls, any other form of communication associated with the user's account may be used to provide such information. For example, the system may be configured to detect instances in which a threat attack is directed to the tamper protection feature, an attempt to alter the configuration via registry or other settings is made, or an endpoint device has determined that a command is expired, is associated with an inappropriate tenant identifier, and/or has a signature that cannot be verified.
It would have been obvious to a person of ordinary skill in the art at the time of the effective filing of the instant application to modify Bhatia with training a machine learning model to detect and generate rules to prevent alteration to security/protection settings as taught by Shadbolt. The reason for this modification would be to generate rules that protect against know threat/attack vectors
Regarding claims 23, and 26, Bhatia/Shahriva do not teach wherein the at least one respective representative attribute comprises registry information. Shadbolt in the same field of endeavor teaches a system for tamper detection and mitigation using machine learning models. Shadbolt teaches wherein the at least one respective representative attribute comprises registry information( machine learning models trained to detect changes to registry ¶s,60)
[0060] Similarly, in some other implementations, the system can be configured to detect attempts to modify the tamper protection feature by an unauthorized user or other malicious application. In some cases, in response to a detection of such an attempt, the client device can cause a notification to be generated for the security administrator's review. These notifications can be automated, and may be transmitted per system settings and/or security admin preferences, including but not limited to e-mail messages, text messages, chat messages, pop-up windows, automated phone calls, any other form of communication associated with the user's account may be used to provide such information. For example, the system may be configured to detect instances in which a threat attack is directed to the tamper protection feature, an attempt to alter the configuration via registry or other settings is made, or an endpoint device has determined that a command is expired, is associated with an inappropriate tenant identifier, and/or has a signature that cannot be verified.
It would have been obvious to a person of ordinary skill in the art at the time of the effective filing of the instant application to modify Bhatia with training a machine learning model to detect and generate rules to prevent alteration to security/protection settings as taught by Shadbolt. The reason for this modification would be to generate rules that protect against know threat/attack vectors.
Claims 27-29 are rejected under 35 U.S.C. 103 as being unpatentable over Bhatia/Shahriva/Srivatsa as applied to claim 17 above, and further in view of Shadbolt US 2021/0385129.
Regarding claim 27, Bhatia/Shahriva/Srivatsa do not teach wherein the anomaly comprises a modification of a setting used by at least one defender system in the network. Shadbolt in the same field of endeavor teaches a system for tamper detection and mitigation using machine learning models. Shadbolt teaches wherein the anomaly comprises a modification of a setting used by at least one defender system in the network( machine learning models trained to detect changes to security settings ¶s 21,28,60)
[0021] The following description discloses systems and methods for protecting and unauthorized changes to system configuration settings. As will be described in detail below, the proposed systems and methods offer a robust tamper protection paradigm for maintaining the desired security of client devices and systems. The tamper protection feature disclosed herein is configured to prevent malicious or other unwanted changes to security settings on devices, such as unauthorized attempts to disable security protection features, by limiting access to the tamper protection feature. For example, in one implementation, changes in management and deployment of the desired tamper protection state may only be made through a designated cloud-based enterprise mobility management tool (MMT), rather than conventional methods such as group policies, registry keys, PowerShell cmdlets, or WMI. When a security administrator enables the tamper protection feature, the policy is first digitally signed. The receiving endpoint verifies the validity and intent of the policy, establishing that it is a signed package that only security operations personnel with the necessary admin rights can control. The feature can be enabled or disabled for the entire organization, or enabled or disabled on selected devices identified through mechanisms such as device and user groups. A wide range of services and settings can then be protected from undesired modification, including virus and threat protection, real-time protection, behavior monitoring, antivirus, cloud-delivered protection, and/or security intelligence updates. The tamper protection feature provides an enterprise-wide shield that blocks attempts by malicious applications, as well as by day-to-day end-users (including, for example, end-users with local administrative privileges), to alter critical settings.
[0028] As noted earlier, one example of a critical policy configuration includes configuration settings affecting the deployment and operation of an anti-virus protection (AVP) system 180. In different implementations, AVP system 180 can be deployed as a cloud service, non-cloud applications (such as at local devices), or a combination of both. The AVP system 180 generally includes one or more computers and storage to store anti-virus detection information (e.g., malware detection metadata) and executable code in some examples. In some examples, the AVP system 180 may be provided to one or more endpoint devices via a computer network. The AVP system 180 may be configured to operate using an anti-virus service that prevents, detects, and/or remediates system abuse by malware. Some or all of the AVP system 180 or the functionality of the AVP system 180 for an end-user computing device can be implemented within the end-user computing device. For example, interceptions of certain operations may be performed by the end-user computing device. In some examples, the malware detection metadata can include signatures, heuristics, data to drive emulation, dynamic translation, cloud queries, and/or machine learning-based techniques (such as, but not limited to, machine data learning models, behavioral analysis, etc.). In some implementations, the functionality of the AVP system 180 is performed, within a protected environment that is isolated from the operating system (for example, using virtualization-based security techniques). In one implementation, AVP system 180 is configured to perform automatic remediation of a generic class of malware which in one example modifies data or files belonging to the operating system. For example, malware detection metadata defines a list of system binary files and configuration files targeted by malware.
[0060] Similarly, in some other implementations, the system can be configured to detect attempts to modify the tamper protection feature by an unauthorized user or other malicious application. In some cases, in response to a detection of such an attempt, the client device can cause a notification to be generated for the security administrator's review. These notifications can be automated, and may be transmitted per system settings and/or security admin preferences, including but not limited to e-mail messages, text messages, chat messages, pop-up windows, automated phone calls, any other form of communication associated with the user's account may be used to provide such information. For example, the system may be configured to detect instances in which a threat attack is directed to the tamper protection feature, an attempt to alter the configuration via registry or other settings is made, or an endpoint device has determined that a command is expired, is associated with an inappropriate tenant identifier, and/or has a signature that cannot be verified.
It would have been obvious to a person of ordinary skill in the art at the time of the effective filing of the instant application to modify Bhatia/Shahriva/Srivatsa with training a machine learning model to detect and generate rules to prevent alteration to security/protection settings as taught by Shadbolt. The reason for this modification would be to generate rules that protect against know threat/attack vectors.
Regarding claim 28, Bhatia/Shahriva/Srivatsa do not teach wherein the anomaly comprises a modification of a real-time protection setting used by at least one defender system in the network. Shadbolt in the same field of endeavor teaches a system for tamper detection and mitigation using machine learning models. Shadbolt teaches wherein the anomaly comprises a modification of a real-time protection setting used by at least one defender system in the network( machine learning models trained to detect changes to security settings ¶s 21,28,60)
[0021] The following description discloses systems and methods for protecting and unauthorized changes to system configuration settings. As will be described in detail below, the proposed systems and methods offer a robust tamper protection paradigm for maintaining the desired security of client devices and systems. The tamper protection feature disclosed herein is configured to prevent malicious or other unwanted changes to security settings on devices, such as unauthorized attempts to disable security protection features, by limiting access to the tamper protection feature. For example, in one implementation, changes in management and deployment of the desired tamper protection state may only be made through a designated cloud-based enterprise mobility management tool (MMT), rather than conventional methods such as group policies, registry keys, PowerShell cmdlets, or WMI. When a security administrator enables the tamper protection feature, the policy is first digitally signed. The receiving endpoint verifies the validity and intent of the policy, establishing that it is a signed package that only security operations personnel with the necessary admin rights can control. The feature can be enabled or disabled for the entire organization, or enabled or disabled on selected devices identified through mechanisms such as device and user groups. A wide range of services and settings can then be protected from undesired modification, including virus and threat protection, real-time protection, behavior monitoring, antivirus, cloud-delivered protection, and/or security intelligence updates. The tamper protection feature provides an enterprise-wide shield that blocks attempts by malicious applications, as well as by day-to-day end-users (including, for example, end-users with local administrative privileges), to alter critical settings.
[0028] As noted earlier, one example of a critical policy configuration includes configuration settings affecting the deployment and operation of an anti-virus protection (AVP) system 180. In different implementations, AVP system 180 can be deployed as a cloud service, non-cloud applications (such as at local devices), or a combination of both. The AVP system 180 generally includes one or more computers and storage to store anti-virus detection information (e.g., malware detection metadata) and executable code in some examples. In some examples, the AVP system 180 may be provided to one or more endpoint devices via a computer network. The AVP system 180 may be configured to operate using an anti-virus service that prevents, detects, and/or remediates system abuse by malware. Some or all of the AVP system 180 or the functionality of the AVP system 180 for an end-user computing device can be implemented within the end-user computing device. For example, interceptions of certain operations may be performed by the end-user computing device. In some examples, the malware detection metadata can include signatures, heuristics, data to drive emulation, dynamic translation, cloud queries, and/or machine learning-based techniques (such as, but not limited to, machine data learning models, behavioral analysis, etc.). In some implementations, the functionality of the AVP system 180 is performed, within a protected environment that is isolated from the operating system (for example, using virtualization-based security techniques). In one implementation, AVP system 180 is configured to perform automatic remediation of a generic class of malware which in one example modifies data or files belonging to the operating system. For example, malware detection metadata defines a list of system binary files and configuration files targeted by malware.
[0060] Similarly, in some other implementations, the system can be configured to detect attempts to modify the tamper protection feature by an unauthorized user or other malicious application. In some cases, in response to a detection of such an attempt, the client device can cause a notification to be generated for the security administrator's review. These notifications can be automated, and may be transmitted per system settings and/or security admin preferences, including but not limited to e-mail messages, text messages, chat messages, pop-up windows, automated phone calls, any other form of communication associated with the user's account may be used to provide such information. For example, the system may be configured to detect instances in which a threat attack is directed to the tamper protection feature, an attempt to alter the configuration via registry or other settings is made, or an endpoint device has determined that a command is expired, is associated with an inappropriate tenant identifier, and/or has a signature that cannot be verified.
It would have been obvious to a person of ordinary skill in the art at the time of the effective filing of the instant application to modify Bhatia/Shahriva/Srivatsa with training a machine learning model to detect and generate rules to prevent alteration to security/protection settings as taught by Shadbolt. The reason for this modification would be to generate rules that protect against know threat/attack vectors
Regarding claim 29, Bhatia/Shahriva/Srivatsa do not teach wherein the at least one respective representative attribute comprises registry information. Shadbolt in the same field of endeavor teaches a system for tamper detection and mitigation using machine learning models. Shadbolt teaches wherein the at least one respective representative attribute comprises registry information( machine learning models trained to detect changes to registry ¶s,60)
[0060] Similarly, in some other implementations, the system can be configured to detect attempts to modify the tamper protection feature by an unauthorized user or other malicious application. In some cases, in response to a detection of such an attempt, the client device can cause a notification to be generated for the security administrator's review. These notifications can be automated, and may be transmitted per system settings and/or security admin preferences, including but not limited to e-mail messages, text messages, chat messages, pop-up windows, automated phone calls, any other form of communication associated with the user's account may be used to provide such information. For example, the system may be configured to detect instances in which a threat attack is directed to the tamper protection feature, an attempt to alter the configuration via registry or other settings is made, or an endpoint device has determined that a command is expired, is associated with an inappropriate tenant identifier, and/or has a signature that cannot be verified.
It would have been obvious to a person of ordinary skill in the art at the time of the effective filing of the instant application to modify Bhatia/Shahriva/Srivatsa with training a machine learning model to detect and generate rules to prevent alteration to security/protection settings as taught by Shadbolt. The reason for this modification would be to generate rules that protect against know threat/attack vectors.
Claims 1 and 9 are rejected under 35 U.S.C. 103 as being unpatentable over Bhatia US 2020/0272741, and further in view of Karanam US 2021/0150264.
Regarding claims 1 and 9, Bhatia teaches a device and method comprising:
generating a representative attributes template for use in a production environment(generate detection rules from threat characteristics, ¶103)
[0103] Once trained to correlate input threat characteristics with output SIEM rule components, when the RNN 124 is presented with new threat characteristics, such as may be identified from parsing and NLP performed on threat intelligence feeds from the threat intelligence feed computing systems 160 or external source computing systems 170, the RNN 124 is able to automatically generate the correct combination of STEM rule components, and their sequence, that should be used to define a SIEM rule to address the new threat. The output from the RNN 124 may then be input to a template used by the rule generation engine 122 to convert the output of the RNN 124 into a text definition of the STEM rule's test, such as the test portion of the SIEM rule shown in FIG. 3, as discussed previously. The newly generated rule may then be deployed to the enterprise computing environment 130 as part of a modified SIEM rule set data structure 136, for example.
wherein the representative attributes template as associated with an anomaly, wherein the representative attributes template identifies representative attributes to be collected for security analysis of the anomaly(threat characteristics , anomaly conditions correspond to attribute that represent an attack/threats, such characteristics are collected for machine learning engine to generate detection rules, ¶s43,97)
[0043] In further aspects of the illustrative embodiments, the ARA provides mechanisms for decomposing rules into their constituent components, e.g., rule conditions, for use in generating new rules. The ARA trains a machine learning or cognitive computing system comprising machine learning mechanisms, such as a Recurrent Neural Network (RNN) or the like, to learn to generate new rules from threat characteristics and from various rule conditions available from STEM rule creation tools. That is, the ARA is trained using known threat characteristics and known rules with their corresponding conditions, to learn how human analysts compose rules to address threats, e.g., when these threat characteristics are present, human analysts uses these rule conditions to address those threat characteristics. Based on this learning, through a supervised machine learning process, the RNN is trained such that when given input threat characteristics and/or rule conditions that are satisfied by a threat, the RNN generates a new SIEM rule based on its machine learning, such that the new SIEM rule may be presented to a human analyst for consideration, editing, and deployment into an enterprise STEM rule set, or in some cases may be automatically deployed without human intervention.
[0097] FIG. 10A is an example diagram illustrating the STEM rules that may be provided by a STEM tools provider computing system 190 to the rule decomposition engine 120. The parse and NLP engine 102 of the ARA 100 may be employed by the rule decomposition engine 120 to parse and perform NLP operations on the STEM rules, or the “cleaned” or reformatted version of these SIEM rules, so as to extract the various conditions of the STEM rules, e.g., offense conditions, flow conditions, behavior conditions, event conditions, anomaly conditions, threshold conditions, and common conditions. Such conditions are typically used by analysts to manually create rules combining them with thresholds, clauses, log sources, etc. These conditions are compared and used to train a machine learning model to create new rules.
And wherein generating the representative attributes template comprises generating multiple respective template for multiple respective instances of the anomaly, wherein generating a respective template comprises of the multiple respective templates comprises (The process of machine learning comprise a iterative process where the machine learning algorithm learns threat characteristics such learning comprises multiple iterations(i.e. cycles) where the RNN output rule components on each iterations as it refines toward a convergence RNN model , ¶s 45,97,100 )
[0045] It should be appreciated that while the illustrative embodiments described herein reference SIEM rules and security rule based computing environments, the illustrative embodiments may be applied to any rules and rule based computing environments, including other security rules and non-security rules, e.g., business rules or the like. SIEM rules are based off of events or flows from inline network devices throughout a network of a managed computing environment, e.g., events may be obtained from firewalls, servers, endpoints, and the like, and the SIEM rules are applied based on the activities happening throughout the network. Other types of security rules are also inline or are associated with span/tap ports and look at packet level datagrams and take actions based on packet signatures or heuristics. Business rules based computing mechanisms provide structured logic for controlling the operation or behavior of a business by describing the operations, definitions, and constraints that apply to the organization, such that the rules may be applied by appropriate computing systems to control interactions of processes and the flow of data in the computing environment. In any of these cases, the mechanism of the illustrative embodiments described herein may be implemented to perform rule management and generation, and in some illustrative embodiments may be implemented with regard specifically to SIEM rules, as will be assumed in the following description for purposes of illustration. Thus, in general, references to SIEM rules hereafter may also be considered to reference other types of security rules, or rules used in other computing environments, in other illustrative embodiments.
[0097] FIG. 10A is an example diagram illustrating the STEM rules that may be provided by a STEM tools provider computing system 190 to the rule decomposition engine 120. The parse and NLP engine 102 of the ARA 100 may be employed by the rule decomposition engine 120 to parse and perform NLP operations on the STEM rules, or the “cleaned” or reformatted version of these SIEM rules, so as to extract the various conditions of the STEM rules, e.g., offense conditions, flow conditions, behavior conditions, event conditions, anomaly conditions, threshold conditions, and common conditions. Such conditions are typically used by analysts to manually create rules combining them with thresholds, clauses, log sources, etc. These conditions are compared and used to train a machine learning model to create new rules.
[0100] This process is performed in an iterative manner until a convergence of the RNN 124 is achieved and the error is less than a predetermined threshold. Because the RNN 124 includes the ability to track patterns with regard to a temporal aspect, the RNN 124 can not only learn the particular STEM rule components to utilize, but the particular sequence of these STEM rule components, leading to an output of a sequence of SIEM rule components that together constitute a new STEM rule definition to address the threat characteristics.
receiving respective security event information comprising at least one attribute associated with an instance of the anomaly(SIEM system received threat data and updates or creates new detection/security rules based the data, analysis and rule generation is created from a machine learning model for each event/incident detected ¶s30, 97)
[0030] A Security Incident and Event Management (SIEM) tool or system is the backbone of threat monitoring and detection in a security operations center (SOC). As mentioned above, the SIEM tool or system uses rule correlation to trigger offenses when specific events meet rule threshold criteria. These offenses are then examined by a human or machine analyst to make decisions on whether or not to escalate the offense as a “security incident” and take appropriate remediation action. A security rule, such as a SIEM rule, or simply “rule”, is a data structure that specifies a series of complex logical statements that include correlation logic on log sources, conditions, operators, and thresholds for rule firing, e.g., generating an alert notification as to a detected threat. An example SIEM tool or system installation comes with over 100-300 “out of the box” rules and several more are added when new log sources are commissioned, or new threat intelligence feeds are received. New custom rules are also added continuously on client requests or when a change is detected in the environment.
[0097] FIG. 10A is an example diagram illustrating the STEM rules that may be provided by a STEM tools provider computing system 190 to the rule decomposition engine 120. The parse and NLP engine 102 of the ARA 100 may be employed by the rule decomposition engine 120 to parse and perform NLP operations on the STEM rules, or the “cleaned” or reformatted version of these SIEM rules, so as to extract the various conditions of the STEM rules, e.g., offense conditions, flow conditions, behavior conditions, event conditions, anomaly conditions, threshold conditions, and common conditions. Such conditions are typically used by analysts to manually create rules combining them with thresholds, clauses, log sources, etc. These conditions are compared and used to train a machine learning model to create new rules.
providing the security event information as an input to a neural network-based processor;(threat characteristics provided to RNN, ¶43)
identifying, by the neural network-based processor, at least one respective representative attribute based on the input, wherein the at least one respective representative attribute includes one or more of the at least one attribute or at least one other attribute other than the at least one attribute(threat characteristics are extracted and used to create generate detection rules, ¶43)
[0043] In further aspects of the illustrative embodiments, the ARA provides mechanisms for decomposing rules into their constituent components, e.g., rule conditions, for use in generating new rules. The ARA trains a machine learning or cognitive computing system comprising machine learning mechanisms, such as a Recurrent Neural Network (RNN) or the like, to learn to generate new rules from threat characteristics and from various rule conditions available from STEM rule creation tools. That is, the ARA is trained using known threat characteristics and known rules with their corresponding conditions, to learn how human analysts compose rules to address threats, e.g., when these threat characteristics are present, human analysts uses these rule conditions to address those threat characteristics. Based on this learning, through a supervised machine learning process, the RNN is trained such that when given input threat characteristics and/or rule conditions that are satisfied by a threat, the RNN generates a new SIEM rule based on its machine learning, such that the new SIEM rule may be presented to a human analyst for consideration, editing, and deployment into an enterprise STEM rule set, or in some cases may be automatically deployed without human intervention.
wherein the at least one respective representative attribute is determined by the neural network- based processor to represent the instance of the anomaly for security analyses of production environment instances of the anomaly(neural network machine learning with NLP used to process input to generate rules, ¶97)
[0097] FIG. 10A is an example diagram illustrating the STEM rules that may be provided by a STEM tools provider computing system 190 to the rule decomposition engine 120. The parse and NLP engine 102 of the ARA 100 may be employed by the rule decomposition engine 120 to parse and perform NLP operations on the STEM rules, or the “cleaned” or reformatted version of these SIEM rules, so as to extract the various conditions of the STEM rules, e.g., offense conditions, flow conditions, behavior conditions, event conditions, anomaly conditions, threshold conditions, and common conditions. Such conditions are typically used by analysts to manually create rules combining them with thresholds, clauses, log sources, etc. These conditions are compared and used to train a machine learning model to create new rules.
And including the at least one respective representative attribute in the respective template(rule conditions represent learned threat characteristics for detecting threats, ¶97)
[0097] FIG. 10A is an example diagram illustrating the STEM rules that may be provided by a STEM tools provider computing system 190 to the rule decomposition engine 120. The parse and NLP engine 102 of the ARA 100 may be employed by the rule decomposition engine 120 to parse and perform NLP operations on the STEM rules, or the “cleaned” or reformatted version of these SIEM rules, so as to extract the various conditions of the STEM rules, e.g., offense conditions, flow conditions, behavior conditions, event conditions, anomaly conditions, threshold conditions, and common conditions. Such conditions are typically used by analysts to manually create rules combining them with thresholds, clauses, log sources, etc. These conditions are compared and used to train a machine learning model to create new rules.
deploying a representative attributes template to the respective generated templates to the production environment configured to automatically detect the production environment instances of the anomaly in the network, wherein the production environment is configured to use representative the template to define at least one collected attribute that is collected for the security analyses of the instances production environment of the anomaly(the created new rules can be deployed to the system automatically or after human administrator approval, ¶43 , upon a similarity threshold rules are aggregated into rule and deployed, ¶114).
[0043] In further aspects of the illustrative embodiments, the ARA provides mechanisms for decomposing rules into their constituent components, e.g., rule conditions, for use in generating new rules. The ARA trains a machine learning or cognitive computing system comprising machine learning mechanisms, such as a Recurrent Neural Network (RNN) or the like, to learn to generate new rules from threat characteristics and from various rule conditions available from STEM rule creation tools. That is, the ARA is trained using known threat characteristics and known rules with their corresponding conditions, to learn how human analysts compose rules to address threats, e.g., when these threat characteristics are present, human analysts uses these rule conditions to address those threat characteristics. Based on this learning, through a supervised machine learning process, the RNN is trained such that when given input threat characteristics and/or rule conditions that are satisfied by a threat, the RNN generates a new SIEM rule based on its machine learning, such that the new SIEM rule may be presented to a human analyst for consideration, editing, and deployment into an enterprise STEM rule set, or in some cases may be automatically deployed without human intervention.
[0114] Thus, as shown in FIG. 14, the similarity measures are compared to a predetermined threshold value indicating a threshold level or degree of similarity for integration of standard SIEM rules into the SIEM rule set data structure (step 1470). For those standard SIEM rules in the standard SIEM rule repository, that do not have a corresponding similarity measure with an existing SIEM rule in the SIEM rule set data structure that is equal to or above the predetermined threshold value, those standard SIEM rules are added to the SIEM rule set data structure to generate a modified SIEM rule set data structure (step 1480). The modified SIEM rules data structure is returned to the computing environment for deployment and utilization in monitoring and managing security incidents and events (step 1490). The operation then terminates.
Bhatia teach training until convergence(¶100) but does not teach similarity as a measure of convergence performing a consistency check comprising comparing the multiple respective templates to determine whether the multiple respective templates satisfy a predefined similarity threshold;
and in response to the multiple respective templates satisfying the predefined similarity threshold including identifications of representative attributes from at least one of the multiple respective templates in the representative attributes template. Karanam being reasonably relevant to the problem of creating accurate machine learning models teaches method for ensuring model accuracy. Karanam teaches performing a consistency check comprising comparing the multiple respective templates to determine whether the multiple respective templates satisfy a predefined similarity threshold(feature vector generation is a iterative process that executes multiple cycles of training until convergence(ie. similarity of feature) is acchieved ¶s 5, 16, 17)
and in response to the multiple respective templates satisfying the predefined similarity threshold including identifications of representative attributes from at least one of the multiple respective templates in the representative attributes template(once convergence is reached the feature vector is accurate enough to be using in visual recognition, ¶s5,16,17 )
[0005] In an initialization cycle, given a 3D rendering of a physical environment (e.g., a CAD rendering of a system of components which are target objects for object recognition), random 2D images of various viewpoint poses may be rendered to simulate various perspectives useful for finding candidate keypoints. The rendered images may be used to generate training data for learning viewpoint invariant feature representations from which keypoints may be generated. For example, given a test image having viewpoint pose information, a point in the image may be randomly sampled and a correspondence in a rendered image of another pose may be determined. The rendered image may be generated by perturbing the given pose of the test image. Locating local patches around the two corresponding points may generate a pair of similar patches, which may train a convolutional neural network to learn a feature representation that is viewpoint invariant. Sample keypoints may be randomly selected from a test image, and compared to random keypoints of reference images to generate data to train a keypoint detector network. The previously trained feature representation network may be used to process each candidate keypoint and reference keypoint for assigning a score to the candidate keypoint. This score is representative of two key properties of keypoints: repeatability and uniqueness. The data generated in this fashion may be used to train the keypoint detector network. After the feature representation network and the keypoint detector network are trained by the initialization phase, an iterative refinement may be performed in subsequent cycles. Using the keypoint detector, keypoints in the images may be detected and patches may be sampled around these keypoints. These patches may be used as input to refine the feature representation network. This iterative procedure of refining the feature representation network and keypoint detector network may be repeated until convergence.
[0016] Methods and systems are disclosed for visual recognition of objects in images using machine learning to train a first network to detect strong localized features, called keypoints, in the presence of image noise caused by visual sensors. Conventional object recognition systems that employ keypoint matching are hindered by sensor noise and tend to identify weak keypoints that may be representative of a feature influenced by the noise instead of an actual physical feature of the target object. A second network may be trained by machine learning to determine viewpoint invariant feature representations of patches around the detected keypoints in a target image. The advantage of viewpoint invariance is to enhance recognition of regions in a target image which correspond to stored feature representations of the regions in an inventory library where the stored feature representations may be of a viewpoint not identical to the target image. Multiple cycles of keypoint detection and feature representation generation may be applied to the first and second networks for learning refinement until convergence. Application of the trained first and second networks of the visual recognition system include processing input images to find strong keypoints within the images, identify the feature representations of the images based on the keypoints, and identify objects in the image based on matching the feature representations to a library of objects indexed by the features.
[0017]…. During training of the keypoint detector network at stage 104, the labeled keypoints may be input to the network. The learning of the keypoint detector network is semi-supervised since the labels were generated without manual assistance or tagging using human expertise. An advantage of the iterative learning process of this disclosure is eliminating the need for a source of labeled training images, such as photos or other images obtained by cameras or vision sensors, which may be corrupted by sensor noise and interference. With both neural networks trained, additional cycles of the process 100 for the visual recognition system may be executed iteratively to refine the machine learning by feeding labeled keypoints from the keypoint detector network to the feature representative network, and determining stronger keypoints with each iteration of the learning by the feature representation network. The next cycle begins at stage 105, in which one or more rendered images may be processed by the trained keypoint detector to process patches to determine keypoints and corresponding score values. Patch pairs may be generated and labeled according to the score values as refined training data for refined learning by the trained feature representation network at a second iteration of stage 102. For example, patches with high scores (e.g., score value 0.5<S<=1) may be paired to be labeled as similar patch pairs, and patches with low scores (e.g., 0<S<=0.5) may be paired to be labeled as dissimilar patch pairs. Various ranges may be set for high and low scores, including but not limited to 0<S<=0.7 for low score and 0.7<S<1 for high score. Successive cycles of process 100 may be repeated until a convergence is reached. In an embodiment, accuracy of the trained networks may be evaluated with a validating dataset to verify convergence.
It would have been obvious to a person of ordinary skill in the art at the time of the effective filing of the instant application to modify Bhatia’s training of model generating security rules with the method of iterative model training until the performance of the model reaches a convergence . The reason for this modification would be to ensure a that rules can accurately(i.e. consistently) detect anomalies and that such rules can be updated in response to new threats.
Claims 17 are rejected under 35 U.S.C. 103 as being unpatentable over Bhatia/Shahriva and further in view of Karanam US 2021/0150264.
Regarding claim 17, Regarding claims 1 and 9, Bhatia teaches a method comprising:
generating a representative attributes template for use in a production environment(generate detection rules from threat characteristics, ¶103)
[0103] Once trained to correlate input threat characteristics with output SIEM rule components, when the RNN 124 is presented with new threat characteristics, such as may be identified from parsing and NLP performed on threat intelligence feeds from the threat intelligence feed computing systems 160 or external source computing systems 170, the RNN 124 is able to automatically generate the correct combination of STEM rule components, and their sequence, that should be used to define a SIEM rule to address the new threat. The output from the RNN 124 may then be input to a template used by the rule generation engine 122 to convert the output of the RNN 124 into a text definition of the STEM rule's test, such as the test portion of the SIEM rule shown in FIG. 3, as discussed previously. The newly generated rule may then be deployed to the enterprise computing environment 130 as part of a modified SIEM rule set data structure 136, for example.
wherein the representative attributes template as associated with an anomaly, wherein the representative attributes template identifies representative attributes to be collected for security analysis of the anomaly(threat characteristics , anomaly conditions correspond to attribute that represent an attack/threats, such characteristics are collected for machine learning engine to generate detection rules, ¶s43,97)
[0043] In further aspects of the illustrative embodiments, the ARA provides mechanisms for decomposing rules into their constituent components, e.g., rule conditions, for use in generating new rules. The ARA trains a machine learning or cognitive computing system comprising machine learning mechanisms, such as a Recurrent Neural Network (RNN) or the like, to learn to generate new rules from threat characteristics and from various rule conditions available from STEM rule creation tools. That is, the ARA is trained using known threat characteristics and known rules with their corresponding conditions, to learn how human analysts compose rules to address threats, e.g., when these threat characteristics are present, human analysts uses these rule conditions to address those threat characteristics. Based on this learning, through a supervised machine learning process, the RNN is trained such that when given input threat characteristics and/or rule conditions that are satisfied by a threat, the RNN generates a new SIEM rule based on its machine learning, such that the new SIEM rule may be presented to a human analyst for consideration, editing, and deployment into an enterprise STEM rule set, or in some cases may be automatically deployed without human intervention.
[0097] FIG. 10A is an example diagram illustrating the STEM rules that may be provided by a STEM tools provider computing system 190 to the rule decomposition engine 120. The parse and NLP engine 102 of the ARA 100 may be employed by the rule decomposition engine 120 to parse and perform NLP operations on the STEM rules, or the “cleaned” or reformatted version of these SIEM rules, so as to extract the various conditions of the STEM rules, e.g., offense conditions, flow conditions, behavior conditions, event conditions, anomaly conditions, threshold conditions, and common conditions. Such conditions are typically used by analysts to manually create rules combining them with thresholds, clauses, log sources, etc. These conditions are compared and used to train a machine learning model to create new rules.
And wherein generating the representative attributes template comprises generating multiple respective template for multiple respective instances of the anomaly, wherein generating a respective template comprises of the multiple respective templates comprises (The process of machine learning comprise a iterative process where the machine learning algorithm learns threat characteristics such learning comprises multiple iterations(i.e. cycles) where the RNN output rule components on each iterations as it refines toward a convergence RNN model , ¶s 45,97,100 )
[0045] It should be appreciated that while the illustrative embodiments described herein reference SIEM rules and security rule based computing environments, the illustrative embodiments may be applied to any rules and rule based computing environments, including other security rules and non-security rules, e.g., business rules or the like. SIEM rules are based off of events or flows from inline network devices throughout a network of a managed computing environment, e.g., events may be obtained from firewalls, servers, endpoints, and the like, and the SIEM rules are applied based on the activities happening throughout the network. Other types of security rules are also inline or are associated with span/tap ports and look at packet level datagrams and take actions based on packet signatures or heuristics. Business rules based computing mechanisms provide structured logic for controlling the operation or behavior of a business by describing the operations, definitions, and constraints that apply to the organization, such that the rules may be applied by appropriate computing systems to control interactions of processes and the flow of data in the computing environment. In any of these cases, the mechanism of the illustrative embodiments described herein may be implemented to perform rule management and generation, and in some illustrative embodiments may be implemented with regard specifically to SIEM rules, as will be assumed in the following description for purposes of illustration. Thus, in general, references to SIEM rules hereafter may also be considered to reference other types of security rules, or rules used in other computing environments, in other illustrative embodiments.
[0097] FIG. 10A is an example diagram illustrating the STEM rules that may be provided by a STEM tools provider computing system 190 to the rule decomposition engine 120. The parse and NLP engine 102 of the ARA 100 may be employed by the rule decomposition engine 120 to parse and perform NLP operations on the STEM rules, or the “cleaned” or reformatted version of these SIEM rules, so as to extract the various conditions of the STEM rules, e.g., offense conditions, flow conditions, behavior conditions, event conditions, anomaly conditions, threshold conditions, and common conditions. Such conditions are typically used by analysts to manually create rules combining them with thresholds, clauses, log sources, etc. These conditions are compared and used to train a machine learning model to create new rules.
[0100] This process is performed in an iterative manner until a convergence of the RNN 124 is achieved and the error is less than a predetermined threshold. Because the RNN 124 includes the ability to track patterns with regard to a temporal aspect, the RNN 124 can not only learn the particular STEM rule components to utilize, but the particular sequence of these STEM rule components, leading to an output of a sequence of SIEM rule components that together constitute a new STEM rule definition to address the threat characteristics.
receiving respective security event information comprising at least one attribute associated with an instance of the anomaly(SIEM system received threat data and updates or creates new detection/security rules based the data, analysis and rule generation is created from a machine learning model for each event/incident detected ¶s30, 97)
[0030] A Security Incident and Event Management (SIEM) tool or system is the backbone of threat monitoring and detection in a security operations center (SOC). As mentioned above, the SIEM tool or system uses rule correlation to trigger offenses when specific events meet rule threshold criteria. These offenses are then examined by a human or machine analyst to make decisions on whether or not to escalate the offense as a “security incident” and take appropriate remediation action. A security rule, such as a SIEM rule, or simply “rule”, is a data structure that specifies a series of complex logical statements that include correlation logic on log sources, conditions, operators, and thresholds for rule firing, e.g., generating an alert notification as to a detected threat. An example SIEM tool or system installation comes with over 100-300 “out of the box” rules and several more are added when new log sources are commissioned, or new threat intelligence feeds are received. New custom rules are also added continuously on client requests or when a change is detected in the environment.
[0097] FIG. 10A is an example diagram illustrating the STEM rules that may be provided by a STEM tools provider computing system 190 to the rule decomposition engine 120. The parse and NLP engine 102 of the ARA 100 may be employed by the rule decomposition engine 120 to parse and perform NLP operations on the STEM rules, or the “cleaned” or reformatted version of these SIEM rules, so as to extract the various conditions of the STEM rules, e.g., offense conditions, flow conditions, behavior conditions, event conditions, anomaly conditions, threshold conditions, and common conditions. Such conditions are typically used by analysts to manually create rules combining them with thresholds, clauses, log sources, etc. These conditions are compared and used to train a machine learning model to create new rules.
providing the security event information as an input to a neural network-based processor;(threat characteristics provided to RNN, ¶43)
identifying, by the neural network-based processor, at least one respective representative attribute based on the input, wherein the at least one respective representative attribute includes one or more of the at least one attribute or at least one other attribute other than the at least one attribute(threat characteristics are extracted and used to create generate detection rules, ¶43)
[0043] In further aspects of the illustrative embodiments, the ARA provides mechanisms for decomposing rules into their constituent components, e.g., rule conditions, for use in generating new rules. The ARA trains a machine learning or cognitive computing system comprising machine learning mechanisms, such as a Recurrent Neural Network (RNN) or the like, to learn to generate new rules from threat characteristics and from various rule conditions available from STEM rule creation tools. That is, the ARA is trained using known threat characteristics and known rules with their corresponding conditions, to learn how human analysts compose rules to address threats, e.g., when these threat characteristics are present, human analysts uses these rule conditions to address those threat characteristics. Based on this learning, through a supervised machine learning process, the RNN is trained such that when given input threat characteristics and/or rule conditions that are satisfied by a threat, the RNN generates a new SIEM rule based on its machine learning, such that the new SIEM rule may be presented to a human analyst for consideration, editing, and deployment into an enterprise STEM rule set, or in some cases may be automatically deployed without human intervention.
wherein the at least one respective representative attribute is determined by the neural network- based processor to represent the instance of the anomaly for security analyses of production environment instances of the anomaly(neural network machine learning with NLP used to process input to generate rules, ¶97)
[0097] FIG. 10A is an example diagram illustrating the STEM rules that may be provided by a STEM tools provider computing system 190 to the rule decomposition engine 120. The parse and NLP engine 102 of the ARA 100 may be employed by the rule decomposition engine 120 to parse and perform NLP operations on the STEM rules, or the “cleaned” or reformatted version of these SIEM rules, so as to extract the various conditions of the STEM rules, e.g., offense conditions, flow conditions, behavior conditions, event conditions, anomaly conditions, threshold conditions, and common conditions. Such conditions are typically used by analysts to manually create rules combining them with thresholds, clauses, log sources, etc. These conditions are compared and used to train a machine learning model to create new rules.
And including the at least one respective representative attribute in the respective template(rule conditions represent learned threat characteristics for detecting threats, ¶97)
[0097] FIG. 10A is an example diagram illustrating the STEM rules that may be provided by a STEM tools provider computing system 190 to the rule decomposition engine 120. The parse and NLP engine 102 of the ARA 100 may be employed by the rule decomposition engine 120 to parse and perform NLP operations on the STEM rules, or the “cleaned” or reformatted version of these SIEM rules, so as to extract the various conditions of the STEM rules, e.g., offense conditions, flow conditions, behavior conditions, event conditions, anomaly conditions, threshold conditions, and common conditions. Such conditions are typically used by analysts to manually create rules combining them with thresholds, clauses, log sources, etc. These conditions are compared and used to train a machine learning model to create new rules.
deploying a representative attributes template to the respective generated templates to the production environment configured to automatically detect the production environment instances of the anomaly in the network, wherein the production environment is configured to use representative the template to define at least one collected attribute that is collected for the security analyses of the instances production environment of the anomaly(the created new rules can be deployed to the system automatically or after human administrator approval, ¶43 , upon a similarity threshold rules are aggregated into rule and deployed, ¶114).
[0043] In further aspects of the illustrative embodiments, the ARA provides mechanisms for decomposing rules into their constituent components, e.g., rule conditions, for use in generating new rules. The ARA trains a machine learning or cognitive computing system comprising machine learning mechanisms, such as a Recurrent Neural Network (RNN) or the like, to learn to generate new rules from threat characteristics and from various rule conditions available from STEM rule creation tools. That is, the ARA is trained using known threat characteristics and known rules with their corresponding conditions, to learn how human analysts compose rules to address threats, e.g., when these threat characteristics are present, human analysts uses these rule conditions to address those threat characteristics. Based on this learning, through a supervised machine learning process, the RNN is trained such that when given input threat characteristics and/or rule conditions that are satisfied by a threat, the RNN generates a new SIEM rule based on its machine learning, such that the new SIEM rule may be presented to a human analyst for consideration, editing, and deployment into an enterprise STEM rule set, or in some cases may be automatically deployed without human intervention.
[0114] Thus, as shown in FIG. 14, the similarity measures are compared to a predetermined threshold value indicating a threshold level or degree of similarity for integration of standard SIEM rules into the SIEM rule set data structure (step 1470). For those standard SIEM rules in the standard SIEM rule repository, that do not have a corresponding similarity measure with an existing SIEM rule in the SIEM rule set data structure that is equal to or above the predetermined threshold value, those standard SIEM rules are added to the SIEM rule set data structure to generate a modified SIEM rule set data structure (step 1480). The modified SIEM rules data structure is returned to the computing environment for deployment and utilization in monitoring and managing security incidents and events (step 1490). The operation then terminates.
Bhatia teach training until convergence(¶100) but does not teach similarity as a measure of convergence performing a consistency check comprising comparing the multiple respective templates to determine whether the multiple respective templates satisfy a predefined similarity threshold;
and in response to the multiple respective templates satisfying the predefined similarity threshold including identifications of representative attributes from at least one of the multiple respective templates in the representative attributes template. Karanam being reasonably relevant to the problem of creating accurate machine learning models teaches method for ensuring model accuracy. Karanam teaches performing a consistency check comprising comparing the multiple respective templates to determine whether the multiple respective templates satisfy a predefined similarity threshold(feature vector generation is a iterative process that executes multiple cycles of training until convergence(ie. similarity of feature) is acchieved ¶s 5, 16, 17)
and in response to the multiple respective templates satisfying the predefined similarity threshold including identifications of representative attributes from at least one of the multiple respective templates in the representative attributes template(once convergence is reached the feature vector is accurate enough to be using in visual recognition, ¶s5,16,17 )
[0005] In an initialization cycle, given a 3D rendering of a physical environment (e.g., a CAD rendering of a system of components which are target objects for object recognition), random 2D images of various viewpoint poses may be rendered to simulate various perspectives useful for finding candidate keypoints. The rendered images may be used to generate training data for learning viewpoint invariant feature representations from which keypoints may be generated. For example, given a test image having viewpoint pose information, a point in the image may be randomly sampled and a correspondence in a rendered image of another pose may be determined. The rendered image may be generated by perturbing the given pose of the test image. Locating local patches around the two corresponding points may generate a pair of similar patches, which may train a convolutional neural network to learn a feature representation that is viewpoint invariant. Sample keypoints may be randomly selected from a test image, and compared to random keypoints of reference images to generate data to train a keypoint detector network. The previously trained feature representation network may be used to process each candidate keypoint and reference keypoint for assigning a score to the candidate keypoint. This score is representative of two key properties of keypoints: repeatability and uniqueness. The data generated in this fashion may be used to train the keypoint detector network. After the feature representation network and the keypoint detector network are trained by the initialization phase, an iterative refinement may be performed in subsequent cycles. Using the keypoint detector, keypoints in the images may be detected and patches may be sampled around these keypoints. These patches may be used as input to refine the feature representation network. This iterative procedure of refining the feature representation network and keypoint detector network may be repeated until convergence.
[0016] Methods and systems are disclosed for visual recognition of objects in images using machine learning to train a first network to detect strong localized features, called keypoints, in the presence of image noise caused by visual sensors. Conventional object recognition systems that employ keypoint matching are hindered by sensor noise and tend to identify weak keypoints that may be representative of a feature influenced by the noise instead of an actual physical feature of the target object. A second network may be trained by machine learning to determine viewpoint invariant feature representations of patches around the detected keypoints in a target image. The advantage of viewpoint invariance is to enhance recognition of regions in a target image which correspond to stored feature representations of the regions in an inventory library where the stored feature representations may be of a viewpoint not identical to the target image. Multiple cycles of keypoint detection and feature representation generation may be applied to the first and second networks for learning refinement until convergence. Application of the trained first and second networks of the visual recognition system include processing input images to find strong keypoints within the images, identify the feature representations of the images based on the keypoints, and identify objects in the image based on matching the feature representations to a library of objects indexed by the features.
[0017]…. During training of the keypoint detector network at stage 104, the labeled keypoints may be input to the network. The learning of the keypoint detector network is semi-supervised since the labels were generated without manual assistance or tagging using human expertise. An advantage of the iterative learning process of this disclosure is eliminating the need for a source of labeled training images, such as photos or other images obtained by cameras or vision sensors, which may be corrupted by sensor noise and interference. With both neural networks trained, additional cycles of the process 100 for the visual recognition system may be executed iteratively to refine the machine learning by feeding labeled keypoints from the keypoint detector network to the feature representative network, and determining stronger keypoints with each iteration of the learning by the feature representation network. The next cycle begins at stage 105, in which one or more rendered images may be processed by the trained keypoint detector to process patches to determine keypoints and corresponding score values. Patch pairs may be generated and labeled according to the score values as refined training data for refined learning by the trained feature representation network at a second iteration of stage 102. For example, patches with high scores (e.g., score value 0.5<S<=1) may be paired to be labeled as similar patch pairs, and patches with low scores (e.g., 0<S<=0.5) may be paired to be labeled as dissimilar patch pairs. Various ranges may be set for high and low scores, including but not limited to 0<S<=0.7 for low score and 0.7<S<1 for high score. Successive cycles of process 100 may be repeated until a convergence is reached. In an embodiment, accuracy of the trained networks may be evaluated with a validating dataset to verify convergence.
It would have been obvious to a person of ordinary skill in the art at the time of the effective filing of the instant application to modify Bhatia’s training of model generating security rules with the method of iterative model training until the performance of the model reaches a convergence . The reason for this modification would be to ensure a that rules can accurately(i.e. consistently) detect anomalies and that such rules can be updated in response to new threats.
Bhatia teaches a language based(NLP -based ) neural network but does not specifically teach the neural network is a large network model. Srivatsa in the same field of endeavor teach a machine learning based system for network traffic anomaly detection. Srivatsa teaches the neural network is a large network model(BERT LLM used to train model and generated a trained model for anomaly detection, ¶26).
[0026] Deep neural network models have been applied to natural language processing (NLP) and image based tasks. For application to network analysis and detection of anomalies in network traffic for a network, one or more embodiments provide deep neural network models that can be effectively generalized to perform very well on multiple network tasks in different environments. Traditional deep models often rely on categorical features but cannot handle unseen categorical features/values. One method according to one or more embodiments for addressing such problems is to learn contextual embeddings for categorical features/variables used by deep neural networks in order to improve their performance. As discussed herein, one or more embodiments can adapt the NLP pre-training technique and associated deep model BERT to learn semantically meaningful numerical representations (contextual embeddings) for Fully Qualified Domain Names (FQDNs), protocol fields, protocol values, and/or other categorical features used in a communications network, which can be used to quickly detect anomalies and improve cyber security protection, or achieve other network management tasks (e.g., flow classification). One or more techniques of embodiments walk through a series of experiments illustrating that such techniques can be used to generate foundational models that maintain their effectiveness when applied to environments other than the one in which they were trained, thereby being modified for communication networks according to one or more embodiments.
It would have been obvious to a person of ordinary skill in the art at the time of the effective filing of the instant application to modify Bhatia/Shahriva with a large language model type neural network to train and generate trained detection models as taught by Srivatsa. The reason for this modification would be to improve rule generation using well known equivalents to a NLP based neural network.
Applicant Remarks
Applicant’s arguments with respect to claims 1,7-9,15-17 and 21-33 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.
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 Tom Y. Chang whose telephone number is 571-270-5938. The examiner can normally be reached on Monday-Friday from 9am to 5pm.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Emmanuel Moise, can be reached on (571)272-3865. 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 Patent Center. Status information for published applications may be obtained from Patent Center. Status information for unpublished applications is available through Patent Center for authorized users only. Should you have questions about access to Patent Center, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
/TOM Y CHANG/
Primary Examiner, Art Unit 2455
Prosecution Insights