MODULE 26 - CERTIFICATION REVISION PREPARATION Flashcards

Question

Alert Generation: The fields available for the real-time events are as follows: -- ST -- CNT -- Sensor -- Alert ID -- Date/Time -- Event Message

Answer 1

Alert Generation: The fields available for the real-time events are as follows: -- ST -- CNT -- Sensor -- Alert ID -- Date/Time -- Event Message

Answer 2

--ST This is the status of the event. RT means real time. The event is color-coded by priority. The priorities are based on the category of the alert. There are four priority levels: very low, low, medium, and high. The colors range from light yellow to red as the priority increases.

Answer 3

- CNT This is the count for the number of times this event has been detected for the same source and destination IP address. The system has determined that this set of events is correlated. Rather than reporting each in a potentially long series of correlated events in this window, the event is listed once with the number of times it has been detected in this column. High numbers here can represent a security problem or the need for tuning of the event signatures to limit the number of potentially spurious events that are being reported.

Answer 4

-- Sensor This is the agent reporting the event. The available sensors and their identifying numbers can be found in the Agent Status tab of the pane which appears below the events window on the left. These numbers are also used in the Alert ID column. From the Agent Status pane, we can see that OSSEC, pcap, and Snort sensors are reporting to Sguil. In addition, we can see the default hostnames for these sensors, which includes the monitoring interface. Note that each monitoring interface has both pcap and Snort data associated with it.

Answer 5

-- Alert ID This two-part number represents the sensor that has reported the problem and the event number for that sensor. We can see from the figure that the largest number of events that are displayed are from the OSSEC sensor (1). The OSSEC sensor has reported eight sets of correlated events. Of these events, 232 have been reported with event ID 1.24.

Answer 6

-- Date/Time This is the timestamp for the event. In the case of correlated events, it is the timestamp for the first event.

Answer 7

-- Event Message This is the identifying text for the event. This is configured in the rule that triggered the alert. The associated rule can be viewed in the right-hand pane, just above the packet data. To display the rule, the Show Rule checkbox must be selected.

Answer 8

Alert Generation: Depending on the security technology, alerts can be generated based on rules, signatures, anomalies, or behaviors. No matter how they are generated, the conditions that trigger an alert must be predefined in some manner.

Answer 9

Rules and Alerts Alerts can come from a number of sources: NIDS HIDS Asset management and monitoring HTTP, DNS, and TCP transactions Syslog messages

Answer 10

-- NIDS Snort, Zeek, and Suricata

Answer 11

-- HIDS OSSEC, Wazuh

Answer 12

-- Assest Management and Monitoring Passive Asset Detection System (PADS)

Answer 13

-- HTTP, DNS, and TCP transcations Recorded by Zeek and pcaps

Answer 14

-- Syslog messages Multiple sources

Answer 15

Rules and Alerts The information found in the alerts that are displayed in Sguil will differ in message format because they come from different sources.

Answer 16

It is important for the cybersecurity analyst to be able to interpret what triggered the alert so that the alert can be investigated. For this reason, the cybersecurity analyst should understand the components of Snort rules, which are a major source of alerts in Security Onion.

Answer 17

Rules and Alerts Sguil Alert and the Associated Rule https://snipboard.io/ZeA4ki.jpg

Answer 18

Snort Rule Structure Snort rules consist of two sections, as shown in the figure the rule header and the rule options. The rule header contains the action, protocol, source and destination IP addresses and netmasks, and the source and destination port information. The rule options section contains alert messages and information on which parts of the packet should be inspected to determine if the rule action should be taken. Rule Location is sometimes added by Sguil. Rule Location is the path to the file that contains the rule and the line number at which the rule appears so that it can be found and modified, or eliminated, if required. Snort Rule Structure and Sguil-supplied Information https://snipboard.io/cgUSNy.jpg

Answer 19

Snort Rule Structure Component rule header alert ip any any -\> any any Contains the action to be taken, source and destination addresses and port, and the direction of traffic flow

Answer 20

Snort Rule Structure Component rule options (msg:”GPL ATTACK\_RESPONSE ID CHECK RETURNED ROOT”;…) Includes the message to be displayed, details of packet content, alert type, source ID, and additional details, such as a reference for the rule or vulnerability

Answer 21

Snort Rule Structure Component rule location /nsm/server\_data/securityonion/rules/… Added by Sguil to indicate the location of the rule in the Security Onion file structure and in the specified rule file

Answer 22

Snort Rule Structure The Rule Header The rule header contains the action, protocol, addressing, and port information, as shown in the figure. In addition, the direction of flow that triggered the alert is indicated. The structure of the header portion is consistent between Snort alert rules.

Answer 23

Snort Rule Structure The Rule Header Snort can be configured to use variables to represent internal and external IP addresses. These variables, $HOME\_NET and $EXTERNAL\_NET, appear in the Snort rules.

Answer 24

Snort Rule Structure The Rule Header They simplify the creation of rules by eliminating the need to specify specific addresses and masks for every rule. The values for these variables are configured in the snort.conf file. Snort also allows individual IP addresses, blocks of addresses, or lists of either to be specified in rules. Ranges of ports can be specified by separating the upper and lower values of the range with a colon. Other operators are also available.

