The present invention relates generally to computer security and networks, and particularly to improving Security Operations Center (SOC) efficiency and coverage with a network adaptive cybersecurity incident prioritization system.
Security operations centers (SOCs) comprise facilities where teams of information technology (IT) professionals monitor, analyze and protect organizations from cyber-attacks. In the SOC, internet traffic, networks, desktops, servers, endpoint devices, databases, applications and other systems are continuously monitored for signs of a security incident. In operation, SOCs can reduce the impact of potential data breaches by helping organizations respond to intrusions quickly.
The description above is presented as a general overview of related art in this field and should not be construed as an admission that any of the information it contains constitutes prior art against the present patent application.
There is provided, in accordance with an embodiment of the present invention, a method including receiving, from a plurality of sources, respective sets of incidents, and respective source-assigned suspiciousness labels for the incidents, applying a set of labeling rules so as to assign rule-based labels to respective incidents in a subset of the incidents in the received sets, comparing, in each of the incidents in the subset, the respective rule-based label to the respective source-assigned suspiciousness label so as to compute a respective label quality score for each of the sources, identifying the sources having respective label quality scores meeting a predefined criterion, fitting, by a processor, a model for computing predicted labels to the incidents received from the identified sources and the respective source-assigned suspiciousness labels of the incidents, applying the model to an additional incident received from one of the sources to compute a predicted label for the additional incident, and prioritizing a notification of the additional incident in response to the predicted label.
In one embodiment receiving a given set of incidents from a given source includes receiving a set of alerts from the given source and grouping the alerts into the given set of incidents.
In a first alert embodiment, the rule-based labels include rule-based incident labels, and wherein applying the labeling rules includes identifying a subset of the alerts from the given source having matching labeling rules, and applying the labeling rules to identified subset of alerts so as to generate respective rule-based alert labels for the alerts in the subset.
In a second alert embodiment, the rule-based alert labels have respective priorities, and wherein assigning a given rule-based incident label to a given incident includes identifying a highest of the priorities, and assigning the identified highest priority to the given rule-based incident label.
In a third alert embodiment, fitting the model includes computing an alert bitmask indicating the alerts in each of the incidents.
In another embodiment, the subset of the incidents includes the incidents having matching labeling rules.
In an additional embodiment, fitting the model includes computing one or more profile-based features for the incidents.
In a further embodiment, fitting the model includes computing one or more binned features for the incidents.
In a supplemental embodiment, fitting the model includes fitting respective models for the sources, and wherein fitting a given model for a given source includes analyzing the incidents received the sources other than the given source.
In one embodiment, the method further computing respective counts of incidents received from the sources, and wherein fitting the model includes analyzing the incidents received from the sources whose respective counts exceed a specified threshold.
In another embodiment, fitting the model includes fitting respective models for the sources, and wherein fitting a given model for a given source includes assigning a higher incident weight to the incidents received from the given source, and assigning a lower incident weight to the incidents received from the sources other than the given source.
In an additional embodiment, applying the model includes computing, using the model, a confidence score indicating maliciousness of the additional incident, computing an impact score indicating damage that can be caused by the additional incident, and wherein prioritizing the notification of the additional incident in response to the predicted label includes prioritizing the notification of the additional incident in response to the confidence score and the impact score.
In a first impact score embodiment, the additional incident includes a sequence of sub-incidents having respective stages in the sequence, and computing the impact score for each of the sub-incidents includes analyzing the respective stages of the sub-incidents.
In a second impact score embodiment, receiving the additional incident includes receiving a set of alerts, and grouping one or more of the alerts into the additional incident.
In a third impact score embodiment, computing the impact score includes analyzing the grouped one or more alerts.
In a fourth impact score embodiment, the grouped one or more alerts have respective alert types, and computing the impact score includes analyzing given alert type.
In a fifth impact score embodiment, the one of the sources includes one or more endpoints, and a given alert includes a given endpoint accessing a specified Uniform Resource Locator (URL).
In a sixth impact score embodiment the one of the sources includes one or more endpoints, and a given alert includes a given endpoint executing a command-line that matches a specified string.
In a seventh impact score embodiment, the method further includes computing a count of the grouped one or more alerts, and computing the impact score includes analyzing the computed count.
In an eighth impact score embodiment, the one of the sources includes one or more endpoints, and the method further includes computing a volume of data transmitted by the one or more endpoints during the additional given incident, wherein computing the impact score includes analyzing the computing volume of data.
In a ninth impact score embodiment, the one of the sources includes one or more endpoints, and the method further includes determining a number of files accessed or modified by the one or more endpoints during the additional given incident, wherein computing the impact score includes analyzing the determined number of files.
In a tenth impact score embodiment, the one of the sources includes one or more endpoints, and the method further includes determining one or more privileges of a user accessing a given endpoint during the additional given incident, wherein computing the impact score includes analyzing the determined one or more privileges.
In an eleventh impact score embodiment, the one of the sources includes one or more endpoints, and the method further includes determining a role of a given endpoint during the additional given incident, wherein computing the impact score includes analyzing the role.
There is also provided, in accordance with an embodiment of the present invention, an apparatus, including a memory configured to store a set of labeling rules, and at least one processor configured to receive, from a plurality of sources, respective sets of incidents, and respective source-assigned suspiciousness labels for the incidents, to apply a set of labeling rules so as to assign rule-based labels to respective incidents in a subset of the incidents in the received sets, to compare, in each of the incidents in the subset, the respective rule-based label to the respective source-assigned suspiciousness label so as to compute a respective label quality score for each of the sources, to identify the sources having respective label quality scores meeting a predefined criterion, to fit a model for computing predicted labels to the incidents received from the identified sources and the respective source-assigned suspiciousness labels of the incidents, to apply the model to an additional incident received from one of the sources to compute a predicted label for the additional incident, and to prioritize a notification of the additional incident in response to the predicted label.
There is additionally provided, in accordance with an embodiment of the present invention, a computer software product, the product includes a non-transitory computer-readable medium, in which program instructions are stored, which instructions, when read by a computer, cause the computer to receive, from a plurality of sources, respective sets of incidents, and respective source-assigned suspiciousness labels for the incidents, to apply a set of labeling rules so as to assign rule-based labels to respective incidents in a subset of the incidents in the received sets, to compare, in each of the incidents in the subset, the respective rule-based label to the respective source-assigned suspiciousness label so as to compute a respective label quality score for each of the sources, to identify the sources having respective label quality scores meeting a predefined criterion, to fit a model for computing predicted labels to the incidents received from the identified sources and the respective source-assigned suspiciousness labels of the incidents; to apply the model to an additional incident received from one of the sources to compute a predicted label for the additional incident, and to prioritize a notification of the additional incident in response to the predicted label.
The disclosure is herein described, by way of example only, with reference to the accompanying drawings, wherein:
Security operations centers (SOCs) can be flooded with huge daily volumes of cyber-security alerts that indicate a set of cyber-security incidents. In some instances, the number of incidents (e.g., 100) can exceed the SOC's handling capacity (e.g., 15). To expand this example, if the SOC employs 10 SOC analysts that can each handle 15 incidents per day (on average), and the SOC receives a daily average of 1,200 incidents, this number of daily incidents is too high for the SOC analysts to manually prioritize, let alone process.
Typically, SOC systems generate SOC rules based on previously prioritized use-cases that match a small subset of the alerts, which the SOC system uses to select which incidents are to be investigated. However, applying these SOC rules to real-world alerts can often result with the SOC system selecting false positives (i.e., incidents that are not malicious), while not selecting true positives (i.e., incident that are malicious).
Embodiments of the present invention provide methods and systems for prioritizing cyber-security incidents. Upon receiving, from a plurality of sources, respective sets of incidents, and respective source-assigned suspiciousness labels for the incidents, a set of labeling rules are applied so as to assign rule-based labels to respective incidents in a subset of the incidents in the received sets. In each of the incidents in the subset, the respective rule-based label is compared to the respective source-assigned suspiciousness label so as to compute a respective label quality score for each of the sources. Upon computing the respective label quality score for each of the sources, the sources having respective label quality scores meeting a predefined criterion are identified, and a processor fits a model for computing predicted labels to the incidents received from the identified sources and the respective source-assigned suspiciousness labels of the incidents. Finally, the model is applied to an additional incident received from one of the sources to compute a predicted label for the additional incident, and a notification of the additional incident is prioritized in response to the predicted label.
By using long term behavioral profiles that are observed (i.e., “learned”) on each of the sources, systems implementing embodiments of the present invention can enrich alerts in the SOC with relevant information, and thereby efficiently prioritize the incidents for the SOC analysts so as to improve recall (i.e., the percentage of true positive cases covered), precision, response time, while at the same time reducing alert fatigue. Additional advantages of systems implementing embodiments of the present invention include:
In some embodiments, each source 28 comprises an organization (e.g., a company) that has a respective local data network 25 coupling a given SOC server 26 to a plurality of network endpoints 27 such as hosts (e.g., computer workstations, laptops and tablets), routers, firewalls and other network equipment. In these embodiments, each SOC server 26 on a given data network 25 can be configured to collect, from the endpoints on the given network, alerts 30 and incidents 32, and convey, via Internet 24, the collected alerts and incidents to security server 20.
In some embodiments, SOC server 26 comprises an SOC processor 31 and an SOC display (e.g., an L.E.D. monitor) 33, and can be configured to collect alerts 30 and incidents 32 from endpoints 27 by collecting raw logs (not shown) on endpoint agents 29 (e.g., Cortex XDR™ produced by Palo Alto Networks, Inc., of 3000 Tannery Way, Santa Clara, CA 95054 USA) that execute on the endpoints. In additional embodiments, the collected alerts and incidents may be anonymized.
A given alert 30 typically comprises a combination of one or more activities on a given host that have a potential to represent malicious or suspicious activity, and a given incident 32 typically comprises a group of one or more alerts 30 that are related to the same malicious activity in one or more of the hosts.
The following is an example of a given incident 32 comprising a set of alerts 30:
Living off the land (LOL) is a cybersecurity term used to explain the use of trusted, pre-installed system tools to conduct malicious activity. One LOL technique comprises LOLBins, which use Windows™ (produced by Microsoft Corporation, Redmond WA, USA) binaries to hide malicious activity. A given incident 32 may comprise a series of LOLBin alerts 30 that detected the following activity:
Each given SOC server 26 can be configured to collect source-assigned suspiciousness labels 34 for a subset of the incidents collected by the given SOC server, and to convey, via Internet 24, the collected labels to security server 20. In one embodiment, SOC analysts can manually generate source-assigned suspiciousness labels 34 in response to examining alerts 30 and incidents 32. In another embodiment, a given endpoint can execute a software application that generates source-assigned suspiciousness labels 34 in response to examining alerts 30 and incidents 32.
Examples of source-assigned suspiciousness labels 34 include benign, malicious, or potentially unwanted activity (PUA). While PUAs are not malicious, they comprise activities not desired on a corporate network. For example, a BitTorrent™ client executing on a given endpoint 27 on a given network 25 can indicate that copyright protected material may be illegally downloaded to the given endpoint.
Security server 20 may comprise a server processor 36 and a memory 38. In embodiments described herein, security server 20 is configured to generate and deploy incident prioritization model 22 that is configured to compute incident risk scores 40 to prioritize handling of incidents 32, thereby enabling SOC analysts at sources 28 to efficiently handle the incidents. In the configuration shown in
Processors 31 and 36 comprises a general-purpose central processing units (CPU) or special-purpose embedded processors, which are programmed in software or firmware to carry out the functions described herein. This software may be downloaded to security server 20 or SOC server(s) 26 in electronic form, over a network, for example. Additionally or alternatively, the software may be stored on tangible, non-transitory computer-readable media, such as optical, magnetic, or electronic memory media. Further additionally or alternatively, at least some of the functions of processors 31 and 36 may be carried out by hard-wired or programmable digital logic circuits.
Examples of memory 38 include dynamic random-access memories, non-volatile random-access memories, hard disk drives and solid-state disk drives.
In some embodiments, tasks described herein performed by server 20, SOC server 26 and endpoints 27 may be split among multiple physical and/or virtual computing devices. In other embodiments, these tasks may be performed in a data cloud.
In embodiments described herein scores 40, 98, 100 and 102 have respective ranges between zero (i.e., less suspicious/malicious) and one (i.e., more suspicious/malicious).
As described in the description referencing
As described in the description referencing
In embodiments of the present invention, processor 36 can compute label quality score 56 for a given source 28 by applying labeling rules 50 to alerts 30 and/or incidents 32 collected from the given source so as to generate rule-based alert labels 74 for the alerts and/or rule-based incident labels the incidents. Processor 36 can then compare the generated rule-based labels 74 and/or 96 to source-assigned suspiciousness labels 34 received from the given source for the alerts and/or the incidents. Since labeling rules 50 are typically defined for a subset (e.g., 20 out of 150 possible alerts) of alerts 30 and/or incidents 32, processor 36 can ignore, when computing the label quality score, any alerts 30 and incidents 32 that do not have corresponding labeling rules 50.
In some embodiments, one or more SOC analysts can create the set of labeling rules 50 that automatically label specific incidents 32 and/or alerts 30 with a verdict with high accuracy (e.g., 85%, 90% or 95%). Similar to source-assigned suspiciousness labels 34, the possible verdicts (i.e., that processor 36 can assign to incidents 32 and/or alerts 30) for each labeling rule 50 can be, benign, malicious or potentially unwanted activity (PUA). Note that some of alerts 30 and/or incidents 32 might not have a deterministic verdict. In these instances, some sources 28 may consider a “PUA” verdict as malicious, while other sources 28 may consider them as “benign”.
Examples for labeling rules 50 include, but are not limited to:
In some embodiments, processor 36 can compute the following label attributes that the server processor can use to compute the label quality score for a given source 28 as:
In some embodiments, when computing label quality scores 56, processor 36 can ignore any alerts 30 and incidents 32 whose corresponding rule-based alert labels 74 or 96 are “PUA”.
Upon computing the label attributes for each source 28, processor 36 can use the following formula to compute respective label quality scores 56 for sources 28:
An example of the function in this formula may comprise:
To train event prioritization model 22, processor 36 can select incidents 32, and extract information from the selected incidents. As described hereinbelow, processor 36 can group alerts 30 into the incidents that the server processor can use to train event prioritization model 22.
In some embodiments, processor 36 can select sources 28 having label quality scores 56 that meet a redefined criterion (e.g., exceed a specified threshold), and extract, from the incidents from the selected sources, the information to train event prioritization model 22. For example, if the label quality scores range between zero (not suspicious) and one (very suspicious), processor 36 can select the sources whose respective label quality scores 56 exceed 0.5.
In embodiments described herein, processor 36 can fit event prioritization model 22 by fitting one or more models 42 for computing incident risk scores 104 (also referred to herein as predicted labels) to the incidents and/or incidents received specific sources 28 and the respective source-assigned suspiciousness labels 34. Fitting a given model 42 may also be referred to herein as training the given model, and Information that processor 36 can use to train event prioritization model 22 (i.e., models 42) is described hereinbelow.
In embodiments described herein, models 42 may comprise:
Information that processor 36 can extract from (or compute for) each selected incident 32 includes:
As described supra, features 92 may comprise profile-based features 92 and binned features 92. In some embodiments, processor 36 can compute a profile across all sources 28 or for a specific customer 28, and use the computed profiles as a given feature 92. Examples of profile-based features 92 include:
In machine learning, features having high cardinalities (i.e., large number of distinct values) can cause trouble during a training phase, because the machine learning algorithm may learn very specific patterns in the data which may be incorrect or noisy. For example, the algorithm can learn that if a combination of alerts 30 was seen on more endpoints 27 then the combination is less suspicious, except for cases where it was seen on 45-47 endpoints 27, in which case it is highly suspicious (this is obviously a random phenomenon and not a general rule).
A common method for accommodating these types of features in machine learning is discretization, which can be used to prevent ML system 53 from overfitting models 42. An example of discretization comprises mapping values to a “t-shirt size” using a predefined threshold list. For example, for the feature ‘feature_combination_number_of_group_ids_seen’, and thresholds [10, 20, 100, 999999] (i.e., [bin #1, bin #2, bin #3, bin #4]:
To implement discretization, embodiments of the present invention can use binned features 92 that comprise features indicating how many endpoints 27 had the same alert 30. When computing a given binned feature 92, the result can be binned values instead of getting a specific number (e.g., how many endpoints 27 had the same alert 30). For example, if the bins comprise 1-3, 4-9 and 10+, then:
Examples of binned features 92 processor 36 can use to create models 42 include:
In addition to profile-based features 92 and binned features 92, processor 36 can also compute, for each given incident 32 comprising a set of alerts 30 received from a given source 28, additional features 92 such as:
Upon computing features 92, processor 36 can input, to machine learning system 53, the computed features and information from alert entries 46 and incident entries 48 so as to generate global models 42, global customer models 42 and customer specific models 42.
In step 110, processor 36 loads a set of labeling rules 50. As described supra, labeling rules 50 can be defined by one or more SOC analysts.
In step 112, processor 36 receives, from the SOC servers at the plurality of sources 28, respective sets of alerts 30 and/or incidents 32, wherein each of the sets comprises alerts 30 and/or incidents 32 from a given source 28. In some embodiments, endpoints 27 generated the received alerts within a specific timespan (e.g., 7, 14, 21 or 28 days).
In step 114, processor 36 groups the received alerts into a set of incidents 32 (i.e., that include the received incidents). In one example, processor 36 can group alerts 30 with identical parent process IDs into a single incident 32. In another example, processor 36 can group all alert 30 having identical destination domains into a single incident 32.
In step 116, processor 36 receives, from sources 28, respective source-assigned suspiciousness labels 34 for the received incidents. In some embodiments, processor 36 can receive the respective source-assigned suspiciousness labels for a given received incident 32 by receiving source-assigned suspiciousness labels 34 for the alerts in the given incident.
In step 118, processor 36 identifies a subset of the received alerts and/or incidents to which labeling rules 50 can be applied. In other words, processor 36 identifies any of the received alerts and/or incidents that have matching labeling rules 50. As described supra, labeling rules 50 can be defined for a specific set of alerts 30 and/or incidents 32, and processor 36 may receive, from sources 28, alerts 30 and/or incidents 32 that are not in the specific set.
As described supra, a given incident 32 may comprise a series of LOLBin alerts 30. Therefore, a given labeling rule 50 for a given alert 30 may comprise assigning, upon detecting execution of a renamed LOLBin (i.e., on a given endpoint 27), a respective rule-based alert label 74 (e.g., PUA or malicious) to the given alert. Likewise, a given labeling rule 50 for a given incident may comprise assigning, upon detecting a specific sequence of LOLBin alerts (e.g., the LOL example described supra) in a process chain (i.e., executing on a given endpoint 27), a respective rule-based incident label 96 (e.g., PUA or malicious) to the given incident.
In step 120, processor 36 applies labeling rules 50 to the alerts and/or incidents in the identified subset so as to assign respective rule-base alert labels 74 and rule-based incident labels 96 to the identified alerts and/or incidents.
As described supra, processor 36 can assign, to alerts 30, rule-base alert labels 74 (i.e., verdicts) such as malicious, PUA and benign to rule-based incident labels 96, and then determine, for incidents 32, rule-based incident labels 96 by analyzing the respective rule-based alert labels of the alerts in the respective incidents.
As described supra, processor 36 can assign verdicts such as benign, PUA and malicious to rule-base alert labels 74. In some embodiments, processor 36 can assign priorities to each of the possible verdicts. For example, processor 36 can assign “0” (i.e., a low priority) to benign, assign “1” (i.e., a medium priority) to PUA, and “3” (i.e., a high priority) to malicious.
In these embodiments, processor 36 can identify and assign, to a given rule-based incident label 96 for a given incident 32, the highest priority rule-base alert label 74 for the alerts in the given incident as follows:
In step 122, processor 36 compares, for each of the incidents in the identified subset, the respective generated rule-based incident label to the respective received source-assigned suspiciousness label (i.e., stored in a given customer generated incident label 94) so as to compute a respective label quality score 56 for each source 28. In some embodiments (i.e., if available), processor 36 may additionally (or alternatively) compute one or more label quality score 56, by comparing, for each of the alerts in the identified subset, the respective generated rule-based alert label to the respective received source-assigned suspiciousness label (i.e., stored in a given source alert label 72) so as to compute a respective label quality score 56 for each source 28.
In step 124, processor 36 identifies (any of) the sources having respective label quality scores 56 meeting a predefined criterion. In a first embodiment, a given source 28 having higher label quality score 56 may indicate a higher quality of the source-assigned suspiciousness labels the processor 36 received from the given source, and the predefined criterion may comprise a minimum threshold for the label quality score 56. For example, label quality scores 56 can have a range between zero and one, and processor 36 can select the sources whose respective label quality score 56 are greater than 0.5. This ensures that information used to train event prioritization model 22 is extracted from incidents 32 comprising alerts received from sources 28 that have reliable labeling.
In a second embodiment, a given source 28 having lower label quality score 56 may indicate a higher quality of the source-assigned suspiciousness labels the processor 36 received from a given source, and the predefined criterion may comprise a maximum threshold for the label quality score 56. In a third embodiment, the label-quality score may simply generate quality-labels (e.g., “poor”, “fair”, “good”, “excellent”) that indicate the quality of the source-assigned suspiciousness labels the processor 36 received from a given source, and the predefined criterion may comprise specific quality-labels (e.g., “good” and “excellent”). In addition to these three embodiments, any predefined or dynamic criterion that processor 36 can use to identify sources 28 having higher qualities of source-assigned suspiciousness labels is considered to be within the spirit and scope of the present invention.
In step 126, processor 36 generates/extracts features 92 from incidents 32 received from the sources identified in step 124. Features 92 are described hereinabove.
In step 128, processor 36 uses machine learning system 53 executing on the server processor to fit event prioritization model 22 (i.e., one or more models 42) for computing predicted labels to the incidents (i.e., the features that the server processor generated from alerts) and/or incidents received from the identified sources and the respective source-assigned suspiciousness labels 34 (i.e., stored in customer generated incident labels 94). As described supra, models 42 comprise global models 42, global customer models 42 and customer specific models 42. As described in the description referencing
In one embodiment, fitting event prioritization model 22 may comprise computing alert bitmask 90 and features 92. In another embodiment, fitting event prioritization model 22 may comprise training global models 42, global customer models 42 and customer specific models 42, as described hereinbelow. In an additional embodiment, fitting event prioritization model 22 may comprise computing profile-based features 92 and/or binned features 92.
Finally, in step 130, processor 36 deploys incident prioritization model 22 (comprising trained models 42, functions 44, incident weights 58 and source-defined rules 59) to SOC servers 26 at sources 28, and the method ends. As described in the description referencing
In step 140, a given SOC processor 31 in a given SOC server 26 at a given source 428 receives a set of additional alerts 30 from endpoint agents 29 deployed on endpoints 27 at the given source.
In step 142, using embodiments described supra, the given SOC processor in the given SOC server groups one or more (i.e., a subset) of the additional alerts into an additional incident 32. In some embodiments, the given SOC processor in the given SOC server can group the additional alerts into a set of additional incidents 32, and the additional incident (i.e., in step 142) comprises one of the additional incidents in the set.
In step 144, the given SOC processor in the SOC server computes/extracts, using embodiments described supra, features 92 for the additional incident.
In step 146, the given SOC processor in the given SOC server applies model 22 to the additional incident so as to compute a predicted label for the additional incident. In embodiments described herein, the predicted label comprises incident risk score 40. In some embodiments, the given SOC processor can apply model 22 to the additional incident by conveying (i.e., inputting) the computed features into the global model, the global customer model and the customer specific model so as to compute respective model scores 98. In other embodiments, the given SOC processor can apply model 22 to the additional incident by computing, as described hereinbelow, one or more scores such as confidence score 100, impact score 102 and incident risk score 40.
In step 148, the given SOC processor in the given SOC server computes, using a first given function 44, the confidence score for the additional incident. The first given function configured to compute confidence scores 100 may also be referred to herein simply as confidence score function 44.
In some embodiments, confidence score function 44 may comprise:
In a first embodiment, confidence score function 44 can identify a highest (i.e., max( )) of the three model scores. In a second embodiment, confidence score function 44 can compute a mean of the three model scores. In a third embodiment, confidence score function 44 may comprise a computation such as:
(alpha*global_model_score)+(beta*global_customer_model_score)+(gamma*gustomer_specific_model_score)
where alpha, beta and gamma comprise values between zero and one.
In step 150, the given SOC processor in the given SOC server computes, using a second given function 44, the impact score for the additional incident. The impact score for the additional incident indicates “possible damage” that the additional incident can cause if the additional incident is indeed malicious. As described hereinbelow, the given SOC processor can compute impact score 102 for the additional incident by comprises analyzing the grouped alerts (i.e., described in the description referencing step 142 hereinabove) in the additional incident.
The second given function configured to compute impact scores 102 may also be referred to herein simply as impact score function 44. In some embodiments, impact score function 44 can be custom defined by sources 28.
In a first impact score embodiment, the given SOC processor can execute impact score function 44 so as to compute impact score 102 by assigning (i.e., on a per-source 28 basis) higher priorities to “featured assets” such as specific alerts 30 and alerts associated with specific subnets, endpoints 27 or users. For example, the given SOC processor can compute impact score 102 so as to have a higher score (i.e., value) if the additional incident involves a given endpoint 27 comprising a production server, a given endpoint 27 comprising a C-level executive workstation or a given user ID 88 that has access privileges to financial information.
In a second impact score embodiment, the given SOC processor can execute impact score function 44 so as to compute impact score 102 by applying source-defined (i.e., defined by the customer(s)) rules 59 within a given incident 30. Examples of source-defined rules 59 include:
In a third impact score embodiment, an SOC analyst at the given source 28 can flag one or more alert types 62 as being more critical. In this embodiment, the given SOC processor can execute impact score function 44 so as to compute impact score 102 by analyzing the alert types. For example, the given SOC processor can execute impact score function 44 so as to compute impact score 102 by assigning a higher value to the given impact score if any of the alert types in the alerts in the additional entry match any of the flagged alert.
In a fourth impact score embodiment, an SOC analyst can, based on previously performed research (e.g., by an SOC analyst), identify score attributes e.g., information stored in the corresponding alert entries 46 and/or incident entry 48) in incidents 30, determine respective impacts of the score attributes, and adjust the given impact score accordingly.
In a first example for the fourth impact score embodiment, a given score attribute comprises a count, in the additional incident, of additional alerts 30 that a given endpoint 28 generated after the endpoint agent on the given endpoint executed a preventive action (i.e., “after prevention”). This may indicate that an attacker tried multiple approaches until the attacker successfully performed an attack. In this example, the given SOC processor can execute impact score function 44 so as to adjust the impact score as follows:
In some embodiments the additional incident 32 may indicate a cyberattack comprising a sequence of “sub-incidents” such as:
In a second example for the fourth impact score embodiment, a given score attribute comprises the respective stages (e.g., the first, second and third sub-incidents in the sequence described hereinabove), and the given SOC processor can execute impact score function 44 to compute impact score 102 by analyzing the respective stages. For example, impact score function 44 can assign, to the impact score, lower values for earlier sub-incidents in the sequence and higher values for later sub-incidents in the sequence. For example, in the sequence described hereinabove, impact score function 44 can adjust the impact score as follows:
In a third example for the fourth impact score embodiment, the given SOC processor can compute a volume (e.g., a number of bytes) of data uploaded from (i.e., transmitted by) one or more given endpoints 27 involved in the additional incident. In this embodiment, the given SOC processor can execute impact score function 44 so as to compute impact score 102 by analyzing the computed volume. For example, impact score function 44 can assign a higher value to the impact score if the volume exceeds a specified threshold. For example, if the given endpoint involved in the additional incident uploaded more than one gigabyte of data during the additional incident, then impact score function 44 can increase the impact score by 0.3.
In a fourth example for the fourth impact score embodiment, the given SOC processor can compute a count of files accessed or modified by one or more given endpoints 27 involved in the additional incident. In this embodiment, the given SOC processor can execute impact score function 44 so as to compute impact score 102 by analyzing the computed count of files. For example, the given SOC processor can assign a higher value to the impact score if a exceeds a specified threshold. For example, if the given endpoint involved in the additional incident accessed or modified more than 20 files during the additional incident, then impact score function 44 can increase the impact score by 0.2.
In a fifth example for the fourth impact score embodiment, the given SOC processor can determined user privileges (e.g., domain administrator, local administrator and guest) of users accessing (i.e., logged into) endpoints 27 involved in the additional incident. In this embodiment, the given SOC processor can execute impact score function 44 so as to compute impact score 102 by analyzing the determined user privileges. For example, if a given user is accessing a given endpoint 27 involved in the additional incident and has domain administrator privileges, then impact score function 44 can increase the impact score by 0.8. However, if a given user is accessing a given endpoint 27 involved in the additional incident and has guest privileges, then there may be no impact to the impact score.
In a sixth example for the fourth impact score embodiment, the given SOC processor can determine (i.e., derive) roles of endpoints (i.e., hosts) 27 involved in the additional incident. In this embodiment, the given SOC processor can execute impact score function 44 so as to compute impact score 102 by analyzing the determined roles. For example:
In step 152, the SOC processor in the given SOC server computes, using a third given function 44, the incident risk score for the additional incident. In some embodiments, the given SOC processor can use the computed confidence and impact scores to compute the incident risk score. The third given function configured to compute incident risk scores 40 may also be referred to herein simply as incident risk score function 44.
In a first risk score embodiment, incident risk score function 44 may compute the incident risk score as:
max(confidence_score,impact_score)
wherein confidence_score comprises the computed confidence score for the additional incident, and wherein impact_score comprises the incident score for the additional incident.
In a second risk score embodiment, incident risk score function 44 may compute the incident risk score as:
confidence_score*impact_score
In a third risk score embodiment, incident risk score function 44 may compute the incident risk score as:
(alpha*confidence_score)+(beta*impact_score)
where alpha and beta comprise values between zero and one.
Finally, in step 154, in response to a predicted label comprising the computed incident risk score, the given SOC processor in the given SOC server prioritizes the additional incident for handling by an SOC analyst, and the method ends. For example, if there are 1,000 daily incidents 32 for a given source 28 and the SOC analysts at the given source have capacity to handle 100 incidents 32 per day, the SOC analysts can prioritize the 100 incidents with the highest incident risk scores 40.
In one embodiment, the given SOC processor in the given SOC server can prioritize the additional incident by prioritizing a notification in response to the predicted label. For example, presenting, on display 33, a notification (e.g., a warning message) comprising an ID, description and the computed incident risk score for the additional incidents. In another embodiment, the given SOC processor can prioritize the notification by presenting the notification in different colors responsively to the computed risk score (e.g., green for lower risks and red for higher risks). In an additional embodiment where there are multiple additional incidents with respective notifications, the given SOC processor can prioritize the additional incidents by presenting their respective notification sorted by their respective incident risk scores (i.e., highest risk first).
It will be appreciated that the embodiments described above are cited by way of example, and that the present invention is not limited to what has been particularly shown and described hereinabove. Rather, the scope of the present invention includes both combinations and subcombinations of the various features described hereinabove, as well as variations and modifications thereof which would occur to persons skilled in the art upon reading the foregoing description and which are not disclosed in the prior art.
Number | Name | Date | Kind |
---|---|---|---|
5991881 | Conklin et al. | Nov 1999 | A |
6347374 | Drake et al. | Feb 2002 | B1 |
6704874 | Porras et al. | Mar 2004 | B1 |
7003790 | Inoue et al. | Feb 2006 | B1 |
7007301 | Crosbie et al. | Feb 2006 | B2 |
7178164 | Bonnes | Feb 2007 | B1 |
7181769 | Keanini et al. | Feb 2007 | B1 |
7523016 | Surdulescu et al. | Apr 2009 | B1 |
7684568 | Yonge, III et al. | Mar 2010 | B2 |
7694150 | Kirby | Apr 2010 | B1 |
7703138 | Desai et al. | Apr 2010 | B2 |
7712134 | Nucci et al. | May 2010 | B1 |
7752665 | Robertson et al. | Jul 2010 | B1 |
7908655 | Bhattacharyya et al. | Mar 2011 | B1 |
8245298 | Pletka et al. | Aug 2012 | B2 |
8397284 | Kommareddy et al. | Mar 2013 | B2 |
8429180 | Sobel et al. | Apr 2013 | B1 |
8490190 | Hernacki et al. | Jul 2013 | B1 |
8516573 | Brown et al. | Aug 2013 | B1 |
8555388 | Wang et al. | Oct 2013 | B1 |
8578345 | Kennedy et al. | Nov 2013 | B1 |
8607353 | Rippert, Jr. et al. | Dec 2013 | B2 |
8620942 | Hoffman et al. | Dec 2013 | B1 |
8677487 | Balupari et al. | Mar 2014 | B2 |
8762288 | Dill | Jun 2014 | B2 |
8769681 | Michels et al. | Jul 2014 | B1 |
8925095 | Herz et al. | Dec 2014 | B2 |
8966625 | Zuk et al. | Feb 2015 | B1 |
9038178 | Lin | May 2015 | B1 |
9118582 | Martini | Aug 2015 | B1 |
9147071 | Sallam | Sep 2015 | B2 |
9231962 | Yen et al. | Jan 2016 | B1 |
9319421 | Ferragut | Apr 2016 | B2 |
9342691 | Maestas | May 2016 | B2 |
9378361 | Yen et al. | Jun 2016 | B1 |
9386028 | Altman | Jul 2016 | B2 |
9531614 | Nataraj et al. | Dec 2016 | B1 |
9531736 | Torres et al. | Dec 2016 | B1 |
9690933 | Singh | Jun 2017 | B1 |
9736251 | Samant et al. | Aug 2017 | B1 |
9773112 | Rathor et al. | Sep 2017 | B1 |
9979739 | Mumcuoglu et al. | May 2018 | B2 |
9979742 | Mumcuoglu et al. | May 2018 | B2 |
10027694 | Gupta et al. | Jul 2018 | B1 |
10075461 | Mumcuoglu et al. | Sep 2018 | B2 |
10140453 | Fridakis | Nov 2018 | B1 |
10237875 | Romanov | Mar 2019 | B1 |
10706144 | Moritz et al. | Jul 2020 | B1 |
10728281 | Kurakami | Jul 2020 | B2 |
10904277 | Sharifi Mehr | Jan 2021 | B1 |
20020059078 | Valdes et al. | May 2002 | A1 |
20020133586 | Shanklin et al. | Sep 2002 | A1 |
20030110396 | Lewis et al. | Jun 2003 | A1 |
20030133443 | Klinker et al. | Jul 2003 | A1 |
20040003286 | Kaler et al. | Jan 2004 | A1 |
20040015728 | Cole et al. | Jan 2004 | A1 |
20040117658 | Klaes | Jun 2004 | A1 |
20040199793 | Wilken et al. | Oct 2004 | A1 |
20040210769 | Radatti et al. | Oct 2004 | A1 |
20040250169 | Takemori et al. | Dec 2004 | A1 |
20040260733 | Adelstein et al. | Dec 2004 | A1 |
20050015624 | Ginter et al. | Jan 2005 | A1 |
20050060295 | Gould et al. | Mar 2005 | A1 |
20050069130 | Kobayashi | Mar 2005 | A1 |
20050071330 | Douceur et al. | Mar 2005 | A1 |
20050123138 | Abe et al. | Jun 2005 | A1 |
20050128989 | Bhagwat et al. | Jun 2005 | A1 |
20050183120 | Jain et al. | Aug 2005 | A1 |
20050216749 | Brent | Sep 2005 | A1 |
20050262556 | Waisman et al. | Nov 2005 | A1 |
20050262560 | Gassoway | Nov 2005 | A1 |
20050268112 | Wang et al. | Dec 2005 | A1 |
20050286423 | Poletto et al. | Dec 2005 | A1 |
20060018466 | Adelstein et al. | Jan 2006 | A1 |
20060075462 | Golan | Apr 2006 | A1 |
20060075492 | Golan et al. | Apr 2006 | A1 |
20060075500 | Bertman et al. | Apr 2006 | A1 |
20060107321 | Tzadikario | May 2006 | A1 |
20060126522 | Oh | Jun 2006 | A1 |
20060136720 | Armstrong et al. | Jun 2006 | A1 |
20060137009 | Chesla | Jun 2006 | A1 |
20060149848 | Shay | Jul 2006 | A1 |
20060156398 | Ross et al. | Jul 2006 | A1 |
20060161984 | Phillips et al. | Jul 2006 | A1 |
20060190803 | Kawasaki et al. | Aug 2006 | A1 |
20060191010 | Benjamin | Aug 2006 | A1 |
20060215627 | Waxman | Sep 2006 | A1 |
20060242694 | Gold et al. | Oct 2006 | A1 |
20060259967 | Thomas et al. | Nov 2006 | A1 |
20060282893 | Wu et al. | Dec 2006 | A1 |
20070011319 | McClure et al. | Jan 2007 | A1 |
20070072661 | Lototski | Mar 2007 | A1 |
20070073519 | Long | Mar 2007 | A1 |
20070116277 | Ro et al. | May 2007 | A1 |
20070124474 | Margulis | May 2007 | A1 |
20070198603 | Tsioutsiouliklis et al. | Aug 2007 | A1 |
20070201691 | Kumagaya | Aug 2007 | A1 |
20070201693 | Ohno | Aug 2007 | A1 |
20070218874 | Sinha et al. | Sep 2007 | A1 |
20070226796 | Gilbert et al. | Sep 2007 | A1 |
20070226802 | Gopalan et al. | Sep 2007 | A1 |
20070245420 | Yong et al. | Oct 2007 | A1 |
20070255724 | Jung et al. | Nov 2007 | A1 |
20070283166 | Yami et al. | Dec 2007 | A1 |
20080005782 | Aziz | Jan 2008 | A1 |
20080013725 | Kobayashi | Jan 2008 | A1 |
20080016339 | Shukla | Jan 2008 | A1 |
20080016570 | Capalik | Jan 2008 | A1 |
20080104046 | Singla et al. | May 2008 | A1 |
20080104703 | Rihn et al. | May 2008 | A1 |
20080134296 | Amitai et al. | Jun 2008 | A1 |
20080148381 | Aaron | Jun 2008 | A1 |
20080198005 | Schulak et al. | Aug 2008 | A1 |
20080244097 | Candelore et al. | Oct 2008 | A1 |
20080262991 | Kapoor et al. | Oct 2008 | A1 |
20080271143 | Stephens et al. | Oct 2008 | A1 |
20080285464 | Katzir | Nov 2008 | A1 |
20090007100 | Field et al. | Jan 2009 | A1 |
20090007220 | Ormazabal et al. | Jan 2009 | A1 |
20090115570 | Cusack, Jr. | May 2009 | A1 |
20090157574 | Lee | Jun 2009 | A1 |
20090164522 | Fahey | Jun 2009 | A1 |
20090193103 | Small et al. | Jul 2009 | A1 |
20090265777 | Scott | Oct 2009 | A1 |
20090320136 | Lambert et al. | Dec 2009 | A1 |
20100014594 | Beheydt et al. | Jan 2010 | A1 |
20100054241 | Shah et al. | Mar 2010 | A1 |
20100071063 | Wang et al. | Mar 2010 | A1 |
20100107257 | Ollmann | Apr 2010 | A1 |
20100146292 | Shi et al. | Jun 2010 | A1 |
20100146293 | Shi et al. | Jun 2010 | A1 |
20100146501 | Wyatt et al. | Jun 2010 | A1 |
20100162400 | Feeney et al. | Jun 2010 | A1 |
20100197318 | Petersen et al. | Aug 2010 | A1 |
20100212013 | Kim et al. | Aug 2010 | A1 |
20100217861 | Wu | Aug 2010 | A1 |
20100235915 | Memon et al. | Sep 2010 | A1 |
20100268818 | Richmond et al. | Oct 2010 | A1 |
20100272257 | Beals | Oct 2010 | A1 |
20100278054 | Dighe | Nov 2010 | A1 |
20100280978 | Shimada et al. | Nov 2010 | A1 |
20100284282 | Golic | Nov 2010 | A1 |
20100299430 | Powers et al. | Nov 2010 | A1 |
20110026521 | Gamage et al. | Feb 2011 | A1 |
20110035795 | Shi | Feb 2011 | A1 |
20110087779 | Martin et al. | Apr 2011 | A1 |
20110125770 | Battestini et al. | May 2011 | A1 |
20110135090 | Chan et al. | Jun 2011 | A1 |
20110138463 | Kim et al. | Jun 2011 | A1 |
20110153748 | Lee et al. | Jun 2011 | A1 |
20110185055 | Nappier et al. | Jul 2011 | A1 |
20110185421 | Wittenstein et al. | Jul 2011 | A1 |
20110214187 | Wittenstein et al. | Sep 2011 | A1 |
20110247071 | Hooks et al. | Oct 2011 | A1 |
20110265011 | Taylor et al. | Oct 2011 | A1 |
20110270957 | Phan et al. | Nov 2011 | A1 |
20110271343 | Kim et al. | Nov 2011 | A1 |
20110302653 | Frantz et al. | Dec 2011 | A1 |
20110317770 | Lehtiniemi et al. | Dec 2011 | A1 |
20120042060 | Jackowski et al. | Feb 2012 | A1 |
20120079596 | Thomas et al. | Mar 2012 | A1 |
20120102359 | Hooks | Apr 2012 | A1 |
20120136802 | Mcquade et al. | May 2012 | A1 |
20120137342 | Hartrell et al. | May 2012 | A1 |
20120143650 | Crowley et al. | Jun 2012 | A1 |
20120191660 | Hoog | Jul 2012 | A1 |
20120222120 | Rim et al. | Aug 2012 | A1 |
20120233311 | Parker et al. | Sep 2012 | A1 |
20120240185 | Kapoor et al. | Sep 2012 | A1 |
20120275505 | Tzannes et al. | Nov 2012 | A1 |
20120308008 | Kondareddy et al. | Dec 2012 | A1 |
20120331553 | Aziz et al. | Dec 2012 | A1 |
20130031600 | Luna et al. | Jan 2013 | A1 |
20130061045 | Kiefer et al. | Mar 2013 | A1 |
20130083700 | Sndhu et al. | Apr 2013 | A1 |
20130097706 | Titonis et al. | Apr 2013 | A1 |
20130111211 | Winslow et al. | May 2013 | A1 |
20130031037 | Brandt et al. | Jul 2013 | A1 |
20130196549 | Sorani | Aug 2013 | A1 |
20130298237 | Smith | Nov 2013 | A1 |
20130298243 | Kumar et al. | Nov 2013 | A1 |
20130333041 | Christodorescu et al. | Dec 2013 | A1 |
20140010367 | Wang | Jan 2014 | A1 |
20140013434 | Ranum et al. | Jan 2014 | A1 |
20140165207 | Engel et al. | Jun 2014 | A1 |
20140198669 | Brown et al. | Jul 2014 | A1 |
20140201776 | Minemura et al. | Jul 2014 | A1 |
20140230059 | Wang | Aug 2014 | A1 |
20140325643 | Bart et al. | Oct 2014 | A1 |
20150026810 | Friedrichs | Jan 2015 | A1 |
20150040219 | Garraway et al. | Feb 2015 | A1 |
20150047032 | Hannis et al. | Feb 2015 | A1 |
20150071308 | Webb, III et al. | Mar 2015 | A1 |
20150121461 | Dulkin et al. | Apr 2015 | A1 |
20150156270 | Teraoka et al. | Jun 2015 | A1 |
20150180883 | Aktas et al. | Jun 2015 | A1 |
20150195300 | Adjaoute | Jul 2015 | A1 |
20150264069 | Beauchesne et al. | Sep 2015 | A1 |
20150295903 | Yi et al. | Oct 2015 | A1 |
20150304346 | Kim | Oct 2015 | A1 |
20150341380 | Heo et al. | Nov 2015 | A1 |
20150341389 | Kurakami | Nov 2015 | A1 |
20160021141 | Liu et al. | Jan 2016 | A1 |
20160119292 | Kaseda et al. | Apr 2016 | A1 |
20160127390 | Lai et al. | May 2016 | A1 |
20160142746 | Schuberth | May 2016 | A1 |
20160191918 | Lai et al. | Jun 2016 | A1 |
20160234167 | Engel et al. | Aug 2016 | A1 |
20160247163 | Donsky et al. | Aug 2016 | A1 |
20160315954 | Peterson et al. | Oct 2016 | A1 |
20160323299 | Huston, III | Nov 2016 | A1 |
20160359895 | Chiu et al. | Dec 2016 | A1 |
20170026387 | Vissamsetty et al. | Jan 2017 | A1 |
20170026395 | Mumcuoglu et al. | Jan 2017 | A1 |
20170054744 | Mumcuoglu et al. | Feb 2017 | A1 |
20170063921 | Fridman et al. | Mar 2017 | A1 |
20170078312 | Yamada et al. | Mar 2017 | A1 |
20170111376 | Friedlander et al. | Apr 2017 | A1 |
20170171229 | Arzi et al. | Jun 2017 | A1 |
20170262633 | Miserendino et al. | Sep 2017 | A1 |
20170294112 | Kushnir | Oct 2017 | A1 |
20170374090 | McGrew et al. | Dec 2017 | A1 |
20180004948 | Martin et al. | Jan 2018 | A1 |
20180007013 | Wang | Jan 2018 | A1 |
20180048662 | Jang et al. | Feb 2018 | A1 |
20180077189 | Doppke et al. | Mar 2018 | A1 |
20180288081 | Yermakov | Oct 2018 | A1 |
20180332064 | Harris et al. | Nov 2018 | A1 |
20190044963 | Rajasekharan et al. | Feb 2019 | A1 |
20190068620 | Avrahami et al. | Feb 2019 | A1 |
20190207966 | Vashisht | Jul 2019 | A1 |
20190297097 | Gong et al. | Sep 2019 | A1 |
20190319981 | Meshi et al. | Oct 2019 | A1 |
20190334931 | Arlitt et al. | Oct 2019 | A1 |
20200007566 | Wu | Jan 2020 | A1 |
20200082296 | Fly | Mar 2020 | A1 |
20200145435 | Chiu et al. | May 2020 | A1 |
20200162494 | Rostami-Hesarsorkh | May 2020 | A1 |
20200195673 | Lee | Jun 2020 | A1 |
20200244658 | Meshi et al. | Jul 2020 | A1 |
20200244675 | Meshi et al. | Jul 2020 | A1 |
20200244676 | Amit et al. | Jul 2020 | A1 |
20200244683 | Meshi et al. | Jul 2020 | A1 |
20200244684 | Meshi et al. | Jul 2020 | A1 |
20200274894 | Argoeti | Aug 2020 | A1 |
20200285737 | Kraus | Sep 2020 | A1 |
20200293917 | Wang et al. | Sep 2020 | A1 |
20200327221 | Street | Oct 2020 | A1 |
20200374301 | Manevich et al. | Nov 2020 | A1 |
20210004458 | Edwards et al. | Jan 2021 | A1 |
20210182387 | Zhu et al. | Jun 2021 | A1 |
20210224676 | Arzani | Jul 2021 | A1 |
20220217156 | Wahbo | Jul 2022 | A1 |
20230171235 | Chhibber | Jun 2023 | A1 |
Number | Date | Country |
---|---|---|
103561048 | Feb 2014 | CN |
0952521 | Oct 1999 | EP |
2056559 | May 2009 | EP |
03083660 | Oct 2003 | WO |
Entry |
---|
International Application # PCT/IB2022/059544 Search Report dated Jan. 20, 2023. |
International Application # PCT/IB2022/060920 Search Report dated Feb. 7, 2023. |
EP Application # 19832439.4 Office Action dated Mar. 1, 2023. |
U.S. Appl. No. 17/175,720 Office Action dated Mar. 20, 2023. |
International Application # PCT/IB2022/061926 Search Report dated Mar. 27, 2023. |
U.S. Appl. No. 17/700,579 Office Action dated Mar. 23, 2023. |
U.S. Appl. No. 17/464,716 Office Action dated Apr. 14, 2023. |
U.S. Appl. No. 17/464,709 Office Action dated Apr. 14, 2023. |
Light Cyber Ltd, “LightCyber Magna”, pp. 1-3, year 2011. |
Tier-3 Pty Ltd, “Huntsman Protector 360”, Brochure, pp. 1-2, Apr. 1, 2010. |
Tier-3 Pty Ltd, “Huntsman 5.7 the Power of 2”, Brochure, pp. 1-2, Oct. 8, 2012. |
Bilge et at., “Disclosure: Detecting Botnet Command and Control Servers Through Large-Scale NetFlow Analysis”, ACSAC, pp. 1-10, Dec. 3-7, 2012. |
Blum., “Combining Labeled and Unlabeled Data with Co-Training”, Carnegie Mellon University, Research Showcase @ CMU, Computer Science Department, pp. 1-11, Jul. 1998. |
Felegyhazi et al., “On the Potential of Proactive Domain Blacklisting”, LEET'10 Proceedings of the 3rd USENIX Conference on Large-scale exploits and emergent threats, pp. 1-8, San Jose, USA, Apr. 27, 2010. |
Frosch., “Mining DNS-related Data for Suspicious Features”, Ruhr Universitat Bochum, Master's Thesis, pp. 1-88, Dec. 23, 2011. |
Bilge at al., “Exposure: Finding Malicious Domains Using Passive DNS Analysis ”, NDSS Symposium, pp. 1-17, Feb. 6-9, 2011. |
Gross et al., “Fire: Finding Rogue Networks”, Annual Conference on Computer Security Applications (ACSAC'09), pp. 1-10, Dec. 7-11, 2009. |
Markowitz, N., “Bullet Proof Hosting: A Theoretical Model”, Security Week, [pp. 1-5, Jun. 29, 2010, downloaded from http://www.infosecisland.com/blogview/4487-Bullet-Proof-Hosting-A-Theoretical-Model.html. |
Konte et al., “ASwatch: An AS Reputation System to Expose Bulletproof Hosting ASes”, SIGCOMM , pp. 625-638, Aug. 17-21, 2015. |
Markowitz, N., “Patterns of Use and Abuse with IP Addresses”, Security Week, pp. 1-4, Jul. 10, 2010, downloaded from http://infosecisland.com/blogview/5068-Patterns-of-Use-and-Abuse-with-IP-Addresses.html. |
Wei et al., “Identifying New Spam Domains by Hosting IPs: Improving Domain Blacklisting”, Department of Computer and Information Sciences, University of Alabama at Birmingham, USA, pp. 1-8, Dec. 8, 2010. |
Goncharov,M., “Criminal Hideouts for Lease: Bulletproof Hosting Services”, Forward-Looking Threat Research (FTR) Team, A TrendLabsSM Research Paper, pp. 1-28, Jul. 3, 2015. |
Niksun, “Network Intrusion Forensic System (NIFS) for Intrusion Detection and Advanced Post Incident Forensics”, Whitepaper, pp. 1-12, Feb. 15, 2010. |
Shulman, A., “Top Ten Database Security Threats How to Mitigate the Most Significant Database Vulnerabilities”, White Paper, pp. 1-14, year 2006. |
Xu, “Correlation Analysis of Intrusion Alerts,” Dissertation in Computer Science submitted to the Graduate Faculty, North Carolina State University, pp. 1-206, year 2006. |
U.S. Appl. No. 17/038,285 Office Action dated Mar. 21, 2022. |
“PA-3250 Next Generation Firewall,” PS-3200 Series, Datasheet, Palo Alto Networks, Inc., Santa Clara, CA, USA, pp. 1-4, year 2021. |
“What is PCI DSS?” Palo Alto Networks, Cyberpedia, pp. 1-5, year 2021, as downloaded from https://www.paloaltonetworks.com/cyberpedia/what-is-a-pci-dss. |
Wikipedia, “Active Directory,” pp. 1-14, last edited Oct. 2021. |
International Application # PCT/IB2021/058621 Search Report dated Dec. 14, 2021. |
Steimberg et al., U.S. Appl. No. 17/038,285, filed Sep. 30, 2020. |
Rimer et al., U.S. Appl. No. 17/505,673, filed Oct. 20, 2021. |
Asrigo et al., “Using VMM-based sensors to monitor honeypots,” Proceedings of the 2nd International Conference on Virtual Execution Environments, pp. 13-23, Jun. 14, 2006. |
Bhuyan et al., “Surveying Port Scans and Their Detection Methodologies”, Computer Journal, vol. 54, No. 10, pp. 1565-1581, Apr. 20, 2011. |
Skormin, “Anomaly-Based Intrusion Detection Systems Utilizing System Call Data”, Watson School of Engineering at Binghamton University, pp. 1-82, Mar. 1, 2012. |
Palo Alto Networks, “Cortex XDR”, datasheet, pp. 1-7, year 2020. |
Palo Alto Networks, “WildFire”, datasheet, pp. 1-6, year 2020. |
Barford et al., “Characteristics of Network Traffic Flow Anomalies,” Proceedings of the 1st ACM Sigcomm Workshop on Internet Measurement, pp. 69-73, year 2001. |
U.S. Appl. No. 17/175,720 Office Action dated Nov. 7, 2022. |
U.S. Appl. No. 17/506,713 Office Action dated Nov. 8, 2022. |
Brownlee et al., “Traffic Flow Measurement: Architecture,” Request for Comments 2722, Network Working Group, pp. 1-48, Oct. 1999. |
Number | Date | Country | |
---|---|---|---|
20230224311 A1 | Jul 2023 | US |