Answer 25

Snort Rule Structure Snort Rule Header Structure Snort Rule Header Structure https://snipboard.io/UfKNGE.jpg

Answer 26

Snort Rule Structure Snort Rule Header Structure COMPONENTS: alert ip any any -\> any any

Answer 27

Snort Rule Structure Snort Rule Header Structure : alert the action to be taken is to issue an alert, other actions are log and pass

Answer 28

Snort Rule Structure Snort Rule Header Structure : ip the protocol

Answer 29

Snort Rule Structure Snort Rule Header Structure :any any the specified source is any IP address and any Layer 4 port

Answer 30

Snort Rule Structure Snort Rule Header Structure : -\> the direction of flow is from the source to the destination

Answer 31

Snort Rule Structure Snort Rule Header Structure : any any the specified destination is any IP address and any Layer 4 port

Answer 32

Snort Rule Structure The Rule Options The structure of the options section of the rule is variable. It is the portion of the rule that is enclosed in parenthesis, as shown in the figure. It contains the text message that identifies the alert. It also contains metadata about the alert, such as a URL that provides reference information for the alert.

Answer 33

Snort Rule Structure The Rule Options Other information can be included, such as the type of rule and a unique numeric identifier for the rule and the rule revision. In addition, features of the packet payload may be specified in the options. The Snort users manual, which can be found on the internet, provides details about rules and how to create them.

Answer 34

Snort Rule Structure The Rule Options Snort rule messages may include the source of the rule. Three common sources for Snort rules are: -- GPL -- ET -- VRT

Answer 35

--GPL Older Snort rules that were created by Sourcefire and distributed under a GPLv2. The GPL ruleset is not Cisco Talos certified. It includes Snort SIDs 3464 and below. The GPL ruleset is can be downloaded from the Snort website, and it is included in Security Onion.

Answer 36

-- ET Snort rules from Emerging Threats. Emerging Threats is a collection point for Snort rules from multiple sources. ET rules are open source under a BSD license. The ET ruleset contains rules from multiple categories. A set of ET rules is included with Security Onion. Emerging Threats is a division of Proofpoint, Inc.

Answer 37

-- VRT These rules are immediately available to subscribers and are released to registered users 30 days after they were created, with some limitations. They are now created and maintained by Cisco Talos.

Answer 38

The Rule Options Rules can be downloaded automatically from Snort.org using the PulledPork rule management utility that is included with Security Onion. Alerts that are not generated by Snort rules are identified by the OSSEC or PADS tags, among others. In addition, custom local rules can be created. Snort Rules Options Structure https://snipboard.io/u790CK.jpg

Answer 39

Snort Rule Structure Component : msg: Text that describes the alert.

Answer 40

Snort Rule Structure Component : content: Refers to content of the packet. In this case, an alert will be sent if the literal text “uid=0(root)” appears anywhere in the packet data. Values specifying the location of the text in the data payload can be provided.

Answer 41

Snort Rule Structure Component : reference: This is not shown in the figure. It is often a link to a URL that provides more information on the rule. In this case, the sid is hyperlinked to the source of the rule on the internet.

Answer 42

Snort Rule Structure Component : classtype: A category for the attack. Snort includes a set of default categories that have one of four priority values.

Answer 43

Snort Rule Structure Component : sid: A unique numeric identifier for the rule.

Answer 44

Snort Rule Structure Component : rev: The revision of the rule that is represented by the sid.

Answer 45

As user and organizational needs change, so also does the attack surface. Threat actors have learned how to quickly vary features of their exploits in order to evade detection.

Answer 46

Exploits will inevitably evade protection measures, no matter how sophisticated they may be. Sometimes, the best that can be done is to detect exploits during or after they have occurred.

Answer 47

In other words, it is better to have alerts that are sometimes generated by innocent traffic, than it is to have rules that miss malicious traffic. For this reason, it is necessary to have skilled cybersecurity analysts investigate alerts to determine if an exploit has actually occurred.

Answer 48

The Need for Alert Evaluation Tier 1 cybersecurity analysts will typically work through queues of alerts in a tool like Sguil, pivoting to tools like Zeek, Wireshark, and Kibana to verify that an alert represents an actual exploit. Primary Tools for the Tier 1 Cybersecurity Analyst https://snipboard.io/5Sj4o8.jpg

Answer 49

This classification scheme is used to guide actions and to evaluate diagnostic procedures. For example, when a patient visits a doctor for a routine examination, one of the doctor’s tasks is to determine whether the patient is sick. One of the outcomes can be a correct determination that disease is present and the patient is sick. Another outcome can be that there is no disease and the patient is healthy.

Answer 50

Evaluating Alerts The concern is that either diagnosis can be accurate, or true, or inaccurate, or false. For example, the doctor could miss the signs of disease and make the incorrect determination that the patient is well when they are in fact sick. Another possible error is to rule that a patient is sick when that patient is in fact healthy. False diagnoses are either costly or dangerous.

Answer 51

Evaluating Alerts In network security analysis, the cybersecurity analyst is presented with an alert. This is similar to a patient going to the doctor and saying, “I am sick.” The cybersecurity analyst, like the doctor, needs to determine if this diagnosis is true. The cybersecurity analyst asks, “The system says that an exploit has occurred. Is this true?”

Answer 52

Evaluating Alerts Alerts can be classified as follows: True Positive: The **alert has been verified to be an actual security incident.** False Positive: The **alert does not indicate an actual security incident.** Benign activity that results in a false positive is sometimes referred to as a benign trigger.

Answer 53

Evaluating Alerts An alternative situation is that an alert was not generated. The absence of an alert can be classified as: True Negative: **No security incident has occurred.** The activity is benign. False Negative: **An undetected incident has occurred.**

Answer 54

Evaluating Alerts When an alert is issued, it will receive one of four possible classifications https://snipboard.io/W4Zbcv.jpg

Answer 55

Evaluating Alerts True positives are the desired type of alert. They mean that the rules that generate alerts have worked correctly.

Answer 56

Evaluating Alerts False positives are not desirable. Although they do not indicate that an undetected exploit has occurred, they are costly because cybersecurity analysts must investigate false alarms; therefore, time is taken away from investigation of alerts that indicate true exploits.

Answer 57

Evaluating Alerts True negatives are desirable. They indicate that benign normal traffic is correctly ignored, and erroneous alerts are not being issued.

Answer 58

Evaluating Alerts False negatives are dangerous. They indicate that exploits are not being detected by the security systems that are in place. These incidents could go undetected for a long time, and ongoing data loss and damage could result.

Answer 59

Evaluating Alerts Benign events are those that should not trigger alerts. Excess benign events indicate that some rules or other detectors need to be improved or eliminated.

Answer 60

Evaluating Alerts When true positives are suspected, a cybersecurity analyst is sometimes required to escalate the alert to a higher level for investigation. The investigator will move forward with the investigation in order to confirm the incident and identify any potential damage that may have been caused. This information will be used by more senior security personnel who will work to isolate the damage, address vulnerabilities, mitigate the threat, and deal with reporting requirements.

Answer 61

Evaluating Alerts A cybersecurity analyst may also be responsible for informing security personnel that false positives are occurring to the extent that the cybersecurity analyst’s time is seriously impacted. This situation indicates that security monitoring systems need to be tuned to become more efficient. Legitimate changes in the network configuration or newly downloaded detection rules could result in a sudden spike in false positives as well.

Answer 62

For this reason, it is important to monitor threat intelligence to learn of new vulnerabilities and exploits and to evaluate the likelihood that the network was vulnerable to them at some time in the past. In addition, the exploit needs to be evaluated regarding the potential damage that the enterprise could suffer. It may be determined that adding new mitigation techniques is sufficient, or that a more detailed analysis should be conducted.

Answer 63

Deterministic Analysis and Probabilistic Analysis Statistical techniques can be used to evaluate the risk that exploits will be successful in a given network. This type of analysis can help decision makers to better evaluate the cost of mitigating a threat with the damage that an exploit could cause.

Answer 64

This type of risk analysis can only describe the worst case. However, many threat actors, although aware of the process to carry out an exploit, may lack the knowledge or expertise to successfully complete each step on the path to a successful exploit. This can give the cybersecurity analyst an opportunity to detect the exploit and stop it before it proceeds any further.

Answer 65

Deterministic Analysis and Probabilistic Analysis Probabilistic analysis estimates the potential success of an exploit by estimating the likelihood that if one step in an exploit has successfully been completed that the next step will also be successful. Probabilistic analysis is especially useful in real-time network security analysis in which numerous variables are at play and a given threat actor can make unknown decisions as an exploit is pursued.

Answer 66

Deterministic Analysis and Probabilistic Analysis Probabilistic analysis relies on statistical techniques that are designed to estimate the probability that an event will occur based on the likelihood that prior events will occur. Using this type of analysis, the most likely paths that an exploit will take can be estimated and the attention of security personnel can be focused on preventing or detecting the most likely exploit.

Answer 67

Deterministic Analysis and Probabilistic Analysis In a deterministic analysis all of the information to accomplish an exploit is assumed to be known. The characteristics of the exploit, such as the use of specific port numbers, are known either from other instances of the exploit, or because standardized ports are in use. In probabilistic analysis, it is assumed that the port numbers that will be used can only be predicted with some degree of confidence. In this situation, an exploit that uses dynamic port numbers, for example, cannot be analyzed deterministically. Such exploits have been optimized to avoid detection by firewalls that use static rules.

Answer 68

Deterministic Analysis and Probabilistic Analysis The two approaches are summarized below. Deterministic Analysis - For an exploit to be successful, all prior steps in the exploit must also be successful. The cybersecurity analyst knows the steps for a successful exploit. Probabilistic Analysis - Statistical techniques are used to determine the probability that a successful exploit will occur based on the likelihood that each step in the exploit will succeed.

MODULE 26 - CERTIFICATION REVISION PREPARATION Flashcards

(92 cards)